Access to the Internic Blocked

Fri Aug 23 19:52:57 UTC 1996

Curtis Villamizar <curtis at ans.net> wrote:

>We have traced back such "clever" denial of service attacks before.
>Within the last 6 months even.

>Have you forgotten that we log and keep track of source/destination
>pairs.

I sincerely wish you good luck doing that at OC-12.   If you know
a magic technology which can do that please let me know.
Doing that at 10 kpps is not going to be a solution any time soon.

I would also wish you luck with logging SA/DA pairs at places like
.ICP.NET. where source/destination matrix is about 1-2 millon
entries long.

>It is really easy for us to spot in incoming path with a set
>of sources that were never coming from that direction and start
>working backwards.

Yeah?  Over six backbones?

>Other respectable providers cooperate.  Nearnet
>for example flew out a person and workstation to track an attack
>coming through them.

Cool.  Now, if such a bogon generator becomes someting easily
accessible to every newbie (as it is bound to become, sooner or
later), that certainly will help.

>We have Unix boxes deployed in every POP, even
>with our new backbone.  These watch over the FDDI rings.

That certainly helps to people who already have to use FDDI switches.

>Half the time the people doing this hacking are coming in from dialup
>lines.  Sometimes they break into somewhere better connected.

Quote from one friendly sysadmin at very large and prestigeous u here
in Bay Area: "Security?  We don't have any.  We have that special
wide-open box so hackers can play with it and leave other machines alone".

>An attack capable of any noticable load on a backbone is quite remote.

I had two instances where unintentional flooding was saturating the
backbone links (both cases with T-3 connected customers, one caused
by fautly software, another by broken FDDI adapter).

> Ok, with only one intermediate point allowed.  _That_ should
> take care of all diagnostic needs.

>That would be useful.  It could still be UDP.

Sending something to ports which can be used by applications is
not kosher.  If anything, traceroute should at least attempt to
use UDP "discard" service, not some random high ports.

> Should i write a backbone-crasher and post it to USENET just to
> make a point about LSRRs?  Note that a provider which won't
> shut LSRR will be the threat to others...

>If we find out you did we would prosectute.

I know for sure that the code doing nasty things with TCP resets
exists and works.  (As for "finding out" -- sorry, there is no
concievable way of tracing origins of code if minimal precautions
are taken, as any virus writer can attest).

In any case, i don't care to do it.  I have much more straightforward
ways to achieve the same effect, in the very unlikely case that i
ever wish or need to do that, ok?

>We can very easily detect probes because we don't run any telnet,
>rsh/rcp, or RCP services and these are commonly attacked.  Any
>activity destined to these ports is logged.  Of course we log LSRR
>to lower port numbers too.

Sure.  The real security is proactive, not retroactive.  Logging
only helps you to find out idiots who don't know better than to
send sufficient quantities of probes to attract attention.  A
serious attacker would find a throw-away staging point (about five
minutes worth of searching, realistically) and do probes from there.

It is _much_ better to eliminate the unnecessary door, than to post
guard at it.

--vadim