Peering Over the Firewall

Using Snort and a homemade read-only cable to follow network traffic

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:

Figure 1. LAN w/Broadband Router

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.

Figure 2. LAN w/Broadband Router and Snort Cable

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.

Figure 3. Snort Read-Only Cable Wiring Diagram

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.

Figure 4. Snorting Inside the LAN

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Peering Over the Firewall

Anonymous's picture

Excellent article. It's hard finding technical (but not too technical!) information for the user who's in between medium and advanced. I've been trying to find an article like this for weeks.

Re: Peering Over the Firewall

Anonymous's picture

Excellent article. It's hard finding technical, but not too technical, information for the user who's in between medium and advanced. I've been trying to find an article like this for weeks.

Re: Peering Over the Firewall

Anonymous's picture

Excellent info, many thanks!

By the way, network wiring definitely has color standards. Here's a good overview - BlackBox Premise Wiring Info.

Re: Peering Over the Firewall

Anonymous's picture

After I wrote the article, I found another writeup that gave the color codes. I had just checked several commercial cables and they didn't match. I may see if they match the two different orderings given in your link.

Re: www.linuxcad.com

Anonymous's picture

Cute! spam.

Re: Peering Over the Firewall

Anonymous's picture

This is what I look forward to every time I come to this site !
Its fresh, to the point and not too technical.

Re: Peering Over the Firewall

Anonymous's picture

I second that...

Re: Peering Over the Firewall

Anonymous's picture

Wonderful Article !

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix