Suricata with RangeForce

Author: Stefan Waldvogel

This guide is a small write-up for Rangeforce's Suricata labs. This chapter might help solve the Bluestar Challenge.
The official help:
https://suricata.readthedocs.io/en/suricata-6.0.1/

The basics
The installation is straightforward:

sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install suricata

The most important file is the suricata.yaml file. This file is the heart of Suricata, and you can configure Suricata with it.
As a beginner, you have to find your network card name first (command: ip a). The RangeForce firewall machine uses enp1s10 and enp1s9, and the question is, what is the correct IP?

enp1s9 -> 192.168.6.4/24
enp1s10 -> 192.168.10.254/24

We have two different subnets. According to the topology, the desktop machine is 192.168.6.4/24, and the server was 192.168.10.254/24. To protect the server, we have to configure the server subnet with the matching network card. The traffic has to go to both ip's; therefore, we can add both. Here, it is enp1s10, and we have to look for af-packet.

# search for af-packet and print line number
grep -in "af-packet:" /etc/suricata/suricata.yaml
# start nano at specific line
sudo nano +580 /etc/suricata/suricata.yaml

Here, the matching number is 580, but if you install Suricata without selecting the repository, the af-packet option is on the top. You can save the edited file with Ctrl + x. If you have an error, remember you are changing a config file, and you need sudo rights.
You can set the home_net, too. If you change it, you can use the variables HOME_NET and EXTERNAL_NET. In this case, the homenet is the server subnet.
After setting up the suricata.yaml file, you have to reload the file. This works with restarting the service:

sudo service suricata restart

Testing Suricata
Suricata uses eve.json to log all events. You can use the tail command on Linux systems to show the last added line to a file. The option -f means you can see tracklogs in real-time.
The correct command for the server is:

tail -f /var/log/suricata/eve.json | grep '"src_ip":"192.168.10.2"'

With this configuration, we see the traffic, but we do not have rules. We log, nothing more.

Hint:
You can use multitail to see more logs at the same time.

sudo apt install multitail

Example:

sudo multitail /var/log/apache2/access.log /var/log/apache2/error.log

Suricata as IDS
An IDS is a detection system and does not interrupt traffic. You get alerts, and it is up to you what you are doing with it.
You need to edit two things: You have to create a rule, and you have to add the rule to the suricata.yaml file.
You can create a file with the touch command or use nano, vi, vim, etc.. The lab is not 100% correct if you create the file like this:

sudo touch /etc/suricata/rules/custom.rules

You have to change the default-rule-path to: /etc/suricata/rules/
The lab designer changed the HOME_NET and the af-packet, but I recommend rechecking it. af-packet has both interfaces configured.

The first rule
At the beginning, we want to see all http traffic in both ways. The syntax is straight forward:
<action> <protocol> <source> <source port> <direction> <destination> <destination port> (msg: <message>; sid:<signature id>; rev:<revision>;)
The rule:

alert http any any <> any any (msg:"HTTP traffic"; sid:10000001; rev: 1;)

Hint: If you copy the rules and you get weird errors, think about the ". Two look similar, but they are different.
We create an alert rule. All matching traffic is going into fast.log, and eve.json has all the traffic. Before you reload, the rules fast.log is empty. You can reload the rules with:

sudo suricatasc -c reload-rules

This command does not reload the suricata.yaml file, it updates only the rules!

tail -f /var/log/suricata/fast.log

Now, you should see traffic.
Hint: If you copy the rules and you get weird errors, think about the ". Two types look similar, but they are different. You need the straight version.

The rule priority
It is simple to add new rules, and you can do it in the same file. A new line is a new rule. The lab uses priority 3 for the task, but that does not make much sense because the standard is 3. Adding this value or not does not change anything.

sudo nano /etc/suricata/rules/custom.rules

The syntax is:
<action> <protocol> <source> <source port> <direction> <destination> <destination port> (msg: <message>; priority: <priority>; sid:<signature id>; rev:<revision>;)

alert udp 192.168.10.2 any -> any any (msg:"UDP traffic"; priority: 3; sid:10000002; rev: 1;)

The main difference between both rules is the direction. You can specify if you log all inbound or outbound traffic with the arrows. Here, we log inbound traffic.

sudo suricatasc -c reload-rules
tail -f /var/log/suricata/fast.log

The lab is interesting because one machine sends UDP traffic to a different machine in a very different subnet. UDP 53 is DNS traffic and often not blocked. Here, it looks like someone uses the open port maliciously and sends traffic via upd 53. With Wireshark, we could inspect the traffic.
Hint: 1.1.1.1 is a public Australian DNS resolver, so the traffic is most likely real DNS traffic.

The classtype
Classtypes provide additional information about the rule and the traffic. Big companies have many rules; therefore, they need different fields.

alert tcp any any -> 192.168.6.4 3306 (msg:"incoming MySQL traffic"; classtype: not-suspicious; sid:10000005; rev: 1;)
alert tcp 192.168.6.4 3306 -> any any (msg:"outgoing MySQL traffic"; classtype: not-suspicious; sid:10000006; rev: 1;)

Here, you add additional value to the output. Later, you can use Splunk or a different SIEM to filter the traffic a second time.

Intrusion Prevention
This topic explains the most beneficial Suricata usage and is may be relevant for the BlueStar Challenge. Logging things is nice, but it does not stop an attack. The matching RangeForce lab follows a methodology and the first step is investigation. What is going on?
The lab and Suricata are as IDS pre-configured. You can check the important things first because your friend is not an expert, and it gives you valuable information about the firewall configuration:

fast.log
suricata.yaml
eve.json
the rules

The fast.log
We start with the fast.log to see if we have a working filter. The command is:

tail -f /var/log/suricata/fast.log

You see tcp and udp traffic, the IDS works, and the rules with the proper description give you an idea about the malicious traffic.
A working fast.log means we have a working environment including a configured yaml file and a matching rule.

The suricata.yaml file
We have to check at least three things:

HOME_NET
af-packet
rule path
rule-files

Command to open the file:

sudo nano /etc/suricata/suricata.yaml

The HOME_NET
the HOME_NET:
"[192.168.10.0/24]"
The HOME_NET is the server subnet.

The af-packet
the af-packet:
- interface: enp1s10
- interface: enp1s9
Here, both network cards are configured.

The rules
Where is the rule:
default-rule-path: /etc/suricata/rules
rule-files:
- suricata.rules
- detection.rules
We check the rules:

sudo nano /etc/suricata/rules/suricata.rules

This rule file does not exist, and it is wrong configured!

sudo nano /etc/suricata/rules/detection.rules

The detection rules look like this:

alert http 192.168.6.4 any -> any any (content:"malware"; msg: "malicious tcp packet detected!" ; http_uri; classtype: targeted-activity; sid:11111;)

# ^ I experimented with detection rules, and this rule triggered Suricata!!! What is going on??? Is my net infected now???

alert udp 192.168.6.4 any -> 10.33.33.1 any (msg: "UDP traffic to malicious host!"; classtype: targeted-activity; sid:11112;)

# ^^^ UPD!!! I found the malicious host!!! What am I supposed to do now???
The rules look very simple, and we do not have intelligence behind this rule. Think a short moment about these rules. ... The IP 192.168.6.4 is in the private and non-routable IP range, and this is a machine in your network!
The second rule is even more suspicious because the 10.33.33.1 is also a private IP.
Most likely, this is a unique lab configuration, but if you see something like this, in reality, the first question is: What is the reason for this? Usually, you should see both machines, and you have access to both machines. Malware is on the second machine, too!

The first investigation
We should check eve.json if we see more traffic; our friend is not an expert in the field.

tail -f /var/log/suricata/eve.json

You can get a much cleaner output with:

sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

We see a lot of traffic.... we can see why our friend added the existing rules (filename":"/uploads/malware).
Bonus material:
The lab has a ton of extra traffic, including an ssh brute force attack. We could use the lab to practice other things.

Setting this up for IPS
First, we do not know if your Suricata has NFQUEUE support installed. The command:

suricata --build-info

gives us the value: NFQueue support: yes
The NFQueue is supported. We have to activate it in the yaml file with:

grep -n nfq /etc/suricata/suricata.yaml
sudo nano +1601 /etc/suricata/suricata.yaml

nfq:
mode: accept
Here, the mode is set to accept, and you can use other modes.

Iptables
To understand the lab, you need to understand what iptables is and what you can do with it. Iptables is a firewall for Linux systems and very powerful with many functions. Two examples: You can use YARA to write rules OR you can route traffic to Suricata.
The NFQ mode works like this: All traffic hits the firewall, but the traffic is forced to go to Suricata. Suricata is in charge of it, and iptables do not care about the traffic anymore. This information is essential! If you block an IP via iptables, it does NOT work, and you have to block it in Suricata or use a different mode. You can set the nfq mode in Suricata to "repeat" to avoid this behavior. See: https://suricata.readthedocs.io/en/suricata-6.0.1/configuration/suricata-yaml.html?highlight=repeat#nfq
Before you proceed with adding rules, it is a good idea to check the iptables configuration with:

sudo iptables -vnL

We can see one thing: iptables accepts everything.
The lab setup for IP tables:

sudo iptables -t mangle -I PREROUTING -p tcp -m tcp --dport 80 -j NFQUEUE --queue-num 0
sudo iptables -t mangle -I PREROUTING -p tcp -m tcp --sport 80 -j NFQUEUE --queue-num 0
sudo iptables -t mangle -I PREROUTING -p udp -m udp --dport 53 -j NFQUEUE --queue-num 0
sudo iptables -t mangle -I PREROUTING -p udp -m udp --sport 53 -j NFQUEUE --queue-num 0

You can check iptables to see the new rules:
sudo iptables -vnL
I cannot see the new rules in the lab, but I am a very beginner. iptables is a huge topic, and it is worth learning more about it.

Bonus material:
If you use Suricata as a IPS you should force all traffic through Suricata. The matching command is:

sudo iptables -I FORWARD -j NFQUEU

The lab ignores a lot of potentially malicious traffic because we have more protocols, and Suricata supports a lot more than tcp and udp. The official help gives you an excellent idea about the different options:
https://suricata.readthedocs.io/en/suricata-6.0.1/setting-up-ipsinline-for-linux.html

Another example for a web server configuration:

The lab does not explain iptables, but you need a better understanding of it.
We can run suricata with the NFQ mode with:

sudo suricata -c /etc/suricata/suricata.yaml -q 0

Here, we get an error, and the rules are not configured.
The next step is fixing the rules. We have to add a new rule to the yaml file and commend two others out. To get a green symbol, you need a space between - and prevention.rules and the position has to match.

sudo service suricata restart

Hint:
The lab will not jump to green if the mode: accept has the wrong amount of spaces. It has to look like the solution.

Creating the rules
It is not difficult to create the rules. The suggestion uses four rules, but with the <> operator two should work, too.

sudo nano /etc/suricata/rules/prevention.rules
drop tcp 10.33.33.1 any <> any any (msg: "TCP packet from malicious host, Drop"; sid:10002;)
drop udp 10.33.33.1 any <> any any (msg: "UDP packet from malicious host, Drop"; sid:10004;)

We test the output with:

tail -f /var/log/suricata/fast.log

Conclusion:
This guide shows just the beginning, and I feel overwhelmed with all the options and tools. The blue side is not more accessible compared to the red side. Suricata and iptables are huge topics, and I hope I will learn more.
If you have questions about it, or you can teach me more about iptables, feel free to join the Unofficial RangeForce discord: https://discord.com/invite/ZY4ty2QjkQ
Thanks to RangeForce (Gordon Lawson) and permission to write something about it.

Hint: If you write something like this, you need permission. RangeForce usually does not allow it.

Next: RangeForce SOC 2