Consider how a preprocessor can be used to introduce learning into our intrusion detection system (IDS). One can use the problem defined in Part I of this article, wherethe IDS is encouraged to adapt to changes in the type of traffic seen and alert administrators if the traffic is anomalous.
Before Snort, or any IDS, is able to identify what is considered anomalous, it has to learn what normal network traffic for the network it is deployed on should look like. In artificial intelligence (AI) it is called the baseline, or training. The IDS observes the traffic for some period of time and takes statistics to use later to compare the expected traffic to the seen traffic. If the network traffic is significantly different then usual traffic, an alert can be generated to indicate to the user that something strange is happening.
Since this is meant to be a proof of concept, let's consider an IDS that is monitoring Web traffic where traffic is expected to be coming in and out of one or more Web servers on port 80. This is a very trivial setup; however, it makes the preprocessor much easier to explain, test, and demonstrate.
Outline of the preprocessor
The preprocessor looks at every single packet. In this example, the preprocessor determines whether or not the packet is part of an established connection and on port 80,otherwise the packet is ignored. One of the primary requirements for preprocessors is speed-you do not want a preprocessor chewing up any more cycles then absolutelynecessary. So, if the first two conditions aren't met, the routine exits immediately.
Once the preprocessor identifies traffic on port 80, it determines which of four possible scenarios have manifested themselves:
- LOCAL_IP:PORT ' INTERNET_IP:80
- LOCAL_IP:80 ' INTERNET_IP:PORT
- INTERNET_IP:PORT ' LOCAL_IP:80
- INTERNET_IP:80 ' LOCAL_IP:PORT
If you are inclined to look at the code, you will find that these situations are highlighted and routines for handling each situation are nested in an IF-ELSE construct.
LOCAL_IP:PORT ' INTERNET_IP:80
In this case, one of the machines protected by the IDS is browsing the Internet. Security professionals might not be too worried about the content; however, they would like the IDS to learn what a client request typically looks like on this network. In general, a client request will be quite small. The majority are GET requests. The GET requests should average a relatively small number of bytes compared to the response of the server on the Internet. If the IDS observeslarger requests, this might indicate someone tunneling out of a network on port 80. This is not necessarily a threat to the internal network, but it is something that an IT security specialist should be aware of. The intention is that the IDS learns which clients are likely to be sending large requests to servers and informs the IT security professional so that they can decide if such activity is normal.
LOCAL_IP:80'INTERNET_IP:PORT
This should indicate that a server on your internal network is responding to a client on the Internet. If your internal network has Web servers, the activity itself is probably not an issue. It is strange to see this activity occurring from a machine that is not a Web server. When you configure Snort, there is a section of the Snort.conf file that allows you to list your servers in an environment variable. IT security specialists should be encouraged to check for themselves which IP addresses are running Web servers and indicate these in the Snort.conf. If you open the Snort.conf file (it is very important to configure Snort properly in order to get the best performance out of it) you will see a series of var statements:
- # List of DNS servers on your network:
var DNS_SERVERS $HOME_NET - # List of SMTP servers on your network:
var SMTP_SERVERS $HOME_NET - # List of Web servers on your network:
var HTTP_SERVERS $HOME_NET - # List of telnet servers on your network:
var TELNET_SERVERS $HOME_NET
This can sometimes change over time as new Web servers are added to a network or IP addresses change. Using the preprocessor discussed here, the IDS can learn which IP addresses are most likely to be Web servers by observing the internal port 80 traffic being sent out to the Internet. If such activity exists, the IDS can track it. The IDS will start to profile certain IP addresses and make guesses about whether an IP address represents a Web server or not. Once an IDS observes the activity it should check to see if the source IP address is a known Web server. If it is, then the packets can be ignored. However, if the activity is coming from a box that has not been identified as a Web server, the IDS should monitor the activity and alert the system administrator. This idea in itself is not new. The interesting idea presented here is to have the IDS get feedback from the IT security specialist and to adapt to the network. The IDS will indicate if it suspects a new Web server at some IP address and inturn the IT security specialist verifies that the IP address actually has a Web server. If it does, then the IDS can add the IP address to the list of known Web servers, adjusting its own configuration and thus adapting to the network.
The operator of the IDS does not even need to know, at first, where the Web servers are on a network (this shouldn't be encouraged of course) and can simply deploy the IDS to let it figure out where the Web servers exist. Feedback from the IT security specialist is desirable, but not necessary. By tracking this type of port 80 activity the IDS can build a list of likely Web servers and flag those that demonstrate anomalous Web activity. For example, alerting on Web servers that appear to be producing valid traffic on the local network that are only active for two hours a day from 2:00am to 4:00am, while ignoring Web servers that operate regularly during business hours.
INTERNET_IP:PORT'LOCAL_IP:80
Similar to the situation discussed above, the preprocessor can verify that the destination is in fact a Web server. Also, it can verify that the GET requests being made by the machine outside are not large when compared to the responses from the local server. If very large requests are going into your network, which is atypical of the target server, it might indicate someone trying to upload a malicious executable onto one of your machines.
INTERNET_IP:80'LOCAL_IP:PORT
From a security perspective, this situation is normal. Other content-based Snort rules will check to make sure there is nothing malicious in the payload of the Internet server response. The only thing that may be of interest in this traffic is the average response sizes. Tracking the average response sizes can help ensure that the responses are typically larger than the requests. This is more valuable for demonstrating that the IDS is adapting to the network than it is practical, given the widevariety of possible requests from an Internet IP address.
Article continued on
Page 2
