This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPS Possible false positive for smtp proxied connections

Hello, 
I have SMTP Proxy and IPS on.

This morning I noticed about 100 emails in SMTP spool. My SMTP server's log reports a lot of winsock errors and IPS log reports about 1000 attacks like this:

2014:05:12-12:10:51 FIREWALLNAME snort[26883]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="SERVER-MAIL Metamail header length exploit attempt" group="500" srcip="DMZ_UTM_IP_ADDRESS" dstip="MAIL_SERVER_IP_ADDRESS" proto="6" srcport="34661" dstport="25" sid="22114" class="Attempted Administrator Privilege Gain" priority="1"  generator="1" msgid="0"


After deleting 96 emails, remained only 4 legitimate email. Also in this case the emails were not sent to internal mail server. So I disabled IPS, and the emails were successfully sent. 

Ok, it may happen to run into a false positive, but what I cannot understand is: considering that this attack affects the header of a mail (and it should be analized by SMTP proxy) why IPS didn't block the connection between remote server and SMTP proxy? In that case, the inconveniences caused by false positive affects only a specific email and does not block all incoming email...


This thread was automatically locked due to age.
Parents
  • Snort/IDS rules seem to be a bit twitchy at the moment.  

    I also experienced this with a customer site Friday.   They are or were on version 8.306.   I had to disable all the following rules, as they were all kicking off.   This was safe because we have cloud based anti-spam measures.  I have just put them back to Notify a couple of days later - i.e. today:

    22114 Action: Alert, Notify on
    22113 Action: Alert, Notify on
    22115 Action: Alert, Notify on
    22111 Action: Alert, Notify on


    THEN - I made the big mistake of upgrading them to 8.311. Their CPU has been running since at 100% thanks to SNORT until I disabled all the rulesets except the Malicious one.  This brought sanity back.  You might want to be more careful than me in upgrading.   

    I ignored my own rule of ignoring any release that has been superseded within 30 days of its release.

  • THEN - I made the big mistake of upgrading them to 8.311. Their CPU has been running since at 100% thanks to SNORT until I disabled all the rulesets except the Malicious one.  This brought sanity back.  You might want to be more careful than me in upgrading.   


    AHH!!!
    I have 8.309 and for this week was scheduled 8.311 upgrade!


    I ignored my own rule of ignoring any release that has been superseded within 30 days of its release.

    Uhm... what you mean? 8.311 has been released on august 2013..
Reply

  • THEN - I made the big mistake of upgrading them to 8.311. Their CPU has been running since at 100% thanks to SNORT until I disabled all the rulesets except the Malicious one.  This brought sanity back.  You might want to be more careful than me in upgrading.   


    AHH!!!
    I have 8.309 and for this week was scheduled 8.311 upgrade!


    I ignored my own rule of ignoring any release that has been superseded within 30 days of its release.

    Uhm... what you mean? 8.311 has been released on august 2013..
Children
No Data