Government scrutiny is headed our way

Alex P. Rudnev alex at Relcom.EU.net
Wed Jun 17 15:33:58 UTC 1998


> 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>
Sometimes, they (quickly) filter out this attack. Through I did not hear 
about any successfull tracing.

> 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>
Should you plan to have the distinct sintax for the any kind of attack? 
Wrong idea.

The main issue is to be able to trace PACKETS by the known SRC or DST 
address and of the known type. It can be something like
- where the packets TCP,SYN,DST=xx.xx.xx.xx are coming from?
- where the packets ICMP,ECHO-REQUEST,SRC=xxx.xxx.xxx.xxx  are 
from?

Both cases SRC or DST address is YOUR OWN ADDRESS, and it allow you to 
ask such questions (and prevent you to ask anything about MY 
internal traffic, for example).

If you'll develop anti-smurf system, you'll got SMERF attack and so on. 
THe most important security hole for todays is the possibility to fraud 
addresses, and this is complicated by those attacks when the packets 
frauded are not packets destined to your personally, but the packets with 
frauded SRC address (replaced to YOUR address). 

If you can ask the global INTERNET: _this xxx.xxx.xxx.xxx is MY address; 
where are the packets with this SRC or DST /of the known type/ are coming 
from - the task is solved, and any attack can be traced (and may be - 
blocked by the same way) in a 5 minutes.

> 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
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)




More information about the NANOG mailing list