This document takes you through the basics of intrusion detection, the steps necessary to configure a host to run the snort network intrusion detection system, testing its operation, and alerting you to possible intrusion events.
Snort is a software-based real-time network
intrusion detection system developed by Martin Roesch that can be used
to notify an administrator of a potential intrusion attempt. The
ever-increasing amount of Internet crackers, armed with "ready-to-run"
exploits, as well as the sophisticated attacker that's intent on defacing
your web page necessitates the use of a method to track their activity
and alert you to this.
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:
- Detect and alert based on pattern matching for threats
including buffer overflows, stealth port scans, CGI attacks,
SMB probes and NetBIOS queries, NMAP and other portscanners,
well-known backdoors and system vulnerabilities, DDoS clients, and
many more;
- Use syslog, SMB "WinPopUp" messages, or a file to alert an
administrator;
- Develop new rules quickly once the pattern (attack signature)
is known for the vulnerability;
- Record packets in their human-readable form from the offending IP
address in a hierarchial directory structure.
- Used as a "passive trap" to record the presence of traffic that
should not be found on a network, such as NFS or Napster connections;
- Used on an existing workstation to monitor a home DSL connection,
or on a dedicated server to monitor a corporate web site
Snort uses the popular libpcap library, the same library that tcpdump uses
to perform its packet sniffing. Snort decodes all the packets passing by on
the network to which it's attached by entering promiscous mode.
Based upon the content of the individual packets and the rules defined
in the configuration file, an alert is generated.
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 Snort
There are a few things you should determine before you install snort.
The device may be placed outside an organization's firewall between the
firewall and the external untrusted network. This allows snort to detect
not only the attacks that may make it through the firewall, but also those
that are blocked by the firewall.
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 Interface
The 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 Interface
In 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 Snort
The 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 Ruleset
After 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#Rules
Another 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:
00 00 * * * root /usr/sbin/snort-update -q
It can also be downloaded from
http://www.linuxsecurity.com/programs/snort-update
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:
#
# Taken and modified from "vision.conf", part of Max Vision's
# ArachNIDs work. See /usr/doc/snort-1.6/README.snort-stuff for more
# information on how to use this file.
var INTERNAL 192.168.1.0/24
var EXTERNAL 63.87.101.0/24
var DNSSERVERS 63.87.101.90/32 63.87.101.92/32
preprocessor http_decode: 80 443 8080
preprocessor minfrag: 128
preprocessor portscan-ignorehosts: $DNSSERVERS
preprocessor portscan: $EXTERNAL 3 5 /var/log/snort/portscan.log
# |
# Log file (path/name) ----------------------------------+
# Ruleset, available (updated hourly) from:
#
# http://dev.whitehats.com/ids/vision.conf
# Include the latest copy of Max Vision's ruleset
include /etc/snort/vision.conf
#
# Uncomment the next line if you wish to include the latest
# copy of the snort.org ruleset. Be sure to download the latest
# one from http://www.snort.org/snort-files.htm#Rules
#
# include /etc/snort/06082k.rules
#
# If you wish to monitor multiple INTERNAL networks, you can include
# another variable that defines the additional network, then include
# the snort ruleset again. Uncomment the two following lines.
#
# var INTERNAL 192.168.2.0/24
# include /etc/snort/vision.conf
# include other rules here if you wish.
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:
authpriv.* /var/log/secure.log
[root@krypton ~]# /usr/bin/killall -HUP syslogd
Using Preprocessors
The 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:
[root@krypton ~]# snort -d -l /var/log/snort -c /etc/snort/rules.base
Initializing Network Interface...
User level filter, protocol ALL, raw packet socket
Decoding Ethernet on interface eth0
Initializing Preprocessors!
-------------------------------------------------
Keyword | Preprocessor @
-------------------------------------------------
http_decode : 0x8053070
minfrag : 0x8053290
portscan : 0x8053ce0
portscan-ignorehosts: 0x8054340
-------------------------------------------------
Initializing Plug-ins!
-------------------------------------------------
Keyword | Plugin Registered @
-------------------------------------------------
content : 0x8052050
offset : 0x8052080
depth : 0x80520f0
nocase : 0x8052160
flags : 0x8052710
itype : 0x80528f0
icode : 0x8052a00
ttl : 0x8052b10
id : 0x8052bf0
ack : 0x8052cd0
seq : 0x8052dc0
dsize : 0x8052ec0
ipopts : 0x8054420
rpc : 0x8054670
icmp_id : 0x8054830
icmp_seq : 0x8054930
session : 0x8055300
-------------------------------------------------
Initializating Output Plugins!
-------------------------------------------------
Keyword | Output @
-------------------------------------------------
alert_syslog : 0x8054a20
log_tcpdump : 0x8054ff0
-------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
255 Snort rules read...
255 Option Chains linked into 140 Chain Headers
+++++++++++++++++++++++++++++++++++++++++++++++++++
Performing Rule List Integrity Tests...
---------------------------------------
Alert TCP Chains : OK
Alert UDP Chains : OK
Alert ICMP Chains : OK
Log TCP Chains : Empty list...
Log UDP Chains : Empty list...
Log ICMP Chains : Empty list...
Pass TCP Chains : Empty list...
Pass UDP Chains : Empty list...
Pass ICMP Chains : Empty list...
---------------------------------------
-*> Snort! <*-
Version 1.6
By Martin Roesch (roesch@clark.net, www.clark.net/~roesch)
Press ctrl-C to stop snort for now. At this point you should be able to
start snort using the normal startup procedure. If you need to start
snort manually, use the following:
[root@krypton ~]# /usr/sbin/snort -s -d -D -i eth0 -l /var/log/snort \
-c /etc/snort/rules.base
[root@krypton ~]#
The -D switch is used to have snort run in the background as a daemon.
You may need to supply the correct interface name if you are not using eth0.
Edit the INTERFACE variable in the /etc/rc.d/init.d/snortd
file if you have installed the snort RPM. If you've installed the snort
RPM, you can start snort with the following:
[root@krypton ~]# /etc/rc.d/init.d/snortd
Starting snort: [ OK ]
[root@krypton ~]# ps awx | grep snort
9131 ? S 0:04 /usr/sbin/snort -s -d -D -i eth0 -l
/var/log/snort -c /etc/snort/rules.base
9149 pts/1 S 0:00 grep snort
[root@krypton ~]#
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:
[root@krypton ~]# nmap -p 25,53 -sX -P0 -D 1.2.3.4,5.6.7.8 192.168.200.189
Starting nmap V. 2.54BETA1 by fyodor@insecure.org (www.insecure.org/nmap/)
Interesting ports on smtp.mydomain.com (192.168.200.189):
Port State Service
25/tcp open smtp
53/tcp open domain
Nmap run completed -- 1 IP address (1 host up) scanned in 19 seconds
Replace the 192.168.200.189 with the IP address of a host on
your network. The /var/log/auth.log file would then show
something similiar to:
Jun 18 15:57:52 krypton snort[9131]: spp_portscan: PORTSCAN DETECTED from
1.2.3.4
Jun 18 15:57:52 krypton snort[9131]: spp_portscan: PORTSCAN DETECTED from
5.6.7.8
Jun 18 15:57:58 krypton snort[9131]: spp_portscan: portscan status from
192.168.1.100: 2 connections across 1 hosts: TCP(2), UDP(0) STEALTH
Jun 18 15:57:58 krypton snort[9131]: spp_portscan: portscan status from
1.2.3.4: 2 connections across 1 hosts: TCP(2), UDP(0) STEALTH
Jun 18 15:57:58 krypton snort[9131]: spp_portscan: portscan status from
5.6.7.8: 2 connections across 1 hosts: TCP(2), UDP(0) STEALTH
The /var/log/snort directory contains a hierarchial listing with
each host having it's own directory beneth which contains a file detailing
the information that makes up the intrusion attempt. For example:
[root@krypton ~]# cd /var/log/snort
[root@krypton snort]# find 192.168.200.189
192.168.100.189
192.168.100.189/ICMP_ECHO
192.168.100.189/ICMP_PORT_UNRCH
192.168.100.189/TCP:57554-32771
192.168.100.189/TCP:57555-32771
[root@krypton ~]#
Looking within the TCP:57554-32771 file reveals:
[root@krypton 192.168.100.189]# cat TCP:57554-32771
** MISC-Attempted Sun RPC high port access **
06/18-00:48:31.928357 192.168.100.189:57554 -> 192.168.200.189:32771
TCP TTL:42 TOS:0x0 ID:5410
***F*P*U Seq: 0x0 Ack: 0x0 Win: 0x400
00 00 00 00 00 00 ......
The corresponding syslog entry looks like:
Jun 18 00:48:31 krypton snort[8757]: MISC-Attempted Sun RPC high port
access: 192.168.100.189:57554 -> 192.168.200.189:32771
Several perl scripts exist to process this information into an HTML page which
can be accessed periodically to determine what is occuring on the network.
The snort2html
is a perl script written by Dan Swan that does a nice job of producing
useable information in HTML format. If you decide to save this in a
directory accessable by a web server, be sure to apply the proper
authentication mechanism to prevent outsiders viewing this file. It
contains a great deal of helpful information to a potential intruder.
It can be used as follows:
[root@krypton ~]# /usr/bin/snort2html /var/log/auth.log
This will produce an HTML file in /var/log/snort-log.html that
is for use with the Max Vision ruleset and creates links to the CVE
definition of each intrusion attempt. This version has been modified from
the original to accept the filename from the command-line. You can edit
this file to save the resulting HTML file in another location.
Resources
- Lance Spitzner shows snort in action as he
tracks an intruder
and performs forensic analysis on the trails of the intruder.
- Fyodor has put together a document that describes the snort internals
- The snort download page
includes pointers to source code, plugins to send snort output data
directly to a database, the Win32 port, and the latest rulesets.
- The snort.org has a wealth of helpful
information and documentation.
Feel free to drop me an email if
you have questions or comments about this document.
Powered by AkoComment! |