The Becsta.NET - Home Intrusion Detection

One of the failings of a filtering firewall is that it (generally) doesn't look at what is in the individual packets - only what the source, destination, and port values are. The filtering firewall (generally) doesn't have the smarts to look at the application layer. This is mostly correct behaviour, as a firewall which does have smarts to look at application layer stuff is generally quite slow at filtering. Firewalls which have been built using "stateful inspection" technology have the smarts to look at some application layer traffic (like HTTP and FTP), and filter based on the outcome of such inspections, but they don't know about all of the protocols being used.

Most of the firewalls that utilise stateful inspection are expensive - well beyond the reach of a home network user.

A packet filtering firewall and an IDS should, therefore, suffice for most home networks - the firewall stops unauthorised connections at the network layer, and the IDS detects and responds to attacks at both the application and network layer. The only investment required is time.

What this page attempts to do is provide the basic steps to implement an IDS onto a home network gateway machine, so that the home user has some visibility of hack attempts. So sit back, relax, and enjoy the installing experience...

IDS Types

I believe that there are three types of IDS (Intrustion Detection Systems):

1. Host-based IDS. This type of IDS involves utilising products that are installed onto a host which detects changes in the operating system and applications. Tripwire is one such product, which calculates various signatures for each file on the system, which can then be compared against a base set of signatures - any differences will be reported on.
2. Network-based IDS. This type of IDS involves running an IDS on a host or switch which listens to the traffic passing over a network segment, comparing the packets to "signatures" within the IDS' databases. If a packet's signature matches, an alert is generated. An IDS which fits this category is Snort, an open-source network-based IDS.
3. Vigilance-based IDS. This type of IDS involves using one's eyeballs to look around a system from time to time, and physically checking to see if things are operating "as expected". Basically, patterns are determined, and when an event happens that falls outside of the pattern, you investigate it.

Network-based IDS's will not work in high-volume environments, because scanning packets and matching them against a database takes time - far too much time. There is also the issue of how to interface the IDS to a response mechanism on firewalls and routers. For a home network, high-volume is not an issue. Because the IDS and firewall will be residing on the same host, interfacing is a simple matter of having a script monitor the IDS logs, and write firewall rules "on the fly". Denial of service issues caused by forged packets is not an issue if a little bit of smarts is put into the script.

Snort IDS

Snort is an open-source network-based IDS, written by Martin Roesch, which inspects packets flowing over a network, and compares them to a list of attack "signatures", writing a report to the host's syslog. It can detect all sorts of attacks, ranging from buffer overflows, CGI exploits, port scans, to fingerprinting. The attack signatures are contributed by users of Snort, and are stored in two locations, on the Snort web site, and the WhiteHats web site, so you can say the signatures are open-source too. The signatures are searchable on these web sites, so you can see exactly what a particular signature is looking for.

Requirements

I'm going to assume that the system which we will be installing and configuring Snort on is a RedHat Linux system.

Requirements for installing and configuring Snort IDS are as follows:

• Root access to the machine
• Latest version of libpcap installed. Current version is 0.6.2
• Kernel version 2.2 series or higher
• External interface name, which will possibly be ppp0
• Internal network address range, which could be 192.168.1.0/24

Downloading Snort

My favourite spot to get Snort from is the ArachNIDS Center, located on the Whitehats web site. Download the source RPM. While you're at it, download the vision.rules.gz file, which is the compressed signatures file for Snort. I'll get to the signatures file later. As of writing this page, the current version of Snort is 1.7.

Compiling Snort

* It's very easy to compile the source RPM. Make sure you have libpcap installed before attempting to compile Snort! Log in or su to root, and then issue the following command:

# rpm --rebuild snort-1.7-1.src.rpm

The RPM system will go off and compile snort, and package it into an i386 RPM, stored in /usr/src/redhat/RPMS/i386

Installing Snort

It is very easy to install Snort. The difficult part is configuring the beast.

* To install Snort, (as root still) do the following:

# rpm -ivh /usr/src/redhat/RPMS/i386/snort-1.7-1.i386.rpm

You should see snort being installed.

With the RPM package, Snort itself is stored in /usr/sbin, and the configuration files are stored in /etc/snort. The Snort logs are stored in /var/log/snort.

* Unpack the vision.rules.gz file into the /etc/snort directory:

# cd /etc/snort && gunzip /root/vision.rules.gz

* Snort comes with an oldish set of signatures. If you have a look in the /etc/snort directory, there will be lots of signature files in there (the "lib" files). Some of them we won't need, some of them we will. The way to specify which signature files to read, as well as providing other information to Snort is through configuring the /etc/snort/snort.conf file.

Configuring Snort

This is the fun part - "getting your hands dirty" by modifying config files...

* Open up the /etc/snort/snort.conf file into an text editor (again as root).

* Starting from the top of the file, there are several "var" entries which need to be modified to reflect your home network configuration:

• "var HOME_NET 192.168.1.0/24" - specify the internal network address range for your home network.
• "var EXTERNAL_NET any" - specify the external network address range (generally set to "any")
• "var EXTERNAL any" - set the same as above "EXTERNAL_NET" entry. The duplication is due to the combination of snort rules from two different sources - "EXTERNAL" is referred to throughout the vision.rules file.
• "var INTERNAL 192.168.1.0/24" - set the same as "HOME_NET" above. Again, the diplication arises due to the combination of snort rules from two different sources. The "INTERNAL" setting is referred to throughout the vision.rules file
• If there is a line referring to "DNS_SERVERS", comment it out by putting a # (hash) mark at the start of the line.

* The next set of configuration items are "preprocessor" items, and generally don't need to be modified. However, there is one line which should be modified, and this is the "portscan-ignorehosts" directive. Comment it out, as we want to log all portscans - even those originating from internal hosts. On my system, the portscan-ignorehosts directive (as supplied) was set to DNS_SERVERS. Please explain??

* The next section contains "include" directives, which tell Snort the filenames to read the attack signatures from. There can be any number of "include" directives, but the more you have, the slower the scanning becomes. Looking inside each of the files will give you an idea of the type of signatures found there - comment out the lines referring to attack signatures which do not apply to you.

For instance, I have the "webcf-lib", "webiis-lib", and "webfp-lib" include directives commented out, as these files contain signatures for Cold Fusion, IIS, and FrontPage exploits. It would be nice to know if someone is trying to use those exploits against my gateway, but I don't run these services, so they're not going to get anywhere.

* To finish the modifications to the snort.conf file, we need to add an include directive for the vision.rules file to the end of the file:

include /etc/snort/vision.rules

* Save the modified snort.conf file.

Modifying Startup Scripts

We haven't finished yet!

* The next major step is to modify the /etc/rc.d/init.d/snortd startup script to specify the external interface name. When Snort starts up, it needs to know which interface to set promiscuous mode on. Edit the script, and change the "INTERFACE" entry to your external interface name. For dialup's, it's usually ppp0, so the line would read "INTERFACE=ppp0". Save the changes

Running Snort

Because Snort puts an interface into promiscuous mode (so it can read all of the packets on a network segment), I've found that I can only get Snort to run when the interface is up. For an ethernet segment, this shouldn't be much of a problem, but for a PPP session, it is a problem.

Thus, one way to get Snort to start up after the PPP session has been established is to hook into the PPP interface up scripts. In Redhat, this is usually the /etc/ppp/ip-up.local file. Add a line to the end of this file (just before the "exit 0" line) with the following:

/etc/rc.d/init.d/snortd start

Then save the file. Make sure that the "ip-up.local" file has execute permissions set.

That's it! Once the PPP link starts up, snort should start up, and begin to log any suspicious attempts into the /var/log/snort directory.

For an ethernet interface, it should be sufficient to make a link from /etc/rc.d/rc2.d/S99snort to /etc/rc.d/init.d/snortd.

Blocking Attacks

As far as I am aware, Snort itself doesn't have the ability to stop attacks - it only detects them. There are several utilities out there which "hook" into Snort to provide this functionality, Guardian being one of them. This utility (wich can be found on the Whitehats web site) is a script which starts up after Snort, and reads the Snort logs to determine whether an attack is occuring, and from where. It will then write an ip-chains rule to block traffic from the source IP address.

Guardian needs to be configured, so it knows which IP addresses it shouldn't block, otherwise it could write an ip-chains rule that blocks off access from everywhere, causing a denial-of-service.

Conclusion

Snort will provide a higher awareness level of attacks, giving you some options to defend against these attacks. It will not stop attacks from happening, and it will not stop attacks from succeeding. With a bit of smarts, the functionality can be extended by using other software or scripts to close attacks as they occur. However, because the signatures being relied upon can be quite old, and need to be constantly updated, it will not detect recent exploits. An IDS and blocking mechanism does not excuse you from failing to install patches and updates - defence in depth is a wonderful thing.

It is possible to stop script-kiddies, but it's not possible to stop determined, skilled adversaries.