| Network Intrusion Detection Using Snort |
|
Until now, intrusion detection devices were either dedicated-use commercial products, or not real-time and difficult to install. Snort is the solution for monitoring small TCP/IP networks where it is not cost-effective to deploy commercial products. Snort is an easy-to-use, "lightweight", and very functional alternative.
What is Network Intrusion Detection?A Network Intrusion Detection System (NIDS) is a system that is responsible for detecting anamolous, inappropriate, or other data that may be considered unauthorized occuring on a network. Unlike a firewall, which is configured to allow or deny access to a particular service or host based on a set of rules. If the traffic matches an acceptible pattern, it is permitted regardless of what the packet contains. However, an NIDS captures and inspects all traffic, regardless of whether it's permitted or not. Based on the contents, at either the IP or application level, an alert is generated. Snort is a "lightweight" NIDS in that it is non-intrusive, easily configured, utilizes familiar methods for rule development, and takes only a few minutes to install. Snort currently includes the ability to detect more than 1100 potential vulnerabilities. Keep in mind that Intrusion Detection devices work in conjunction with other security measures, and are not a replacement for other good security practices. It is also quite feature-packed right out of the box. Among its features include the ability to:
Why Use Intrusion Detection?Intrusion detection devices are an integral part of any network. The Internet is constantly evolving, and new vulnerabilities and exploits are found regularly. They provide an additional level of protection to detect the presence of an intruder, and help to provide accoutability for the attacker's actions.
Before Installing SnortThere are a few things you should determine before you install snort.
The presence of switches, routers and firewalls will all have an effect on the correct placement of the box. A decision must be made as to which network segment will catch the traffic you actually want to monitor. Placement of the NIDS on the local side of the firewall will allow the NIDS to monitor traffic that the firewall has already determined to be permissable, but not necessarily benign. This will, of course, not catch traffic that the firewall has already blocked, potentially masquerading port scans, probes and other types of attack.
Single InterfaceThe easiest configuration is a box with a single interface. The same interface that listens to the network traffic is the same one from which administration is done.
![]() Images Courtesy Network Flight Recorder This will be the typical configuration for home network users and administrators monitoring internal networks.
Dual InterfaceIn a dual-interface configuration, one interface is used to listen to network traffic in promiscuous mode while the other is used for remote administration. This type of configuration is used in environments where it is not possible to administrate the box from the same interface that is listening to the network traffic. In this configuration, the external interface should be well-protected and the box designed explictly for this purpose. The box should not be offering any network services except for ssh on the internal interface only.
![]() Images Courtesy Network Flight Recorder
Installation of SnortThe file INSTALL included with the distribution contains information on installing and configuration snort from the downloadable source code. It is very easy to compile, configure, and install. If you are a Red Hat or compatible user, a precompiled RPM file is available from http://www.linuxsecurity.com/programs/snort-1.6.2.2-1.i386.rpm. You will also need the libpcap-0.4 package which is included with all Linux distributions. The source code and other information are downloadable from ftp://ftp.ee.lbl.gov/libpcap.tar.Z.
Installing the Snort RulesetAfter snort is installed, you'll want to download the latest rules file. Currently there are two different rulesets that people use. A ruleset developed by Jim Forster can be downloaded from http://www.snort.org/snort-files.htm#RulesAnother ruleset, developed as part of Max Vision's ArachNIDS work, is available from http://dev.whitehats.com/ids/vision.conf and updated hourly. The Max Vision ruleset is particularly nice because it follows the Common Vulnerabilities and Exposures (CVE) database, allowing people to refer to a particular vulnerability using a consistent name. From the CVE Frequently Asked Questions: "CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability databases and security tools with this "common enumeration." " If you've installed the snort RPM, the /usr/sbin/snort-update script written by Dave Dittrich can be used to download the latest Max Vision ruleset from cron:
This assumes the wget package is installed, the local box can download the file at http://dev.whitehats.com/ids/vision.conf, and it can successfully deliver mail to an administrator. The snort-update script will place the vision.conf file in /etc/snort/vision.conf.new and an email notification will be sent to the local root account with the differences from the previous version, if any. You must then rename the vision.conf.new to vision.conf. You might also consider using the snort.org ruleset in addition to the Max Vision ruleset. This can be achieved by downloading the snort.org ruleset. Information on combining these rulesets together is included below. The backdoor-lib, misc-lib, overflow-lib and other similar files are included with the source code, but are pretty dated and not typically used. Before snort can be started, a few variables must be defined. Also included in the snort RPM is a file called rules.base which was derived from Max Vision's vision.conf file. It is a short file that contains a few variables that define your internal and external networks, hosts that snort should ignore portscans from, and on which networks snort should watch for portscans. It can also be downloaded from http://www.linuxsecurity.com/programs/rules.base. A portscan is defined as TCP connection attempts to more than P ports in T seconds or UDP packets sent to more than P ports in T sections. Read Martin's "Writing Snort Rules" for a full description of portscan. You'll need to supply the information for your INTERNAL and EXTERNAL networks, and from DNS servers which tend to trigger the portscan detection.
The rules.base file looks as follows:
If you are on a dialup machine, the INTERNAL setting would be your dialup interface with a /32 subnet mask, indicating the host itself.
Additionally, you may need to configure syslogd to log snort and
other security events to a specific log file. Edit /etc/syslog.conf
to log snort alerts, then signal syslogd to re-read the
/etc/syslog.conf file:
Using PreprocessorsThe preprocessor directives listed above are used to examine the data flow before the intrusion detection engine applies the ruleset to the packets. This can be used to modify the contents of the packet, or to signal the detection engine to not process a particular packet. The preprocessor http_decode: directive instructs the detection engine to convert the data within HTTP URI strings into a format that defeats attempts at eluding the content analysis strings used to examine HTTP traffic for suspicious activity. Supply the ports on which a web server is running. The preprocessor portscan: directive is used to define the host or network for which snort should watch for a portscan. The <>/32 appearing after the IP addresses indicates CIDR notation for a 32-bit subnet mask (the host itself). For a Class C network, use /24. It may also be necessary to exclude some hosts from triggering the portscan detection module. Boxes that generate legitimately generate traffic on a large number of ports in a short amount of time, including NFS or DNS servers are typical candidates. More on Patrick Mullen's portscan preprocessor can be found at http://www.linuxrc.org/projects/snort/. The portscan-ignorehosts preprocessor is used for this, and includes the hosts to ignore as its argument seperated by spaces: preprocessor portscan-ignorehosts: 63.87.101.90/32 63.87.101.92/32 You might consider trying it without the portscan-ignorehosts directive first, as you don't want to unnecessarily disable the ability to detect portscans if it's not necessary. The minfrag preprocessor checks for fragmented packets which can be used to disguise TCP packets from IP filters used in routers and hosts. Packets less than 512 bytes do not need to be fragmented with modern networks, and packets found smaller than that typically indicate attempts to subvert a firewall or intrusion detection.
You should now be able to test your configuration file and the normal operation of snort:
After you believe snort is working correctly, you should do what an intruder
might do, and attack your own network. Notice that qualifier -- your own
network!. My attack host (krypton) is 192.168.100.189
and the victim host is 192.168.200.189. With
nmap in hand, using the decoy
feature, you might run the following as root:
Looking within the TCP:57554-32771 file reveals:
Resources
Feel free to drop me an email if you have questions or comments about this document.
Only registered users can write comments. Powered by AkoComment! |
||