|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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]]On 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 Saturday....I think not. A lot less > personal on-site to deal with possible issues. > > -Mark Vallar > > > >
|