This is the first post in a multi-part series explaining how to use Suricata to make an NDR (Network Detection and Response) program.

But first: what is Suricata?

It’s an IDS (Intrusion Detection System). This means it’s a tool that analyzes network traffic and determines if it’s malicious or suspicious.

You may be thinking “why do I need this? Why can’t I just look at PCAP files?” Great question!

A pcap file contains every byte of data that travels between two endpoints or the entire network.

When you’re analyzing traffic between two endpoints or a single TCP stream, this is a good option. But what about analyzing traffic on a network with thousands of endpoints? It’d take you a month to evaluate just a few hours of traffic on a network like that. This is why we use an IDS instead.

The main function of an IDS is the rule/alert system. You can program Suricata with rules, and if any traffic matches those rules, Suricata will generate an alert.

It can alert on anything. Ports, protocols, sending IPs, receiving IPs, traffic content, malicious file strings, attempted hacks, TOR traffic, command and control servers. It’s a powerful tool.

Let’s download Suricata onto our Kali box. The best way to install Suricata is to compile it from source, but since this isn’t a production environment, it’s sufficient to use apt. Run this command  as root to install it:

apt install suricata -y

If you run Suricata with no arguments, you’ll see the help page:

This might seem overwhelming, but don’t worry. We’ll spend the next few lessons covering key parts.

Start with the /etc/suricata directory to see what you have available.

The suricata.yaml file and the rules directory are extremely important. A yaml is essentially a configuration file. This file tells Suricata what to do and when to do it.

The rules directory contains the rule sets that Suricata can alert on. Here are the ones Suricata has by default:

As you can see, much of Suricata’s value lies in writing your own rules (and using other people’s rules, too.)

To get Suricata running with the default configurations, run this command:

suricata —af-packet=<your_interface_name>

—af-packet is a capture mode. After running this command, I see that Suricata launched successfully.

The traffic that is sent back and forth is logged (not all of it, just the key parts called “metadata”) in the /var/log/suricata/eve.json file.

However, you can see a concise overview of any alerts by checking the FAST log.

On my system, since I made and triggered a custom alert, I can see the alerts in the fast log by running this command as root:

tail /var/log/suricata/fast.log

Voila! I get an overview of all traffic that matched my rule.

Here’s how I made the rule and triggered it to alert:

As root and in the /etc/suricata/rules directory, make a file for your rule.

vim local.rules

Now write the rule and save it.

How? Examine the docs:

Here’s the rule I made:

Now change to the /etc/suricata directory and update the Suricata configuration file (suricata.yaml), so the rule is included.

Now run Suricata using this command:

suricata -c /etc/suricata/suricata.yaml -i <your_interface_name>

Do something that should trigger your alert, then check the fast.log file:

A future post will be about making these alerts searchable. We’ll then dive into ELK and how to make visualizations with these alerts.

I suggest you experiment with writing your own rule and triggering it to alert. This will provide a good foundation for future lessons.

Thanks for reading!