Suricata is an open source Intrusion Detection System (IDS) that is used by organizations to detect malicious traffic entering a network by using signatures and rules. It can also be used as an Intrusion Prevention System (IPS).

In this project I installed Suricata on a Kali Linux virtual machine and created a custom alert. I first opened up Suricata’s configuration file (suricata.yaml) by typing in the command “sudo vim /etc/suricata/suricata.yaml” in the terminal and this is what it returns:

Once in here, I had to specify the network’s subnet on which I want to receive alerts for. To get that information, I ran the “ip a s” (same as ip addr show) command in Kali.

I went ahead and entered the subnet 10.0.2.15/24 into the “HOME_NET” address group back in the configuration file. I also searched for the interface to make sure it was set to “eth0”.

Then I exited out and went to create a custom rule. I typed in the command “sudo vim local.rules” and it opened the custom rules folder where I could create a new one. Below is an example from Suricata’s guidelines. The text in red is the action, the green is the header, and the blue are the options.

In the custom rules folder, I typed in the rule: alert icmp any any -> $HOME_NET any (msg: “ICMP traffic alert”; sid 1023456;). This rule will essentially create an alert for ICMP packets coming through any port from any source IP to the destination IP of my device through any port.

The next step was to add the location of the file where I stored the custom rule that I created. Under “suricata.rules” I typed in the name of the file which was “path/to/local.rules”.

Then I typed in the command “sudo systemctl start suricata.service” to get Suricata up and running in the background so that it can begin to monitor network traffic.

To confirm this, I ran the status command to see if the status is active.

Then I checked to see if the suricata.yaml configuration file had any issues and based on the last line it looks like there was an error with rules file, so I went back to see what could be causing the issue.

After reviewing the suricata.yaml configuration file, I realized I forgot to change the name of the default rule path so that custom rules can be found.

I reran the command to check the error and it was resolved, but some new errors seem to have been created. I am actively troubleshooting it to see what the root cause may be so that I can successfully test my rule and review the alert. Once resolved I’ll provide an update as to whether it is a bug or a missed step in the configuration process.

For the sake of this project, I’ll go through the final steps of what the process should look like. If I were to run the “sudo suricata -T -c /etc/suricata/suricata.yaml” command and it returned no errors, I would then proceed to pinging my Kali VM from my physical computer. After that, I would run the command “sudo cat /var/log/suricata/fast.log” to get the alert results. Below is an example of what it would look like:

Here it shows an ICMP packet was received and lists the source IP as well as the classification. A priority level can be assigned as well in the rules, and the classification can also show if it is potentially suspicious traffic.

This type of information can be extremely useful in a corporate network so that network attacks can be identified and dealt with early on. Technology doesn’t always run as smooth as it should and it is necessary to take a few steps back to find the cause of the issue, as shown here. Although it may be tedious at times, it is a great learning experience and opportunity to practice when having to troubleshoot an issue as it is a necessary skill to have on the job.