Identifying DoS sources quickly (was: Bogon list or Dshield.org type list)
As far as tracking DoS, I've read some good papers on the subject and it always boils down to tracking MAC addresses and going interface by interface to the source, demanding inter-ISP cooperation, and finally legal assistance. This has been tried during a few severe instances with poor results.
That's the obvious solution to the problem if the problem is how to track down the source(s) of a DoS attack. However, in any DoS attack, there is always a victim and one or more devices sending attack traffic to the victim. The owners of the attacking devices are accessories to the crime although I'm sure they could plead ignorance and avoid any liability. But what if they could not plead ignorance? What if we could identify some of the attacking devices, and what if the victim sent a legal "cease and desist" letter to the owners of the attacking devices? Now, the victim is in a position to sue the owners of these attacking devices if they don't fix the problem by securing their machines. And once this happens and gets some press coverage, a whole bunch of other machine owners will wake up and realize that they could be stuck with big legal bills if they don't secure their machines. So, to restate the problem, how do we identify some of the sources of a DoS attack quickly, maybe even while the attack is still in progress?
Bots/Zombies are traded openly on IRC and there is no accountability for personal security. ISPs won't shut someone down because they've been "hacked", merely send them a warning Email or call--a process that takes days in my experience.
How many ISPs would identify the user of an IP address for the purposes of sending a "cease and desist" letter when contacted by a lawyer? Considering that failure to provide the identity would result in the ISP themselves getting sued by the DoS victim? As long as *SOME* ISPs would cooperate with a DoS victim, there is enough to get the legal ball rolling. The alternative is to painfully backtrack until you find an uncooperative ISP and then sure them. As I said before, if there was a central registry something like dshield.org that collected data on the destination IP addresses of DoS attacks along with estimated magnitude based on analysing the traffic from random source addresses blocked by ingress filters, then we have something an ISP can use to analyze their outgoing traffic. If you are an ISP and you have netflow data that contains destination addresses which also occur in the DoS victim registry then you should be willing to act on that data. Of course, it's up to you what you do with it. You may offer the DoS victim the identity of the source provided that they serve you with the right legal documents. Or you might go to the owner of the machine yourself with the evidence and warn them that they are aiding and abetting cyber terrorists and could suffer the legal consequences if they don't secure their machines. It's certainly not perfect but it's worth a try. --Michael Dillon
How many ISPs would identify the user of an IP address for the purposes of sending a "cease and desist" letter when contacted by a lawyer?
Despite 9/11, privacy still counts for something. It's rather dangerous to give out private user information without a court order. If one of our suscribers were involved in a DoS, we would deal with it inernally, saving any records in the event of a court search warrant. -Ralph
On Tue, 30 Jul 2002 michael.dillon@radianz.com wrote:
That's the obvious solution to the problem if the problem is how to track down the source(s) of a DoS attack. However, in any DoS attack, there is always a victim and one or more devices sendingattack traffic to the victim. The owners of the attacking devices are accessories to the crime although I'm sure they could plead ignorance and avoid any liability. But what if they could not plead ignorance? What if we could identify some of theattacking devices, and what if the victim sent a legal "cease and desist" letter to the owners of the attacking devices? Now, the victim is in a position to sue the owners of these attacking devices if they don't fix the problem by securing their machines. And once this happens and gets some press coverage, a whole bunch of other machine owners will wake up and realize that they could be stuck with big legal bills if they don't secure their machines.
So, to restate the problem, how do we identify some of the sources of a DoS attack quickly, maybe even while the attack is still in progress?
Not a complete solution but a start: IP Source Tracker: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120... Available as of 12.0(22)S for 7500 and 12000 series Cisco routers. -Hank
Hank Nussbacher wrote:
So, to restate the problem, how do we identify some of the sources of a DoS attack quickly, maybe even while the attack is still in progress?
Not a complete solution but a start: IP Source Tracker:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 limit/120s/120s21/ipst.htm
Available as of 12.0(22)S for 7500 and 12000 series Cisco routers.
Hank, one major flaw with this is that you can't track back further when you are on an (ethernet based) IXP. IIRC older versions of IOS gave L2 information (MAC address) as well which helped you to identify the last hop. -- Arnold -- Arnold Nipper / nIPper consulting e-mail: arnold@nipper.de phone/mob: +49 172 265 0958 fax: +49 6224 9259 333
Not a complete solution but a start: IP Source Tracker: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 limit/120s/120s21/ipst.htm Available as of 12.0(22)S for 7500 and 12000 series Cisco routers.
ah yes. the new enterprise image. :-(
## On 2002-07-30 08:23 -0700 Randy Bush typed: RB> RB> >> Not a complete solution but a start: RB> >> IP Source Tracker: RB> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 RB> > limit/120s/120s21/ipst.htm RB> >> Available as of 12.0(22)S for 7500 and 12000 series Cisco routers. RB> RB> ah yes. the new enterprise image. :-( RB> RB> Am I missing the joke ? AFAIK 12.0S only has the "service provider" feature set -- Rafi
On Wed, Jul 31, 2002 at 12:22:30AM -0700, Randy Bush wrote:
AFAIK 12.0S only has the "service provider" feature set
i fear that the joke is on us. at least one other train seems to have been merged into the ex-isp train. not sure how much. can't get a straight answer. welcome back to 1997, and bye bye what stability we had.
It looks something like 12.0(21)S1----12.0(21)S2---- ... only for a limited time / ---12.0(x)S-----12.0(21)S +---12.0(22)S----12.0(23)S---- ... / ---12.0(x)ST----12.0(21)ST--+ So basicly 12.0(22)S is what would have been 12.0(22)ST if they hadn't renumbered. The "old" S train will be recieving bug fixes as 12.0(21)S1 S2 S3 etc. for a limited period of time. So be carefull when you go from 12.0(x)S, x <= 21 to 12.0(y)S, y > 21 /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
## On 2002-07-31 10:09 +0200 Jesper Skriver typed: JS> On Wed, Jul 31, 2002 at 12:22:30AM -0700, Randy Bush wrote: JS> > JS> > > AFAIK 12.0S only has the "service provider" feature set JS> > JS> > i fear that the joke is on us. at least one other train seems to JS> > have been merged into the ex-isp train. not sure how much. can't JS> > get a straight answer. welcome back to 1997, and bye bye what JS> > stability we had. JS> JS> It looks something like JS> JS> 12.0(21)S1----12.0(21)S2---- ... only for a limited time JS> / JS> ---12.0(x)S-----12.0(21)S +---12.0(22)S----12.0(23)S---- ... JS> / JS> ---12.0(x)ST----12.0(21)ST--+ JS> JS> So basicly 12.0(22)S is what would have been 12.0(22)ST if they hadn't JS> renumbered. JS> JS> The "old" S train will be recieving bug fixes as 12.0(21)S1 S2 S3 etc. JS> for a limited period of time. JS> JS> So be carefull when you go from 12.0(x)S, x <= 21 to 12.0(y)S, y > 21 Thanks for the info I thought that the next evolution in the "S" series was supposed to be merger of 12.1E and 12.0S into 12.2S ? - anyone know about that ? -- Rafi JS> JS> /Jesper JS> JS>
On Thu, Aug 01, 2002 at 04:35:03PM +0300, Rafi Sadowsky wrote:
## On 2002-07-31 10:09 +0200 Jesper Skriver typed:
JS> On Wed, Jul 31, 2002 at 12:22:30AM -0700, Randy Bush wrote: JS> > JS> > > AFAIK 12.0S only has the "service provider" feature set JS> > JS> > i fear that the joke is on us. at least one other train seems to JS> > have been merged into the ex-isp train. not sure how much. can't JS> > get a straight answer. welcome back to 1997, and bye bye what JS> > stability we had. JS> JS> It looks something like JS> JS> 12.0(21)S1----12.0(21)S2---- ... only for a limited time JS> / JS> ---12.0(x)S-----12.0(21)S +---12.0(22)S----12.0(23)S---- ... JS> / JS> ---12.0(x)ST----12.0(21)ST--+ JS> JS> So basicly 12.0(22)S is what would have been 12.0(22)ST if they hadn't JS> renumbered. JS> JS> The "old" S train will be recieving bug fixes as 12.0(21)S1 S2 S3 etc. JS> for a limited period of time. JS> JS> So be carefull when you go from 12.0(x)S, x <= 21 to 12.0(y)S, y > 21
Thanks for the info
I thought that the next evolution in the "S" series was supposed to be merger of 12.1E and 12.0S into 12.2S ? - anyone know about that ?
There is a 12.2(x)S comming - as I understand it, it's a merge of 12.0(x)ST and the service provider related features in 12.2(x)T /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
On Tue, 30 Jul 2002 michael.dillon@radianz.com wrote:
The owners of the attacking devices are accessories to the crime although I'm sure they could plead ignorance and avoid any liability. But what if they could not plead ignorance? What if we could identify some of the attacking devices, and what if the victim sent a legal "cease and desist" letter to the owners of the attacking devices?
I wonder how the new pending RIAA legislation would change things, since it proposes to totally shield the attackers from criminal penalties. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
participants (8)
-
Dan Hollis -
Hank Nussbacher -
Jesper Skriver -
michael.dillon＠radianz.com -
Nipper, Arnold -
Rafi Sadowsky -
Ralph Doncaster -
Randy Bush