Introduction to IDS – IPCop

The added benefit of an IDS is that we can see what is passing through our network and attempt to isolate any traffic that appears malicious. This is important as it's a function many firewalls lack (except those with layer-seven support, which are termed application-layer firewalls). Since firewalls work at the lower layers of network communication their filtering rules are generally limited to IP addresses, ports, time of day, and only a few other criteria. If we have a firewall that isn't looking into the payload of a packet and only making decisions based on packet headers, it's far from inconceivable to say that these devices may allow some malicious traffic to pass.

The role of our IDS is to do deep inspection of these packets looking at the data contained within and make decisions such as: "Does this look like the Code Red worm?", "Is this an attempt at a buffer overflow in our sendmail server?", or "Has one of our users just been exploited by the latest 0-day WMF exploit?". It's quite valuable for an administrator to be notified of any packets that throw up these warning signs in the IDS, as we can then use this information to look further into the status of our network to see if we have a major issue to contend with, although often these warnings are false alarms. We can think of an IDS as an early warning system that something might be going on that requires our attention. In an attempt to protect our network, this is very valuable information to have!

IDSs can be further categorized as NIDS or HIDS, the difference being that the former watches the network and the latter monitors the host. This is important when choosing an IDS as we have to be sure of what exactly we are monitoring.

For example, many administrators won't employ a HIDS on Windows or Unix boxes due to their built-in abilities to log extensively (event logs/syslog), and therefore prefer to monitor the traffic on the network for signs of malicious behavior. This can also be more reliable than host monitoring as it's hard to trust the logs of a compromised host.

In the case of IPCop what we have is a built-in NIDS on our firewall, pre-configured and ready to use with the absolute minimal configuration, the Snort intrusion detection system.

Snort is the IDS included with IPCop, and is one of the best-known and commonly used sniffers available today and used by networks large and small the world over. It has continually updated signatures for a massive number of vulnerabilities, a massive user base, commercial support, and excellent documentation available online as well as in print. Initially as a sniffer Snort was quite good and was linked to its slightly older relative TCPDUMP. Eventually Snort was expanded and become known as more of a NIDS than a sniffer (many of Snort's users are unaware of its sniffing capabilities and use it purely as an IDS).

As Snort became very popular, Martin Roesch decided to start a company based on Snort to offer security services based on the expertise that he had as a Snort developer. This led to the creation of Sourcefire ([HYPERLINK@www.sourcefire.com]). Sourcefire now offers commercial support and other services based on Snort. Though it also employs full time developers for Snort, it still remains an open-source product, and hence can be provided with IPCop. The IPCop developers add to this a pre-configured Snort system with very easy-to-use and simple management options in the IPCop interface.

How Does an IDS Work?

NIDS in general, and Snort specifically, are run on devices that have the ability to monitor as much of the network as possible, generally on or near a gateway device, (as in the case of IPCop) or on some sort of monitoring port on a switch (SPAN/Mirror ports). The NIDS then sets up the network card or cards on the device to work in promiscuous mode meaning they will pass packets up through the network stack whether or not they are destined for the machine. This is important as a NIDS will often be monitoring machines other than itself. The NIDS on the host will then take these packets and have a look at the data payload (and sometimes the headers as well) to see if it notices anything malicious. This may sound like artificial intelligence as the NIDS just sits there thinking to itself about packets passing by; it's actually quite a lot simpler than that!

Every day exploits, viruses, worms, spyware, and other malicious software generate network traffic, and this traffic often has patterns specific to the piece of software in use, a specific string in an exploit, specific hosts it contacts, and specific options in the TCP/IP headers. There are many people watching their networks and as they notice something that looks strange they document it and generally seek advice from their peers to see if anyone notices something similar. Quite shortly afterwards, if malicious activity is detected, someone will write a signature for their favorite IDS and in many cases for a few IDSs all at once. Based on these signatures the IDS detection engine will decide whether to flag a packet as possibly malicious.

These are rarely 100% accurate as they can and will provide false positives or negatives. This detection is designed as an extra layer of defense and cannot say for sure that a network has or has not been compromised. What can be done is alerting of an administrator that something is up. Snort on an IPCop box is placed in an excellent position to alert on any malicious behavior attempting to pass through the firewall to protected interfaces—or even between protected interfaces.

Using Snort with IPCop

Setting up Snort with IPCop is a very straightforward process. SourceFire require users to register if they want to download updated signatures. We really do want to have updated rules, and so we should ensure we register with SourceFire.

Once registered, we select each interface we want to monitor by marking the corresponding checkbox. The author's preference is to monitor all interfaces at this point and filter later when monitoring the logs. We should also choose SourceFire VRT rules for registered users unless we have a paid for subscription that allows us access to the subscription rules. Then we enter our Oink Code as obtained from the Snort website. We can now download the most up-to-date rules. That's it! We have now, by filling in a very simple form, configured a NIDS for our network. Now surely we are secure!

This article has been extracted from the book, "Configuring IPCop Firewalls: Closing Borders with Open Source ". For further details please visit [HYPERLINK@www.packtpub.com]