Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 609 views
  • Users 0 members are here
Options
Suggested
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

Alert time stamps

Scott_Klassen
Been getting some IPS alerts lately under the SMTP category and I'm trying to determine what exactly is triggering them (trying to tie to a specific SMTP session so I can find out sender and receiver).  Trying to determine if they are false positives or not.
 
I've pulled up each instance in the IPS logs, then go to the SMTP logs to see the traffic around the time of the alert. All alerts have been triggered during normal weekday business hours.  Each time, there's a valid message at the exact second of the alert, but something invalid within a second or two preceeding the alert.
 
Here's my question. Is there going to be a short time lag between something triggering an alert and the IPS log entry being written, or are the time stamps going to match up completely.
 
The alerts in question are ID 10995 A SMTP possible BDAT DoS attempt and ID 2183 A SMTP Content-Transfer-Encoding overflow attempt. I really wish I could tell what it takes to trigger these, since that would also help as to whether I should continue to pass these packets or drop them.
 
Thanks.


This thread was automatically locked due to age.
  • 0
    Hello Scott,

       I've been receiving tons of these in the last few days and am trying to figure them out as well.  I've been searching ALL logs to find a tie-in and have so far been unsuccessful.  It did take up all the outgoing bandwidth from the site and 2 of the user email accounts were spamming however, there is nothing in any virus files from the firewall or Symantec that indicates any investation and all the machines were cleaned from safe-mode but nothing whatsoever was found in the way of virus.

    So I am at a loss as to the cause.  Have you got any further info?

    Thanks 
    L A Jensen
  • 0 in reply to LAJensen
    Both of those are rather common false positives... but what I would do is check your email server logs and / or the exim logs on the astaro during that particular event... by determining what hosts are involved, you should be able to rule out a true attack, and then disable the rule.