How to leverage Suricata IDS for enhanced security visibility

Security starts and ends with visibility

You can’t catch what you can’t see. Taking control of your threat landscape means ensuring that you are spotting, retaining, and analyzing everything that could potentially become a threat. Nowadays, even the most scant security postures include passable tools for aggregating when and how the outside world is knocking at your network’s edge. What can frequently get lost though is a view of what those on the inside may be inviting through your door. This includes many things, but the most ubiquitous is malware.

The malware problem…

Malware comes via attachments, malvertising, man-in-the-middle, man-in-the-browser, social engineering, and countless other vectors. Even the most stringent of binary whitelisting can quickly be rendered ineffective by a compromised application update server or exploits in otherwise legitimate software. Endpoint protection factors in as well, but there will always be occasions where malware has evolved to a new hash and your product’s heuristics just happen to miss it.

What happens in these cases? Well, for a little while, nothing. Then indicators of compromise start coming in from the network monitoring team or user reports, and the incident response process begins. Of course, like many modern malware strains, it self-destructed upon execution and since endpoint monitoring missed it, it’s not quarantined anywhere. Without the malware itself or incredibly detailed network and process logging, accurately determining the scope of the incident is very unlikely.

Such situations demonstrate the deficiencies of reactive quarantining from an incident response perspective. No person nor piece of software can reliably predict what will be relevant to an investigation and what should be retained. However, it is possible to avoid reliance on such predictions by proactively retaining everything that could be relevant.

Time to put Suricata to the test

Suricata is the core of our intrusion detection services. We leverage Suricata not only for its top-notch performance and IDS capabilities, but also because of its invaluable ability to extract files from packet captures and traffic streams.

Suricata’s file extraction capabilities are perfect for extracting and storing would-be malware as it enters or exits your network. However, since Suricata can be a bit unwieldy, we will walk through setting up a complete development environment with a Suricata IDS and test workstation to get hands-on with these features.

This tutorial uses VirtualBox and Ubuntu Server 16.04 and assumes basic familiarity with both.

Let’s get started

Start off by creating a virtual machine for the IDS. The default options will be fine.

When the machine is created, add an additional interface for the internal network.

After you have added the interface, install the operating system.

After you have installed the operating system, configure a static address for the internal interface. (Interface names may differ from the example).

After you have configured the interfaces, add the OISF Suricata-stable repository and install Suricata.

This tutorial demonstrates Suricata running as a NAT gateway device. The following steps require elevated privileges. Setup the NAT by editing /etc/sysctl.conf as follows.

Note: This line may already exist with a default 0 value.

Then load the sysctl settings manually.

Finally, configure iptables to forward packets between the internal and external interfaces. (Interface names may differ from the example).

Before starting and configuring Suricata, create a virtual machine for the test workstation. The default options will be fine.

When the machine is created, attach the primary interface to the internal network used above.

After you have configured the interface, install the operating system. DHCP autoconfiguration will fail. Configure a manual address when prompted.

Use the Suricata instance’s internal address as the gateway for the test workstation and Google’s DNS (8.8.8.8) for the nameserver.

Continue with the installation.

Once installed, ensure that the IDS is forwarding traffic by verifying network connectivity from the test workstation.

Return to the IDS and configure Suricata. Edit /etc/suricata/suricata.yaml as follows.

Change the af-packet interface to the internal interface.

Configure the file-store and file-log outputs.

Configure the stream and libhtp settings.

Add a local rule file to the top of the rule list.

Add a test rule to /etc/suricata/rules/local.rules.

Restart Suricata to apply the new changes.

Suricata will now save files to disk that it detects in the traffic stream. Setup a directory watch on the IDS and download some files from the test workstation.

The detected files are renamed to file.x and their metadata is stored in the corresponding file.x.meta.

The difference between watching and stopping a breach

This type of visibility provides immediate, actionable threat intel – hashes to blacklist, URLs to block, machines to quarantine, etc. Whether it is traditional malware executables, weaponized macros, malicious PDFs, or anything else, this type of visibility can be the difference between watching a breach in progress and stopping a breach in progress.