[Snort-users] No trace for corresponding alerts

niceshorts at ...131... niceshorts at ...131...
Fri Oct 12 09:48:06 EDT 2001


    I appreciate the email Mike. I *do* notice that the frequency
    of my phantom alerts dropped significantly when Nimda and
    CodeRed|CRv2 has dropped off.

    This leads me to believe that load is a significant factor in
    causing lost traces or phantom alerts whatever it may be.

    Here's one I got this morning (it used to be 30-40% of all my
    alerts, now it's around 10%):

[**] [1:1002:1] WEB-IIS cmd.exe access [**]
[Classification: Attempted User Privilege Gain] [Priority: 8]
10/12-12:30:24.617116 4.41.y.z:12628 -> 192.168.a.b:80
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:3065
***AP*** Seq: 0xE1E8D757  Ack: 0x37C4DEA  Win: 0x4470  TcpLen: 20

    The TTL is unlikely. The source is a Windows box which
    normally does not set initial TTL that high.

    Again, the TOS = 0x10 (0001 0000)
    There is not a single instance of TOS:0x10 in any trace I
    have. The only time I see this TOS value is in the alert.ids

    The IP address 4.41.y.z is from a real user not a
    Nimda/CR affected host. Web logs indicate that its traffic is
    business as usual.

    The IP ID field is zero.

    Unfortunately, I haven't had the chance to try RELEASE yet.

    Here's my snort.conf:

var HOME_NET [x.x.x.x/y]
preprocessor frag2
preprocessor stream4: detect_scans
preprocessor stream4_reassemble
preprocessor unidecode: 80 -unicode -cginull
preprocessor portscan: $HOME_NET 4 3 portscan.log
preprocessor portscan-ignorehosts: $DNS_SERVERS
include classification.config
include exploit.rules
include scan.rules
include smtp.rules
include backdoor.rules
include dos.rules
include ddos.rules
include dns.rules
include netbios.rules
include web-cgi.rules
include web-coldfusion.rules
include web-frontpage.rules
include web-iis.rules
include web-misc.rules
include misc.rules
include policy.rules
include info.rules
include virus.rules
include local.rules

Michael Steele hat geschrieben:

>Do you think there is something we are doing when we create the builds
>or a programming concern?
>Did reverting back to the release solve the problem? We also keep all
>the latest CVS builds online. Maybe try going back to a previous CVS
>build will fix it?
>          Commercial Snort Support
>               1.866.41.SNORT
>Silicon Defense - www.silicondefense.com
>Michael Steele - Snort Support Technician
>-----Original Message-----
>From: snort-users-admin at lists.sourceforge.net
>[mailto:snort-users-admin at lists.sourceforge.net] On Behalf Of
>niceshorts at ...131...
>Sent: Saturday, October 06, 2001 10:51 AM
>To: Sheahan, Paul (PCLN-NW)
>Cc: 'Anthony Kim'; snort-users at lists.sourceforge.net
>Subject: Re: [Snort-users] No trace for corresponding alerts
>    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
>>"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.
>>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
>>typically have some of these weird symptoms:
>>A bit is set in TOS. The IP ID field is zeroed. The source of the
>>is a Windows machine which normally defaults to a TTL of 128 but comes
>>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
>>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
>>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
>>alert tcp $HOME_NET any <> $EXTERNAL_NET 69 (msg:"Outgoing tftp port
>>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
>>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
>>>snort_stat.pl to generate reports for me every night at midnight. I
>>>have the report emailed to me automatically.
>>>For every alert, there has ALWAYS been a corresponding trace in my
>>>file. This allows me to lookup details on alerts when needed. Ever
>>>upgrading to Build 78 and the latest snort_stat (both upgraded around
>>>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
>HTTP request sent, awaiting response... 404 Object Not Found
>ERROR 404: Object Not Found.
>Snort-users mailing list
>Snort-users at lists.sourceforge.net
>Go to this URL to change user options or unsubscribe:
>Snort-users list archive:

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

More information about the Snort-users mailing list