Friday, July 11, 2014

Example fo SMTP_AUTH protection fortigate IPS style

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
The latter is easy to identify by looking at the username in the failures. If it's valid user and with no random usernames ( the same users fails over and over and over,etc...) than it might be a legit mis-configuration.

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
    edit "SMTP_AUTH01"
        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 ( 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  )

Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- Socpuppets ---dot---com

   ^    ^
=( $ $ )=
     /  \

1 comment:

  1. I'm finding your blog very useful Ken as I'm still learning FortiOS.

    Any chance you could provide a little further guidance on this? I'm implementing a Fortigate 60D with FortiOS 5.2.3 and find that my attempt to replicate your SMTP_AUTH01 signature above has its rate parameter ignored.

    Offending IPs are quarantined successfully but after their first authentication failure with a rate of 2, 90 set rather than after their second as I would expect.

    Any debugging hints / tips you might have would be appreciated.