Do you feel your network is safe? Do you really know what is happening on your network right now? Once upon a time, there were network administrators who thought that the solution to their security was a simple firewall. In the past few years, we have verified that this is not true anymore. The need for some element that could alert and inform administrators about something strange in near real time resulted in intrusion detection systems (IDSes). In this article we discuss the types and models of IDSes: the host-based intrusion detection system (HBIDS), the network intrusion detection system (NIDS) and the new concept of hybrid-IDS. How to analyze the data generated and how to create signatures (the patterns that identify the attacks) also are discussed, as well as some examples of IDSes for Linux, like the open-source NIDS Snort.

An IDS is a program that tries to detect strange packets and behaviors that may compromise a network. The first IDS was the host-based IDS, but the one that really got the market was the NIDS, the network-based. There is usually some software or appliance, called a sensor or agent, that has one or two network interfaces (as we will see later, it may work perfectly with one network interface), which works in promiscuous mode. In other words, it will catch all the packets that come to the interface and not just those with its particular destination IP address. In this way, the IDS can analyze all the packets that cross the network, check if they contain, for example, any suspicious strings and then decide how to perform a reaction, such as interacting with the firewall to create new rules to block the IP address, sending pager/e-mail alerts to the security administrator and so on. One important topic about the NIDS is where to deploy the sensor, inside or outside the firewall. I like to quote an interesting passage about this from SANS' GIAC Director Stephen Northcutt's book, Network Intrusion Detection: An Analyst's Handbook:

Where is the best place? We may have a long discussion about this since there are defenders of both points, but undoubtedly all agree that the best option is the use of sensors inside and outside the firewall.

To understand the IDS better, first we need to know how it works. Basically we have two models of IDSes: the misuse or signature-based model and the anomaly model.

The misuse or signature-based is the most-used IDS model. Signatures are patterns that identify attacks by checking various options in the packet, like source address, destination address, source and destination ports, flags, payload and other options. The collection of these signatures composes a knowledge base that is used by the IDS to compare all packet options that pass by and check if they match a known pattern. Later we will discuss a Nimda worm signature example in the Snort IDS.

The anomaly model tries to identify new attacks by analyzing strange behaviors in the network. To make this possible, it first has to “learn” how the traffic in the network works and later try to identify different patterns to then send some kind of alert to the sensor or console. The disadvantage of this model is that you will never know if your network has produced all types of behavior in the IDS learning phase, so it may cause a high number of false-positive alerts.

False-positives are false alerts produced by the IDS to inform of an attack when in fact it is just nonconfigured variables or an application that sent some packet to a different port than usual, instead of a real backdoor, for example. To solve this, the security administrator has to observe the alerts generated by the IDS for some time and then fine-tune it.

Host-based intrusion detection systems usually are located in servers and only detect events related to the machine in which it is installed. The main purpose of the HBIDS is to avoid changes that may compromise the machine and detect malicious queries. Examples of changes that can prove the importance of this kind of IDS are web defacement and rootkits installed in the machine to attack other machines.

Rootkits are packages installed in the compromised machine by the cracker, which contain files used to open backdoors, erase log files to hide their presence and replace binaries like ps and netstat, and also hide any dæmon or open port.

Besides this, the HBIDS has the function of trying to detect attacks before they happen, analyzing logs to point out strange behaviors and also detecting port scans.

Tripwire is an example of an HBIDS for Linux [see Michael Rash's Paranoid Penguin, LJ February 2002 for an open-source alternative to Tripwire]. It can be identified as an HBIDS because it fills in for the lack of file-integrity detection tools. With Tripwire, the user can define, in a configuration file, a set of files that he or she wishes to protect against changes, and then Tripwire uses a checksum of these files and attributes. In the case of any changes, it can send alerts to the system administrator. The default configuration file provides a good starting point, but the user also must customize it to reduce the chance of false positives. Pay special attention to the log files. It doesn't make sense to include the log files into the set of files that you select to be checked, since you know that they will grow as soon as any event happens, such as a login.

Tripwire can be used together with the cron scheduler dæmon. In this mode, users can automatize the process and define wherever they want to run it.

PortSentry [see also “PortSentry” by Anthony Cinelli on the LJ web site, /article/4751] is part of the Abacus Project, from Psionic Software, whose goal is to “produce a suite of tools to provide host-based security and intrusion detection free to the internet community”. It is an important kind of HBIDS because it detects packets addressed to the host and can be used with TCP Wrappers and iptables. This type of detection is useful because a port scan is often a precursor to an attack. PortSentry can detect TCP and UDP port scans, making you aware of other hosts that run a service in the scanned port. The next step is to verify for new patches or updates, or even configure it to create ACLs (access control lists) to block future connections from the host scanner, using TCP Wrappers. It also can create rules in the firewall, i.e., iptables, to drop everything from the host scanner. The following is an example of PortSentry alerts from Syslog:

Dec 9 03:03:17 mobile portsentry[701]: attackalert:
  TCP SYN/Normal scan from host:
  200.185.61.132/200.185.61.132 to TCP port: 111
Dec 9 03:03:17 mobile portsentry[701]: attackalert:
  Host 200.185.61.132 has been blocked via wrappers
  with string: "ALL: 200.185.61.132"
Dec 9 03:03:18 mobile portsentry[701]: attackalert:
  Host 200.185.61.132 has been blocked via dropped
  route using command: "/sbin/iptables -I
  INPUT -s 200.185.61.132 -j DROP"

Swatch is a log watcher that observes the logs and alerts the security administrator about predefined strings found in the log file, i.e., /var/log/messages. In the example below, I created a very simple Swatch configuration file and chose to define the strings “snort” and “portsentry” and send the alert to screen in different colors (and with a beep) every time that it finds these strings:

watchfor /snort/
echo red
bell
watchfor /portsentry/
echo blue
bell

I also could ask Swatch to send an e-mail or execute a command when it finds something. As the result of the previous Swatch config file, I received these alerts:

Dec 9 03:22:53 flamengo snort[3268]: [1:1256:2]
  WEB-IIS CodeRed v2 root.exe access [Classification:
  Web Application Attack] [Priority: 1]:
  {TCP} 200.31.36.11:2153 -> 200.204.68.154:80
Dec 9 03:03:17 mobile portsentry[701]: attackalert:
  TCP SYN/Normal scan from host:
  200.185.61.132/200.185.61.132 to TCP port: 111

LIDS stands for Linux intrusion detection system. It is a project that tries to give Linux some extra security features deployed as kernel patches. In these features we can include file and process protection and port-scan detection. The first two deserve a little more explanation. File and process protection will guard even against root superuser changes. This is very useful because when a cracker exploits a bug in your system, such as a buffer overflow, that person will have root access that permits him or her to do almost anything, such as install rootkits, change logs, erase your HTML pages, etc. With these features you can define ACLs to control files and include passwords to access/change them, avoiding changes from unauthorized users, even root. The same is valid for process because it will protect your system from altered binaries/dæmons. Another good feature is that it offers a port-scan detector in kernel space.

Network intrusion detection systems are the kind of IDSes responsible for detecting attacks related to the network. One point of discordance is where it should be deployed. You may encounter network topology where it is before a firewall, and you may find it after a firewall. As I said before, there are good arguments for both; it depends on your needs. In these examples I will use the open-source Snort.

Snort was created by Marty Roesch and currently has over 1,000 rules used to detect attacks like simple port scans and even new attacks such as the SSH CRC32 exploit [see “Snort: Planning IDS for Your Enterprise” by Nalneesh Guar on the LJ web site at /article/4668]. One of the greatest advantages of Snort is its flexibility to create new rules on demand. Whereas with some IDS vendors you have to wait until they release new packages, you may customize and create signatures as soon as the attacks are exposed. One good example was the wu-ftpd exploit in mid-December 2001. Just a few hours after the release of the exploit, the Snort filter was released on security mailing lists. Snort also has the capability to interact with firewalls, i.e., Check Point FireWall-1, using the OPSEC feature or using other plugins to interact with Linux's iptables. Besides the fact that Snort has a large signature database and is mainly based on the misuse model, it offers a beta feature to introduce it to the anomaly model. This feature, called SPADE, does a statistical analysis of the data it gathers and tries to find out what the ordinary behavior is. As with many open-source applications, Snort has a lot of additional applications that you may want to use together.

One nice application from Silicon Defense is SnortSnarf, which creates HTML reports based on the data gathered by Snort.

Snort also works perfectly well with just one network interface card (NIC). Instead of other NIDSes, which need two NICs, one to gather the data and other to be used by the administration interface, Snort can work with one NIC in the promiscuous mode and also can be used to administrate it, inserting new rules or upgrading it.

More recently, another concept of IDS is becoming popular. It is the hybrid intrusion detection system. Marcus Ranum, founder of NFR (Network Flight Recorder, Inc.), wrote that “The shim-type hybrid IDSes are an interesting blend of the strengths and weakness of HBIDSes and NIDSes.” This means that it has most of the features of the NIDS but on a per-host basis. This has a lot of advantages, as it will try to detect attacks to the host exclusively, and the traffic that it will analyze will be only packets with the host destination IP address. The disadvantage of this kind of IDS is that it needs to be deployed in every host.

Prelude is an example of a hybrid-IDS. It is divided into two different parts: the sensor, called Prelude NID, that is responsible for the packet capture and analysis, and the report server, used by the sensor to report an intrusion attempt. Prelude has an interesting feature that deserves some comments: the capability to read rules from Snort IDS. In other words, it has a complete rule set ready to use. From its web site, it is also capable of reading rules from any NIDS. Prelude was built with the cluster concept in mind. This explains the idea of deploying information into a different machine called a report server, which has the job of translating all the information received into a user-friendly format, such as HTML.

As we learned before, signatures are attack patterns. It's important to understand how they work, so we can create them on-demand or when a new exploit is discovered. In our examples, we will see how Snort handles its signatures. In the second half of 2001 we observed new and powerful worms on the Net, such as Code Red, Code Red II and Nimda. When these attacks started to happen, Linux users (and I was one of them) felt very lucky because the worms mainly were attached to Microsoft's IIS (Internet Information Server). These worms had some particular patterns, for example, trying to access the cmd.exe file through Microsoft's IIS. By knowing this, we easily could create a Nimda Snort rule as mentioned in the section “IDS types and Models”:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80
  (msg:"WEB-IIS cmd.exe access"; flags: A+;
  content:"cmd.exe"; nocase;
  classtype:web-application-attack; sid:1002; rev:2;)

Okay, but what does it mean? Snort rules are nothing more than sequential parameters divided in two sections that we use to inform Snort of what we want it to pay attention to. The first section is called rule header and includes everything before the first brackets. The first parameter in this header tells Snort what to do when the packet matches this rule—in this case, “alert” indicates that Snort will generate an alarm and then log the packet. The second parameter tells Snort what kind of protocol we want—in this case, just TCP. The next five parameters indicate the source IP address and port, direction of the packet, destination IP address and port. In this way, we know that a packet from any address outside of our network, with any source port, going to an IP address in our internal network at port 80 (usually web servers listen to this port) will be checked by the internal parameters of the rule, called rule options. The rule option section contains alert messages and information about which parts will be checked in the packet, and then with the result of this inspection, the appropriate action will be taken.

Rule options in our example:

In the Snort Users Manual you can find more than 30 rule options that you can use to satisfy your needs. Too complicated? No, it is not! Let's try to create a simple rule to alert any porn web access attempt from your network using the few rule options above:

alert tcp $INTERNAL_NET any -> $EXTERNAL_NET  80
  (msg: "Web Porn Access Attempt"; content:"Free porn";
   nocase; flags:A+);

A port scan to a service like portmap (port 111), which is known to have various exploits, would be alerted by PortSentry:

Dec 9 03:03:17 flamengo portsentry[701]: attackalert:
  TCP SYN/Normal scan from host:
  200.185.61.132/200.185.61.132 to TCP port: 111

Learning how to interpret log files is one of the most important things that an intrusion or security analyst must learn in order to decide what action to take in a given situation. The excerpt from the PortSentry alert above was obtained from the syslog file. This alert states that on December 9 at 03:03, the host called flamengo, which has PortSentry installed, detected an SYN-flag Normal port scan in the TCP port 111 which, in general, runs the service portmap, from host IP 200.185.61.132.

A firewall is a primary security element in a network, but it will not detect attacks on a service that is already opened, such as an attack to your DNS or web server. An IDS by itself will not solve all your problems as a security element, but if you customize it for your needs, it certainly will help alert you to strange behaviors and unauthorized attempts to your host or network. With this information, you should contact the administrator of the network in which the intrusion's IP is located and then inform them of what is going on. Being in contact with the security community is also the best way to keep up to date on new attacks and the signatures to detect them. Be aware—install an IDS!

Resources