Re: unidentified DOS "bad traffic"

[Jason Falciola <falciola () us ibm com>]

Quick, subjective, gut-response analysis:  YMMV.  :-)

I'd do some closer looking at the source machine.  I'm somewhat wary of 
trusting the user to just run a AV scan.  This may be a new piece of 
malware that doesn't have an AV def. yet.  Or the user may be doing 
something wrong.  Apply the standard IR procedures.  Especially use 
netstat -an for open connections and fport to map processes bound to 
individual ports.

Based on the destination, I'm guessing that 10.1.2.3 is compromised and 
being used as a bot to perform a DoS (maybe distributed) against an IRC 
server run by AOL.  Are the MS networking ports (135-139, 445) exposed to 
the Internet?  Does the Admin account have a weak/null password?

The sig is firing b/c protocol 255 is reserved and you shouldn't see 
packets w/ that protocol type 
(http://www.iana.org/assignments/protocol-numbers).  I'm guessing this is 
being used either to evade detection by some weaker forms of IDS or to 
slip through packet filtering devices that are only inspecting TCP, UDP, 
ICMP, etc.

Do you have an idea of the volume of packets that were coming from this 
source?  What was the rate in pps?  Are you running Cisco Netflow?  If so, 
check those logs.

Please let me know if you have any questions.

Thanks!

Jason Falciola
Information Security Analyst
IBM Managed Security Services
falciola () us ibm com





DY <dybulk () tri8 net>
03/13/2003 04:53 PM

 
        To:     incidents () securityfocus com
        cc: 
        Subject:        unidentified DOS "bad traffic"



Hi all,

I'm quite surprised at the lack of material I'm turning up in researching
this issue, so I'm resorting to this post.  Please feel free to point me
somewhere.

Twice in the past week I have experienced a severe DOS condition on my
network.  A particular host has been completely flooding the network with
some sort of traffic that chokes the whole thing.  Now, on the first
incident I was unable to obtain packet trace data (I'll spare the details)
and was forced to reconnect the particular segment's port.  We got by for
a few days, and then wham, it happened again.  This time I isolated the
segment with a Snort sensor and captured a large amount of data (actually,
I only sniffed for a few seconds before I'd already swallowed about 10 MB
of data, all of which was identical, so I stopped).  My Snort output on
this trace was filled with nothing but bizillions of these entries
(payload did vary a little):


03/13-07:53:50.650383 10.1.2.3 -> 64.12.165.57
PROTO255 TTL:128 TOS:0x0 ID:50456 IpLen:20 DgmLen:80
45 10 00 3C B5 F5 40 00 40 06 E8 85 CD A2 E9 48  E..<..@.@......H
40 0C A5 39 D3 A6 1A 0B BC C0 DE 3C 00 00 00 00  @..9.......<....
A0 02 7D 78 D3 8E 00 00 02 04 05 B4 04 02 08 0A  ..}x............
00 CD 7F 52 52 00 00 00 01 03 03 00              ...RR.......

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



The source IP is from a private network that I run, which uses basic NAT,
so I can certainly route and identify the host, as this capture is from
the private side of the NAT router.  Now, here's the Snort alert entry
(again, just thousands of this same entry):


[**] [1:1627:1] BAD TRAFFIC Unassigned/Reserved IP protocol [**]
[Classification: Detection of a non-standard protocol or event] [Priority:
2]
03/13-07:53:11.032136 10.1.2.3 -> 64.12.165.57
PROTO255 TTL:128 TOS:0x0 ID:23977 IpLen:20 DgmLen:80


Now, I've read up on the Snort signature that generates this alert (SID
1627).  It says that it's bad traffic (of course) using an unassigned
protocol, which of course the alert states.  However, I'm not finding
anything (Google, Usenet, etc.) that leads me toward the proper analysis
of what this machine was doing.  All I know is:

1) The machine runs Win2K pro.
2) The user has no idea what's going on, of course, and has scanned his
machine with the latest AV updates, with no viri found.
3) IP address 64.12.165.57, the destination for this complete flood of
"bad traffic," resolves (reverse) to irc-m.icq.aol.com.
4) There was so much of this traffic that it shut my network down.  My
main router (Cisco) reported no appreciable CPU consumption during the
attack.  It just appears that the sheer volume of the [bad] packets choked
everybody out.


So, I know of no exploit, no virus, no known malicious destination (which
might lead me to an exploit)...and yet I had no throughput (except for the
"bad traffic").

Can anybody give me a clue, or at least point me somewhere (probably
obvious) that I seem to be missing?  I might post to the Snort-users list
as well, I guess, in case anybody there has ideas.

Many TIA,
--
DY


----------------------------------------------------------------------------

<Pre>Lose another weekend managing your IDS?
Take back your personal time.
15-day free trial of StillSecure Border Guard.</Pre>
<A href="http://www.securityfocus.com/stillsecure";> http://www.securityfocus.com/stillsecure </A>