Feed on
Posts
Comments

The folks at Sourcefire have been working hard at creating the next generation of Snort. Martin Roesch, captain of the brave development team, is boldly taking Snort where no pig has gone before. Cyberspace, the final frontier. Seriously, the core framework for Snort is being rewritten from the ground up. With Snort turning ten in November, the development effort is about adding capabilities to Snort while allowing the current functionality, along with all the rules that have been developed over the years, to continue to work. Need more power from the engines? The Sourcefire development team is working on it. In a world where network throughput is ever increasing, the new architecture is compartmentalizing Snort’s subsystems. Snort will be multithreaded to take advantage of multi-core platforms. Marty predicts, “You’ll be running Snort on bigger and faster networks, so in version 3 we made it easier to add hardware acceleration to it.”

The Three Wise Men Speak

As readers of this blog know, I have been looking at the Bro IDS. I hope to shortly release a post on setting up Bro 1.4, which was released this Friday. It will be interesting to watch these two IDS/IPS progress in the upcoming year. With two such development efforts, it was somewhat surprising to read the news release from the Open Information Security Foundation (OIS) that “OISF Receives Grant Funding for Open Source Next Generation IDS/IPS.” Good to see that innovation is occurring in an area of security previously given up for dead (see post, “IDS/IPS: The Mark Twain of the Security World“).

For cutting edge knowledge on Snort 3 development, Martin Roesch, Leon Ward, and Richard Bejtlich are three wise men who can provide greater insight. Fortunately, they have all written posts on Snort 3:

Overview

In this post, we will be installing Snort 2.8.3.1, the Snort Security Platform (SnortSP), and the Snort 3 analytical engine. Please see Martin Roesch’s, Leon Ward’s, and Richard Bejtlich’s posts for more in-depth discussion. I am going to discuss a few basic concepts of the Snort 3 architecture, go through installation, and discuss some configuration and operation of the software. I plan on following this post with a another concerning the setup and installation of Bro 1.4. I will follow that post with an analysis of results from the two systems. At some point, we will discuss integration of results into RTIR.

The Snort 3 architecture consists of the software framework, called the Snort Security Platform (SnortSP) and engines. Sometimes SnortSP will be referred to as “the framework” or just “framework.” SnortSP is designed to perform basically as an “operating system” for packet-based network security applications, providing common functionality that all programs need. For example, it operates on the data source performing such functions as acquiring the data (DAQ), decoding, flow normalization, IP defragmentation, and stream reassembly. SnortSP is composed of the action system, attribute management system (AMS), and the dispatcher. It allows you the ability to interact with the system through the command shell and snortd. From a developer’s point of view, SnortSP is what gathers data and handles any evasive techniques or other conditions that occur in suspicious and malicious traffic. SnortSP normalizes the data and then provides this cleaned up data to the engines for inspection. The engines are analysis modules that plug into SnortSP. Sometimes the engines will be referred to as “engine modules,” “analytics modules,” or simply the “analytics.” Multiple engines can run simultaneously. Here is a reference diagram.

Some of the major features of Snort 3 include:

  • Shell-based user interface with embedded scripting language
  • Native IPv6, MPLS and GRE support
  • Native support for inline operation
  • More subsystem plugin types such as data acquisition modules, decoders and traffic analyzers
  • Multithreaded execution model – multiple analysis engines may operate simultaneously on the same traffic
  • Performance increases

SnortSP comes with a Snort 2.8.2 detection engine implemented as a SnortSP engine module. Annother engine that is being developed is an network contextually aware engine that will allow Snort to understand what it is defending. Marty describes network context as, “essentially data about the environment that is being defended by Snort, the composition of the hosts in the network as well as the local network composition.” The idea is that no longer will you have to manually teach Snort rules. Marty reports “You teach Snort what the network looks like so it can defend itself accordingly. It tunes itself. My end goal is to have a self-tuning protection engine.” Richard provides insight into another upcoming engine, “SnortSP is expected to support a new engine called Policy Enforcement Point (PEP), a stateless (yes, not stateful) firewall that integrates with Sourcefire’s other products. Any engine running on the SnortSP will be able to call PEP to enforce access control decisions, assuming the sensor/IPS is in a place to take such actions.” It will be very interesting to see what engines are developed. This is the power of the design, giving Snort 3 the ability to grow to meet the needs of the security community.

Installation and Configuration

Generally, it is smart to start with what you know and determine expected results. We will begin with setting up and installing the latest stable version of Snort (Snort 2.8.3.1). Once it is configure and running, we will use some test data consisting of actual attacks that occurred in 2001. This allows us to develop a baseline of expected results. After that, we will move on to installing SnortSP, which comes with a implemented version of Snort 2.8.2 detection engine. First, you will need to have libpcre version 6.0 or greater installed.

PCRE (pcre-7.8)

The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. If you can install PCRE via a port specific to your operating system, that is the best way to install in order to avoid having to keep the software up-to-date. Below are the instructions for installing the software from source.

 root# cd /usr/local/src
 /usr/local/src root# wget \

http://downloads.sourceforge.net/pcre/pcre-7.8.tar.gz?modtime=1220617433&big_mirror=0

 /usr/local/src root# tar xzf pcre-7.8.tar.gz
 /usr/local/src root# cd pcre-7.8
 /usr/local/src/pcre-7.8 root# ./configure --prefix=/usr/local/pcre
 /usr/local/src/pcre-7.8 root# make
 /usr/local/src/pcre-7.8 root# make test
 /usr/local/src/pcre-7.8 root# make install

Libpcap and Large Files Support

Under some OSs, you need to compile libpcap and Snort to support large files (files large than 2G). Since the source code of libpcap will be needed for this configuration, we are going to install the resulting libpcap under /usr/local/snort. If the libpcap installed on your system does not produce an error, skip this step. You will want to follow these steps only if you get the following error when running Snort with a large file:

 root# ls -lh /data/ids/full2.pcap
-rw-r--r-- 1 root root 12G Oct 26 10:01 /data/ids/full2.pcap
 root# /usr/local/snort/bin/snort -o -A none -c /usr/local/snort/conf/snort.conf -l /logs/snort/logs \
-r /data/ids/full2.pcap
Error getting stat on pcap file: /data/ids/full2.pcap: Value too large for defined data type
RROR: Error getting pcaps
Fatal Error, Quitting..

First, we need to compile large file support into libpcap. As mentioned above, we will install the libraries under /usr/local/snort.

 root# cd /usr/local/src
 /usr/local/src root# wget http://www.tcpdump.org/release/libpcap-0.9.8.tar.gz
 /usr/local/src root# wget http://www.tcpdump.org/release/libpcap-0.9.8.tar.gz.sig
 /usr/local/src root# wget http://www.tcpdump.org/tcpdump-workers.asc
 /usr/local/src root# gpg --import tcpdump-workers.asc
gpg: key 89E917F3: "tcpdump.org (SIGNING KEY) " not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
 /usr/local/src root# gpg --verify libpcap-0.9.8.tar.gz.sig libpcap-0.9.8.tar.gz
gpg: Signature made Tue 25 Sep 2007 10:11:56 PM EDT using DSA key ID 89E917F3
gpg: Good signature from "tcpdump.org (SIGNING KEY) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 0227 54EB 4C30 9185 FD31  33A3 464D 3CEB 89E9 17F3
 /usr/local/src root# tar xzf libpcap-0.9.8.tar.gz
 /usr/local/src root# cd libpcap-0.9.8
 /usr/local/src/libpcap-0.9.8 root# ./configure --prefix=/usr/local/snort \
CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
-D_FILE_OFFSET_BITS=64"
 /usr/local/src/libpcap-0.9.8 root# make
 /usr/local/src/libpcap-0.9.8 root# make shared
 /usr/local/src/libpcap-0.9.8 root# make install
 /usr/local/src/libpcap-0.9.8 root# make install-shared

In the next section, we will discuss how to install Snort with and without large file support.

Snort (snort-2.8.3.1)

The latest release of Snort, as of this writing, is Snort 2.8.3.1. Below we will get the software, verify, configure, and install the software under the /usr/local/snort area. Please adjust this to your environment. Reminder to Mac OS X and FreeBSD users, use the md5 command instead of md5sum.

 root# cd /usr/local/src
 /usr/local/src root# wget http://www.snort.org/dl/snort-2.8.3.1.tar.gz
 /usr/local/src root# wget http://www.snort.org/dl/snort-2.8.3.1.tar.gz.md5
 /usr/local/src root# cat snort-2.8.3.1.tar.gz.md5
f7c03b322dae31dafc45756630f2946c  snort-2.8.3.1.tar.gz
 /usr/local/src root# md5sum snort-2.8.3.1.tar.gz
f7c03b322dae31dafc45756630f2946c  snort-2.8.3.1.tar.gz
 /usr/local/src root# tar xzf snort-2.8.3.1.tar.gz
 /usr/local/src root# cd  snort-2.8.3.1

We are going to add in support to place alerts into a MySQL database. If MYSQL installed by the system, you can use the “–with-mysql” configuration option. In a previous post, “Introduction to MySQL,” we went through the installation of MySQL into the /usr/local/mysql directory. For such an installation, the –with-mysql-includes=/usr/local/mysql/include and –with-mysql-libraries=/usr/local/mysql/lib command options must be used. In order to use the dynamic plugin libraries, Snort needs to be able to find libmysqlclient.so. On some operating systems, you may have problems. Adding LDFLAGS=”-L/usr/local/mysql/lib/mysql” should work. If you do not need to compile in large file support, you can do the compilation simply with the command:

 /usr/local/src/snort-2.8.3.1 root# ./configure --prefix=/usr/local/snort \
--with-libpcre-includes=/usr/local/pcre/include \
--with-libpcre-libraries=/usr/local/pcre/lib \
--with-mysql-includes=/usr/local/mysql/include\
--with-mysql-libraries=/usr/local/mysql/lib

For adding in large file support, and having Snort use the libpcap installed under /usr/local/snort, do that with the following command:

 /usr/local/src/snort-2.8.3.1 root# CFLAGS="-D_LARGEFILE_SOURCE \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"  \
./configure --prefix=/usr/local/snort --with-libpcap-includes=/usr/localsnort/include \
--with-libpcap-libraries=/usr/local/snort/lib \
--with-libpcre-includes=/usr/local/pcre/include \
--with-libpcre-libraries=/usr/local/pcre/lib \
--with-mysql-includes=/usr/local/mysql/include\
--with-mysql-libraries=/usr/local/mysql/lib

After you configure Snort (with or without large file support), you continue to make and install it.

 /usr/local/src/snort-2.8.3.1 root# make
 /usr/local/src/snort-2.8.3.1 root# make check
 /usr/local/src/snort-2.8.3.1 root# make install
 /usr/local/src/snort-2.8.3.1 root# mkdir -p /usr/local/snort/etc
 /usr/local/src/snort-2.8.3.1 root# cp etc/* /usr/local/snort/etc
 /usr/local/src/snort-2.8.3.1 root# /usr/local/snort/bin/snort -V

   ,,_     -*> Snort! < *-
  o"  )~   Version 2.8.3.1 (Build 17)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2008 Sourcefire Inc., et al.
           Using PCRE version: 7.8 2008-09-05

Rules

Now we need some rules. For this example we will get the rules from the Snort and the Emerging Threats site. You will need to register for the rules at the Snort site. Do consider subscribing for the latest up-to-date rules. Registered users can only access rules 30 days after their release.

 root# cd /usr/local/src
 /usr/local/src root# wget http://www.emergingthreats.net/rules/emerging.rules.tar.gz
 /usr/local/src root# tar xzf emerging.rules.tar.gz

 /usr/local/src root# mkdir -p /usr/local/snort/rules
 /usr/local/src root# mv rules/* /usr/local/snort/rules
 /usr/local/src root# rmdir rules
 /usr/local/src root# wget \

http://www.snort.org/pub-bin/downloads.cgi/\

Download/vrt_os/snortrules-snapshot-CURRENT.tar.gz
 /usr/local/src root# md5sum snortrules-snapshot-CURRENT.tar.gz
184aed405da3f1043b82d81c98122237  snortrules-snapshot-CURRENT.tar.gz
 /usr/local/src root# mv  snortrules-snapshot-CURRENT.tar.gz /usr/local/snort/
 /usr/local/src root# cd /usr/local/snort/
 /usr/local/snort root# tar xzf snortrules-snapshot-CURRENT.tar.gz
 /usr/local/snort root# rm snortrules-snapshot-CURRENT.tar.gz
 /usr/local/snort root# vi /usr/local/snort/etc/snort.conf

Modify /usr/local/snort/etc/snort.conf to your environment. Make sure the RULE_PATH is set to /usr/local/snort/rules. If you wish to use the emerging threat rules, add:

include $RULE_PATH/emerging.conf

in the /usr/local/snort/etc/snort.conf file. Do not forget to adjust dynamicpreprocessor file and dynamicengine path. Mac OS X users will need to use the dynamic libraries. Uncomment the Mac OS X lines in the Snort configuration file.

Keeping Rules Current

If you want to setup a process to keep your rules as up-to-date as possible from the snort site, you will want to use the program Oinkmaster.

 root# cd /usr/local/src
 /usr/local/src root# wget http://prdownloads.sourceforge.net/oinkmaster/oinkmaster-2.0.tar.gz?download
 /usr/local/src root# md5sum oinkmaster-2.0.tar.gz
d2a1b56f51cf40e919c63206ca4ec8f8  oinkmaster-2.0.tar.gz
 /usr/local/src root# tar xzf oinkmaster-2.0.tar.gz
 /usr/local/src root# cd oinkmaster-2.0
 /usr/local/src/oinkmaster-2.0 root# cp oinkmaster.pl /usr/local/snort/bin
 /usr/local/src/oinkmaster-2.0 root# cp oinkmaster.conf /usr/local/snort/etc

Modify /usr/local/snort/etc/oinkmaster.conf changing “url=” to the location where you want rules to be archived. The URL will also require a Oink Code, which is available once you register with Snort and log into your account. Multiple URLs can be specified for multiple files. You can have Oinkmaster pull down rules from Snort and Emerging Threats. I use oinkmaster to pull down the latest rules, place them in new rules directory (ex: /usr/local/snort/new-rules), backup the previously rules, and send email about what is new. Some rules may have negative impact on Snort’s operation. It is unwise to automatically update the rules without review. Below, the backup/archive area is the directory /usr/local/snort/archive. Modify /usr/local/snort/bin/oinkmaster.pl to know where oinkmaster.conf is located. At that point you are ready to use oinkmaster to update your rules.

 /usr/local/src/oinkmaster-2.0 root# mkdir /usr/local/snort/archive
 /usr/local/src/oinkmaster-2.0 root# vi /usr/local/snort/bin/oinkmaster.pl
 /usr/local/src/oinkmaster-2.0 root# vi /usr/local/snort/etc/oinkmaster.conf
 /usr/local/src/oinkmaster-2.0 root# /usr/local/snort/bin/oinkmaster.pl \
-o /usr/local/snortr/new-rules -b /usr/local/snort/archive
 /usr/local/src/oinkmaster-2.0 root# crontab -l
10 6 * * * /usr/local/snort/bin/oinkmaster.pl -o /usr/local/snort/new-rules -b /usr/local/snort/archive \
| Mail -s "Snort Rule Updates" abbot@securitymonks.com 2>&1

For automatic updates, set up a cron job that runs the above command and email the results.

Testing Snort Using Attack Data

Leon Ward has made available a pcap file containing attacks that occurred back in 2001 against a honeypot. If you have other data that will produce interesting results, please feel free to use that.

 root# mkdir -p /data/ids/tcpdump
 root# cd /data/ids/tcpdump
 /data/ids/tcpdump root# wget rm-rf.co.uk/downloads/Honeynet-RFP-iis.tgz
 /data/ids/tcpdump root# tar xzf Honeynet-RFP-iis.tgz
 /data/ids/tcpdump root# /usr/local/snort/bin/snort -c /usr/local/snort/etc/snort.conf \
-A fast -l /data/ids/tcpdump -r ./Honeynet-RFP-iis.pcap
 /data/ids/tcpdump root# ls /data/ids/tcpdump/alert /data/ids/tcpdump/snort.log.*

Two results files should get created. The file /data/ids/tcpdump/alert will contain the alerts and /data/ids/tcpdump/snort.log.<date>, which contains the pcaps of the detected events.

SnortSP

At this point we are ready to install SnortSP. The first step is to make sure the system has the required software installed, which includes:

The second step involves getting the software, verifying, configuring, and installing the security platform. The engine will be built in the next section.

 root# cd /usr/local/src
 /usr/local/src root# wget http://www.snort.org/dl/prerelease/3.0.0-b2/\
snortsp-3.0.0b2.tar.gz
 /usr/local/src root# wget http://www.snort.org/dl/prerelease/3.0.0-b2/\
snortsp-3.0.0b2.tar.gz.md5
 /usr/local/src root# wget http://www.snort.org/dl/prerelease/3.0.0-b2/\
snortsp-3.0.0b2.tar.gz.sig
 /usr/local/src root# cat snortsp-3.0.0b2.tar.gz.md5
4b2259c08ebe66cf63d91359996c93d9  snortsp-3.0.0b2.tar.gz
 /usr/local/src root# md5sum snortsp-3.0.0b2.tar.gz
4b2259c08ebe66cf63d91359996c93d9  snortsp-3.0.0b2.tar.gz
 /usr/local/src root# gpg --verify snortsp-3.0.0b2.tar.gz.sig snortsp-3.0.0b2.tar.gz
gpg: Signature made Fri 18 Jul 2008 11:09:25 AM EDT using DSA key ID B10683B0
 /usr/local/src root# gpg --keyserver pgpkeys.mit.edu --recv-key B10683B0
gpg: requesting key B10683B0 from hkp server pgpkeys.mit.edu
gpg: key B10683B0: "Snort Release Team (Snort Release Team signing key) " not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
 /usr/local/src root# gpg --verify snortsp-3.0.0b2.tar.gz.sig snortsp-3.0.0b2.tar.gz
gpg: Signature made Fri 18 Jul 2008 11:09:25 AM EDT using DSA key ID B10683B0
gpg: Good signature from "Snort Release Team (Snort Release Team signing key) "
gpg: Note: This key has expired!

Primary key fingerprint: 0A0A BD0C 8FAA BDDC E7A2  A8C3 E6FA 8BA1 B106 83B0

The next step is to configure, install, and test SnortSP installation. We will be using the /usr/local/snort area as the installation directory. Please adjust to your environment.

 /usr/local/src root# tar xzf snortsp-3.0.0b2.tar.gz
 /usr/local/src root# cd  snortsp-3.0.0b2
 /usr/local/src/snortsp-3.0.0b2 root# ./configure --prefix=/usr/local/snort
 /usr/local/src/snortsp-3.0.0b2 root# make
 /usr/local/src/snortsp-3.0.0b2 root# make check
 /usr/local/src/snortsp-3.0.0b2 root# make install
 /usr/local/src/snortsp-3.0.0b2 root# mkdir -p /usr/local/snort/etc/SnortSP
 /usr/local/src/snortsp-3.0.0b2 root# cp etc/* /usr/local/snort/etc/SnortSP
 /usr/local/src/snortsp-3.0.0b2 root# /usr/local/snort/bin/snortsp -V
SnortSP Version 3.0.0b2

Snort 2.8.2 Detection Engine

The next step is to install the Snort 2.8.2 detection engine. We will immediately shut it down with the ssp.shutdown() command. Please see previous sections “Libpcap and Large Files Support” and “PCRE (pcre-7.8).” I am going to include the configuration options for libpcap, pcre, and MySQL. Please adjust the configuration if necessary in the same way snort-2.8.3.1 was modified.

 /usr/local/src/snortsp-3.0.0b2 root# cd src/analysis/snort
 /usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# ./configure --prefix=/usr/local/snort \
 --with-platform-libraries=/usr/local/snort/lib/snortsp \
 --with-platform-includes=/usr/local/snort/include \
 --with-libpcap-includes=/usr/localsnort/include \
 --with-libpcap-libraries=/usr/local/snort/lib \
 --with-libpcre-includes=/usr/local/pcre/include \
 --with-libpcre-libraries=/usr/local/pcre/lib \
 --with-mysql-includes=/usr/local/mysql/include\
 --with-mysql-libraries=/usr/local/mysql/lib
 /usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# make
 /usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# make check
 /usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# make install
 /usr/local/src/snortsp-3.0.0b2 root# /usr/local/snort/bin/snortsp \
-L /usr/local/snort/etc/SnortSP/snort.lua
   ,,_     -*> SnortSP! < *-
  o"  )~   Version 3.0.0b2 (Build 9) [BETA]
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 2008 Sourcefire Inc.
> Control thread running - 3086609296 (9501)
> ssp.shutdown()
 /usr/local/src/snortsp-3.0.0b2 root#

The command “snortsp -L /usr/local/snort/etc/SnortSP/snort.lua” is telling snortsp to use the file “snort.lua“. Examine the file for definitions of functions. Below are a few example functions calls that may be of interest:

 root# /usr/local/snort/bin/snortsp -L /usr/local/snort/etc/SnortSP/snort.lua
snort> ssp.help()
[*] SnortSP Commands:
    help()
    set_log_level( [debug|info|notice|warn|error|critical] )
    shutdown()
  Available subsystems within SnortSP have their own help() methods:
    dsrc        - Data Source
    eng         - Dispatcher/Engine
    analyzer    - Analytics Modules
    output      - Output Modules
  For example: dsrc.help() will call the Data Source help function
snort> dsrc.help()
[*]  Data Source Config Structure
 = {name        = ,
                  type        = ,
                  intf        = ,
                  flags       = [1|2|8],
                  command     = ,
                  snaplen     = ,
                  maxflows    = ,
                  maxidle     = ,
                  flow_memcap = ,
                  filename    = ,
                  max_count   = ,
                  display     = ,
                  gtp_support = [enable]
                  defrag      = {
                                 policy = <>,
                                 max_trackers = <>,
                                 timeout = <>,
                                 memcap = <>
                                }
}

    name: User string used to refernce the instantiated data
          source object.  If no name is provided a UUID is
          generated.
    type: Name of the DAQ module to use.  The list of available
          DAQ modules can be obtained using the
          dsrc.list_daq_modules() command.
    intf: Name of the interface to use for traffic acquisition.
    flags: Bitwise OR of available mode flags for a given DAQ.
           Some modes may not be available on all DAQs.
           Generally you will want to use either mode 1, 2
           or 8.  Default is 0.  To enable inline mode use a
           value of 10.
           Available modes are:
                1 = FILE READ MODE
                2 = PROMISC MODE
                8 = INLINE MODE
    command: BPF filter or other filter command for DAQs that
             support them.  Default is no filtering.
    snaplen: Max bytes to capture per packet.  Default is 0.
    maxflows: Max number of flows to keep in the flow manager
              at one time.  If this number is exceeded the least
              recently used flow is purged.  Default is 8192.
    maxidle: Number of seconds a flow can be idle before being
             timed-out and removed from the flow table.  Default is
             60.
    flow_memcap: Max number of bytes to allow to be used by the
                 flow table.  Default is 16MB.
    filename: In file playback mode, specifies the name of the
              file to run through the SnortSP instance.
    max_count: Number of packets to process before stopping this
               thread.  Default is 0, which is unlimited.
    display: Name of the display mode for printing packets as they
             are processed.  Available modes are:
                none    = Don't print packets at runtime.
                basic   = Display basic packet info on one line.
                classic = Display packets using the classic tcpdump
                          format.
                plus    = Classic mode + MAC header printout.
                max     = Full printout of every packet header
                          field, one field per line.
             Default is none.
    gtp_support: Activate support for the GTP protocol.  Default is
                 disabled.
    defrag: Specifies the IP/IPv6 defragmentation paramters.
                policy: Reassmebly policy for overlapping fragments.
                    Avaliable modes are:
                        
                    Default is bsd.
                max_trackers: The maximum number of unique packets
                              in the process of being reassembled at a
                              at any given time.  Default is 8192.
                timeout: The maximum time in seconds for a fragmented
                         packet to receive all fragments.  Default is 60.
                memcap: Maximum number of bytes to allow to be used for
                        fragment reassembly.  Default is 32MB.
[*] Data Source Commands
    new(  ) - Instantiate a new data source object
    delete(  ) - Delete a data source object
    list() - List all of the instantiated data source objects
    list_daq_modules() - List all of the available DAQ modules
    show( source_name ) - Show the config of the named
                          object
    help() - Print this message

  For example, the following commands will create a data source
  using the afpacket DAQ in inline mode bridging the eth2 and
  eth3 interfaces allowing 262144 flows to occupy 10 MBs of
  memory while timing out flows after 5 minutes of idle time:
      dsrc1 = {name="src",
               type="afpacket",
               intf="eth2:eth3",
               flags=10,
               snaplen=0,
               maxflows=262144,
               maxidle=300,
               flow_memcap=10000000}
      dsrc.new(dsrc1)

snort> dsrc.list()
[*] 0 data sources configured
snort> sniff("eth0")
Creating new data source
Flow manager created with 16384 flow capacity
Engine "e1" created
Linking engine "e1" to data source "src1"
Calling engine_start()

init_pcap: Initializing network interface eth0
[*] Data Source Config:
        Name: src1
        Type: pcap
        Interface: eth0
        Filename:
        Snaplen: 1514
        Flags: 0x00000002
        Display: None (0)
        Filter command:
        DAQ: 0x8078b00
        User Context: 0x9378170
        Max flows: 16384
        Max idle: 60
        Memcap: 10000000
[*] Flow Manager Config:
        Max flows: 16384
        Max idle: 60
        Memcap: 10000000
[*] DAQ config:
   Interface: eth0
   Snaplen: 1514
   Datalink: 1
   Count: 0
   Packet Count: 0
   Promisc flag: 1
   File flag: 0
   pcap ptr: 0x9396488
   analysis context ptr: 0xb71ce008
[*] Spawning engine thread!
snort> e1 thread running - 3072121744 (24685)

snort> dsrc.list()
[*] 1 data sources configured
Name: src1    DAQ: pcap    interface: eth0    Running
snort> dsrc.show("src1")
[*] Data Source Config:
        Name: src1
        Type: pcap
        Interface: eth0
        Filename:
        Snaplen: 1514
        Flags: 0x00000002
        Display: None (0)
        Filter command:
        DAQ: 0x8078b00
        User Context: 0x9378170
        Max flows: 16384
        Max idle: 60
        Memcap: 10000000
[*] Flow Manager Config:
        Max flows: 16384
        Max idle: 60
        Memcap: 10000000
[*] DAQ config:
   Interface: eth0
   Snaplen: 1514
   Datalink: 1
   Count: 0
   Packet Count: 117
   Promisc flag: 1
   File flag: 0
   pcap ptr: 0x9396488
   analysis context ptr: 0xb71ce008
snort> fsniff ("eth0", "port 21")
snort> dsrc.list()
[*] 2 data sources configured
Name: src2    DAQ: pcap    interface: eth0    Running
Name: src1    DAQ: pcap    interface: eth0    Running
snort> ssp.shutdown()
 root#

Lua

Lua is a lightweight scripting language embedded in SnortSP. The Snort Detection Engine is configured via a conf file, but SnortSP is configured by a Lua file. The Snort conf file location is specified in the Lua file. In this section, we are going to be running the shell script sspiffy.sh. The program comes with the SnortSP package and it will convert Snort 2.8.x files into a Lua scripts and a new configuration file for SnortSP.

Previously, we ran snort 2.8.3.1 against the Honeynet-RFP-iis.pcap data with the command:

 root# cd /data/ids/tcpdump
 /data/ids/tcpdump root# /usr/local/snort/bin/snort -c /usr/local/snort/etc/snort.conf \
-A fast -l /data/ids/tcpdump -r ./Honeynet-RFP-iis.pcap

We are going to create and use /data/ids/logs where result log files will be kept. First, backup the snort configuration file and result files previously created with snort 2.3.8.1.

 root# cd /usr/local/snort/etc
 /usr/local/snort/etc root# cp snort.conf snort.conf.orig
 /usr/local/snort/etc root# mkdir -p /data/ids/logs
 /usr/local/snort/etc root# mv /data/ids/tcpdump/alert /data/ids/logs/alert.orig
 /usr/local/snort/etc root# mv /data/ids/tcpdump/snort.log.* /data/ids/logs/

We defined dynamicpreprocessor and dynamicengine in snort configuration file (/usr/local/snort/etc/snort.conf) file, so we do not need to specify their location via command line with –dynamic-preprocessor-lib-dir and and –dynamic-engine-lib. We will use the /usr/local/snort/etc as our configuration directory. The script sspiffy.sh will create a new snort.conf file. To generate a Lua file to run SnortSP with snort, we would use sspiffy.sh as follows:

 root# cd /usr/local/snort/etc
 /usr/local/snort/etc root#  /usr/local/src/snortsp-3.0.0b2/sspiffy.sh \
/usr/local/snort -c /usr/local/snort/etc/snort.conf.orig \
-r /data/ids/tcpdump/Honeynet-RFP-iis.pcap -l /data/ids/logs -A fast 

Checking command line arguments ...

snort.conf is a copy of /usr/local/snort/etc/snort.conf.orig.2 with the following changes:
#SSP - set in lua: dynamicpreprocessor directory /usr/local/snort/lib/snort_dynamicpreprocessor/
#SSP - set in lua: dynamicengine /usr/local/snort/lib/snort_dynamicengine/libsf_engine.so
#SSP - deleted: preprocessor frag3_global: max_frags 65536
#SSP - changed: preprocessor frag3_engine: policy first detect_anomalies

snort.lua is the script that configures and executes SSP.

To run SSP as configured:
/usr/local/snort/bin/snortsp -L snort.lua -P
 -S  

 /usr/local/snort/etc root#  ls snort.lua snort.conf
 /usr/local/snort/etc root#  vi snort.lua snort.conf

The two files that were created in your current directory are snort.lua and snort.conf. Take a look at the files and modify them where appropriate. Make sure the full path to snort.conf is specified in snort.lua (conf=”/usr/local/snort/etc/snort.conf”). To run snortsp with the generated files, use the command:

 /usr/local/snort/etc root#  /usr/local/snort/bin/snortsp -L /usr/local/snort/etc/snort.lua

Now go to the /data/ids/logs area and compare the alert file just generated with the alert.orig file generated by snort 2.8.3.1. The results do match. The differences between the files comes down to SnortSP alert file not including log entries for http_inspect.

Final Thoughts

The new Snort architecture is a very exciting design change that will help future versions of Snort respond quickly to an every changing security battleground. Besides the potential speed performance, along with the ability to take advantage of the multicore systems being developed, what I find particularly interesting is that the new architecture provides a framework where developers can build their applications. There is real potential here for intriguing development and flexibility. Different environments have different requirements and needs. Soon organizations will have the ability to choose from different engines resulting in custom configurations that best address each organization’s risks.

Everyone is looking for a turn key solution. People need to accept the fact that security is hard. By the time you find a solution, the problem has changed. With an ever changing attack vector, there are no turn key solutions that can do anything more than provide help. This is an important concept, because once accepting this fact, it changes a person’s view on viable solutions. That is what I like about the Snort 3 architecture. It is designed to be capable of being adjusted rapidly, which is a really cool concept. All security tools should be designed in such a manner. Our adversaries adjust quickly. We need to be able to also. On the eve of Snort turning ten, it is good to see that the Sourcefire team has been building such a promising IDS that will serve us well far into the future.

Trackbacks/Pingbacks

  1. [...] my previous post, “Snort 3: The Next Generation” [4], Marty provided a roadmap of where Snort is heading. While changes have since been made as Snort [...]

Leave a Reply

Bad Behavior has blocked 342 access attempts in the last 7 days.