A variety of intrusion detection systems (IDS) are on the market, ranging from enterprise-level, managed network monitoring solutions to simple on-the-host logging systems. There is also a distinction between an intrusion prevention system (IPS) and an IDS. An IPS goes one better than the IDS and attempts to block an attack in progress, whereas the IDS attempts to log the attack and optionally notify a responsible party to employ an incident response plan.
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 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 answer questions 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 zero-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 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 because of 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 most commonly used sniffers available today -- used by networks large and small the world over. It has continually updated signatures for a massive number of vulnerabilities, a huge user base, commercial support, and excellent documentation available online as well as in print. Initially used 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 (http://www.sourcefire.com). Sourcefire now offers commercial support and other services based on Snort. Though it also employs full-time developers for Snort, it 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 because 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!
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 because 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 to alert an administrator that something is up. Snort on an IPCop box is placed in an excellent position to alert on any malicious traffic 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 requires users to register if they want to download updated signatures. We really do want to have updated rules, so we should be sure to register with Sourcefire.
Once registered, we select each interface we want to monitor by marking the corresponding checkbox. The authors' 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 Web site. 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.
About the authors:
Barrie Dempster is a Senior Security Consultant for NGS Software Ltd., a world-renowned security consultancy. He has a background in Infrastructure and Information Security in a number of specialized environments across several continents. He has been involved in a variety of projects from the design and implementation of Internet banking systems to large-scale conferencing and telephony infrastructure, as well as penetration testing and other security assessments of business-critical infrastructure.
James Eaton-Lee is a consultant specializing in Infrastructure Security. He has worked with IT in ISPs, manufacturing firms and call centers. James has been involved in the integration of a range of systems, from analog and VoIP telephony to NT and AD domains in mission-critical environments with thousands of hosts, as well as Unix and Linux servers in a variety of roles. For a number of years, James has been a strong believer in the relevancy and merit of Open Source and Free Software and, wherever appropriate, uses it for himself and his clients.
