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

Wireless Support in pfSense

wirelessFirst, I should mention that this is the 100th post on this blog, which if nothing else, shows an unusual (for me) level of persistance on my part. Thanks to all who have visited this blog, visited this site’s Facebook page, or subscribed to this blog’s Twitter feed. I have a number of ideas on how to improve this blog, and I hope to implement some of them in the near future. Now, onto the topic of today’s posting: wireless support in pfSense.

pfSense includes built-in wireless capabilities that allow you to either turn your pfSense box into a wireless access point, use a wireless 802.11 connection as a WAN connection, or both. You can also use another wireless router in conjunction with pfSense. But if you want to use the built-in wireless capabilties, you first need one or more wireless cards supported by pfSense.

FreeBSD has supported wireless cards for a number of years, and there are a variety of wireless cards supported in FreeBSD 8.3. Needless to say, pfSense includes support for every card supported by FreeBSD, although some are supported better than others. Most pfSense developers work with Atheros hardware, so it tends to be the most recommended hardware. Many users have had success with other cards, however, and Ralink is also a popular choice. Other cards may be supported, but do not support all available features. For example, some Intel cards can be used in infrastructure mode but cannot be run in access point mode due to limitations of the hardware itself.


Another factor to take into account is that major wireless card manufacturers commonly change the chipsets used in their wireless cards without changing the model number. As a result, there is no way to ensure a specific model card from these vendors will be compatible, since you have no way of knowing which minor card revision you will end up with. While one revision of a model may be compatible and work, another card of the same model may be incompatible. For this reason, it may be a good idea to avoid cards from major manufacturers such as Linksys, D-Link and Netgear, although if you already have one, it is worth trying to see if it is compatible.

Supported Wireless Drivers

The following drivers are included in pfSense 1.2.1 and newer kernels:

  • ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets. The following cards are known to work in pfSense:
    • CB9-GP-EXT Cardbus/PCMCIA
    • 5004 MP Atheros 4G
    • DCMA-82 Atheros 6G
    • DCMA-82 Industrial Temp
  • rai(4): Ralink Technology IEEE 802.11 wireless network driver – supports cards based on the Ralink Technology RT2500, RT2501 and RT2600 chipsets. There are too many cards supported to list, but the FreeBSD man page for ral has a list of supported cards.
  • wi(4): Lucent Hermes, Intersil PRISM and Spectrum24’s IEEE702.11 driver supports cards based on the Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil, Prism-3, and Symbol Spectrum24 chipsets. These cards support only 802.11b, and a list of cards supported can be found at the FreeBSD man mage for wi.
  • an(4): Aironet Communications 4500/4800 wireless network adapter driver supports Aironet Communications wireless network adapters and variants, such as:
    • Aironet Communications 4500 and 4800 series
    • Cisco Aironet 340 and 350 series
    • Xircom Wireless Ethernet Adapter
  • awi(4): AMD PCnetMobile IEEE 802.11 PCMCIA wireless network drive – supports cards based on the AMD 70c930 controller with Intersil PRISM radio chipset, such as:
    • BayStack 650
    • BayStack 660
    • Icom SL-200
    • Melco WLI-PCM
    • NEL SSMagic
    • Netwave AirSurfer Plus
    • Netwave AirSurfer Pro
    • Nokia C020 WLAN
    • Farallon SkyLINE

With the release of pfSense 2.0, even more wireless cards were supported. Again, the list is too large to include here, but there is a spreadsheet of compatible wireless cards that should work with 2.0. Be aware of the “hostap” column, which shows drivers capable of running in wireless access point mode. If that column is marked “N”, then the card could only be used as a client. The second tab on the sheet lists part numbers for a given driver.

In the next article in this series, I will cover how to configure your wireless card.


External Links:

Supported Wireless Cards at doc.pfsense.org

Ad Links:




Failover with CARP in PF: Part One

Failover with CARP in PF

FailoverCommon Address Redundancy Protocol (CARP) is a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. It was developed as a non-patent-encumbered alternative to Virtual Router Redundancy Protocol (VRRP), which is defined in RFC 2281 and 3768 and was quite far along towards becoming an IETF-sanctioned standard. It is also an alternative to the Hot Standby Router Protocol (HSRP). It manages failover at the intersection of the link layer and IP layer of the OSI model. Each CARP group has a virtual MAC address, and the CARP advertisements are sent out with this as the source address, which helps switches determine which port the virtual MAC address is currently at.

One of the main purposes of CARP is to ensure that the network will keep functioning even when a firewall goes down because of errors or planned maintenance activities such as upgrades (failover). CARP works by allowing a group of hosts on the same network segment to share an IP address. This group of hosts is referred to as a “redundancy group”. The redundancy group is assigned an IP address that is shared among the group members. Within the group, one host is designated as the master and the other as backups. The master host is the one that currently holds the shared IP; it responds to any traffic or ARP requests directed at it. If the master goes down, one of the backups will inherit the IP address. The handover from one CARP host to another may be authenticated, essentially by setting a shared secret, much like a password. The master then sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises the most frequently is the one most likely to become master in the event of a failure.


CARP is rather similar to VRRP, with a few significant differences:

  • The CARP protocol is address family independent, with the OpenBSD implementation supporting both IPv4 and IPv6.
  • CARP has an “arpbalance” feature that allows multiple hosts to share a single IP address simultaneously (in this configuration, there is a virtual MAC address for each host, but only one IP address).
  • CARP uses a cryptographically strong SHA-1 keyed-hash message authentication code (HMAC) to protect each advertisement.

Some synchronization is required, an at least in the case of PF firewalls, pfsync can handle it. If it is done properly, active connections will be handed over without noticeable interruption. The purpose of pfsync in this context is to act as a virtual network interface specially designed to synchronize state information between PF firewalls. In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local link layer access to the subnet used for pfsync traffic can add, change, or remove states from the firewalls. Therefore, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls.


Failover with CARP: Configuration

Here is a simple example CARP configuration:

sysctl -w net.inet.card.allow=1
ifconfig carp1 create
ifconfig carp1 vhid 1 pass password carpdev em0 \
advskew 100 10.0.0.1 netmask 255.255.255.0

This does the following:

  • Enales receipt of CARP packets (the default setting)
  • Creates a carp(4) interface (carp1)
  • Configures carp1 for virtual host #1, enables a password, sets em0 as the interface belonging to the group, and makes the host a backup die to the advskew of 100 (assuming the master has an advskew less than 100). The shared IP assigned to this group is 10.0.0.1/255.255.255.0.

In the next article, I will cover failover CARP configuration in BSD with some real world scenarios.

External Links:

Firewall Redundancy with CARP and pfsync at openbsd.org

Firewall Failover with pfsync and CARP at countersiege.com

Packet Filter: The Engine of pfSense

Packet FilterpfSense is, as most users know, a specialized version of FreeBSD. It can be configured an upgraded through a web-based interface and often runs on embedded systems; it requires no knowledge of the underlying FreeBSD system. Those curious enough to find out, however, will be interested to know that pfSense is based on OpenBSD’s powerful pf (Packet Filter) software, which was released in late 2001 and has since been ported to many other operating systems including FreeBSD, NetBSD, DragonFly BSD, Debian GNU/Free BSD, and Mac OS X 10.7 “Lion” and later.

OpenBSD and the other BSD variants are direct descendants of BSD Unix. BSD, sometimes called Berkeley Unix, is a Unix operating system derivative developed and distributed by the Computer Systems Research Group (CSRG) of the University of California, Berkeley, from 1977 to 1995. The final release from Berkely was 1995’s 4.4BSD-Lite Release 2, after which the CSRG was dissolved and development of BSD at Berkeley ceased. In the meantime, as CSRG was winding down, small groups of enthusiasts around the world began working on further development of the code. Several different variants of BSD Unix came into existence. The OpenBSD group became known as the most security-oriented of the BSDs. For its packet filtering needs, it used a program called IPFilter, written by Darren Reed.


The packet filter’s main function is to filter network packets by matching the properties of individual packets and the network connections build from those packets agains the filtering criteria defined in its configuration files. The packet filter is responsible for deciding what to do with those packets, which could mean passing them through or rejecting them, or triggering events that other parts of the operating system or external applications are set up to handle.

The IPFilter subsystem performed this function within OpenBSD, but in May 2001, IPFilter was removed from the OpenBSD source tree due to licensing issues. The OpenBSD version of IPFilter contained several changes and customizations that, as it turned out, were not allowed under the licensing agreement. For a few weeks, the development version of OpenBSD did not include any firewalling software.


Enter Packet Filter

However, Daniel Hartmeier had already begun work on his own packet filtering software, called PF, and after a few months of development, it was ready to be added to OpenBSD. PF was added as a default part of the OpenBSD 3.0 base system in December 2001. Migrating from IPFilter to PF sense did not pose major problems, as their configuration languages were similar. Moreover, PF has done well in performance tests, performing equally well or better under stress on OpenBSD 3.1 than either IPFilter on OpenBSD 3.1 (or iptables on Linux). PF’s overhead is relatively low, and is capable of running effectively on rather modest hardware.

Future installments of this series of articles will go into greater depth on how to configure and run PF. For now, it should be mentioned that in order to run PF, you need to install and run a BSD system such as OpenBSD, FreeBSD, NetBSD, or DragonFly BSD. OpenBSD is the BSD variant of choice for many, as this is where PF was first introduced and where essentially all PF development happens. Moreover, the newest and most-up-to-date PF code is always to be found on OpenBSD. If you are planning to run PF on FreeBSD, NetBSD, DragonFly BSD, or another system, you should check your system’s release notes and other documentation about which version of PF is included.

External Links:

PF documentation in the OpenBSD FAQ

© 2013 David Zientara. All rights reserved. Privacy Policy