Suricata and password guessing
-
Hi.
I would like to be able to at least generate an alert when someone tries to log in trying to guess the user and password on my internal smtp server. Regarding the smtp i use Postfix with SASL.I created this custom rules for smtps:
alert tcp $EXTERNAL_NET any -> $HOME_NET 465 (msg: "SMTPS - Password Guessing Attack"; flow:to_server; flags: S,12; threshold: type both, track by_src, count 1, seconds 3; classtype:misc-activity; sid:000022465; rev:1;)
However, it is a bit too general and alerts me even in non-"malicious" cases. So i modified it like this
alert tcp $EXTERNAL_NET any -> $HOME_NET 465 (msg: "SMTPS - Password Guessing Attack"; flow:to_server; content: "authentication failure",nocase; flags: S,12; threshold: type both, track by_src, count 1, seconds 3; classtype:misc-activity; sid:000022465; rev:1;)
entering "authentication failure" which is the message my Postfix issues when there is a failed login attempt but so Suricata even doesn't even give the alert.
Can you please tell me where I am wrong.
Thank you. -
@conbonbur If it's an encrypted connection Suricata can't read the packets.
Consider something like fail2ban on the mail server which looks at the mail server logs and blocks IPs via a software firewall on the mail server.
-
@SteveITS is correct. SMTPS implies an encrypted packet stream, thus Suricata is seeing only randomized encrypted bits in the packet payload. So, your content matching rule has nothing to really match unless through some wild alignment of the stars and planets the randomized encrypted payload bits just happened to spell out the ASCII value of your content test.
This is why IDS/IPS setups on a firewall are becoming dinosaurs as more and more of today's network traffic is encrypted (HTTPS, SFTP, DoT, DoH, SMTPS, POP3S, IMAPS). Unless you configure a MITM (man-in-the-middle) proxy interception scheme with trusted certificates on the firewall and all clients so the IDS can see the unencrypted traffic, you are almost just wasting time scanning encrypted traffic. The best you can do is some simple IP address filtering and for now (until encrypted SNI takes hold) some very limited scanning of the TLS or HTTPS certificate exchange. But you can't examine the actual payload, and that's where the bad stuff lives in malicious traffic.
-
Okay. I think i understand. I thank you for your answers.
I will try other ways to keep the malicious out.
