I have a Ubuntu server bastion host acting as a gateway, and it has two interfaces. I am using iptables as my firewall, and have rules defined for input, output, and forward. I am following this tutorial: 13. Setting up IPS/inline for Linux — Suricata 7.0.0-dev documentation. I see I need to run this command: sudo iptables -I FORWARD -j NFQUEUE. My concern is that this will bypass all of the rules I have established (implicit deny). How can I have suricata act as a IPS, yet still have the traffic run through my existing rules, if the traffic is NOT dropped? Do I also need to have this rule for the input and output chains?
I have a similar problem with using Suridata and Fail2ban. The solution is to start Suricata first, then Fail2ban. This puts NFQUEUE at the end of the fail2ban rules.
You did not mention how you load your iptables rules. If it is done manually or a script at startup, start Suricata first, then add your rules. Any restart would require first removing all of your rules and suricata.
On a separate note… Add the “queue bypass” option. If suricata stops for any reason without removing NFQUEUE, all traffic is blocked. A queue bypass prevents that from happening.
So I flushed/removed all iptables rules. I stopped fail2ban. I then created the 3 iptables rules, and started suricata as follows. I had the following rule in there. I could still ping. Fast.log was not producing any alerts about the ping traffic.
/usr/bin/suricata -c /etc/suricata -c /etc/suricata/suricata.yaml -q 0
iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
495 45474 NFQUEUE all – * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 NFQUEUE all – * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
423 55804 NFQUEUE all – * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0
alert tcp any any → any any (msg:“GPL ATTACK_RESPONSE id check returned root”; content:“uid=0|28|root|29|”; classtype:bad-unknown; sid:2522842; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)
From the suricata.yaml file:
outputs:
a line based alerts log similar to Snort’s fast.log
- fast:
enabled: yes
filename: fast.log
append: yes
#filetype: regular # ‘regular’, ‘unix_stream’ or ‘unix_dgram’
The rule you pasted is for tcp traffic, so it won’t match icmp
Sorry, forgot to change that back. Tried ip and udp, and it still fails.
Did you change just the protocol? It checks for a specific content. So unless you create that with that uid you won’t see an alert.
Sorry, but I’m not sure if I follow. I referenced this: 6.1. Rules Format — Suricata 6.0.0 documentation, but didn’t locate anything about what you are saying. Can you please point me in the right direction?
Can someone please help me?
This rule limits packet inspection to the TCP protocol. ping
uses ICMP
traffic so this rule will not be evaluated against it.
This is a very simplistic rule to alert on ICMP traffic. Do not use this rule in a production environment. See the ICMP kewords documentation for more information.
alert icmp any any -> any any (msg:"Example"; itype:0<>41; sid:1;)