Welcome to the Adventures in Suricata series! Over the past couple months I have been exploring Suricata, an open source Intrusion Detection System (IDS), by standing it up in my virtualized ESXi server at home. By sharing my own experiences with you, I hope to overcome the misconception that IDS is only viable for large networks and/or enterprises. This misconception usually stems from the cost associated with monitoring tools; however, Suricata is free to use and can be implemented on a virtualized server or spare computer. In this blog post, I will show you how to set up the networking and what supporting systems are necessary. Note: Suricata can run on top of many different operating systems, including Linux, FreeBSD, OpenBSD, Max OS X, and Windows.
Before implementing this or any other IDS, some planning and decision making is required. I can tell you from firsthand experience that this is important even on a small network. Part way through my own installation, I had to start from scratch once I realized that my network topology would not be well suited for what I wanted to do. Since I was running my entire network on a virtualized ESXi server, including routing, it was impossible to implement it the way that I wanted to. The two big decisions that I had to make to go forward was how I wanted to use Suricata, and how I would have to configure the networking so that Suricata could monitor all inbound and outbound traffic.
Decision #1: How to use Suricata
There are essentially three ways that you can use Suricata. The setup is still the same – it really just depends on where you place it on your .
By installing it on a single stand-alone system, traffic to and from that computer can be monitored. This is not exactly practical or efficient for an actual network, but can be a great starting point if you are interested in learning more about how to configure it.
In this scenario, a system with Suricata receives a copy of all traffic that is being sent to the network. Whenever it identifies something malicious it can throw the red flag and alert you. The bad news would that the traffic already made it to your network, but having received the alert you can at least take the steps needed to clean up after the incident. There are a few ways to send a copy of inbound/outbound network packets to Suricata, you would need to
The most robust method of using Suricata is to have it inspect all inbound and outbound traffic. This gives the system the ability to not only alert on malicious traffic, but actively stop it from entering your network. In this way, it is more like an Intrusion Prevention System (IPS).
Decision #2: Planning the Network
For me, the trickiest part was figuring out how to get Suricata into my network so that it could monitor all inbound and outbound traffic. In my home lab, I run an ESXi server cards. Instead of having a separate router, I use an open source router/firewall called pfSense. All traffic flows into the server on one networking card, which pfSense uses as a WAN port. The second port is used for my LAN, which also hosts other virtual systems. Whether you do it this way, or have a separate router, the concept is pretty much the same. Suricata has to act as a bridge if you want it to be an active inline IDS/
Setting up Suricata
Now that you know what you want Suricata to monitor and where it can be implemented, you can begin to install and configure. There are a lot of different ways to do what I did, so some tweaking may be required if you are interested in doing it a little differently. I will also be linking to a few other websites that I followed along the way, rather than regurgitate information and not give the proper credit.
Step 1: Prepare the System
Before you even install Suricata, you will want to prepare the system that will be running it. I ultimately chose to run it on Ubuntu Server just out of personal preference, but many other systems support it as well (Linux, Unix, and Windows systems).
To setup up the bridge, the system will need to have two network cards. In my case, one network card was virtual, and the other physical. Both network cards will be placed in separate subnets – One card should be on the same subnet as the router, while the other should be the same as your LAN. The IP you configure on this side will ultimately be the default gateway for your LAN.
On Ubuntu, the commands that I used to create the bridge are below. These will work on any Linux/Unix system that supports iptables. Note that eth0 was my external interface (router facing) and eth1 was internal one (LAN facing):
# echo 1 > /proc/sys/net/ipv4/ip_forward
Configure forwarding on interfaces
# /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# /sbin/iptables -A FORWARD -i eth0 -o eth1 -m state
–state RELATED,ESTABLISHED -j ACCEPT
# /sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
Save rules (otherwise they will be erased on reboot)
The full article that explains the bridging configuration on Linux and Unix systems can be found here: http://www.revsys.com/writings/quicktips/nat.html
Step 2: Install and Configure
Once your system is successfully bridging traffic between your local network and the internet, you can install Suricata. In my experience this has been a pretty painless process. The commands that I used on Ubuntu can be found below. If you are installing on other operating systems below, you can refer to the guides found on this page: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_installation
Install Dependencies for Suricata
sudo apt-get -y install libpcre3 libpcre3-dbg libpcre3-dev \
build-essential autoconf automake libtool libpcap-dev libnet1-dev \
libyaml-0-2 libyaml-dev zlib1g zlib1g-dev libcap-ng-dev libcap-ng0 \
make libmagic-dev libjansson-dev libjansson4 pkg-config
Install Dependencies for Suricata’s IPS functionality
sudo apt-get -y install libnetfilter-queue-dev libnetfilter-queue1 libnfnetlink-dev libnfnetlink0
tar -xvzf “suricata-3.0.tar.gz”
Run Auto-Setup (Install Suricata and download rulesets)
./configure && make && make install-full
Vi /etc/suricata/suricata.yaml –
I also had an issue where my default logging directory was not logging to a location that I expected. To resolve this, I simply went into the same suricata.yaml file and changed the default logging directory to /etc/var/suricata.
For further guidance on configuring variables, refer to the following article: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Basic_Setup
Finally – Start Suricata
sudo suricata -c /etc/suricata/suricata.yaml -i wlan0 –init-errors-fatal
Step 3: Install and Manage Rules
For Suricata to be effective, it has to be updated with rules. These rules, alsocalled signatures, tell it what malicious traffic and IP addresses look like. It is recommended that you take advantage of an already existing feed, called Emerging Threats, which is updated with rules daily. It is also recommended that you use a rule management tool called Oinkmaster. Once installed, a simple command will update Suricata with new rules. To install Oinkmaster, the following commands can be used:
sudo apt-get install oinkmaster
sudo vi /etc/oinkmaster.conf
Change the url for the rule feeds to:
sudo mkdir /etc/suricata/rules
The full guide to install Oinkmaster can be found here:
You can automate the rule update process so that you don’t have to do it yourself daily, or risk falling behind. In Linux/Unix, this can be done by creating a cronjob on the command to update the ruleset (sudo oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules)
This site also includes the folder of the Emerging Threat rules, which you can navigate to view the rules and blacklisted IP addresses that it contains. This folder can be found at: http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
At this point Suricata should be up and running with up-to-date rules, and blocking any traffic that is flagged by those rules. Suricata does not come with a any way to monitor traffic that is being blocked. If you want to have transparency over any activity, you have to rely on a third party monitoring tool. For the next post, I am going to install two different event monitoring tools (Snorby and OSSIM) and try to see if one works better with Suricata than the other.
Thanks to the people at SealingTech who listened to what I was trying to do and helped me figure out the network bridge: Dan Lohin, Tony Efantis, Kevin Roberts, and Anthony Sae-Chua.