ID 11669 False Positive or not?

Likely to be a false positive... I've noted this event on several customer firewalls, and have disabled it (none of them use Eudora)... pretty darn sure these were false positives as the IPS reported the source as Astaro's SMTP proxy with the destination being their internal Exchange Server.  THis appears to be a rule that is easy to trigger with legit traffic.

Thanks for the affirmation.  I noticed that this was an "official" snort.org rule addition and not something Astaro specific.  If I get a few spare minutes tomorrow, I might try to try their forums to see what other snort IPS users are seeing with this rule.  If there's anything interesting, I'll post back here.

Hi everybody

I disagree with the criteria of false positive, based on the logs below.

The IP 10.1.0.72 is from my ASL 6.306, and IP 10.1.0.4 is from my Kerio Mail Server (internal mail server):


2007:07:02-13:26:12  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2115
2007:07:02-13:28:10  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2117
2007:07:02-13:29:06  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2119
2007:07:02-13:32:45  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2124
2007:07:02-13:33:10  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2125
2007:07:02-13:34:01  2 (medium)   D       SMTP possible BDAT DoS attempt [Detection of a Denial of Service Attack] TCP 10.1.0.72:58419 -> 10.1.0.4:25
2007:07:02-13:34:01  2 (medium)   D       SMTP possible BDAT DoS attempt [Detection of a Denial of Service Attack] TCP 10.1.0.72:58419 -> 10.1.0.4:25
2007:07:02-13:34:02  2 (medium)   D       SMTP possible BDAT DoS attempt [Detection of a Denial of Service Attack] TCP 10.1.0.72:58419 -> 10.1.0.4:25
2007:07:02-13:35:04  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2127
2007:07:02-13:35:04  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2129
2007:07:02-13:35:04  1 (high)     D       SPECIFIC-THREATS Eudora 250 command response buffer overflow [Attempted User Privilege Gain] TCP 10.1.0.72:25 -> 10.1.0.4:2128

Here we can see that there are an port scanning from my ASL port 25 to my mail server, increasing the target port number. I thing thats no reasons to justify this behavior. 

Thinking on an corrupt software, i prepared another new ASL machine, and after three working days, i began to receive the same messages. Besides, i am receiving too messages "SMTP possible BDAT DoS attempt" from an increasing port of ASL to port 25 of my mail server. In both cases, I blocked the packets (drop) in the definitions of ASL Intrusion Protection Rules.

I look for information on the snort.org site, and anything appeared.

I am worried about these events because they are classified by Astaro like   "Currently circulating attacks and worms" and "SMTP possible BDAT DoS attempt". I am Astaro ASL user since version 3, and never before i seem something like this.

Can anybody explain this? 

Forgive me this long mail and Thanks in advance.

same here on some asl/asg`s.
Set rule to inaktive.

Hi synopex.

Putting the rule to inactive just hide the notifications, but in the case of a real intrusion problem, this remedy will be worst than the illness itself. In that case, you will not even know whats happening, while your system is under attack without defense.

Dont you agree?. 

Anybody know an official answer from Astaro?

Regards.

No matter how well someone tests an IPS rule, you will have instances where your particular setup triggers one falsely; this is something that happens with all types of IPS systems (don't let the marketing fool you).  In this case, I actually looked at the emails that were passing from the SMTP proxy to our Exchange server when the rule was being triggered; all were legitimate emails, and the traffic was legitimate.  This is simply a rule they should have not deployed (judging by the fact that every customer I monitor with an ASG had this exact problem).  If you are not running Eudora (the mail client this rule is targeted for), there is NO need for concern--just disable the rule.  Tuning an IPS is unfortunately a reality that can not be escaped, it does require attention.

Thanks by your answer.

Precisely, as we pay attention to our instalation, we are here discussing.

I will deactivate that rule (only that!). But i dont feel happy with this action. I like to know how and why i do something, mainly when i am responsible of that.

Again, thanks by your time.

Harley