Here's a few simple IPS rule that could be used for the containment of a repetitive SMTPAUTH failures abusers. Massive AUTH failures in your mail-systems logs mens one of two things;
- you have an hackingevent taking place
- you a mailclient end-user that's using the wrong credentials
But if your logs shows random users failures & from the same src ip_address, this is a clear sign of abusive and suspect behavior. This should warrant a closer inspection & monitor.
If the src_address falls in any countries of known bad reputations, that could be a clue of an atack
e.g ( very likely suspects )
note: if you have no users in these geo-country based on the source ip_address, this is a sign of attack!
A sample CLI ips custom rule based on monitoring the server side of the communication and the failure messages
config ips custom
set signature "F-SBID( --attack_id 7393; --revision 1; --name \"SMTP_AUTH_FAILURE01\"; --service SMTP; --protocol tcp; --tcp_flags PA; --pattern \"535 Authentication failed. Restarting authentication process\"; --flow from_server,reversed; --track dst_ip; --rate 10,120; )"
You adjust the sensitivity of the rule by the rate options. You can be more or less aggressive based on decision & after monitoring.
The above allows for 10 failures within a 2min period. This would be a sign of a hacker conducting a bruteforce/dictionary/hybrid attack against a SMTP user mailbox(es).
How long you contain the end user, is solely depending on how bad of the attack. Keep in mind a few users that mis-configure there mailclient smtp authentications values, could be caught in the detection. I would monitor the activity of the rule and conduct my own testing. Monitoring of the logs and ban-users for a few weeks/months , would be beneficial. I've ban smtp abusers from 1 hour to 7 days depending on my mood.
NOTE: it's crucil to conduct your own testing and to figure out the AUTH-failure string that's present to the client from the mail system that you are trying to protect.
In my case, the server kicks out a failure string of ;
535 Authentication failed. Restarting authentication process
Other servers might kick up the following;
535 5.7.3 Authentication unsuccessful
NOTE: In most cases it's a 535 or 538 error code.
Here's a few more rules examples based on the src or dst and the number failure seem or the number of AUTH requests generated by the client
Always monitor your logs and review the ban listing via the cli cmd get user ban list
NOTE: It's adviseable to telnet to your mail server at port 25; Issue a proper EHLO ( aka extended hello ) & request for AUTH
( example of how the dialog steps follows )
telnet x.x.x.x 25 ( x.x.x.x = your mailserver ip_address )
EHLO test.com ( the domain could legit or not, just make sure you issue a domain name )
auth login ( issue auth follow by the type you see available after the EHLO response )
1: wait for the 334 response;
Issue a username ( valid or not encode or not you just need to send something )
2: wait for the 2nd 334 response
Issue a password ( not valid encode or not you just need to send something so the server SMTP AUTH fails )
3: review the authentication failure string
( example of a typical smtp connection dialog, we me sendin username/password unencode to cause the failure )
Freelance Network/Security Engineer
kfelix -----a----t---- Socpuppets ---dot---com
=( $ $ )=