Phil Wood <cpwlanl.gov> wrote in response to me:

I've changed the order of things below in the hope of making the discussion
more clear. First your example:

>In my case, I set up 2 packet capture systems running. [ tcpdump, snort ]
>[ ... Snip ... ]
>Consequently, I get what I call illegal icmp packets. When I compare one
>of these with the real thing captured by the tcpdump, there is a glaring
>difference.
>[ ... Snip ... ]
>When I remove 'defrag' preprocessor. The problem seems to go away.

That's a nice piece of work. Thanks for sharing it.

I haven't been using the 'defrag' preprocessor because I was worried about
the prominently displayed "BETA CODE" warnings, but what I have been wondering
is whether those wierd flag collections are in fact a similar artifact.

Now mine:

>> =====================================================
>> [**] PING-ICMP Destination Unreachable [**]
>> 06/03-00:56:43.763294 12.127.237.65 -> xxx.yyy.zzz
>> ICMP TTL:241 TOS:0x0 ID:14290 IpLen:20 DgmLen:56
>> Type:3 Code:13 DESTINATION UNREACHABLE: PACKET FILTERED
>> ** ORIGINAL DATAGRAM DUMP:
>> xxx.yyy.zzz:25 -> 128.138.77.15:38058
>> TCP TTL:246 TOS:0x0 ID:24527 IpLen:20 DgmLen:40
>> 12U*PRS* Seq: 0xD1F97B19 Ack: 0x0 Win: 0x0 TcpLen: 0 UrgPtr: 0x0
>> ** END OF DUMP
>> ======================================================
>>[ ... Snip ... ]
>>Is this the sort of thing you are referring to?
>
>nope. It's interesting because at first blush, xxx.yyy.zzz sent the
>weird ass packet with 12u*PRS* in it to 128.138.77.15 and an intermediate
>(router) says "hey that's crap my filters don't like it, and I'm going
>to send it back, encapsulated in an icmp destination unreachable packet.
>You deal with it!"

They aren't happening now, but when these alerts are appearing in the snort
log I've tried doing a traceroute to the target machine -- though not in this
example because of the hour -- and found that it *was* in fact unreachable.
Further, port 25 is what sendmail uses, and these wierd packets are, so far
as I can tell, associated with that port, so I checked syslog to see whether
any message bound to or from 128.138.77.15, or the name it resolves to, ever
got through. I didn't find any mention of the host, let alone of problems
connecting with it. I haven't mentioned previously that alerts like this
occur in long strings with the only significant variation being in the flag
settings; all wierd, some like this example, many not.

I checked the mail queue as a matter of course and it was empty. E-mail has
gone in and out to this address normally at other times. The closest example
to that of this packet occurred approximately 36 hours later. There were none
in the previous week.

My next question is why my machine is dumping wierd packets out port 25 bound
for a machine that it can't reach, and apparently doesn't have any useful
business with? It occurs to me that this may be my machine's response to
an attack, and that the target address, 128.138.77.15, is spoofed by the
attacker. Alternatively, I wondered if it could be something like Phil has
found and for some reason snort is not reporting the flags ( at least ) of
the original datagram accurately.

I clearly recognize that there is much here I don't understand. If you, Phil,
or anyone else, has any ideas I'd sure like to read them.

Best regards,

Neil Dickey, Ph.D.
Research Associate/Sysop
Geology Department
Northern Illinois University
DeKalb, Illinois
60115

_______________________________________________
Snort-users mailing list
Snort-userslists.sourceforge.net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]