Suricata custom rule alerts but won't block
-
@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
netmap
pipe 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.