Detecting intruders with Suricata
Finder
In the past, network attackers were much like purse grabbers or "smash and grab" muggers: They would find something they wanted, grab the goods, and run. Today's Advance Persistent Threats (APT) are much more insidious and dangerous. Instead of smashing and grabbing, attackers can find a way to steal your identity and hang around for a long period of time (see the box titled "Dwell Time." To thwart this type of long-term attacker, you need a different, more methodical approach.
Dwell Time
Most organizations are already at the 80% threshold in regard to security. Getting to 90% and above requires hard work and smart allocation of resources. A custom framework is part of the solution. In addition, you need to be aware of the attacker lifecycle:
1. Initial attack: The attacker is able to gain access to the system.
2. Lateral movement: The attacker moves from one system to the next, usually by exploiting unsecured systems or trust relationships between systems.
3. Exfiltration: The attacker moves data from the internal network to a remote network.
The key to arresting the hacker lifecycle is to reduce the dwell time – the time between the initial attack and detection. One security professional I know told me that his daily goal is to reduce dwell time from 14 days to 3 days.
The concept of dwell time contradicts the philosophy embodied in many traditional security metrics. Many people still feel the most important thing is to focus on the number of vulnerabilities found and solved. However, a single attacker only needs one vulnerability to get in; the dwell time on the network is often a much better indicator of the severity of the attack and the insecurity of the network. The key to reducing dwell time and creating a truly resilient defense is deceptively simple: Protect the data where it resides. Focus on pathways to that data when creating a framework.
If the key is to reduce dwell time and identify lurkers, you will need to focus on:
- Tunneled traffic that originates from a legitimate system but is going to an unknown network. This traffic is often encrypted.
- Suspicious traffic that occurs over a long period of time. If I were going to attack a system, I would first discover all of the resources. I would take weeks to conduct my reconnaissance in order to not be detected. I would also use small amounts of traffic each time so that my activity falls below defined intrusion detection thresholds.
The following rule could be used to identify traffic tunneled in DNS query traffic, which uses UDP port 53:
alert udp $EXTERNAL_NET any - > $HOME_NET 53 (msg:"Potential NSTX DNS Tunneling"; content:"|01 00|"; offset:2; w ithin:4; content:"cT"; offset:12; depth:3; content:"|00 10 00 01|"; within:255; class type:bad - unknown; sid:1000 2;
The preceding rule inspects the DNS traffic for any particular embedded information, which could possibly include information about the e-commerce or database server.
For many admins, the Snort Intrusion Detection and Prevention System (IDS/IPS) [1] is the first line of defense, but alternative tools also exist – and some of those alternatives offer advantages in certain situations. This article describes Suricata [2], an open source IDS/IPS sponsored by the Open Information Security Foundation (OISF) [3]. Suricata can read Snort rulesets, which makes it easy to support both systems or even migrate if you decide that one of the tools is better suited to your environment.
Why Suricata?
The homepage of the Suricata website begins with the developers' own list of "Top 3 Reasons You Should Try Suricata":
- Highly Scalable – Suricata is multi-threaded, which maximizes the efficiency of a system configured to work as a Suricata sensor. According to the developers, you can achieve 10-Gbit speeds on real traffic without sacrificing ruleset coverage.
- Protocol Identification – The most common protocols are automatically recognized by Suricata as the stream starts, thus allowing rule writers to write a rule to the protocol, not the expected port.
- File Identification, MD5 Checksums, and File Extraction – Suricata can identify thousands of file types. Suricata also calculates MD5 checksums on the fly, so you can monitor changes to system files or search for malware files with known checksum values.
A quick comparison with the popular, and also powerful, Snort is perhaps the best way to begin. Suricata has a completely different code base, even though it supports Snort-based rules. Figure 1 shows how Snort operates when it is detecting traffic. The packet sniffing, pre-processor, and detection engines are completely separate.
Notice especially how Snort separates the sniffer and preprocessor functions. These functions allow Snort to quickly grab network data, then process it quickly before applying rules. The ruleset function is separate.
Snort's creators have a good reason for separating these functions: The preprocessor function allows Snort to quickly identify certain traffic streams. Otherwise, applying rules to certain traffic streams would take considerable time and very quickly result in a situation where even moderate amounts of network traffic would overwhelm Snort.
Figure 2 shows the Suricata packet processing system. Notice the difference: Whereas Snort typically has a separate sniffer and preprocessor function, Suricata unifies this process when acquiring packets. Also notice that Suricata has a separate decoding function that allows it to inspect the data stream at the application layer. Then, Suricata is able to apply a chain of detection strings. The result is then sent to the network screen, or to a database to save for a later time. The result of this process is that Suricata seems to take a more layered approach to reading and sifting through information.
Both Snort and Suricata have advantages, but for some situations, Suricata might be a better option.
Installing Suricata
Like Snort, Suricata is an open source intrusion detection system that is also capable of intrusion prevention. In other words, Suricata won't just identify attacks; it can also reach out onto the network and disrupt traffic it marks as suspicious. Suricata has a stable code base, and it is used throughout the industry. Although hardly as widely adopted as Snort, Suricata has the ability to monitor both IPv4 and IPv6 traffic, as well as identify security issues. Suricata is quite flexible, and it runs on all flavors of Linux. As of this writing, the latest stable version of Suricata is 2.07.
To install Suricata with both intrusion detection and intrusion prevention capabilities, you will want to install the Libp supporting libraries:
$ 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
Once finished with these support packages, you can grab Suricata from the web site:
$ wget \ http://www.openinfosecfoundation.org/\ download/suricata-2.0.7.tar.gz tar -xvzf suricata-2.0.7.tar.gz cd suricata-2.0.7
Then, take the typical steps to compile the source files into a binary:
./configure --prefix=/usr \ --sysconfdir=/etc --localstatedir=/var make sudo make install sudo ldconfig
I've found that it's sometimes necessary to manually create a log folder, as follows:
$ sudo mkdir /var/log/suricata $ sudo mkdir /etc/suricata
Make sure these folders are owned by the Suricata process, as well as by root. Then, copy the files into the proper directories:
$ sudo cp classification.config /etc/suricata $ sudo cp reference.config /etc/suricata $ sudo cp suricata.yaml /etc/suricata
Congratulations! You now have a working version of Suricata. Understand, though, that Suricata currently doesn't have any rules installed. If you wish, you can download rules from Snort or obtain them from co-workers or third-party sources. You can also download default rule files from the Emerging Threats project. I don't find that these rules are all that special, but they make for a good foundation that you can build on and customize. To obtain the default rules, do:
$ wget \ http://rules.emergingthreats.net/\ open/suricata/emerging.rules.tar.gz tar zxvf emerging.rules.tar.gz cp -r rules /etc/suricata/
Once you have downloaded and copied some rules, it's time to start Suricata to make sure it works. If, for example, you have a typical eth0 interface, you would issue the following command to start the application:
$ sudo suricata -c \ /etc/suricata/suricata.yaml -i eth0
Once Suricata has started, you can use the suricatasc
command to verify that Suricata is working. Figure 3 shows how it is possible to verify the version simply by using suricatasc
with the -c
version switch.
The result of the command in Figure 3 is information about the mode in which Suricata is running. Pay special attention to the runningmode
option, which informs you that it is working properly. The capture-mode
switch is useful, because it will tell you whether or not Suricata is capturing packets. The AF-PACKET_DEV
value lets you know that Suricata is working. The iface-stat
switch reports the status of the interfaces used by Suricata:
$ sudo suricatasc -iface-stat eth0 "drop" 280000404 "invalid checksum": 0, "pkts: 80595950"
The preceding output shows that 280000404 packets have been dropped out of 80595950, and that no packets have had invalid checksums.
Troubleshooting the Implementation
When I've had problems installing Suricata, I've often run into dependency issues in regard to libpcre3
. To avoid dependency issues, you might want to start with a flavor of Linux that already has Suricata installed, or is at least primed for a Suricata implementation. I've found that Debian-based systems, including Ubuntu, are quite suited for Suricata.
You might also need to make sure that all of the relevant services are running:
$ sudo service barnyard2 start $ sudo service snortd start $ sudo service httpd start
Buy this article as PDF
(incl. VAT)