Re: Weird attack or traffic (Was Re: The impending DDoS storm)
It kinda looks like the virus or whatever it is, is spoofing source IP. Now I am seeing lots of spoofed packets trying to egress out of our network. We are filtering egress traffic so obviously its being dropped at edge of course... Just cleared access-list counter about a minute or so ago and this: box02c75-br01#sh ip acces 180 | in deny deny ip any any log-input (17268883 matches) box02c75-br01# -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Fri, Aug 15, 2003 at 01:04:38AM -0400, Haesu wrote: > > Is anyone else seeing backscatters on your network about windowsupdate.com's IP? > > Someone who transits through 65.123.21.137 router is sending out lots of packets > to 204.79.188.11 (windowsupdate.com) in which its not currently advertised to > internet as we speak. Not to mention, packets seem to be source-spoofed to > 65.124.16.0/21 (our block), causing backscatter from 65.123.21.137 to our > network... > > Any ideas/or anyone seeing similar effect? Is someone who is administrative to > Qwest Communications WASH01-WAN-65-123-21 (NET-65-123-21-0-1) aware of this may > be? It looks like a Qwest customer CPE router to me but I dunno.. > > See below for traffic snapshot.. > > -hc > > -- > Sincerely, > Haesu C. > TowardEX Technologies, Inc. > WWW: http://www.towardex.com > E-mail: [EMAIL PROTECTED] > Cell: (978) 394-2867 > > k00:50:22.807370 65.123.21.137 > 65.124.23.125: icmp: net 204.79.188.11 unreachable > 00:50:22.891672 65.123.21.137 > 65.124.22.48: icmp: net 204.79.188.11 unreachable > 00:50:22.979997 65.123.21.137 > 65.124.22.98: icmp: net 204.79.188.11 unreachable > 00:50:23.047340 65.123.21.137 > 65.124.22.21: icmp: net 204.79.188.11 unreachable > 00:50:23.133616 65.123.21.137 > 65.124.22.72: icmp: net 204.79.188.11 unreachable > 00:50:23.520405 65.123.21.137 > 65.124.23.107: icmp: net 204.79.188.11 unreachable > 00:50:23.745844 65.123.21.137 > 65.124.22.3: icmp: net 204.79.188.11 unreachable > 00:50:23.829309 65.123.21.137 > 65.124.22.54: icmp: net 204.79.188.11 unreachable > 00:50:24.493650 65.123.21.137 > 65.124.23.113: icmp: net 204.79.188.11 unreachable > 00:50:24.530074 65.123.21.137 > 65.124.23.35: icmp: net 204.79.188.11 unreachable > 00:50:24.618082 65.123.21.137 > 65.124.23.86: icmp: net 204.79.188.11 unreachable > 00:47:50.611529 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable > 00:47:50.649962 65.123.21.137 > 65.124.17.151: icmp: net 204.79.188.11 unreachable > 00:47:50.711865 65.123.21.137 > 65.124.17.124: icmp: net 204.79.188.11 unreachable > 00:47:50.756960 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable > 00:47:50.826367 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable > 00:47:52.355967 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable > 00:47:52.587141 65.123.21.137 > 65.124.20.46: icmp: net 204.79.188.11 unreachable > 00:47:53.865460 65.123.21.137 > 65.124.22.87: icmp: net 204.79.188.11 unreachable > > 00:48:05.250757 65.123.21.137 > 65.124.16.1: icmp: net 204.79.188.11 unreachable > 00:48:05.713640 65.123.21.137 > 65.124.17.86: icmp: net 204.79.188.11 unreachable > 00:48:05.841169 65.123.21.137 > 65.124.17.60: icmp: net 204.79.188.11 unreachable > 00:48:06.013042 65.123.21.137 > 65.124.16.33: icmp: net 204.79.188.11 unreachable > 00:48:06.549540 65.123.21.137 > 65.124.17.41: icmp: net 204.79.188.11 unreachable > 00:48:06.803847 65.123.21.137 > 65.124.17.92: icmp: net 204.79.188.11 unreachable > 00:48:06.981930 65.123.21.137 > 65.124.17.15: icmp: net 204.79.188.11 unreachable > 00:48:07.26 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable > 00:48:07.343120 65.123.21.137 > 65.124.18.74: icmp: net 204.79.188.11 unreachable > 00:48:07.486285 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable > 00:48:07.569901 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable > 00:48:08.117407 65.123.21.137 > 65.124.18.106: icmp: net 204.79.188.11 unreachable > 00:48:08.356732 65.123.21.137 > 65.124.20.41: icmp: net 204.79.188.11 unreachable > 00:48:08.637485 65.123.21.137 > 65.124.20.14: icmp: net 204.79.188.11 unreachable > 00:48:08.944750 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable > 00:48:08.946623 65.123.21.137 > 65.124.22.49: icmp: net 204.79.188.11 unreachable
Re: Weird attack or traffic (Was Re: The impending DDoS storm)
Yes, we are starting to see this as well. We are filtering at the edge, so the bogus packets are not getting out. We have a /19 of 64.7.128.0/19 and 64.7.229.241 is totally bogus for our network. Aug 14 21:59:16 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.229.241:1069 204.79.188.11:80 out via fxp1 Aug 14 21:59:16 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.39.113:1904 204.79.188.11:80 out via fxp1 Aug 14 21:59:16 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.105.240:1739 204.79.188.11:80 out via fxp1 Aug 14 21:59:16 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.235.113:1178 204.79.188.11:80 out via fxp1 Aug 14 21:59:16 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.46.113:1014 204.79.188.11:80 out via fxp1 Aug 14 21:59:16 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.111.240:1849 204.79.188.11:80 out via fxp1 Aug 14 21:59:17 telus-151front /kernel: ipfw: 3 Deny TCP 64.7.176.240:1685 204.79.188.11:80 out via fxp1 ---Mike At 01:04 AM 15/08/2003 -0400, Haesu wrote: Is anyone else seeing backscatters on your network about windowsupdate.com's IP? Someone who transits through 65.123.21.137 router is sending out lots of packets to 204.79.188.11 (windowsupdate.com) in which its not currently advertised to internet as we speak. Not to mention, packets seem to be source-spoofed to 65.124.16.0/21 (our block), causing backscatter from 65.123.21.137 to our network... Any ideas/or anyone seeing similar effect? Is someone who is administrative to Qwest Communications WASH01-WAN-65-123-21 (NET-65-123-21-0-1) aware of this may be? It looks like a Qwest customer CPE router to me but I dunno.. See below for traffic snapshot.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 k00:50:22.807370 65.123.21.137 > 65.124.23.125: icmp: net 204.79.188.11 unreachable 00:50:22.891672 65.123.21.137 > 65.124.22.48: icmp: net 204.79.188.11 unreachable 00:50:22.979997 65.123.21.137 > 65.124.22.98: icmp: net 204.79.188.11 unreachable 00:50:23.047340 65.123.21.137 > 65.124.22.21: icmp: net 204.79.188.11 unreachable 00:50:23.133616 65.123.21.137 > 65.124.22.72: icmp: net 204.79.188.11 unreachable 00:50:23.520405 65.123.21.137 > 65.124.23.107: icmp: net 204.79.188.11 unreachable 00:50:23.745844 65.123.21.137 > 65.124.22.3: icmp: net 204.79.188.11 unreachable 00:50:23.829309 65.123.21.137 > 65.124.22.54: icmp: net 204.79.188.11 unreachable 00:50:24.493650 65.123.21.137 > 65.124.23.113: icmp: net 204.79.188.11 unreachable 00:50:24.530074 65.123.21.137 > 65.124.23.35: icmp: net 204.79.188.11 unreachable 00:50:24.618082 65.123.21.137 > 65.124.23.86: icmp: net 204.79.188.11 unreachable 00:47:50.611529 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:47:50.649962 65.123.21.137 > 65.124.17.151: icmp: net 204.79.188.11 unreachable 00:47:50.711865 65.123.21.137 > 65.124.17.124: icmp: net 204.79.188.11 unreachable 00:47:50.756960 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:47:50.826367 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:47:52.355967 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:47:52.587141 65.123.21.137 > 65.124.20.46: icmp: net 204.79.188.11 unreachable 00:47:53.865460 65.123.21.137 > 65.124.22.87: icmp: net 204.79.188.11 unreachable 00:48:05.250757 65.123.21.137 > 65.124.16.1: icmp: net 204.79.188.11 unreachable 00:48:05.713640 65.123.21.137 > 65.124.17.86: icmp: net 204.79.188.11 unreachable 00:48:05.841169 65.123.21.137 > 65.124.17.60: icmp: net 204.79.188.11 unreachable 00:48:06.013042 65.123.21.137 > 65.124.16.33: icmp: net 204.79.188.11 unreachable 00:48:06.549540 65.123.21.137 > 65.124.17.41: icmp: net 204.79.188.11 unreachable 00:48:06.803847 65.123.21.137 > 65.124.17.92: icmp: net 204.79.188.11 unreachable 00:48:06.981930 65.123.21.137 > 65.124.17.15: icmp: net 204.79.188.11 unreachable 00:48:07.26 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:48:07.343120 65.123.21.137 > 65.124.18.74: icmp: net 204.79.188.11 unreachable 00:48:07.486285 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:48:07.569901 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:48:08.117407 65.123.21.137 > 65.124.18.106: icmp: net 204.79.188.11 unreachable 00:48:08.356732 65.123.21.137 > 65.124.20.41: icmp: net 204.79.188.11 unreachable 00:48:08.637485 65.123.21.137 > 65.124.20.14: icmp: net 204.79.188.11 unreachable 00:48:08.944750 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:48:08.946623 65.123.21.137 > 65.124.22.49: icmp: net 204.79.188.11 unreachable
Weird attack or traffic (Was Re: The impending DDoS storm)
Is anyone else seeing backscatters on your network about windowsupdate.com's IP? Someone who transits through 65.123.21.137 router is sending out lots of packets to 204.79.188.11 (windowsupdate.com) in which its not currently advertised to internet as we speak. Not to mention, packets seem to be source-spoofed to 65.124.16.0/21 (our block), causing backscatter from 65.123.21.137 to our network... Any ideas/or anyone seeing similar effect? Is someone who is administrative to Qwest Communications WASH01-WAN-65-123-21 (NET-65-123-21-0-1) aware of this may be? It looks like a Qwest customer CPE router to me but I dunno.. See below for traffic snapshot.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 k00:50:22.807370 65.123.21.137 > 65.124.23.125: icmp: net 204.79.188.11 unreachable 00:50:22.891672 65.123.21.137 > 65.124.22.48: icmp: net 204.79.188.11 unreachable 00:50:22.979997 65.123.21.137 > 65.124.22.98: icmp: net 204.79.188.11 unreachable 00:50:23.047340 65.123.21.137 > 65.124.22.21: icmp: net 204.79.188.11 unreachable 00:50:23.133616 65.123.21.137 > 65.124.22.72: icmp: net 204.79.188.11 unreachable 00:50:23.520405 65.123.21.137 > 65.124.23.107: icmp: net 204.79.188.11 unreachable 00:50:23.745844 65.123.21.137 > 65.124.22.3: icmp: net 204.79.188.11 unreachable 00:50:23.829309 65.123.21.137 > 65.124.22.54: icmp: net 204.79.188.11 unreachable 00:50:24.493650 65.123.21.137 > 65.124.23.113: icmp: net 204.79.188.11 unreachable 00:50:24.530074 65.123.21.137 > 65.124.23.35: icmp: net 204.79.188.11 unreachable 00:50:24.618082 65.123.21.137 > 65.124.23.86: icmp: net 204.79.188.11 unreachable 00:47:50.611529 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:47:50.649962 65.123.21.137 > 65.124.17.151: icmp: net 204.79.188.11 unreachable 00:47:50.711865 65.123.21.137 > 65.124.17.124: icmp: net 204.79.188.11 unreachable 00:47:50.756960 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:47:50.826367 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:47:52.355967 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:47:52.587141 65.123.21.137 > 65.124.20.46: icmp: net 204.79.188.11 unreachable 00:47:53.865460 65.123.21.137 > 65.124.22.87: icmp: net 204.79.188.11 unreachable 00:48:05.250757 65.123.21.137 > 65.124.16.1: icmp: net 204.79.188.11 unreachable 00:48:05.713640 65.123.21.137 > 65.124.17.86: icmp: net 204.79.188.11 unreachable 00:48:05.841169 65.123.21.137 > 65.124.17.60: icmp: net 204.79.188.11 unreachable 00:48:06.013042 65.123.21.137 > 65.124.16.33: icmp: net 204.79.188.11 unreachable 00:48:06.549540 65.123.21.137 > 65.124.17.41: icmp: net 204.79.188.11 unreachable 00:48:06.803847 65.123.21.137 > 65.124.17.92: icmp: net 204.79.188.11 unreachable 00:48:06.981930 65.123.21.137 > 65.124.17.15: icmp: net 204.79.188.11 unreachable 00:48:07.26 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:48:07.343120 65.123.21.137 > 65.124.18.74: icmp: net 204.79.188.11 unreachable 00:48:07.486285 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:48:07.569901 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:48:08.117407 65.123.21.137 > 65.124.18.106: icmp: net 204.79.188.11 unreachable 00:48:08.356732 65.123.21.137 > 65.124.20.41: icmp: net 204.79.188.11 unreachable 00:48:08.637485 65.123.21.137 > 65.124.20.14: icmp: net 204.79.188.11 unreachable 00:48:08.944750 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:48:08.946623 65.123.21.137 > 65.124.22.49: icmp: net 204.79.188.11 unreachable
Re: The impending DDoS storm
Dan Hollis wrote: On Wed, 13 Aug 2003, Jason Frisvold wrote: 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 . 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. Jeff
Re: The impending DDoS storm
> What is everyone doing, if anything, to prevent the apparent upcoming > DDoS attack against Microsoft? let's go shopping!
Re: The impending DDoS storm
On Wed, 2003-08-13 at 10:55, Ingevaldson, Dan (ISS Atlanta) wrote: -Does one DNS lookup on "windowsupdate.com" and then uses the IP No, I wouldn't dream of setting windowsupdate.com to 127.0.0.1. Who in their right mind would do that? -Jack
RE: The impending DDoS storm
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.
Re: The impending DDoS storm
> 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. -- Aaron
Re: The impending DDoS storm
On Wed, 13 Aug 2003, Jason Frisvold wrote: > All, > > What is everyone doing, if anything, to prevent the apparent upcoming > DDoS attack against Microsoft? From what I've been reading, and what > I've been told, August 16th is the apparent start date... > > We're looking for some solution to prevent wasting our network > resources transporting this traffic, but at the same time trying to > allow legitimate through... > > So, is anyone planning on doing anything? See previous discussion on filtering... Other than that experience says if these things turn out to be big enough to cause an issue then they quickly burn themselves out anyway Steve
RE: The impending DDoS storm
But doesn't that mean the hacker won? If you change the DNS and a user can not get to windowsupdate, you just helped him create a better DoS than he had... J -Original Message- From: Lloyd Taylor [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 12:26 PM To: Jack Bates Cc: [EMAIL PROTECTED] Subject: Re: The impending DDoS storm 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? --Lloyd On Wed, 13 Aug 2003, Jack Bates wrote: > Date: Wed, 13 Aug 2003 11:10:13 -0500 > From: Jack Bates <[EMAIL PROTECTED]> > To: Jason Frisvold <[EMAIL PROTECTED]> > Cc: "Ingevaldson, Dan (ISS Atlanta)" <[EMAIL PROTECTED]>, > Stephen J. Wilcox <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: The impending DDoS storm > > > On Wed, 2003-08-13 at 10:55, Ingevaldson, Dan (ISS Atlanta) wrote: > >-Does one DNS lookup on "windowsupdate.com" and then uses the IP > > No, I wouldn't dream of setting windowsupdate.com to 127.0.0.1. Who in > their right mind would do that? > > -Jack > --
RE: The impending DDoS storm
On Wed, 2003-08-13 at 10:55, Ingevaldson, Dan (ISS Atlanta) wrote: > More info: > > -Opens a raw socket and spoofs its source address 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... > > Regards, > === > Daniel Ingevaldson > Engineering Manager, X-Force R&D > [EMAIL PROTECTED] > 404-236-3160 > > Internet Security Systems, Inc. > The Power to Protect > http://www.iss.net > === > > > -Original Message- > From: Jason Frisvold [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2003 10:50 AM > To: Ingevaldson, Dan (ISS Atlanta) > Cc: Stephen J. Wilcox; [EMAIL PROTECTED] > Subject: RE: The impending DDoS storm > > > On Wed, 2003-08-13 at 10:14, Ingevaldson, Dan (ISS Atlanta) wrote: > > It might be somewhat tricky to block TCP/80 going to > > windowsupdate.com. > > I agree... but then, who needs updates anyways.. *grin* > > > Regards, > > === > > Daniel Ingevaldson > > Engineering Manager, X-Force R&D > > [EMAIL PROTECTED] > > 404-236-3160 > > > > Internet Security Systems, Inc. > > The Power to Protect > > http://www.iss.net > > === > > > > > > -Original Message- > > From: Stephen J. Wilcox [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 13, 2003 10:38 AM > > To: Jason Frisvold > > Cc: [EMAIL PROTECTED] > > Subject: Re: The impending DDoS storm > > > > > > > > > > On Wed, 13 Aug 2003, Jason Frisvold wrote: > > > > > All, > > > > > > What is everyone doing, if anything, to prevent the apparent > > upcoming > > > DDoS attack against Microsoft? From what I've been reading, and > > > what > > > I've been told, August 16th is the apparent start date... > > > > > > We're looking for some solution to prevent wasting our network > > > resources transporting this traffic, but at the same time trying to > > > allow legitimate through... > > > > > > So, is anyone planning on doing anything? > > > > See previous discussion on filtering... > > > > > > Other than that experience says if these things turn out to be big > > enough to cause an issue then they quickly burn themselves out anyway > > > > Steve -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: The impending DDoS storm
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? --Lloyd On Wed, 13 Aug 2003, Jack Bates wrote: > Date: Wed, 13 Aug 2003 11:10:13 -0500 > From: Jack Bates <[EMAIL PROTECTED]> > To: Jason Frisvold <[EMAIL PROTECTED]> > Cc: "Ingevaldson, Dan (ISS Atlanta)" <[EMAIL PROTECTED]>, > Stephen J. Wilcox <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: The impending DDoS storm > > > On Wed, 2003-08-13 at 10:55, Ingevaldson, Dan (ISS Atlanta) wrote: > >-Does one DNS lookup on "windowsupdate.com" and then uses the IP > > No, I wouldn't dream of setting windowsupdate.com to 127.0.0.1. Who in > their right mind would do that? > > -Jack > --
RE: The impending DDoS storm
On Wed, 2003-08-13 at 10:14, Ingevaldson, Dan (ISS Atlanta) wrote: > It might be somewhat tricky to block TCP/80 going to windowsupdate.com. I agree... but then, who needs updates anyways.. *grin* > Regards, > === > Daniel Ingevaldson > Engineering Manager, X-Force R&D > [EMAIL PROTECTED] > 404-236-3160 > > Internet Security Systems, Inc. > The Power to Protect > http://www.iss.net > === > > > -Original Message- > From: Stephen J. Wilcox [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2003 10:38 AM > To: Jason Frisvold > Cc: [EMAIL PROTECTED] > Subject: Re: The impending DDoS storm > > > > > On Wed, 13 Aug 2003, Jason Frisvold wrote: > > > All, > > > > What is everyone doing, if anything, to prevent the apparent > upcoming > > DDoS attack against Microsoft? From what I've been reading, and what > > I've been told, August 16th is the apparent start date... > > > > We're looking for some solution to prevent wasting our network > > resources transporting this traffic, but at the same time trying to > > allow legitimate through... > > > > So, is anyone planning on doing anything? > > See previous discussion on filtering... > > > Other than that experience says if these things turn out to be big > enough to > cause an issue then they quickly burn themselves out anyway > > Steve -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
RE: The impending DDoS storm
Has anyone determined a method for triggering the DOS attack manually? We've attempted this by changing an infected machine's clock, however it did not work on our test box. If anyone has triggered the attack, do you have a copy of the sniffed data stream? It sounds like uRPF is going to be of very little benefit to blocking the attack if the spoofed addresses come from the infected host's subnet/parent subnet. -Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vallar Sent: Wednesday, August 13, 2003 7:18 PM To: [EMAIL PROTECTED] Subject: Re: The impending DDoS storm Jack Bates Wrote: > I have no affiliation with Microsoft, nor do I care about their > services or products. What I do care about is a worm that sends out > packets uncontrolled. If there is the possibility that this "planned" > DOS will cause issues with my topology, then I will do whatever it > takes to stop it. The fact that user's can't reach windowsupdate.com > is irrelevant. > There will most likely be issues with a lot of networks. I had a glimpse of what is to come on the 16th on Tuesday. We have a firewall customer that had an infected machine behind the firewall and the RTC clock was set incorrectly to 8/16. The firewall was *logging* ~50 attempts per second trying to connect on port 80 to windowsupdate.com. Since the worm was sending from a spoofed source address the firewall was denying the packets. This customers network is a /24 out of traditional Class B space and I was seeing random source addresses from almost every IP out of the /16. This is not a forensic analysis, just what I observed in the firewall logs. Is it a coincidence that 8/16 is a SaturdayI think not. A lot less personal on-site to deal with possible issues. -Mark Vallar
RE: The impending DDoS storm
--On Thursday, August 14, 2003 11:24:53 AM -0400 Josh Fleishman <[EMAIL PROTECTED]> wrote: Has anyone determined a method for triggering the DOS attack manually? We've attempted this by changing an infected machine's clock, however it did not work on our test box. If anyone has triggered the attack, do you have a copy of the sniffed data stream? The code looks at the clock once at startup. Once the code is running, it does not appear to recheck the clock. Set your clock prior to running the test. Kevin
RE: The impending DDoS storm
Today at 11:24 (-0400), Josh Fleishman wrote: > Date: Thu, 14 Aug 2003 11:24:53 -0400 > From: Josh Fleishman <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: RE: The impending DDoS storm > > Has anyone determined a method for triggering the DOS attack manually? > We've attempted this by changing an infected machine's clock, however it > did not work on our test box. If anyone has triggered the attack, do > you have a copy of the sniffed data stream? Josh, Have you tried rebooting the infected box? Apparently, the date check and decision to DoS or infect others comes early on in the code and is not rechecked. - Christopher ==
Re: The impending DDoS storm
On Wed, 13 Aug 2003, Jason Frisvold wrote: > 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? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: The impending DDoS storm
Assuming cable operators have enabled: cable source-verify or cable source-verify dhcp for Cisco IOS based CMTSes, spoofing in the same subnet will be dropped at the CMTS. Other vendors have similar features to mitigate this possibility. The worst a cable operator would likely from this see is some upstream saturation since the packets aren't dropped until the CMTS. D. --- Darren Richer Director of Telecommunications Persona Communications Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Painter Sent: August 14, 2003 2:16 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: The impending DDoS storm http://www.dslreports.com/forum/remark,7652257~root=security,1~mode=flat;sta rt=0 - Original Message - From: "Josh Fleishman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 14, 2003 5:24 AM Subject: RE: The impending DDoS storm > > > > Has anyone determined a method for triggering the DOS attack manually? > We've attempted this by changing an infected machine's clock, however it > did not work on our test box. If anyone has triggered the attack, do > you have a copy of the sniffed data stream? > > It sounds like uRPF is going to be of very little benefit to blocking > the attack if the spoofed addresses come from the infected host's > subnet/parent subnet. > > -Josh > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Vallar > Sent: Wednesday, August 13, 2003 7:18 PM > To: [EMAIL PROTECTED] > Subject: Re: The impending DDoS storm > > > > > Jack Bates Wrote: > > > I have no affiliation with Microsoft, nor do I care about their > > services or products. What I do care about is a worm that sends out > > packets uncontrolled. If there is the possibility that this "planned" > > DOS will cause issues with my topology, then I will do whatever it > > takes to stop it. The fact that user's can't reach windowsupdate.com > > is irrelevant. > > > > There will most likely be issues with a lot of networks. > > I had a glimpse of what is to come on the 16th on Tuesday. We have a > firewall customer that had an infected machine behind the firewall and > the RTC clock was set incorrectly to 8/16. The firewall was *logging* > ~50 attempts per second trying to connect on port 80 to > windowsupdate.com. Since the worm was sending from a spoofed source > address the firewall was denying the packets. This customers network is > a /24 out of traditional Class B space and I was seeing random source > addresses from almost every IP out of the /16. > > This is not a forensic analysis, just what I observed in the firewall > logs. > > Is it a coincidence that 8/16 is a SaturdayI think not. A lot less > personal on-site to deal with possible issues. > > -Mark Vallar > > > >
Re: The impending DDoS storm
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. On Wed, 2003-08-13 at 12:25, Lloyd Taylor wrote: > 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? > > --Lloyd > > On Wed, 13 Aug 2003, Jack Bates wrote: > > > Date: Wed, 13 Aug 2003 11:10:13 -0500 > > From: Jack Bates <[EMAIL PROTECTED]> > > To: Jason Frisvold <[EMAIL PROTECTED]> > > Cc: "Ingevaldson, Dan (ISS Atlanta)" <[EMAIL PROTECTED]>, > > Stephen J. Wilcox <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > Subject: Re: The impending DDoS storm > > > > > > On Wed, 2003-08-13 at 10:55, Ingevaldson, Dan (ISS Atlanta) wrote: > > >-Does one DNS lookup on "windowsupdate.com" and then uses the IP > > > > No, I wouldn't dream of setting windowsupdate.com to 127.0.0.1. Who in > > their right mind would do that? > > > > -Jack > > -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: The impending DDoS storm
http://www.dslreports.com/forum/remark,7652257~root=security,1~mode=flat;start=0 - Original Message - From: "Josh Fleishman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 14, 2003 5:24 AM Subject: RE: The impending DDoS storm > > > > Has anyone determined a method for triggering the DOS attack manually? > We've attempted this by changing an infected machine's clock, however it > did not work on our test box. If anyone has triggered the attack, do > you have a copy of the sniffed data stream? > > It sounds like uRPF is going to be of very little benefit to blocking > the attack if the spoofed addresses come from the infected host's > subnet/parent subnet. > > -Josh > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Vallar > Sent: Wednesday, August 13, 2003 7:18 PM > To: [EMAIL PROTECTED] > Subject: Re: The impending DDoS storm > > > > > Jack Bates Wrote: > > > I have no affiliation with Microsoft, nor do I care about their > > services or products. What I do care about is a worm that sends out > > packets uncontrolled. If there is the possibility that this "planned" > > DOS will cause issues with my topology, then I will do whatever it > > takes to stop it. The fact that user's can't reach windowsupdate.com > > is irrelevant. > > > > There will most likely be issues with a lot of networks. > > I had a glimpse of what is to come on the 16th on Tuesday. We have a > firewall customer that had an infected machine behind the firewall and > the RTC clock was set incorrectly to 8/16. The firewall was *logging* > ~50 attempts per second trying to connect on port 80 to > windowsupdate.com. Since the worm was sending from a spoofed source > address the firewall was denying the packets. This customers network is > a /24 out of traditional Class B space and I was seeing random source > addresses from almost every IP out of the /16. > > This is not a forensic analysis, just what I observed in the firewall > logs. > > Is it a coincidence that 8/16 is a SaturdayI think not. A lot less > personal on-site to deal with possible issues. > > -Mark Vallar > > > >
Re: The impending DDoS storm
Jack Bates Wrote: > I have no affiliation with Microsoft, nor do I care about their services > or products. What I do care about is a worm that sends out packets > uncontrolled. If there is the possibility that this "planned" DOS will > cause issues with my topology, then I will do whatever it takes to stop > it. The fact that user's can't reach windowsupdate.com is irrelevant. > There will most likely be issues with a lot of networks. I had a glimpse of what is to come on the 16th on Tuesday. We have a firewall customer that had an infected machine behind the firewall and the RTC clock was set incorrectly to 8/16. The firewall was *logging* ~50 attempts per second trying to connect on port 80 to windowsupdate.com. Since the worm was sending from a spoofed source address the firewall was denying the packets. This customers network is a /24 out of traditional Class B space and I was seeing random source addresses from almost every IP out of the /16. This is not a forensic analysis, just what I observed in the firewall logs. Is it a coincidence that 8/16 is a SaturdayI think not. A lot less personal on-site to deal with possible issues. -Mark Vallar
Re: The impending DDoS storm
McBurnett, Jim wrote: But doesn't that mean the hacker won? If you change the DNS and a user can not get to windowsupdate, you just helped him create a better DoS than he had... I have no affiliation with Microsoft, nor do I care about their services or products. What I do care about is a worm that sends out packets uncontrolled. If there is the possibility that this "planned" DOS will cause issues with my topology, then I will do whatever it takes to stop it. The fact that user's can't reach windowsupdate.com is irrelevant. -Jack
