Suricata Intrusion Detection System: Part Two

Suricata

Defining a pass list in Suricata.

In the first article about Suricata, we covered basic installation as well as global settings. In this article, we will continue our look at configuration.

In Global Settings, you must choose a set of rules to download, as well as update settings for those rules. Once you do that and save the settings, you can move on to the “Update Rules” tab. I chose the ETOpen rule and Snort VRT rules, set my update interval to 12 hours, and my update start time to 04:00, and saved the settings.

By clicking on the “Update Rules” tab, you can download the enabled rule sets. Under “Update Your Rule Set“, you can press “Check“, which will download an update if available, or “Force” to force an update. A separate screen will load once downloading begins; press the “Return” button to return to the “Update Rules” tab. The “Installed Rule Set MD5 Signature” should now be updated with both the MD5 signature hash and MD5 signature date of the downloaded rules. You can also view the log by clicking on the “View” button.

If you are running Suricata for the first time, you can skip past the “Alerts” and “Blocked” tabs for now, and go straight to “Pass Lists“. Here you can create pass lists, which are lists of hosts which will never be blocked by Suricata. Click on the “plus” button on the right side to add a pass list. You can specify a “Name” and “Description” for the file in the top two edit boxes. In the “Add auto-generated IP Addresses” section, there are six check boxes covering categories such as local networks, WAN IPs, and VPNs. Check whichever categories of IPs you don’t want to be blocked. Beneath that is the “Assigned Aliases” edit box, which allows you to add a custom IP address from a configured alias. If you have any aliases that you do not want to be blocked, you can add them here. Press the “Save” button at the bottom of the page to save these settings.


Adding an Interface with Suricata

You should be ready to add your first Suricata interface now. Click on the “Suricata Interfaces” tab and press the “plus” button on the right side of the page to add an interface. Once you do, there will be seven new additional tabs covering all the settings for that interface. On the first tab, there are several sections. In “General Settings“, the “Enable” check box will enable Suricata inspection on the interface. The “Interface” dropdown box allows you to select the interface. In this case, we will leave it set to WAN. In the “Description” field; we can enter a meaningful description for this interface; we’ll leave it as “WAN“. In “Logging Settings“, you can set a number of preferences related to logging, but we should take note of a few of these settings. First there is the “Send Alerts to System Log” (to send alerts to the firewall’s system log) and “Enable Stats Log” (to log statistics for the interface). Next is the “Stats Update Interval” (in seconds). The default is 10 seconds. If you’re concerned about the size of the log file, you may want to alter “Max Packet Log File Size” (the maximum size in megabytes of the packet log file) and “Max Packet Log Files” (the maximum number of packet log files to maintain).

The next section is “Alert Settings“. The “Block Offenders” check box will automatically block hosts that generate a Suricata alert. Once a host is blocked, they may still have entries in the firewall’s state table and persistent connections; checking the “Kill States” check box will kill firewall states for the blocked IP so the host will no longer have access through your firewall. The “Which IP to Block” dropdown list allows you to select which IP from the packet you wish to block: the source IP, destination IP, or both. Choosing both is the recommended option and is the default value.

Scrolling further down the page, we reach the “Networks Suricata Should Inspect and Protect” section. The “Home Net” dropdown box allows you to define the home net you want this interface to use; the default is local networks, WAN IPs, gateways, VPNs and virtual IPs, but you can create an alias to define friendly IPs. The “External Net” dropdown box defines networks not in the home net. The “Pass List” allows you to choose the pass list you want this interface to use; if you defined one or more pass lists earlier, you can specify them here. Clicking on the “Save” button at the bottom of the page allows you to save these settings.

This is a good start, but we have only scratched the surface on interface settings. In the next article, we we continue our look at these settings.


External Links:

The official Suricata web site

Suricata Intrusion Detection System: Part One

Suricata

The global settings tab in Suricata.

Suricata is an open source-based intrusion detection system (IDS). There are several advantages to running Suricata. [1] It is multi-threaded, so you can run one instance and it will balance the load processing across every processor. [2] The most common protocols are automatically recognized by Suricata as the stream starts, allowing rule writers to write a rule to the protocol, not to the port expected. [3] Suricata can identify thousands of file types on your network, and you can tag files for extraction so the file will be written to disk with a metadata file describing the capture situation and flow. Another advantage of Suricata is that it is compatible with Snort rules, so while it is an alternative to Snort, you can still use Snort updates. Suricata has been available as a pfSense package since March 2014; you must be running pfSense 2.1 or later to install the Suricata pfSense package.

Suricata Installation and Configuration

Suricata can easily be downloaded, compiled and installed under FreeBSD (the underlying OS for pfSense). The installation instructions can be found at the official Suricata website for FreeBSD 8 and later. Fortunately, if you are running pfSense 2.1 or later, you can just install Suricata from the package menu and configure it from the GUI. In this case, just navigate to System -> Packages, scroll down to Suricata in the package listing, and press the “plus” button on the right side of the row. On the next screen, press “Confirm” to confirm installation. It will take several minutes for the package installer to download, install and configure Suricata.


Once the package installer is done, there will be a new option on the “Services” menu called “Suricata”. You can now navigate to Services -> Suricata and begin configuration. The first step is to configure global settings, which you can do by clicking on the “Global Settings” tab. The first part of the page configures which rules you want to download. The first setting is “Install Emerging Threats rules“, which allows you to install ETOpen and ETPro. ETOpen is an open source set of Snort rules, while ETPro for Snort offers daily updates and extensive coverage of current malware threats. ETPro offers more extensive coverage of threats, but costs $500 a year. The “Install Snort VRT rules” check box allows you to install either Snort VRT free registered user or paid subscriber rules. The next option is “Install Snort Community rules“. Checking this check box will install the Snort Community Ruleset – a GPLv2 VRT-certified ruleset that is distributed free of charge without any VRT License restrictions. [If you are a Snort VRT paid subscriber, the community ruleset is already built into the Snort VRT rules, so you don’t need to install this.]

Next is the “Rules Update Settings” section. In the “Update Interval” dropdown box, you can select the interval for rule updates. Choosing NEVER disables auto-updates. The options range from 6 hours to 28 days, as well as never for no updates. Below that is the “Update Start Time” edit box, where you can enter the rule update start time in 24-hour format (the default is 00:30). Finally, the “Live Rule Swap on Update” check box, if checked, enables a “live swap” reload of the rules after downloading an update instead of a hard restart. [If you encounter problems with live reloads, you should probably uncheck this option.]

The final section on the “Global Settings” tab is “General Settings“. The “Remove Blocked Hosts Interval” dropdown box allows you to select the amount of time you would like hosts to be blocked (values run from 15 minutes to 28 days; never is also an option). The “Log to System Log” check box enables copying of Suricata mesages to the firewall system log. The “Keep Suricata Settings After Disinstall” checkbox, if checked will not remove any changed settings during package deinstallation. Press the “Save” button at the bottom of the page to save settings.

In the next article, we will continue our look at Suricata settings.


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 www.snort.org

DD-WRT

OpenWRT

Tomato

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

snort:*:40000:snort

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 192.168.1.0/24:

var RULE_PATH /etc/snort/rules
ipvar HOME_NET 192.168.1.0/24
ipvar EXTERNAL_NET !$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-2.9.5.5.tar.gz


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

cd /usr/local/src/snort-2.9.5.5
./configure -enable-sourcefire
make
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 www.snort.org, 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-2.9.5.5/etc/*.
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 2.9.5.5 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