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
Today at 11:24 (-0400), Josh Fleishman wrote:
Date: Thu, 14 Aug 2003 11:24:53 -0400
From: Josh Fleishman <flyman2@corp.earthlink.net>
To: nanog@merit.edu
Subject: RE: The impending DDoS stormHas 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
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
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.