Curtis Villamizar <curtis@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