Open Source Network Analysis and Threat Detection (Suricata) + XDR (Wazuh) → Active Response on Endpoints and Network devices... Come on!!!
Hi friends,
here we are again with another music recommendation, hope you like it, “Back to Black” (2007) - Amy Winehouse...17 years have passed!... Incredible.
Suricata – Port-Mirroring - XDR/Wazuh
Alright, let's get to it. In this new post, I will share a small implementation with Suricata and Wazuh that we have carried out in the lab. For this, we have installed Suricata on a new machine, debiansrv02.home.arpa. Here is the link showing how to perform this installation: Suricata - Installation.
We have connected the new machine, debiansrv02.home.arpa, to the ethernet interface 4 of our fw/router rtr01.lab.local. The idea is to send as much traffic as possible to the Suricata service for analysis. To achieve this, we have configured the port-mirroring functionality on the router rtr01.lab.local. Port-mirroring allows us to send a copy of the traffic from one interface to another interface. The copied traffic can be the traffic sent by the source interface, received, or both sent and received, or limited to an access list or VLAN; the actual capabilities will depend on the equipment we are using. In this case, it is a Mikrotik router (Switch Chip Features), and we send a copy of all traffic sent and received on ethernet interface 1 (connection to the internet firewall) to our server debiansrv02.home.arpa. Therefore, a copy of all traffic to and from the internet will be analyzed.
It is important to consider two things: the port-mirroring capability of the router or switch and the capacity of the server running the Suricata service. I know it’s obvious, but we need to check the capabilities of these systems and size them correctly.
The following image shows a status map of this environment:
In this situation, the Suricata service is already receiving the traffic we are interested in. A traffic capture on debiansrv02.home.arpa will confirm this point. Below is an echo request from a device on the user network to a device on the internet, captured on debiansrv02.home.arpa thanks to port-mirroring:
To integrate Suricata with our favorite SIEM/XDR, you can follow these guides for reference: Network IDS integration, Responding to network attacks with suricata and wazuh xdr. The key point is how the logs are handled, their location, and FORMAT:
<agent_config>
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
</agent_config>
Reviewing Suricata events in Wazuh
We have verified that the Suricata service is receiving the traffic of interest to us. Now it's time to check if the alerts are being forwarded to Wazuh. To do this, we will perform a simple package update on a Debian server.
As you can see, traffic from the Android mobile device is also received and analyzed.
Responding to attacks by modifying policies on our routers and firewalls
The following link explains how we can configure the environment to respond to attacks based on detections made by Suricata: Responding to network attacks with suricata and wazuh xdr. Basically, we can modify the firewalls of each endpoint to block traffic with the attacker's IPv4 address. In this post, we're going to go a step further and attempt to change security policies on network elements automatically. These policy changes will occur when a rule level of 12 or higher associated with the Suricata service on the agent debiansrv02.home.arpa is triggered in Wazuh.
Router/Firewall Preparation
The first thing we are going to do is prepare the network equipment, in this case, our router rtr01.lab.local, so that we can apply security policies easily and scalably. In this case, we have created a security policy (a rule in the firewall), so that all traffic associated with a list of IPv4 addresses will be blocked. This approach allows us to block IPv4 addresses very simply, we just have to include the attacker's IPv4 address in this list. This type of address lists are very common in practically all types of firewalls, even with nftables. In the following post, I show how to block traffic to and from networks without ROA...→ PoC: Use RPKI invalid route information as seed to dynamically modify the policies of remote firewalls...all of these is O-P-E-N S-O-U-R-C-E!!! For the case at hand, Mikrotik, we have created an address list called: ALO_ATTACKERS.
/ip firewall address-list
add address=192.0.2.254 comment=ALO_ATTACKERS disabled=no dynamic=no list=ALO_ATTACKERS
This list is applied on the router as follows:
add action=drop chain=input comment="DROP ALL INPUT: ALO_ATTACKERS" log=yes log-prefix="DROP ALL INPUT ALO_ATTACKERS" src-address-list=ALO_ATTACKERS
add action=drop chain=forward comment="DROP ALL FORWARD: ALO_ATTACKERS" log=yes log-prefix="DROP ALL FORWARD ALO_ATTACKERS" src-address-list=ALO_ATTACKERS
All IPv4 addresses included in the ALO_ATTACKERS list will be blocked by the router/firewall.
领英推荐
Wazuh Custom Active Response
Obviously, we're not reinventing the wheel; this post isn't rocket science. All credit goes to Wazuh... Wazuh allows for the creation of Custom active response scripts.
In short, it's getting late and my wife threatens me again, you can create custom scripts to run under specific circumstances that you determine.
In this case, we've created a script that changes the configuration of our rtr01.lab.local to include the IPv4 address of the attacker detected by Suricata in the ALO_ATTACKERS address list. As a result, all traffic associated with this IPv4 address will be blocked by our network device. This not only protects Wazuh agents but also other devices that don't have an agent or aren't subject to active response for whatever reason.
Test Custom Active Response
To check the functionality of our environment, we will simulate an internal attacker, with the IP address 172.16.1.100, by running an nmap scan against 192.168.1.1:
nmap scan against 192.168.1.1:
nmap -sV -sC 192.168.1.1 -oN nmap_results.txt
Starting Nmap 7.93 ( https://nmap.org ) at 2024-06-08 11:23 CEST
...
Of course, the stateless custom script is executed and the corresponding logs are generated... This is the active-response.log on the server that executes the script modifying the configuration of our rtr01.lab.local:
We can also find the configuration change on the syslog server that stores the logs of rtr01.lab.local, as well as the drops once the changes are applied.
Came On!!!! We are the fucking masters!!!
We still need to work on maturing the solution a little bit, especially regarding optimizing script execution.
Conclusion
This is a basic proof of concept of Wazuh's active response capability with network devices, it simply works.
This is a new step that enhances our security posture, but don't forget that we must manage false positives, false negatives, fake 20 euro bills, false sexual proposals, false hopes for humanity to improve, etc.
Documentation
Sales Engineer at Aruba, a Hewlett Packard Enterprise
8 个月Suricata is our internal IPS engine in some of our platforms. ?? Good Job.