Deploying Snort

Methods of Deployment
Processing the Data

Methods of Deployment

In this section I am going to describe how to deploy snort in a real enviroment. This includes topics such as positioning the sensor, defining a ruleset, storing alerts and logs, and processing the data. There are many ways to different ways to deploy snort, I will not attempt to cover them all. Most of what I present here will be based upon how I have actually deployed snort. Therefore, this is biased section. I will not say that my method is the best, but it works well for my particular situation.

Positioning the Sensor

To clarify this discussion, I am going to designate the network interface that snort is gathering data from the "detection interface." In a typical setup, snort operates by examing all the traffic that passes past its detection interface. It accomplishes this by setting the interface into promiscuous mode. In order for snort to be most effective, it needs to be positioned where it will see the most traffic possible. On a shared ethernet network, the detection interface can be simply connected to the shared network. In a switched enviroment, the detection interface will need to be connected to a "monitor port" on the switch. A "monitor port" is a port that is configured to receive all of the traffic that passes through the switch [1]. The final, and possibly most popular, deployment is where the sensor is used to monitor all traffic coming (and leaving) an otherwise isolated network. Some examples would be an organization with a single high-speed connection to the internet. By placing sensor where it can examine all of the traffic that enters (and departs) over that connection, snort can be effectively used to monitor for incoming (and outgoing) attacks. [2] One way to accomplish this is to place a shared hub between the border router and the internal network. This allows the sensor to examine all of the data associated with the external link. Another method is to use a network tap to replicate the data on the connection. Another location it is prudent to deploy snort is on the home network. In most (well ASFAIK most) home networks, there is a single machine that acts as a gateway to the rest of the network. By deploying snort to use the external link as its detection interface, it is possible to monitor for attempted attacks. Even if the only machine on the home network is the gateway, it would be wise to deploy an IDS on the external interface. This (on the gateway to a small network or when used as a "personal" IDS) is the only time I endorse using a "real" interface as the detection interface. In all of the other scenarios, I recommend utilizing seperate interfaces for real traffic and monitoring.

Defining a ruleset

An intrusion detection system is only as good as its ruleset. It is very easy to develop a ruleset that gives no "false positives", it simply ignores all packets that it sees. It is also very easy to develop a ruleset that gives no "false negatives", it simply sends an alert for every packet it sees. Obviously, some middle ground is needed. As discussed in the Anatomy of a Rule section, snort rules have two parts. There is the address/port section and the detection plugin section (which examines the packet in more detail). When defining a rule, it is best to use both portions. If you rely on the address/port part alone, you will be overwhelmed with false negatives generated by valid traffic (such as someone connecting to a web server from port 31337 or a new piece of software that happens to use port 12345 on the server). You also do not want to rely on just the detection plugins either. These take much more time than address/port checking and it is not often much use to look for attacks against your webservers that are on ports on than what the webserver is running on.
More stuff goes here
To make life easier, there are some dedicated individuals who maintain rulesets specifically designed for use with snort. At Whitehats is the arachNIDS database maintained by Max Vision. This database includes many rules for use in snort along with a description of the vulnerabilty and the signature used to generate the rule. Many of the rules in my rulesets have come from this site. Another site is Rapidnet.

Storing alerts and logs

On a very active network, snort can generate big log files and a large number of alerts.
more stuff goes here

Processing the Data

I consider this such an important part of the deployment of snort that I have given it its own section. What good is having an intrusion detection system if you do not look at what it produces. Snort produces two sets of data to be used to analyze an attack. It produces alerts and logs. Unless you have a very small network, you will probably not want to step through the alerts one at a time to determine if it warrants further investigation. Also, I have learned that very few managers like looking at raw data, they would much rather see some sort of summary or statistics (and many of them seem to like little colored pictures). This is where the various tools available to work with snort output come in handy. If you skipped over it earlier, I strongly suggest you go back to Snort Tools now and look over all the tools that are available.

_{[1] Setting up a single port to monitor several other ports on a switch can easily run into bandwidth problems.
If the aggregate bandwidth of the ports being monitored exceeds the bandwidth of the monitor port, then not
all of the packets will be seen by the detection system.}
_{[2] For those of you that wonder why I am so concerned about outgoing attacks; I work at a University}