Snort time from alert to block



  • I setup a Snort rule that creates an alert if an external party tries to logon my email server. External addresses in alert will be put on the block list.

    alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP AUTH LOGON brute force attempt"; content:"AUTH LOGIN"; nocase; classtype:suspicious-login; sid:1000001; rev:2;)

    The above works. The question is how long time will it take from Snort setting the attacker on the blocking list before the attacker is blocked?

    I am asking because I see several logon attempts from the same attacker over a time span of 30 seconds after the first alert is fired. I tried to create an reject rule but this does not change the behavior. Any advice on how I can block right away when the first alert is fired?

    pfSense runs on a Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz



  • @jandohrmann:

    I setup a Snort rule that creates an alert if an external party tries to logon my email server. External addresses in alert will be put on the block list.

    alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP AUTH LOGON brute force attempt"; content:"AUTH LOGIN"; nocase; classtype:suspicious-login; sid:1000001; rev:2;)

    The above works. The question is how long time will it take from Snort setting the attacker on the blocking list before the attacker is blocked?

    I am asking because I see several logon attempts from the same attacker over a time span of 30 seconds after the first alert is fired. I tried to create an reject rule but this does not change the behavior. Any advice on how I can block right away when the first alert is fired?

    pfSense runs on a Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz

    The time from detection to block is measured in a few hundred microseconds or less.  However, you may be seeing the effects of "stateful inspection" from the firewall.  Snort works on copies of the packets while the original packets continue on through the firewall.  On the first packet through, pfSense will create a State Table entry allowing traffic to come and go without going through the firewall rule stack again.  To kill State Table entries when a block is inserted, be sure you have the option clicked to kill states when blocking offenders on the Snort Interface tab.

    Bill



  • Txs Bill,

    I will check the kill state table and see what happens. Currently there is a delay from first packet through to an entry in the blacklist of about 2 minutes.

    Best Regards
    Jan



  • @jandohrmann:

    Txs Bill,

    I will check the kill state table and see what happens. Currently there is a delay from first packet through to an entry in the blacklist of about 2 minutes.

    Best Regards
    Jan

    That certainly should not be happening.  The same code that writes the Snort alert to the log file fires off a subroutine to write the IP address into the table in the packet filter of pfSense.  You can see this table under Diagnostics…Tables from the pfSense menu.

    Bill



  • Hi Bill,

    Please see the below.

    Alert log:

    02/13/14 22:27:05 2 TCP An Attempted Login Using a Suspicious Username was Detected x.x.x.x 58676 y.y.y.y 25 1:1000001 SMTP AUTH LOGON brute force attempt

    Block list log:

    x.x.x.x  SMTP AUTH LOGON brute force attempt - 02/13/14-22:31:00

    Any other settings that could cause this?

    Best Regards
    Jan


  • Moderator

    @jandohrmann:

    I setup a Snort rule that creates an alert if an external party tries to logon my email server. External addresses in alert will be put on the block list.
    alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP AUTH LOGON brute force attempt"; content:"AUTH LOGIN"; nocase; classtype:suspicious-login; sid:1000001; rev:2;)

    A mail server needs to have port 25 (SMTP) open to accept mail. Why would you want to create an alert or a block for that?

    If you only want to use the mail server for local traffic, than just don't open any ports on the WAN side for port 25.



  • Hi,

    I want the mail server to receive messages from the outside so port 25 need to be open. The challenge is that I am under attack where a bot net is trying to do AUTH on the mail server (for spamming). Of course the mail server rejects the false userids/passwords but it used a lot of resources.

    The idea is to stop the intruders by blocking any SMTP trafic from the outside with an attempt to logon to the mail server.

    Best regards
    Jan


  • Moderator

    Unfortunately you cant do much unless you want to install pfBlocker and block access from other countries that you do not want to receive mail from on port 25.

    What kind of mail server are you running?

    The mail server should have RBL's where you can block most of spam and bring it down to a trickle. You should also ensure that your mail server is not Relaying mail which spammers will
    love to spam from.

    You can use these two sites do some analysis on your mail server

    http://mxtoolbox.com/

    http://www.dnsstuff.com/?reqp=1&reqr=  Use the DNS report tool.



  • The challenge is not spam but outside machines that are trying to log on to the mail sender so they could send mail from it.

    The mail sender recognize the logon attempt and blocks it but I want to stop it in the firewall.

    The question is how to stop a SMTP telegram with content AUTH.

    Snort detects the package and sends it to the block list. The problem is that pfSense "detects" it to late and let the attacker try several times. With a bot net trying right now with several attempts per second it is a huge problem.

    Best regards
    Jan


  • Moderator

    What kind of Mail server are you using?



  • I am using James (java based)


  • Moderator

    I tried to look online but couldn't find any detail about how to check for DNSRBL in the James Project Mail server software.

    I found some traces online, so it has DNSRBL's available. You need to configure them to block the known spammers.

    You should reject on the following -

    reject_invalid_hostname
    reject_non_fqdn_hostname
    reject_non_fqdn_sender

    reject_rbl_client use zen.spamhaus.org
    reject_rbl_client use bl.spamcop.net

    There are several other RBL lists available.. See    http://multirbl.valli.org/list/ or MxToolBox for other lists.

    Taken from the James Website

    James seems to be an open relay for Spam, is it?

    In some simple tests of mail relays James appears to be an open relay, properly configured it is not.
    Because James is an email application platform it currently accepts all mail delivered to it via SMTP for processing. Only after the mail has been recieved does this processing begin.
    This means that James accepts Spam. However the default configuration, and any sensible re-configuration has a number of anti-spam measures which will prevent the re-transmisson of spam from James. This makes it a blackhole for spam.

    This also means that James will not verify addresses, but of course this means that valid addresses can't be harvested from James by spammers either.

    As I said earlier, you have to leave port 25 open, but you can use pfBlocker and add sites like Spamhaus, Emerging Threats, AlienVault, dShield, CIArmy, IBlocklist, SpyEye, Malware Domain List, SRI, DRG etc etc

    These can block the known spammers before they try to get to your mail server.

    Than the Mail server needs to do the rest. Like Not Relay Mail, Check the SPF records, lookup hostname, check for FQDN etc…

    But they need to login to port 25 to do that.

    You could also install OSSEC on the Mail server that can block offenders after repeated failures.



  • Hi,

    The problem is solved.

    @bmeeks you are right - it is important to set the option to kill states when blocking offenders on the Snort Interface tab and pfSense will block the attacker before the SMTP AUTH telegram come through. The reason why I still got attacks was that the attacker went to TLS so the SMTP AUTH attempt was encapsulated. The solution to that was to let Snort identify SMTP STARTTLS telegrams from the outside and let pfSense block them.

    @Bcan17 Thank you for the James information. The mentioned settings are already used and relaying can not happen if the attacker is on an outside network (send denied) and/or do not know a valid user/password pair (send denied). Another mail server would have the same issue - if port 25 is open nothing blocks an attacker from trying to log in on a mail server with either plain text or through TLS. Snort and pfSense can block it. My mail server went from 5 unsuccessful logon attempts per second to 0.

    Best Regards
    Jan


  • Banned

    My mailserver blocks the IP for a month if failed to authenticate more than 5 times. It works.



  • Hi Supermule,

    My mail server does the same but under attack the mail server have to handle a lot of attempts through port 25. Would you agree in that it is better to let the firewall shield the mail server from outside logon attempts by blocking SMTP AUTH?

    Best Regards
    Jan


  • Banned

    Yes, thats why I think Snort is great since it takes the brute force attempts and blocks them.

    I have set it to block forever and kill states. They simply run out of fuel for Ddos and other things… :D



  • @jandohrmann:

    Hi,

    The problem is solved.

    @bmeeks you are right - it is important to set the option to kill states when blocking offenders on the Snort Interface tab and pfSense will block the attacker before the SMTP AUTH telegram come through. The reason why I still got attacks was that the attacker went to TLS so the SMTP AUTH attempt was encapsulated. The solution to that was to let Snort identify SMTP STARTTLS telegrams from the outside and let pfSense block them.

    Best Regards
    Jan

    Glad you solved it.  I will add a TODO list item to make sure "kill states" is the default when enabling BLOCK OFFENDERS.  I will allow a user to uncheck the box if they wish, but I will code it so the default state is checked.

    Bill


  • Moderator

    @jandohrmann:

    alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP AUTH LOGON brute force attempt"; content:"AUTH LOGIN"; nocase; classtype:suspicious-login; sid:1000001; rev:2;)

    I didn't see the "content:"AUTH LOGIN" in the rule above. My bad. Thought you were blocking port 25 completely at first glance.