CYBERSECURITY JOB HUNTING GUIDE
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:
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?
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:
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:
Hint:
You can use multitail to see more logs at the same time.
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:
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:
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:
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.
<action> <protocol> <source> <source port> <direction> <destination> <destination port> (msg: <message>; priority: <priority>; sid:<signature id>; rev:<revision>;)
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.
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:
We start with the fast.log to see if we have a working filter. The command is:
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:
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:
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.
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:
The NFQueue is supported. We have to activate it in the yaml file with:
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:
The lab setup for IP tables:
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:
https://suricata.readthedocs.io/en/suricata-6.0.1/setting-up-ipsinline-for-linux.html
Another example for a web server configuration:
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
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
- # 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
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
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"'
Hint:
You can use multitail to see more logs at the same time.
- sudo apt install multitail
- sudo multitail /var/log/apache2/access.log /var/log/apache2/error.log
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
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;)
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
- tail -f /var/log/suricata/fast.log
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
<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;)
- sudo suricatasc -c reload-rules
- tail -f /var/log/suricata/fast.log
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;)
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
We start with the fast.log to see if we have a working filter. The command is:
- tail -f /var/log/suricata/fast.log
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
- sudo nano /etc/suricata/suricata.yaml
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
- sudo nano /etc/suricata/rules/detection.rules
- alert http 192.168.6.4 any -> any any (content:"malware"; msg: "malicious tcp packet detected!" ; http_uri; classtype: targeted-activity; sid:11111;)
- alert udp 192.168.6.4 any -> 10.33.33.1 any (msg: "UDP traffic to malicious host!"; classtype: targeted-activity; sid:11112;)
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
- sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'
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
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
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
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
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
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:
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.
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.
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.
We can run suricata with the NFQ mode with:
- sudo suricata -c /etc/suricata/suricata.yaml -q 0
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
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;)
- tail -f /var/log/suricata/fast.log
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.
© 2021. This work is licensed under a CC BY-SA 4.0 license