Suricata IPS in Inline Mode and Fail2ban Integration

Help
, ,
1

I have successfully set up Suricata in IPS inline mode using AF_Packet (Ubuntu). To test it, I used testmynids.org, and Suricata correctly blocked the response:
root@jasser:/home/jasser# curl --max-time 5 http://testmynids.org/uid/index.html
curl: (28) Operation timed out after 5000 milliseconds with 0 out of 39 bytes received

However, I noticed that Suricata only drops packets but does not block the attacker’s source IP automatically. I want to implement a solution to achieve this.

Scenario: Preventing SSH Brute Force Attacks (password guessing)
I tried using Fail2ban, but it doesn’t seem to work. Here’s my configuration:

/etc/fail2ban/filter.d/suricata.conf:
[Definition]
failregex = “src_ip”:“”
ignoreregex =

/etc/fail2ban/jail.d/suricata.local:
[suricata]
enabled = true
filter = suricata
action = iptables[name=Suricata, port=any, protocol=all]
logpath = /var/log/suricata/eve.json
backend = auto
bantime = 3600
findtime = 1
maxretry = 1

my custom rule:
drop tcp $EXTERNAL_NET any → $HOME_NET 22 (msg:“Drop SSH brute force attempt”; flow:to_server,established; detection_filter:track by_src, count 80, seconds 15; classtype:attempted-admin; sid:990001; rev:1;)

Issue:
Fail2ban does not appear to block the attacker’s IP even when Suricata logs the event in eve.json.

Questions:

  1. Is my Fail2ban configuration correct for parsing Suricata logs?
  2. Should I modify the Suricata rule to trigger Fail2ban properly?
  3. Are there alternative methods to automatically block attackers detected by Suricata?

Any help or suggestions would be greatly appreciated!

2

I’m not familiar with fail2ban, but given the following line it looks likes its trying to use iptables to block?

 action = iptables[name=Suricata, port=any, protocol=all]

Something to note about AF_PACKET IPS is that it is userland bridge. It passively picks up packets on one interface, provided Suricata doesn’t have a drop rule for that packet, it copies it out the other interface. I don’t believe iptables ever has a chance to drop the packet, so you’ll want to look at Suricata solutions.

The documentation covers datasets, where a dataset can be a table of IP addresses that you have blocked. Its better than a rule per IP address you want to block as you won’t need to reload the ruleset each time. You can use the “suricatasc” tool to add and remove addresses at runtime. I don’t have a full example handy though.

3

I just want a solution that blocks the attacker’s IP address in real time.
So did you mean?:
-Suricata detects suspicious activity using a rule designed to match malicious behavior.
-A script or tool then automatically adds the attacker’s IP to a dataset via suricatasc in real time without requiring a restart.

4

Yes, that is the approach I would look at. Note that if you do go with a rule per block you still don’t need to restart Suricata, you can just trigger a reload. But its probably not something you would want to do in an automated fashion as its quite intensive compared to dynamically updating a dataset.

1 Like
5

We use Suricata in NFQ mode. Fail2ban scans fast.log for matches and adds the IP to the input block list.

The rules:

[suricata-2]
enabled  = true
logpath  = /data01/var/log/suricata/fast.log
datepattern = %%m/%%d/%%Y-%%H:%%M:%%S
#
bantime = 91.31d
maxretry = 1
findtime = 3w
action = iptables-allports[name=sri2t, protocol=tcp]

The filter:

[Definition]
__suricata-2_actions = (?:dropping|refusing)

# 03/28/2021-10:06:07.788374  [Drop] [**] [1:2500200:5750] ET COMPROMISED Known Compromised or Hostile Host Traffic group 101 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 5.188.206.246:3346 -> 192.168.69.246:53

failregex = ^.*\[1\:25002..\:.*\] ET COMPROMISED Known Compromised or Hostile Host Traffic group.* \{TCP\} <HOST>\:.*
            ^.*\[1\:24000..\:.*\] ET DROP Spamhaus DROP Listed Traffic Inbound group.* \{TCP\} <HOST>\:.*
            ^.*\[1\:24020..\:.*\] ET DROP Dshield Block Listed Source group.* \{TCP\} <HOST>\:.*
            ^.*\[1\:2009358\:.*\].* \{TCP\} <HOST>\:.*
            ^.*\[1\:2032903\:.*\].* \{TCP\} <HOST>\:.*
6

Thank you, Here’s what I’ve implemented so far:

  1. Created a dataset containing known malicious IPs.
  2. Added a drop rule to automatically block any IPs in that dataset.
  3. Developed a custom Python script that continuously monitors Suricata’s eve.json log to:
  • Detect security alerts,
  • Extract the src_ip from flagged events,
  • Dynamically add those IPs to the blocked-ips dataset via suricatasc.
7

Do iptables and firewalls impact Suricata when running in IPS mode (AF_Packet, inline) on Ubuntu in transparent mode?