Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Security Week: July 28th, 2014
Linux Advisory Watch: July 25th, 2014
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

Network Intrusion Detection Using Snort Print E-mail
User Rating:      How can I rate this item?
Features 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.
  • Do you have approval to run an intrusion detection device by your organization?
  • Is the system you're installing snort on secure? The last thing you want is the feeling of that false sense of security that you get by looking at what you think is happening but really has been modified by an intruder. The use of OpenSSH is mandatory for remote access. Reading the Solaris Security FAQ and the Linux Security HOWTO should provide you with a starting point.
  • Where are you going to put it? If you are simply trying to find out who is port scanning or attempting to attack your home system, it's an easy decision. However, placement in an organization may be more difficult.
  • Is the date and time correct? Ensure the time and date are correct on the host that snort will be running on. Install the xntpd time server so you can be sure the time of the events you are recording is correct. Chances are it is included with or already installed on your system but may still need to be configured. Once you have found a suitable timeserver from the URL provided above, a root crontab entry such as the following should suffice:

    	00 * * * * root /usr/sbin/ntpdate -u 

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 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

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

Another ruleset, developed as part of Max Vision's ArachNIDS work, is available from 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

This assumes the wget package is installed, the local box can download the file at, and it can successfully deliver mail to an administrator.

The snort-update script will place the vision.conf file in /etc/snort/ 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 to vision.conf.

You might also consider using the ruleset in addition to the Max Vision ruleset. This can be achieved by downloading the 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

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.


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:

# 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 ruleset.  Be sure to download the latest
# one from
# 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.
# 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

The portscan-ignorehosts preprocessor is used for this, and includes the hosts to ignore as its argument seperated by spaces:

preprocessor portscan-ignorehosts:

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 (,
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 and the victim host is With nmap in hand, using the decoy feature, you might run the following as root:

[root@krypton ~]# nmap -p 25,53 -sX -P0 -D,

Starting nmap V. 2.54BETA1 by (
Interesting ports on (
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 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
Jun 18 15:57:52 krypton snort[9131]: spp_portscan: PORTSCAN DETECTED from
Jun 18 15:57:58 krypton snort[9131]: spp_portscan: portscan status from 2 connections across 1 hosts: TCP(2), UDP(0) STEALTH
Jun 18 15:57:58 krypton snort[9131]: spp_portscan: portscan status from 2 connections across 1 hosts: TCP(2), UDP(0) STEALTH
Jun 18 15:57:58 krypton snort[9131]: spp_portscan: portscan status from 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
[root@krypton ~]#

Looking within the TCP:57554-32771 file reveals:

[root@krypton]# cat TCP:57554-32771
** MISC-Attempted Sun RPC high port access **
06/18-00:48:31.928357 ->
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: ->
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.


  • 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 has a wealth of helpful information and documentation.

Feel free to drop me an email if you have questions or comments about this document.

my snortd do not runWritten by hassan on 2006-07-12 13:58:33
please i want someone to help me . 
my problem is that : 
i have installed snort-2.6.0 like the manual describe but when  
i try to use the command service snortsd start, it appear [echouĂ©] 
what can i doing ? please help me

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

< Prev   Next >


Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
DARPA-derived secure microkernel goes open source tomorrow
Hacker Gary McKinnon turns into a search expert
Hackers seed Amazon cloud with potent denial-of-service bots
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.