Intrusion Detection with the Snort IDS
Snort provides an array of rules for filtering out unwanted traffic. Snort rules are mostly easy to understand and customize. Each rule is separated into two sections: the rule header and the rule options. The header describes what message to display when the rule is triggered. The option contain keywords that tell Snort how to inspect the packet and references for research and information on the message to be displayed if an alert is triggered.
In the following rule:
alert tcp $EXTERNAL_NET any ->$HTTP_SERVERS $HTTP_PORTS(msg:"WEB-IIS unicode directorytraversal attempt"; flow:to_ server,established;content:"/ ..%c1%1c../"; nocase;reference:cve,2000-0884; reference:nessus,10537;classtype:web-application-attack; sid:982; rev:13;)
The rule header consists of the command alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS. In brief, this header tells Snort to alert when the rule is triggered and to examine only traffic coming from external networks (any source port) to internal http servers (on configured http ports). Although the alert statement at the beginning might seem obvious, at times you might only want to log the traffic into the database, or even do some more advanced stuff with dynamic and activate actions. If you're using Snort as an in-line IPS, you can also use the Drop, Reject, or Sdrop options to manage unwanted traffic. Snort can check TCP, UDP, IP, or ICMP packets, depending on your requirements. If the rule specifies TCP, and a UDP packet comes in, even if the rest of the rule header and options match perfectly, Snort will not perform any action. This rule specifies TCP, which is pretty standard for http traffic.
The next part of the header calls on some variables that are already configured into the Snort configuration file. The rule will examine traffic arriving from the $EXTERNAL_NET variable you set in the snort.conf any source port number. The -> denotes the direction of traffic. In this case, the rule applies to anything coming from $EXTERNAL_NET to the $HTTP_SERVERS on $HTTP_PORTS. These variables are defined in the Snort configuration file.
The direction of traffic is very important. In this case, any replies coming back from the $HTTP_SERVERS will be ignored since they won't match the direction of the rule.
The remainder of the example forms the rule options. The options section starts by telling Snort what message to display in the alert. In this case, the rule tells Snort to output "WEB-IIS unicode directory traversal attempt" into the log/database and alert. Following this command is the most important part of the rule options: the part dealing with matching desired traffic. The flow tag tells Snort to only examine packets sent to the target server once a session is established. This requirement prevents Snort from examining the SYN, SYN-ACK, ACK 3-way handshake that initializes the connection. On a busy IDS, eliminating the handshake traffic from the rule check could significantly improve the performance of the system.
The content section is where the real meat of the rule is formed. In simple terms, Snort will take the value specified in the content tag and compare it against requests sent to the server. The preceding example rule is searching for the string "/..%c1%1c../". This string uses Unicode to hide a directory traversal attempt on a web server. Most systems are now immune from this kind of attack, but you'll still find a number of attempts to exploit this vulnerability on well-traveled sites. The nocase command following the content tag tells the rule to ignore case when matching the contents. The final tag to consider is the classtype tag. The information within this tag tells Snort how severe the event is. In this case, the web-application-attack class type matches a high priority level. These levels are better explored and configured in the classifications.config file.
To fine tune the list of active rules, take a look into /etc/snort/snort.conf again and examine the list of rules near the bottom. The default configuration enables a range of rules that provide a general overview of traffic coming into the network.
To trim the alerts to a manageable level, and to ensure you're monitoring the correct services, you can modify the list of rules. Creating a more focused list will reduce packet loss and ensure better performance. The rules you leave active are dependent on your network infrastructure and overall requirements. If your network doesn't use specific services or protocols, disable any unnecessary rules to reduce overhead.
By default, a number of rules are disabled. Many of the disabled rules occasionally cause false positives, but you might want to enable some of them to use for specific purposes. Once you have tailored the list to your requirements, take some time to provide information on specific services.
As you have already seen, Snort offers built-in variables to simplify the task of configuring rules. Without variables, if your company had a number of http servers listening on a port other than the standard port 80 (port 8080 for example), you would have to edit every Snort rule to alter the http port from 80 to 8080. Not only that, but you would have to change every rule with every update of the rule set. Instead, you can use Snort's built-in variables to set the value of $HTTP_PORTS to 8080 instead of the standard 80. Then you can run the servers on whatever ports you want without having to always edit the rules to match the environment. To change the value of HTTP_PORTS to 8080, edit the snort.conf file as follows:
var HTTP_SERVERS [10.10.10.100/32,10.10.10.111/32] var HTTP_PORTS [80,8080]
If you want to specify a range of ports instead of a long list (i.e., 8000 through to 8080), use a colon (8000:8080).
snort.conf includes built-in variables for HTTP, AIM, and Oracle services. Also, you can add your own variables for other services if you plan to reference them in custom rules. Providing Snort with information on where and how the services on your network are configured lets the IDS reduce overhead by restricting traffic checks to a limited range of destinations. Why check SMTP traffic destined for a system that only supports SSH or FTP services? On large networks, you can never be 100% sure what traffic is passing over the wires. You might discover an SMTP service is running on an obscure server that's been in the company since the dawn of time.
Snort also lets you create custom rules. The best way to learn about creating rules is to look at an existing rule. Once you have examined a few of the rules, you can select one that most closely matches your requirements and play around with it. It is common to add these custom rules to the local.rules file for testing purposes. Adding your custom rules to local.rules also protects them from being overwritten when you update to a new rule set.
Custom rules come in handy in situations when the patch for a known vulnerability isn't available yet. Adding a custom rule to your IDS/IPS can give you an added layer of protection, or at least an early warning system if the problem appears.
Preprocessors, which you can enable and disable through snort.conf, let Snort manipulate inbound traffic. Snort automatically enables a number of preprocessors to deal with fragmented traffic, stateful stream inspection, performance monitoring, RPC traffic decoding, ftp/telnet/SMTP/DNS/SMB traffic monitoring, and port scanning. You'll even find a preprocessor especially designed for the Back Orifice trojan. Each preprocessor has its own set of options and settings. The defaults should be fine as a starting point, but spend some time with the preprocessor configuration if you want to get the most out of your IDS. In particular, the sfPortscan preprocessor can create false positives if set incorrectly. If you begin to receive false positives, you can easily disable sfPortscan through snort.conf.
If your server is low on RAM, you might need to tweak some of the preprocessor memory settings. As an example, the frag3 preprocessor uses 64MB of RAM as a default for storing and reassembling fragmented traffic. Although 64MB doesn't seem like much on today's servers, you can see how the addition of several preprocessors could start to make a dent in server performance. Inversely, if you have more than enough RAM, you can increase the available memory to ensure fragmented traffic doesn't become a problem in high-load environments.
Spec'ing the Server
If you are planning a Snort server, it is important to consider the traffic you're expecting to handle. Snort will run on almost any kind of hardware. However if you want a fast, reliable IDS without high packet loss, Snort needs a reasonably fast processor. Needless to say, you'll also need storage space for the logs and alerts. The most critical thing, however, is a good NIC. Where possible, ensure the NIC is a separate card and not built into the motherboard. Most major NIC manufacturers now offer a server class network card with an onboard processor especially designed for network traffic processing.
Logs and Alerts
Your IDS system is ticking away, logging traffic, and alerting a MySQL database. Having a database full of alerts and logged traffic is a great thing. However, receiving an alert at your desktop when somebody is port scanning your systems is even better.
Unfortunately, Snort doesn't offer a built-in solution for delivering alerts to a remote desktop. As with many *nix projects, however, Snort is easy to interface with other utilities. Two possible candidates are Swatch and Logsurfer.
Other products are available on the front end to display your Snort data as nice graphs and statistics. One of the more popular systems is BASE (Basic Analysis and Security Engine) . Download BASE version 1.3.9 from the project website. To get started with BASE, you'll need to set up Apache and PHP on your server. BASE also relies on ADOdb  to provide access to the database through PHP. For security and performance reasons, it is a good idea to set this up on a system separate from the Snort sensor system.
A management console is no good if you can't get access to it while the IDS is busy dealing with other traffic. Sometimes having a second NIC in the Snort sensor especially for monitoring and management is a good idea. Once you have the Apache, PHP, and ADOdb packages installed, you will need to untar the BASE code into /var/www/base. For the time being, change the permissions on the /var/www/base directory to make it world writable (chmod 777). This practice is terrible for security, but you'll only need this capability for the duration of the configuration process. You can then go to the BASE web page, http://Your_Server/base, to configure access to the database (Figure 4). You'll need to enter the path to ADOdb files, as well as your MySQL server name, logon, and password into the web form.
If the BASE web page says the configuration files aren't writable, check the chmod you just performed. BASE will add content to the MySQL database for reporting, and once completed, the setup is finished. If you experience problems, you might need to uncomment the mysql.so extension in your php.ini file. Don't forget: You will need to reset the permissions on the /var/www/base directory to something readable by your Apache server. It is important to note that BASE doesn't provide any built-in security for the web front end. So if possible, enabling SSL and ensuring that there's an .htpasswd on the BASE directory is a step in the right direction.
Aside from the database, you will also find text logs and alerts in /var/log/snort. These logfiles contain the complete log data in tcpdump format. Should you want, you can easily write a script to inform you when a new alert is logged. To work with these files, use snort -r to process the tcpdump file into something easier to read. The -vd switches provide verbose information. To make things a little easier, Snort also supports the use of BPF (Berkeley Packet Filter)  to filter output from the command line.
snort -vd -r snort.log.1206804587 tcp and src port 22 snort -vd -r snort.log.1206804587 not host 192.168.0.1
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?