Full Disclosure mailing list archives
RE: msblast DDos counter measures (More Insight Maybe?)
From: "Christopher Lyon" <cslyon () netsvcs com>
Date: Fri, 15 Aug 2003 09:02:10 -0700
From: Vladimir Parkhaev [mailto:vladimir () arobas net] Quoting B3r3n (B3r3n () argosnet com):Christopher,So, the machine is coming back up and the date was set after the
16th
and what do I see, I see a SYN flood but the source is 127.0.0.1
and
thedestination is 192.168.X.X/16. (I am using 192.168.252.100 so the
X's
are the random numbers)A question: does 192.168.x.x/16 reflects the configuration of theinfectedmachine, or maybe a subnet of its configuration?I don't see the problem... The PC in question is on 192.168.x.0 nw with address 192.168.x.y. According to the worm analysis, it msblaster picks random src IP addresses limited to first 2 octets of infected PCs nw - anything between 192.168.0.0-192.168.255.255 (or
192.168.255.254).
The OP points windowsupdate.com to 127.0.0.1. The worm starts
generting
packets dst 127.0.0.1 src in 192.168.0.0-192.168.255.255. Since PC is not runing web server, OS sends a RST to the dst in 192.168.0.0-192.168.255.255 (basic TCP). More SYN packets are
generated,
more RST packets you get on your class B n/w. Conclusion - pointing windowsupdate.com to 127.0.0.1 replaces SYN
attack
of windowsupdate.com by RST attack on your class B. Solution - patch the freaking PCs!
I agree that patching the PC is the ultimate answer but what I am saying is that what we ALL think the virus will do when we try to set the windowsupdate.com to 127.0.0.1 is just the opposite. Look at these traces to see what it is doing. Note the source and destination ports and addresses. WINDOWSUPDATE.COM set to resolve normally 19:48:23.963345 192.168.187.171.1823 > 204.79.188.11.http: S 886046720:886046720(0) win 16384 It is allowed to resolve normally and the source is just what we think. 192.168.x.x with the x's random numbers. This is what we all know and can prove. WINDOWSUPDATE.COM set to 127.0.0.1 19:39:56.131653 localhost.localdomain.http > 192.168.83.210.1269: R 0:0(0) ack 68419585 win 0 Now look at the source, the source is 127.0.0.1 and the destination is the 1921.68.x.x with the x's being random numbers. That is what I am saying is different. Also note that the dst port is 80. So, what I am saying is that the syn flood will leave the box but it will leave differently then we all think. So, can someone confirm this? I have been seeing this in two different environments now.
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: msblast DDos counter measures (More Insight Maybe?) Christopher Lyon (Aug 15)
- RE: msblast DDos counter measures (More Insight Maybe?) B3r3n (Aug 15)
- Re: msblast DDos counter measures (More Insight Maybe?) Vladimir Parkhaev (Aug 15)
- Re: msblast DDos counter measures (More Insight Maybe?) Chris Garrett (Aug 15)
- msblast DDos counter measures - a new worm to fix the problem Daniel Rudolph (Aug 15)
- Re: msblast DDos counter measures - a new worm to fix the problem Paul Schmehl (Aug 15)
- Re: msblast DDos counter measures - a new worm to fix the problem Ron DuFresne (Aug 15)
- msblast DDos counter measures - a new worm to fix the problem Daniel Rudolph (Aug 15)
- RE: msblast DDos counter measures (More Insight Maybe?) B3r3n (Aug 15)
- <Possible follow-ups>
- RE: msblast DDos counter measures (More Insight Maybe?) Christopher Lyon (Aug 15)
- Re: msblast DDos counter measures (More Insight Maybe?) Vladimir Parkhaev (Aug 15)
- RE: msblast DDos counter measures (More Insight Maybe?) Christopher Lyon (Aug 15)
- Re: msblast DDos counter measures (More Insight Maybe?) Vladimir Parkhaev (Aug 15)
