|
|
About Snort | Server Protection | Acceptable Use | References
John Kemp
kemp@ns.uoregon.edu
The Security Group at the University of Oregon performs a variety of services in the area of computer and network security. Among these services are general security consulting, risk assessment, vulnerability scanning, incident handling, and intrusion detection. The latter--intrusion detection--is among the most interesting of these because it provides a direct window into the world of the hacker.
To help safeguard a network, various types of Intrusion Detection Systems (IDSs) can be employed, and they can be used in many ways. IDSs can be divided into two broad categories: host-based systems and network-based systems.
Host-based detection involves running software on a host to monitor just that particular host at a high level of detail. Network-based systems are placed strategically within a network to passively listen to a large percentage of an organization's network traffic.
Network-based systems may not provide the precision or level of detail that a host-based system can, but they do have the advantage of being centralized, and they can yield significant returns for a smaller overall investment. The rest of this article focuses on network-based systems.
IDSs can be used for tasks as simple as network traffic accounting or as complex as detecting anomalous behavior in network traffic. One of their more common uses is to monitor the network for incoming attacks. IDSs utilize a database of signatures that describe what the network traffic "looks like" for certain well known attack programs.
Detection of things like the "Code Red" and "Nimda" network worms are common. IDSs can also be used to detect port scanning or Denial-of-Service (DoS) attacks, where a flood of traffic is sent in an attempt overload a system on the network.
The more quickly a break-in is detected and dealt with, the better. Most IDS systems have near-real-time capabilities for detection and notification. Once an attack is detected, a range of actions may follow. The first course of action is to notify the attacker's Internet Service Provider (ISP) and request that the attacker be removed from the network. Local network engineers can respond by putting filters in place to block further attacks from the same source. In cases where break-in attempts are successful, campus administrators are notified and the affected machines are removed from the network until the damage can be cleaned up.
It should be emphasized that there is less value in detection than there is in prevention. It is much better if an attack is prevented before it occurs, rather than detected after it has been successful. For this reason, security professionals usually recommend that resources be committed to preventative measures (such as installing firewalls and keeping up-to-date on application and operating system patches) before they're expended on detection. A break-in itself, and the cleanup afterwards, are costly events. Nevertheless, an IDS is still a valuable tool for detecting attacks and break-ins, and monitoring anomalous behavior on a network.
Software for running network-based IDSs is available in the form of commercial and open-source applications. Some of the more popular applications are Snort, ISS RealSecure, Bro, Cisco NetRanger, and Network Flight Recorder. Snort and Bro are both open-source, and are freely available. What follows is a more detailed discussion of Snort as a sample case of a network-based IDS.
Snort is a network data analysis tool that can be run on Unix and Windows systems. As the name implies, Snort was originally designed as a packet sniffer. It evolved into a more sophisticated tool after Martin Roesch of Sourcefire, Inc., who was trying to design a better version of tcpdump for displaying packet dumps, realized he could easily extend his new sniffer's capabilities to do pattern matching. And so Snort turned into a rudimentary network IDS as well. Since then, a great deal of work has been done to expand the functionality of the program.
Snort can be run in three different modes: as a packet sniffer, a packet logger, or an IDS.
1. Packet sniffing mode. The simplest mode is running Snort from the command line of a Unix system in much the same way as tcpdump. For example, to look at the internal traffic on a Unix system, you'd issue the command
# snort -dave -i lo
The display format is like tcpdump, but it is displayed in a much more readable format. In addition, an ASCII representation of the data is displayed alongside the hexadecimal packet data.
2. Packet logger mode. Snort can also be run in packet logger mode. In this mode, Snort will save the packet data to a disk instead of displaying it to the screen. The default filename format is snort-<MMDD@HHmm>.log, where MM=month, DD=day, HH=hour, and mm=minute, which indicates the time that logfile was created. In the following example the data is saved in binary format, and the file is created in the directory /var/log/snort:
# snort -i eth0 -b -l /var/log/snort
Without the binary flag, snort will split out the data into directories based on the IP address of the remote machines, and within those directories it will save individual files, based on protocol and port number, containing the fully formatted ASCII data of the packets. While this can create a large number of files and a significant amount of data on a busy system, it is a logical way for storing this kind of data.
3. IDS mode. The full capabilities of Snort come into play when it is run as an IDS system. Snort has preprocessing, signature matching rules, advanced logging, and alerting capabilities when run in IDS mode. A configuration file can be used to describe these extended features. This is the default mode that Snort will try to run in, but it is common to specify this mode explicitly on the command line:
# snort -c snort.conf -l /var/log/snort -b -A fast
The above command tells snort to read from the configuration file snort.conf, to log to the directory /var/log/snort, to save the data files in binary format, and to send brief alerts when an intrusion is detected. For later analysis the files can be read back in using the -r read option to Snort.
The most common use of Snort is as a signature-based IDS. A signature database is created that contains identifying features that occur in the network packet data from known attacks. Over time, as more attacks are discovered and captured, the signature database is expanded. The community of Snort users is large, and a community database of the signatures of well-known attacks is maintained at the Snort website.
When an attack is detected, it can be logged, or trigger an alert. The alert mechanism in Snort is very flexible. Alerts can be sent as brief headers or as full text. Alerts can be transmitted using the syslog mechanism, or via SMB message popups, or passed over a network socket to another system. Additional alert options are available for storing alert messages into databases.
The signatures detected by Snort are described by a rules language. These rules contain an action, a protocol field, source address and source port, destination address and destination port, traffic direction, and an options field that is used to match the specific contents of packets. Here is one example:
alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:"NETBIOS nimda .eml"; content: "|00|E|00|M|00|L"; flags:A+; classtype:bad-unknown; reference:url,www.datafellow s.com/v-descs/nimda.shtml; sid:1293; rev:2;)
This rule represents a check for one variant of the Nimda worm. The source and destination are defined by variables that classify the traffic as coming from a remote network to the local network. The message section is used to define an informative message to send when issuing the alert. In this case, a NetBIOS-over-TCP packet coming into the network on port 139, that contains the string <null>E<null>M<null>L, would trigger an alarm. A reference link to information about the vulnerability can be included as a part of the alert.
Here is another example of a Snort rule. In this case, a specific set of web servers is being watched for Code Red attempts, and the attack is coming into the network on port 80. Instead of the plain "content" type, uricontent type is used so that the rule will match only in the event that the string "scripts/root.exe?" is found within the section of the packet that contains an HTTP request:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS Code Red v2 root.exe access"; flags: A+; uricontent:"scripts/root.exe?"; nocase; classtype:web-application-attack; reference:url,www.cert.org/advisories/CA-2001-19.html; sid:1256; rev:3;)
Some of the more powerful features of Snort are available in IDS mode through preprocessor modules. These modules operate on streams of data that are gathered together and organized, rather than on individual packets. For certain types of attacks, this sort of buffering of the data is necessary. Things like HTTP decoding, port scan detection, telnet stream scanning, and defragmentation can be performed using these modules.
The kinds of attacks that are appearing on UOnet are about what you might expect. There are typically 10 to 20 scans every day covering the entire UOnet address space. WWW server and FTP server buffer overflow attacks are common. Interestingly enough, Microsoft SQL Server is also a popular target. Less common but still popular are buffer overflow attacks against Unix machines. Probes looking for RPC services, older SSH versions, and LPD vulnerabilities are common.
Stay current. The best advice in these cases is to make sure that your server software is up-to-date, especially your WWW, FTP, and SSH server software. If your server software is not kept current, the odds are very good that your system will be compromised.
Use Windows File Sharing with care. Break-in attempts against Windows machines that have Windows File Sharing enabled have also been common. Shares that have weak passwords, or that have blank passwords, have been hardest hit. In other cases, vulnerabilities in the File Sharing authentication mechanism have been targeted.
Run antivirus software. If you are not using Windows File Sharing, make sure it is disabled. The recent implementation of a packet-filtering policy on campus, which blocks non-affiliated users from accessing Windows File Sharing, has been effective in blocking most of these types of attacks. Nevertheless, email viruses continue to be successful, taking advantage of the fact that Microsoft Outlook is a common mail client, and that many users do not have anti-virus software running on their machines. Running anti-virus software on a Windows machine and keeping it up to date is a simple way to guard against many of these attacks.
Please note that running a sniffer on your machine can be an invasion of privacy and a violation of the acceptable use policies for the UOnet network. In general, you should run Snort only on a machine that is wholly operated by you and where you are the only user on the machine. Additionally,you should only observe traffic that involves your own machine.
Restricting the traffic that Snort observes can be done either by specifying the loopback interface or by specifying the local hostname as an argument to the "host"option. Specifying the loopback interface makes Snort only look at traffic that involves the machine communicating internally with itself. Specifying the "host <myhostname>" option makes Snort only look at traffic to and from the local machine.
When run in either of these ways, Snort can be a helpful tool for understanding Internet protocols and the behavior of Internet traffic. All other uses should be considered forbidden, except where permission is explicitly granted for problem resolution under the direction of Network Services.
SANS Reading Room
http://rr.sans.org/intrusion/intrusion_list.php
CERT Advisories
http://www.cert.org/
Snort Documentation and IDS References
http://www.snort.org/docs/
The MicroHelp Security Pages
http://micro.uoregon.edu/security/
The MicroHelp Norton Anti-Virus Distribution
http://micro.uoregon.edu/av/nav.html
The UO Security Group
http://security.uoregon.edu/