Monitor a network using NIDS (Snort)

NIDS (Network-based intrusion detection systems) run on one or several critically placed hosts and view the network as a whole.  NIDS use NICs running in promiscuous mode to capture and analyze raw packet data in real time.

A NIDS may be stateful or stateless.  Like a packet filter, stateful can catch more attacks.

Most NIDS use one of two methods to identify an attack: statistic anomaly detection or pattern-matching (or signature-based) detection.

Anomaly-based Detection

In the statistic anomaly detection model, the software discovers intrusions by looking for activity that is different from a user’s or system’s normal behavior.

The baseline for normal behavior is established by profiling user, host, or network activity for some learning period.  After the learning period ends, the anomaly detection-based IDS scans for usage which deviates from the baseline.

The advantage to an anomaly-based IDS is that it does not have to be specifically trained to look for a given attack and can often spot new attacks before they are well publicized.  The downside is that there is also a good chance of receiving false positives even with an extensive learning period and frequent tweaking.

Signature-based Detection

Because an anomaly-based IDS is relatively high maintenance, professionals whose sole job function is not site security are more likely to employ some form of pattern-matching detection.

A signature based NIDS examines visible network activity, looking for suspicious activity such as port scans, packets with fake source addresses, etc.  Not all malicious activity is visible on a given host’s NIC, so the location and number of such scanners must be carefully thought out.

Signature based detection works by comparing packets to a set of attack signatures, which are stored in some form of database and must be frequently updated as new attacks emerge.  (This works like many virus scanners.)  Such scanners can detect attacks well and quickly, but not zero-day attacks.  These are attacks for which no signatures have been yet developed. Anomaly detectors work more like spam filters, they collect and analyze normal traffic to establish a baseline.  Then any unusual traffic triggers an alert.

The advantages to a pattern-matching IDS include an easier implementation and smaller learning curve for the administrator, as well as the generating fewer false positives.  However, they are more easily fooled by the obfuscation and evasion techniques of black hats.  This may not be a problem as the most common attacks are from script-kiddies, who rarely use such techniques.

Setting up Snort as an NIDS

[ Adapted from the Sun BigAdmin article on snort, at ]

SNORT is a popular stateful signature-based NIDS and scanner.  To be useful you must regularly update the signature database.  The Snort website ( includes subscription access to Sourcefire VRT Certified Rule Updates, as well as the free source code, documentation, and other resources.  Note if you don’t want to subscribe to the rule distribution (which costs about $2000/year), you can just register with and periodically check the site for the latest rule set (available 5 days after paying subscribers can get them).  If you don’t want to do that either, you can download a limited set of freebie rules.

(If you subscribe you can use tools to automatically update rules, see .)

Note the people who invented snort formed sourcefire (, to provide commercial IDS services.  They use many technologies including snort.  Such companies are useful to out-source intrusion detection when it doesn’t pay to train and maintain local security experts and buy and maintain commercial tools.

Snort can perform real-time packet logging, protocol analysis, and content searching/matching.  It can be used to detect a variety of attacks and probes such as stealth port scans, CGI-based attacks, Address Resolution Protocol (ARP) spoofing, and attacks on daemons with known weaknesses.  Snort can also be used as a (packet) scanner, like tcpdump or ethereal (only not with as many filtering features as those programs).

Snort utilizes descriptive rules to determine what traffic it should monitor and a modularly designed detection engine to pinpoint attacks in real time.  When an attack is identified, Snort can take a variety of actions to alert the systems administrator to the threat.

Snort comes as a tar-ball, with MD5 and GPG signatures available on the website.  To install you perform the usual steps as shown below.  Note the rules are a separate download.  In both cases be sure to download the latest versions, currently 2.4.3.

Some configure options to consider are to enable database (e.g., MySQL) support with “--with-mysql”, and extra features for dealing with hostile connection attempts with “--enable-flexresp”.  See “./configure ‑‑help=short” and look up any interesting-sounding options in the docs.  Note some features will require additional libraries.

Additionally snort comes with plug-ins you can download and use, as well as additional tools (rule maintenance, GUI front-ends, ...)

$ wget

$ wget

$ wget‑bin/downloads.cgi\


$ wget‑bin/downloads.cgi\


$ md5sum -c snortrules-pr-2.4.tar.gz.md5

$ gpg --verify snort-2.4.3.tar.gz.sig

$ gpg --recv-keys 731681A1

$ gpg --verify snort-2.4.3.tar.gz.sig

$ tar -zxf snort-2.4.3.tar.gz

$ cd snort-2.4.3

$ ./configure

$ make

$ su -c 'make install'

$ mkdir  /etc/snort  /var/log/snort  /var/snort

$ tar -zxf snortrules-pr-2.4.tar.gz.md5 -C /etc/snort

$ cp etc/*.{config,map} /etc/snort

$ cd /etc/snort

$ cp -f rules/*.{config,map} .  # replace defaults with latest

$ vi snort.conf  # change "var RULE_PATH ../rules" to "rules"

To run snort as a packet sniffer, showing only the packet headers, run:

snort ‑v

(for view the data, rather than capture it).  Hit control-C when you want to stop, and snort provides a summary.  To use your configuration file settings, you must tell snort where the snort.conf file is.  (It looks by default in /etc/snort.conf.):

     snort -v -c /etc/snort/snort.conf

To view packet data add the “-d” option.  To view data-link (layer 2) headers too, add the “-e” option (for Ethernet?).

In packet logging mode (no “-v” flag), the captured data is saved in a directory hierarchy with subdirectories for each IP address.  You specify where to put this with the “-l dir” flag. (You must create the directory first!)

By default snort now uses tcpdump (pcap) file format for captured data, so all collected data goes into a single file.  The older format used ASCII files and directories.  If you use “-K ascii” option, snort will create subdirectories and log packets based on the address of the remote or local host address.

Snort logs the packets both flowing from your host and to your host.  If you just specify a plain -l option, Snort sometimes uses the address of the remote computer as the directory in which it places packets and sometimes it uses the local host address.  In order to log relative to the home network, so all captured traffic is logged in directories named for the remote end, you need to tell Snort which network is the home (local end) network using the “‑h net/mask” option:

snort -de -K ascii -l /tmp/snort-log \

   -h -c /etc/snort/snort.conf

This rule tells Snort that you want to print out the data link and TCP/IP headers as well as application data into the directory /tmp/snort-log, and you want to log the packets relative to the class C network.  All incoming packets will be recorded into subdirectories of the snort-log directory, with the directory names being based on the address of the remote (non-192.168.1) host.

Note:  If both the source and destination hosts are on the home network, they are logged to a directory with a name based on the source or destination IP address of the packet, depending on which has the higher of the two port numbers.  Or in the case of a tie, the source address is used.

If you’re on a high speed network or you want to log the packets into a more compact form for later analysis, you should consider logging in binary mode.  Binary mode logs the packets in tcpdump format to a single binary file in the logging directory:

  snort -l /tmp/snort-log -c /etc/snort/snort.conf -b

Note the command line changes here. We don’t need to specify a home network any longer because binary mode logs everything into a single file.  You don’t need to run in verbose mode or specify the -d or -e switches because in binary mode the entire packet is logged, not just sections of it.

To enable Network Intrusion Detection (NIDS) mode so that you don’t record every single packet sent down the wire, try this:

snort -b -l /tmp/snort-log -h \
-c /etc/snort/snort.conf

Snort will look for /etc/snort.conf. This will apply the rules configured in the snort.conf file to each packet to decide if an action based upon the rule type in the file should be taken.  If you don’t specify an output directory for the program, it will default to /var/log/snort.


The default logging and alerting mechanisms are to log in pcap format and use full alerts.  The full alert mechanism prints out the alert message in addition to the full packet headers.  There are several other alert output modes available at the command line, as well as two logging facilities.

To save all data in binary mode use “-b” as before (this is recommended).  To just provide alerts and not log the data (not recommended, the data is useful for later analysis or legal evidence), use “‑N” along with “‑A mode”.

Use the “‑A mode” option to configure alerts.  You can use the default of full, fast (timestamp, brief message, source and dest IP and port numbers), none (just log packets), and others too.

To send alerts using syslog, add the “-s” switch. Alerts go to AUTHPRIV facility by default.

To run in the background as a daemon use the “-D” option.  To run snort at boot time but the appropriate command in rc.local.  To more easily control snort it may be better to create a proper script in /etc/init.d for it, and then use chkconfig (and service) to control it.

When run as a network sensor (NIDS), you carefully decide where to place the host that runs snort.  Use a hardened host (with excess software removed).

Make sure you have plenty of disk space available for the logs, on a busy network you may have terabytes of data!  Consider using disk quotas and log file rotation for snort to prevent disk full errors.

Use syslog to forward the alerts to a central host (syslog-ng is a better choice than vanilla syslog).

Make sure you routinely check for new rules frequently (or subscribe to alerts on a mailing list).

Have a policy on escalating alerts to the proper personnel.