Suricata custom rule alerts but won't block
-
@RedDelPaPa said in Suricata custom rule alerts but won't block:
@bmeeks I did some more testing of those rules today using telnet and then trying to send auth login. Even with both rules, I noticed that Suricata is very very slow to alert and block. It had as much as a two minute delay between the time I sent the auth command that the rules are scanning for and the time that Suricata picked it up and blocked my telnet session. Of course, I have it running in Legacy mode, but is it normal for it to take that long to recognize and block?
Two minutes does not sound realistic at all. How are you measuring the blocking time? If you are watching the GUI's ALERTS tab or the BLOCKS tab, that will be very misleading because those pages only update their displayed results every 60 seconds by default. The actual blocking happens within a fraction of a second (typically a few milliseconds at most between the packet and the block, and that would be if a number of packets had to be analyzed before the rule had enough info to trigger).
-
@bmeeks so the way I’m doing it is, I will login to my Mail server using telnet from a remote location, and then I will immediately send the auth login command. Then I’m counting how long I can continue to mess around in the Telnet session before the connection gets dropped and blocked. And it was taking an average of a minute to kill the connection and in some cases two minutes.
-
@bmeeks Ok, I just ran wire shark capture and discovered why it takes so long to block when "auth login" is sent to my mailserver via telnet. Telnet sends 1 packet at a time with one character at a time in each packet. 1 A 2 U 3 T 4 H, etc. A mail client sends the entire "auth login" in one packet. Making it much easier and faster for suricata to alert on.
-
@RedDelPaPa said in Suricata custom rule alerts but won't block:
@bmeeks Ok, I just ran wire shark capture and discovered why it takes so long to block when "auth login" is sent to my mailserver via telnet. Telnet sends 1 packet at a time with one character at a time in each packet. 1 A 2 U 3 T 4 H, etc. A mail client sends the entire "auth login" in one packet. Making it much easier and faster for suricata to alert on.
That is unwittingly a beautiful demonstration of how an IDS actually works at the packet level. It must receive enough of the flow to see all of the data specified by the signature. It blocks as soon as it has all the data to trigger the rule, but it may need to wait for a ton of packets before the rule has enough data to match and trigger on.
This also illustrates, somewhat, the difference between Legacy Mode and Inline IPS Mode blocking. With Legacy Mode, because PCAP is used to capture data, the original packets are continuing on to the network stack of pfSense while Suricata is analyzing a copy of the original packets. Once Suricata sees enough data to trigger the rule, it inserts a block of the offender's IP in the firewall and then clears any open states established by the original traffic that was allowed in while Suricata was analyzing the copy. Inline IPS Mode works differently. It literally sits between the network card hardware driver and the pfSense network stack. The only way data can get from the NIC to pfSense is by passing through the
netmappipe created by Suricata. In that mode, Suricata will buffer traffic for the flow until it has seen the entire exchange, then it will analyze the data and either drop the traffic or pass it on. -
@bmeeks Yes that makes perfect sense. 60 seconds to block though still seams and 50 seconds too long though when trying to fire the block via telnet.
I can't use inline mode though because I'm using traffic shaping.
-
@RedDelPaPa said in Suricata custom rule alerts but won't block:
@bmeeks Yes that makes perfect sense. 60 seconds to block though still seams and 50 seconds too long though when trying to fire the block via telnet.
I can't use inline mode though because I'm using traffic shaping.
Well, there is nothing the IDS can do until it sees enough of the traffic to match the rule. It can't foretell the future and know what's coming ...
. -
@bmeeks Of course. It just seems like it should be able to see "auth login" in less than 60 seconds. Again, it works pretty quick when an actual mail client is used for the test. But about a minute when the commands are sent via a telnet session.
-
I have submitted the Suricata blocking module fixes to the pfSense RELEASE branch Github repository and asked that those changes be merged on Monday (September 30th). If that happens as planned, a new Suricata package will appear for pfSense-2.4.4_p3 users sometime Monday.
-
@bmeeks Will be watching. Thank you sir.
-
@bmeeks Just updated the suricata package and tried my original rule. It now works as it should! Thank you!
-
@RedDelPaPa said in Suricata custom rule alerts but won't block:
@bmeeks Just updated the suricata package and tried my original rule. It now works as it should! Thank you!
Great! Thanks for the feedback.
