Government scrutiny is headed our way

Wed Jun 17 14:14:10 UTC 1998

On Wed, Jun 17, 1998 at 09:07:50AM +0800, David R. Conrad wrote:
> Karl,
> 
> >2.	There is even less than zero excuse for a "fuck you" response from
> >	a NOC when you call them with a denial of service issue.  Yet this
> >	is what we, all too often, get, along with a refusal to transfer to
> >	a manager and in some cases, a refusal to give the employee's NAME!
> >	The first thing these guys want is a customer ID; don't have one, 
> >	go straight to hell.
> 
> I suspect including information about response from NOCs in the canonical
> smurf amplifier registry would be instructive.
> 
> Regards,
> -drc

That's simple.  Follow the question path below to obtain your answer:

1.	Is the network provider "next in the chain" a large national
	concern in the United States?

2.	If yes, don't bother wasting your time.  You will be told one of:
	a)	We don't know what you're talking about <click>
	b)	We'll contact security (two hours later, after the attack
		is over and is no longer traceable, they call back)
	c)	What's your customer number?  Oh, you're not a customer?
		Sorry.  <click>

3.	If no, you will be told one of:
	a)	We don't know how to trace that <click>
	b)	The source address isn't ours, sorry, we can't help you
		<click>

I have yet to have *ONE* Smurf attack, even ones which go on for an hour 
or more, successfully traced back to the source.  At some point in the 
chain before you get to the source you WILL get one of the above answers.

This is why the government needs to get involved and *demand* that the
ability exist via a *protocol* for people in a NOC to initiate and follow
these traces automatically, without human intervention by the NOCs in the
chain.

What I would love to see is:

	"trace-smurf <forged-victim-address> <amplifier-address>" <return>

This would launch a trace which:

1.	Looks "upstream" automatically for the destination address flow
	that matches the "victim" and amplifier, until it gets there
	(basically, set a "trap" condition for the address pair tuple, and
	then wait a few seconds for it to come through).

2.	Determines the broadcast address for the interface which caused
	the smurf to be amplified.

3.	Substitutes the broadcast address for the amplifier address, and
	then repeat upstream further until you get to the router where the 
	victim/amplifier address pair is originating.

4.	Displays its progress, much like a traceroute, as it is doing so,
	including the "turning point" where it is searching for the source
	as opposed to the amplifier.  Hopefully we can get the ASNs along 
	the way too (ala CISCO).

This would NAIL the source of these things, be quick to execute, and put 
the nail in the coffin of the smurfer kiddies.  Once you've identified the
source of the attacks you now can direct the legal people to the right
place, *AND* drop them from your list of people you will accept traffic 
from if you'd like.

The trick is that you don't have to call anybody, and you can execute a
trace in a few seconds to a minute tops.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost