OPNsense Next-Gen Firewall: A Deep Dive into Suricata Integration
Summary:
In this lab we will setup and configure an OPNsense firewall, along with setting up Suricata as our Intrusion Prevention System (IPS)/ Intrusion Detection System (IDS). We will set custom rules for Suricata to alert us of potential stealth scans on our network. These stealth scans will be used for network reconnaissance using nmap. We will verify if our detection system works properly and alerts us.
What is OPNsense?
OPNsense is an open source stateful firewall. This firewall supports both IPv4 and IPv6, along with multi-WAN for load balancing and failover support. You can configure you OPNsense with Suricata IDS/IPS. Come with routine protocols, proxying and web application filtering.
The initial configuration of this firewall, will require us to login as an Installer.
Username: installer
Password: opnsense
After logging in , continue with default mapping. It will ask you to install using Unix File System (UFS), selected this and install.
It will prompt you to change the root password. As best practice you are going to want to change this.
Option 1: Option 1 is Link aggregation Groups. If we had multiple network card, we could group 2 or 4 of them to make a high speed link.
VLANS: Virtual LAN, used for segmenting our network.
As seen above, we will set the WAN as em0 and LAN as em1.
I left my IP as the default, so I will be using 192.168.1.100 for OPNsense. I pinged it on my Kali VM to make sure it’s reachable.
We can now go on Kali web browser and type in 192.168.1.100 to reach the OPNsense login page.
After we login, we can see our Firewall dashboard:
To make sure OPNsense runs to the best of it’s ability we will make sure everything is up to date. Navigated to Firmware, Status and click “Check for updates”.
Now it’s time to set up our IDS/IPS (Suricata).
What is an IDS/IPS?
Intrusion Detection System (IDS) can be installed on our firewalls or devices. It can be used to detect if there is any triggers hit or anomalies found in traffic. This is based on signatures and patents that we can configure the IDS to look out for.
Intrusion Prevention System (IPS) can do everything and IDS does. Additionally, we can also block or deny specific traffic based off of those signatures or anomalies we set our system to look out for.
Installing our IPS/IDS
In order for IPS/IDS to work properly, we’ll need to go into the interface settings and disable the Hardware settings(Check all the boxes).
After applying the changes, navigate to “Services”, “Intrusion Detection”, “Administration”. Turn on “advanced mode”, check all the box such as Enabled, IPS mode, Promiscuous mode, and Enable Syslog output. Next, change the pattern matcher to “Hyper matcher” for a more modern pattern matcher. We will switch the Interface to LAN for this lab, along with putting only our home network/LAN subnet IP address.
Now we will create our custom ruleset. Create a file and name it “customnmap.rules”. The breakdown of the rule is as follows: This rule will trigger when we match our protocol, which is TCP. ‘home_net’ serves as a placeholder for our home network. This rule applies to any TCP traffic originating from the home network on any port and heading in the direction of our firewall IP. When this condition is met, it will generate a message that states, ‘Possible NMAP Stealth scan detected.
A stealth scan is typically a hackers first step of reconnaissance. The hope for this scan is to get as much information on the system and network as you can. This rule is designed to look for a partially pattern to lookout for the scan and hopefully alert us.
This file should contain:
alert tcp $HOME_NET any -> 192.168.0.0/24 any (msg:”POSSIBLE NMAP SYNSTEALTH SCAN DETECTED”; flow:stateless; flags:S; priority:5; threshold:type threshold, track by_src, count 50, seconds 1; classtype:attempted-recon; sid:1234;)
Next, we’ll navigate to “Settings” and then “Administration”. Make sure to check the boxes for Secure Shell Server, Root Login(For lab only), Authentication Login, and set the Listening Interfaces to LAN.
Time to create our xml file. In the the same folder as our customnmap.rules file create a new document named “customnmap.xml”.
In the file populate it with:
<?xml version=”1.0"?>
<ruleset documentation_url=”http://docs.opnsense.org/">
<location url=”http://192.168.1.101/" prefix=”customnmap” />
<files>
<file description=”customnmap rules”>customnmap.rules</file>
<file description=”customnmap” url=”inline::rules/customnmap.rules”>customnmap.rules</file>
</files>
</ruleset>
This .xml file will search for our customnmap.rule file. Now we need to move our .xml custom rules file over using filezilla. Using secure FTP we will navigate and add our customnmap.xml file: /usr/local/opnsense/scripts/suricata/metadata/rules
In the same location our files are stored we will need to use python to create an http server. This server is used to serve our .rules file to OPNsense when the .xml queries for it.
Run:
python3 -m http.server 80
Navigate to “Services”, “Intrusion Detection”, and then “Administration”. In the top we will click “reset service” and our custom rules should appear.
Check “customnmap/customnamp rules”, click “enable selected”, and then “Download & Update Rules”.
We can check in “Rules” that it has been added.
Testing
We are going to test our Intrusion device by using Nmap. Since we setup our rule to detect a stealth scan, we can conduct a scan and check if we are alerted of this activity.
To start our stealth scan we will use -sS to initiate our SYN (Stealth) scan, -Pn to continue with the scan even if a ping is not responded to. The 500 is to scan the top 500 ports and then our firewall IP.
sudo nmap -sS -Pn --top-ports 500 192.168.1.1
The results return that port 22, 53, 80 and 443 are all open. Head back to our firewall and refresh the Alerts section.
We can see the our alert works. It shows the LAN interface was used, the source & destination IP, and that it is a possible stealth scan.
Conclusion
To wrap this lab up, we have successfully installed IPS/IDS based on Suricata on OPNsense. We checked out the rules and how to create a custom rule. We set up our kali machine to be able to host the rule for us to download on OPNsense. We launched a reconnaissance port scan against our firewall, and saw the result of our rule picking up the signature.
This is a lab environment so not everything will be set up like a production environment such as allow root user to login. Another difference in a production environment is some of the custom rules may create false positives. In these false positive you will need to go investigate and gauge whether it’s a false positive or true positive.
I hope you enjoyed this write up and I would highly suggesting running through the lab yourself! LS111 is very knowledgeable and breaks down each process is detail. I learned a lot going through his lab. I may potentially continue this home lab and will link the next post here.
Resources
Big shoutout to LS111 on making this lab walkthrough!
EP1: Lab Overview
EP2: Installling OPNsense
EP3: Setting up Suricata