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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script