[Snort-users] No trace for corresponding alerts

Sheahan, Paul (PCLN-NW) Paul.Sheahan at ...2218...
Fri Oct 5 13:38:07 EDT 2001

Thanks Anthony. I spoke with Martin Roesch about this in email and he said:

"You've got stream2 and stream4 turned on, turn off stream2 and I bet
everything will work fine."

Not sure if this applies to you, but take a look. I had both turned on. I
probably enabled Stream2 whole experimenting.


Paul Sheahan
Manager of Information Security
paul.sheahan at ...2218...

-----Original Message-----
From: Anthony Kim [mailto:niceshorts at ...131...]
Sent: Friday, October 05, 2001 3:18 PM
To: Paul.Sheahan at ...2218...; snort-users at lists.sourceforge.net
Subject: RE: [Snort-users] No trace for corresponding alerts


I haven't had time to revert back to the RELEASE build of snort.
I set full alerts turned on so I have some correlations. My phantom alerts
typically have some of these weird symptoms:

A bit is set in TOS. The IP ID field is zeroed. The source of the packet
is a Windows machine which normally defaults to a TTL of 128 but comes up
with an unlikely value much higher than the actual hop count. Unlikely
sequence numbers and ACK values, too.

I have far too many of these alerts for it to be mere coincidence or route
flapping. So the problem is one of two:

One) the packets are real and the trace is not occurring (a bug)

Two) the packets are phantom and the trace is correct (the false alerts
never happened) and there is a bug most likely associated with the
pseudo-header used to compute TCP checksums -- you don't get false alerts
for non-TCP traffic do you?

If you turn on alerts to full see if some of your headers have these
symptoms. I will most likely revert to RELEASE or try a new beta build
some time next week. Also correlate your phantom alerts with your trace
file to see if there are patterns before and after the phantom alerts.

Hope this helps.

-anthony kim

-----Original Message-----
From: Sheahan, Paul (PCLN-NW) [mailto:Paul.Sheahan at ...2218...]
Sent: Friday, October 05, 2001 16:54
To: 'niceshorts at ...131...'; Snort List (E-mail)
Subject: RE: [Snort-users] No trace for corresponding alerts

I have two custom rules that I have always used that check for outgoing
connections on port 80 (HTTP) and 69 (TFTP). I don't check for flags
this rarely occurs on our network anyway, so it is always caught just
looking at the destination port. Here are my two custom rules:

alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Outgoing http port 80";)
alert tcp $HOME_NET any <> $EXTERNAL_NET 69 (msg:"Outgoing tftp port 69";)

Internmittenly, these rules are met and an alert is generated. For
here are two alerts directly from my alerts file from yesterday (with
<internal server> replacing the actual IP address):

10/04-00:23:40.992329  [**] [1:0:0] Outgoing http port 80 [**] {TCP}
<internal server>:47873 ->
10/04-00:32:20.996684  [**] [1:0:0] Outgoing tftp port 69 [**] {TCP}
<internal server>:47873 ->

When I check the trace file, there are no corresponding traces. This
with traces not being created seems to be fairly new. One interesting
looking at the above alerts is that both have the same source port of
I would think the chances of this would be very slim. Not sure if there is
any signifigance to this though.....

Any ideas?


Paul Sheahan
Manager of Information Security
paul.sheahan at ...2218...

-----Original Message-----
From: niceshorts at ...131... [mailto:niceshorts at ...131...]
Sent: Thursday, October 04, 2001 2:54 PM
To: Snort List (E-mail)
Subject: Re: [Snort-users] No trace for corresponding alerts

Sheahan, Paul (PCLN-NW) hat geschrieben:

>I'm using Snort 1.8.1 B78 on Red Hat Linux 7.0. I use the latest version
>snort_stat.pl to generate reports for me every night at midnight. I then
>have the report emailed to me automatically.
>For every alert, there has ALWAYS been a corresponding trace in my trace
>file. This allows me to lookup details on alerts when needed. Ever since
>upgrading to Build 78 and the latest snort_stat (both upgraded around the
>same time), maybe 10% of the time, I find no corresponding trace for a
>alert. Not sure if this is a bug in Build 78 or the latest snort_stat,
>there is a DEFINITE problem. This worked flawlessly in the past. Has
>else experienced this? 

    Post some example alerts. I've seen this problem often on
    win32 beta builds. There are some distinguishing features of
    these "phantom" alerts which I would like some correlation
    on. I don't use snort_stat so if you could cut and paste from
    alert.ids that would be great.

    -anthony kim

Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just

More information about the Snort-users mailing list