It *appears* to us through current testing that the source address
spoofed is always within the class of the current subnet... So, a
spoofing filter that denies all but the local subnet may only be
partially affective..
-Randomizes its source port, but destination is always TCP/80
-Does one DNS lookup on "windowsupdate.com" and then uses the IP
returned
-The window size is always 16384 (this might be useful)
It also looks like there is no throttling at all.. it abuses as much
bandwidth as it possibly can...
Does anyone have any notion of what the Blaster worm will do if the
DNS lookup for "windowsupdate.com" returns NXDOMAIN? If it handles this
case by not sending any micreant love, might that not be the best way
to mitigate the potential damage?
If the blaster cannot get a proper DNS response, it continues to
replicate via port 135... It then goes into a retry cycle and continues
to try to get a good DNS lookup.
Since no one has brought it up yet, wouldn't it be just dandy if rev 2 of
this worm attacked different stuff? Call it the perfect storm, RPC
vulnerability used to whack infrastrcture. It doesn't take long to think of
the perfect combinations since this thing was cut and pasted together.
has anyone tried tarpitting eg labrea to slow the worm?
I have been using my Linux kernel module ipt_TARPIT (included in the latest
netfilter.org patch-o-matic release) to do this for any IPs on my network
lacking a route, including outbound from my customers and inbound to my
unused address space.
While it is trying to scan routeless IPs, the tarpit slows it down to
scanning 20 IPs per ~9 minutes. (MSBlast has 20 connection slots, each
apparently timing out after ~9 minutes.) It normally appears to have a
several second connect timeout, so this slows it down by two orders of
magnitude with a similar drop in network traffic.
If the blaster cannot get a proper DNS response, it continues to
replicate via port 135... It then goes into a retry cycle and continues
to try to get a good DNS lookup.
has anyone tried tarpitting eg labrea to slow the worm?
Oh yeah, LaBrea sticks 'em *REAL* good...
LaBrea::Tarpit SOURCE IP's
15223 total threads captured, from these 109 IP addresses
LaBrea makes it look like the exploit worked, and it hangs up the worm trying to send the command to 4444. Thread counts get as high as 2546 (as of now) which is 10x the subnet block where the tarpit lives.
Had more like 30K threads until this morning when we had a power outage that outlived my small UPS so the numbers above are since ~9:30 EST this morning.