[Snort-users] No trace for corresponding alerts

niceshorts at ...131... niceshorts at ...131...
Sat Oct 6 10:52:02 EDT 2001


    Well, Marty is the man.

    Unfortunately, I have stream2 turned off. All other things
    being equal, I'm inclined to believe my problems have to do
    with the win32 beta builds.

    I'll have to revert to RELEASE because I never had this
    problem before.

    Tks.

Sheahan, Paul (PCLN-NW) hat geschrieben:

>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.
>
>Thanks,
>
>Paul Sheahan
>Manager of Information Security
>Priceline.com
>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
>
>
>Paul
>
>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
>because
>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
>example,
>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 -> 64.210.248.166:80
>10/04-00:32:20.996684  [**] [1:0:0] Outgoing tftp port 69 [**] {TCP}
><internal server>:47873 -> 66.69.242.11:69
>
>When I check the trace file, there are no corresponding traces. This
>problem
>with traces not being created seems to be fairly new. One interesting
>thing
>looking at the above alerts is that both have the same source port of
>47873.
>I would think the chances of this would be very slim. Not sure if there is
>any signifigance to this though.....
>
>Any ideas?
>
>Thanks,
>
>Paul Sheahan
>Manager of Information Security
>Priceline.com
>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:
>
>>
>>Hello,
>>
>>I'm using Snort 1.8.1 B78 on Red Hat Linux 7.0. I use the latest version
>of
>>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
>given
>>alert. Not sure if this is a bug in Build 78 or the latest snort_stat,
>but
>>there is a DEFINITE problem. This worked flawlessly in the past. Has
>anyone
>>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
>$8.95/month.
>http://geocities.yahoo.com/ps/info1

-- 
HTTP request sent, awaiting response... 404 Object Not Found
ERROR 404: Object Not Found.




More information about the Snort-users mailing list