Suricata Intrusion Detection: Part Four


Configuring app parser settings in Suricata.

In the previous articles on Suricata, we covered installation, configuring global settings and pass lists, and began looking at setting up an interface. In this article, we will continue setting up our first Suricata interface. In this example, we are configuring the WAN interface.

Configuring App Parsing

The next tab after “WAN Flow/Stream” is “WAN App Parsers“. This tab deals with parsers that operate on the application layer of the TCP/P model, the layer that specifies certain protocols that cover major aspects of functionality such as FTP, SMTP, and others.

The first setting is “Asn1 (Abstract Syntax One) Max Frames“. Abstract Syntax one is a standard and notation that describes rules and structures for representing, encoding, transmitting, and decoding data in telecommunications and computer networking. Application later protocols such as X.400 e-mail, X.500 and LDAP directory services, H.323 (for VoIP) and SNMP use ASN.1 to describe the protocol data units they exchange. “Asn Max Frames” sets a limit for the maximum number of ASN.1 frames to decode (the default is 256).

The next heading is “DNS App-Layer Parser Settings“. Here, you can set parameters relevant to DNS, UDP and TCP parsing. “Global Memcap” and “Flow/State Memcap” set the global memcap and flow/state memcap limits respectively. The default global memcap is 16 MB and the flow/state memcap is 512 KB. The “Request Flood Limit” determines how many unreplied DNS requests are considered a flood; if this limit is reached, an alert is set. The default is 500. Finally, “UDP Parser” and “TCP Parser” enables UDP detection and parsing and TCP detection and parsing. The default for both settings is “yes“.

Below that is “HTTP App-Layer Parser Settings“. “Memcap” sets the memcap limit for the HTTP parser; the default is 64 MB. The “HTTP Parser” dropdown box allows you to enable or disable detection and parsing; there is also a third setting, “detection-only“, which enables detection but disables the parser. The final setting in this section is “Server Configurations“. Pressing the “plus” button allows you to add a new HTTP server policy configuration. You can set the “Engine Name“, as well an alias for the IP list to which the engine will be bound (you can specify “all” to bind the engine to all HTTP servers). The “Target Web Server Personality” allows you to choose the web server personality appropriate for the protected hosts. The default value is “IDS“, but you can set it for Apache 2 and different versions of Microsoft’s Internet Information Services. Below that are parameters for the request body limit and the response body limit, specifying the maximum number of HTTP request body and response body bytes to inspect, respectively. The default in each case is 4096 bytes. Setting either parameter to 0 causes Suricata to inspect the entire client-body or server-body. Finally, there are “Decode Settings“, which if set, will allow Suricata to decode the path and query. Checking the “URI Include-All” check box will include username, password, hostname and port in the normalized URI. Press “Save” at the bottom of the page to save settings for the server configuration or “Cancel” to cancel.

The last heading is “Other App-Layer Parser Settings“. Here, you can set detection and parsing options for several application-layer protocols such as TLS and SMTP. Each protocol has the option of [1] enabling detection and parsing; [2] disabling both detection and parsing, or [3] enabling detection but disabling parsing (“detection-only”). You can press “Save” to save your settings before you exit or “Reset“. Pressing sabe will rebuild the rules file, which may take several seconds. Suricata must also be restarted to activate any changes made.

Finally, the “Variables” tab allows you to set variables which can be used in rules. This prevents you from having to set IP addresses rule by rule. For example, after HOME_NET you can enter your home-IP address. Press “Save” at the bottom when you are done setting these variables.

That covers interface setup. Now that we have at least one interface configured, we can look at the logs. We will cover log settings in the next article.

External Links:

The official Suricata web site

Snort Security Optimization

snort securityIn the previous two articles (part one part two), I discussed the installation of snort. In this article, I will mention some ways to improve snort security.

Improving Snort Security

One of the snort security issues is preventing unauthorized access to a privileged account. There are several ways of preventing this. First, when running snort in daemon (-D) mode, the user (-u) and group (-g) switches should be used. This will allow snort to run as a given user and group after it is initialized. Typically, most system administrators prefer to add the snort user and group to their systems, and that the snort user should be unable to login or initiate shell privileges.

Second, the source code for snort/DAQ binaries, logging directories, shared/static libraries, and configuration files should all be owned by the snort user with appropriate permissions. Finally, all binaries which are produced by the compiling and installation process of snort and DAQ should be verified using a hash function and the output stored on removable media. A cron job could be used to run this process on a regular basis with results e-mailed to a system administrator. Another alternative would be the use of a utility called tripwire for auditing installed software on a computer. All of these measures are excellent ways of increasing snort security.

Mirroring or Copying Network Traffic to Snort

In addition, your small office/home office (SOHO) router can be used to mirror or copy network traffic to a snort sensor running on a standalone system or to a virtual machine running in VirtualBox, VMWare, or Xen. This method of improving snort security can be easily done provided you have a router that is running DD-WRT, OpenWRT, or Tomato as the firmware. If you are running Tomato, you may have to add the following to your startup script:

modprobe ipt ROUTE

Users of OpenWRT must use the Tee option for IPtable (provided by module iptables-mod-tee). The module “iptabels-mod-tee” must be loaded before the following command will work:

iptables -t mangle-A PREROUTING -j TEE -gateway x.x.x.x

Where x.x.x.x is an IP address you wish to mirror traffic to (usually a system running snort). It should be noted that in more recent versions of OpenWRT (10.03.1 and never), iptables-mod-tee does not seem to be enabled by default, and using it will require a rebuild/re-enabling of modules for OpenWRT.

Now, using DD-WRT or Tomato’s GUI (or SSHing into the router), issue the following commands:

iptables -A PREROUTING -t mangle -j ROUTE -gw x.x.x.x -tee

iptables -A POSTROUTING -t mangle -j ROUTE -gw x.x.x.x -tee

In each case, x.x.x.x is the address of the machine running snort. To stop mirroring traffic, type

iptables -F -t mangle

If you have snort running in test mode (-T option), try starting snort with /etc/rc.d/snort start (you should get a running message if snort is running properly). If there is a problem, check the output in /var/log/messages. Also, you can check the status of snort by issuing this command:

./snort status

External Links:

How to make some home routers mirror traffic to Snort at




Snort Installation in pfSense: Part Two

snort installationIn part one of this series, we began our look at snort installation. In this article, we continue the process.

Next, add a directory to /usr/local/lib:

cd /usr/local/lib
mkdir snort_dynamicrules

Add the following line to file /etc/passwd (or use the “useradd” or “adduser” command):


Issue the commands below in order to take ownership of all files in /etc/snort:

cd /etc/snort
chown -R snort:snort *

Locate and modify the following variables in your snort.conf file (in directory /etc/snort) as follows (found between lines 40 and 120 in snort.conf):

This assumes the network you are going to monitor is

var RULE_PATH /etc/snort/rules
ipvar HOME_NET
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules
var WHITE_LIST_PATH /etc/snort/rules
var BLACK_LIST_PATH /etc/snort/rules

You will also need an initialization script. You can find one for FreeBSD 8.x at the official snort website. Place this script into the /etc/rc.d directory on your pfSense box.

You also want to make a symbolic link (symlink) in /usr/sbin to point to where the actual snort binary was compiled. You could also copy the snort binary to /usr/sbin as well. To make the symlink, issue these commands:

cd /usr/sbin
ln -s /usr/local/bin/snort snort
chmod 700 snort

If the directory “/var/log/snort” does not exist on your system, issue the following commands as “root”:

cd /var/log
mkdir snort
chmod 700 snort
chown -R snort:snort snort

The commands below will also change the ownership of the directories and files to user “snort” and group “snort:

cd /usr/local/lib
chown -R snort:snort snort*
chown -R snort:snort snort_dynamic*
chown -R snort:snort pkgconfig
chown -R 700 snort*
chown -R 700 pkgconfig
cd /etc
chown -r snort:snort snort
chmod -R 700 snort

Testing Your Snort Installation

At this point, you should be ready to do some testing of snort to see if it actually starts up and reads in the rules. You can check /var/log/messages to catch any fatal errors or crashes.

If you want to test snort startup, issue the following commands:

cd /usr/local/bin
./snort -T -i em0 -u snort -g snort -c /etc/snort/snort.conf

The above command will cause snort to start up in self-test mode, checking all the supplied command line switches and rules files that are passed to it and indicating that everything is ready to proceed. If all the tests are passed, you should see the following:

Snort successfully validated the configuration!
Snort exiting

If no errors are returned, you can proceed. To manually start snort, issue the following commands:

cd /usr/local/bin
 ./snort -i em0 -D -u snort -g snort -c /etc/snort/snort.conf

Make sure that snort initializes properly before proceeding below, you can check /var/log/messages for more information in the event of an error in initialization.

To see if snort is actually running on the system, you can check which processes are running, like so:

ps aux | grep -i “snort”

If snort is working, it should return output that indicates snort is a running process, like so:

19633 ?? Ss 0:00:04 /usr/local/bin/snort -D -i em0 -u snort -g snort -c /etc/snort/snort/conf -l /var/log/snort/

External Links:

The official snort website


Snort Installation in pfSense: Part One

snort installationIf you are running pfSense and are looking for an additional means of securing your network, you may consider installing snort on your pfSense system. Snort installation will be the subject of this next series of articles. Snort is an open source network intrusion prevention system (NIDS), capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching and matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort has three primary uses. It can be used as a straight packet sniffer like tcpdump, a packet logger, or as a full-blown network intrusion prevention system. In sniffer mode, the program will read network packets and display them on the console. In sniffer mode, the porgram will read network packets and display them on the console. In packet logger mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified.

Snort Installation Under FreeBSD 8.x

Snort installation on a  pfSense box begins with  SSHing into the system to access the shell prompt. If you have a recent version of pfSense (2.0 or newer), it should be running under FreeBSD 8.1 or newer. You will need to install the following package via pkg_add: gcc version 4.2.x (including libraries), zlib (1.2.3), libpcap (1.0.0 including libpcap-devel), pcre (8.32), bison (2.7), m4 (1.4.16), flex (2.5.4 including flex-devel), libdnet (1.11 including libdnet-devel), and tcpdump (4.0.0). Versions of these package can be newer than what is listed here. Then download the source code for snort at the official snort website. Download the archive to /usr/local/src. Type the following commands to unpack snort:

cd /usr/local/src
tar -zxvfsnort-

Once you have unpacked snort, do the following to compile snort:

cd /usr/local/src/snort-
./configure -enable-sourcefire
make install

Note any errors which may cause the “configure” step to abort and also check the file “config.log” which is generated from the “configure” line above.

In order to download snort rules from, you must be a registered user or have a paid subscription to download rules sets or VRT rules. Registered users will be able to download rule sets which are approximately one month behind what is available to paid subscription holders.

Continue snort installation by issuing the commands below to copy the configuration files to /etc/snort:

cd /etc
mkdir -p snort
cd snort
cp /usr/local/src/snort-*.
tar -zvxf snortrules-snapshot-.tar.gz
touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rules

This will place the configuration files from the snort unpack and the rules snapshot under the /etc/snort directory. If the rules snapshot file is newer, this is not an issue (since rules are updated on a periodic basis by the snort team). Also, the configuration files are residing in /etc/snort and the rules files will be in /etc/snort/rules and the so_and preprocessor rules will be located in /etc/snort.

In the next article, we will continue our look at snort installation under pfSense.

External Links:

The official snort web site

Ad Links:

© 2013 David Zientara. All rights reserved. Privacy Policy