Peering Over the Firewall
When our home LAN graduated to a 24x7 Internet connection, my Linux box became the firewall and the router. I liked the ability to customize the firewall, and by using Snort I could keep an eye on the barbarians at the gates. However, I could not experiment much without disrupting the entire household's Internet access. Adding a DSL/cable broadband router (see Resources) with a built-in firewall took my computer off the critical path and allowed me to experiment with various configurations and operating systems without domestic discord. But, I missed seeing what was going on. I do not want the first sign of someone attacking me to occur when they appear inside the firewall.
Intrusion detection systems (IDSs) are standard practice in the corporate world, but they easily can cost more than an entire home network, including computers. With some free software (Snort), a cheap Ethernet hub and a custom cable, you can have an IDS that is almost as good as a commercial system. The major lack is the pretty reports and graphs necessary to justify a big salary.
A typical home LAN with a broadband router is shown here:
Most broadband routers include a multiport switch. A switch sends packets to only the destination port. In contrast, a hub is a simple repeater and sends each packet to all other ports. With a switch, each computer sees only its own traffic, so computer A cannot monitor attacks on the other computers. Figure 2 shows how to use a hub to peer around the router and see all packets.
Residential cable and DSL modems run at 1-2Mbps, so a single speed 10Mbps Ethernet hub is fine. These can be found used, reconditioned or dumped as obsolete for as little as $10 at discount outlets.
A packet sniffer, such as Snort, running in promiscuous mode on the second network interface card (NIC) of computer A can see all traffic, including those packets blocked by the firewall. To keep the second NIC from responding to any IP packets, it needs to be brought up with no IP address, that is, ifconfig eth1 up. If the second NIC already is assigned an IP address, taking it down and bringing it back does not always delete the IP address. Instead, take the interface down, remove the driver module (rmmod ne2k-pci) and bring it back up. If the driver is compiled into the kernel, you probably have to reboot here. Some system configuration tools, such as SuSE's yast, do not let you configure an Ethernet interface without an IP address. In this case, you have to edit the necessary files by hand.
No IP address usually is adequate stealthiness, but the second NIC still can respond to low-level, layer 2 requests, such as ARP requests. To make it totally invisible, use a read-only cable. The wiring diagram is in Figure 3. These cables can be made easily with a length of Cat5 cable, two RJ45 connectors and a crimping tool. First, strip off a half inch of the outer insulation, and insert each wire into a slot on the RJ45 connector and crimp. There does not seem to be a consistent standard for which pin gets which color wire, so eyeball a commercial cable and follow its example. Label this the hub end.
Next, cut two inches off the other end of the cable to get a bit of wire to make the jumper between pins 1 and 2 of the Snort end. You can do this by bending it in half and shoving it in the RJ45 connector. Again, strip a half inch off the outer insulation. Strip a quarter inch of the inner insulation off the wires from pins 1, 2, 3 and 6. With care and solid conductor Cat5 cable, you can push the wires from pins 1 and 3 into the slot for pin 3 and the wires for pins 2 and 6 into slot 6. Be sure all wires are inserted fully into the slots, then crimp the end. See Resources for links to pictures of the result. (A word of warning: trying this with stranded wire is a task for masochists.)
If your cable is stranded or if you can't find a crimper and are handy with a soldering iron, simply cut the patch cord in the middle and connect the appropriate wires together. Use heat shrink tubing to insulate and protect your handiwork.
When you plug the cable into the NIC and hub, the status LEDs should light in their usual pattern. If not, check and correct your work. Next, put Snort in packet dumping mode with snort -d -p -v -i eth1. You now should see traffic coming from both directions.
Finally, edit snort.conf and start Snort in dæmon mode:
snort -D -i eth1 -p -c /etc/snort.conf
Most home broadband connections have dynamic IP addresses, but they don't change often. Therefore, configuring HOME_NET in snort.conf can be done by hand each time the address changes. An alternative is to run the whois program on your external IP address. It may tell you the IP address range(s) owned by your ISP. Using this address/netmask for HOME_NET makes for less work, but then Snort may ignore attacks from your electronic neighbors because they are considered to be part of your LAN.
With this setup, I again could see the script kiddies rattling the door knobs and the various worms, including Slammer, trying to propagate.
When I upgraded to Snort 1.9.1 and its more extensive attack signatures, I started seeing a P2P GNUTella alert. I don't use P2P, so this was suspicious. The router does network address translation (NAT) between the internal private addresses and the single external IP address, hiding the culprit. By moving the hub inside the firewall, as shown in Figure 4, you can see the untranslated internal addresses. You have to change HOME_NET in /etc/snort.conf from the external IP address to the internal range, probably something like 192.168.0.0/16, to do this.
Before you move cables around, check whether your broadband router supports configuring a spanning port to get all traffic, that is, it is not switched. If so, you can leave the hub where it is and plug Snort into the spanning port.
The culprits turned out to be AmphetaDesk (an RSS headline aggregator) and PGP/GPG key fetches. The P2P GNUTella signature is overly broad; it flags any HTTP GET request to a non-standard port (not port 80). Below are some rules you can add to local.rules to eliminate the false positives:
pass tcp $HOME_NET any -> $EXTERNAL_NET !80 (flow:to_server,established; \ content:"User-Agent\: AmphetaDesk"; offset:10;) pass tcp $HOME_NET any -> $EXTERNAL_NET 11371 (flow:to_server,established; \ content:"GET /pks/lookup?op=get&search="; offset:0;)
In conclusion, Snort makes it easy to tell what's going on. To stay on top of what's going on, update your Snort rules frequently.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development