New Denial of Service Attack on Panix

Dear NANOG/IEPG Folks;

As you should know by now from reading the papers, Panix, the first ISP in
NYC, has come under a new denial of service attack. The Wall Street Journal
quoted Bill Cheswick to the effect that the attack is "unstoppable". Almost,
but not quite, true.

It's true that there isn't anything that Panix can do on its own to stop
this attack. It's true that it would be hard to verify source addresses at
MAEs and NAPs. But we could all verify source addresses at the first hop
entry points. And get default route and unauthorized transit protection to boot.

I'd like to know what the community thinks can be done to deal with an
escalation of these attacks should this occur. Are you doing any source
address verification now? Are you doing anything to help Panix? Could you?

How seriously do you take this threat? If Panix were to go out of business
and Bob Metcalfe wrote a column on it, ( :slight_smile: do you think we would have to
deal with it together then, or can we sit tight and expect it to blow over?
After all, it's easy to dump chemicals in the reservoir, but we still drink
the water, right?

Thanks.

--Kent

~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~
Kent W. England Six Sigma Networks
1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400
Encinitas, CA 92024 kwe@6SigmaNets.com
Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

I think we all have learned to live with Bob, and I have plenty of bottled
water in the basement.

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!

Have a look at the firewalls mailing list archive for more info
http://www.greatcircle.com/firewalls/archive/firewalls.9609.Z

There are at least three things you can do to protect yourself from such
attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers
of incomplete socket connections. One is to have another machine or your
network issue RST's for sockets that it thinks are part of the SYN flood
attack. And one is to install a SYN proxy machine between your net and the
Internet which catches all SYN packets and holds them until an ACK is
received at which point the SYN and the ACK are passed on to your network.
Such a proxy can be built to handle HUGE numbers of incomplete conections.

Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com

Sender: owner-nanog@merit.edu

   Dear NANOG/IEPG Folks;

   As you should know by now from reading the papers, Panix, the first
   ISP in NYC, has come under a new denial of service attack. The Wall
   Street Journal quoted Bill Cheswick to the effect that the attack
   is "unstoppable". Almost, but not quite, true.

Not only is it difficult to stop, but difficult to trace since it
requires the *immediate* cooperation of all intervening providers.

   It's true that there isn't anything that Panix can do on its own to
   stop this attack. It's true that it would be hard to verify source
   addresses at MAEs and NAPs. But we could all verify source
   addresses at the first hop entry points. And get default route and
   unauthorized transit protection to boot.

   I'd like to know what the community thinks can be done to deal with
   an escalation of these attacks should this occur. Are you doing any
   source address verification now? Are you doing anything to help
   Panix? Could you?

We just put in source address filters. Being a single homed site with
only 3 CIDR blocks made that quick and easy. I think we need to make
it as easy as possible for ISP's with little technical knowledge to do
the same.

Has someone come up with instructions on how to do source address
filtering/verification for different brands of routers? It would be
good if someone could put up a web page with complete instructions on
how to do this. If this could be done quick enough we could possibly
get the URL some publicity due to the current Panix attack.

Another item that may be usefull would be a list of providers that do
perform source address verification. Is there an easy way to verify
from an outside host that the filtering is being done? Without
verification we couldn't trust the list of sites that claim to filter.

Operating system changes may also minimize the impact of this type of
attack and those changes should be encouraged. Changes like an
adaptive SYN timout along with more dynamic table allocation.

   How seriously do you take this threat? If Panix were to go out of
   business and Bob Metcalfe wrote a column on it, ( :slight_smile: do you think
   we would have to deal with it together then, or can we sit tight
   and expect it to blow over? After all, it's easy to dump chemicals
   in the reservoir, but we still drink the water, right?

How likely is Panix to go under from this? Admittedly incomming
connections are seriously effected, but if Panix were to filter out
incoming SYN's at their entry points could their customers still do
outbound browsing? They could open and close the door periodically to
try and receive incoming e-mail or move MX records around to get mail
in.

Their Web customers would seem to be the most heavily effected as
their pages can't be seen.

Bottom line, exactly how is this attack effecting Panix servers and
what are they able to do to at least operate in a degraded fashion
during these attacks? What could *I* do if my site were attacked?

   Thanks.

   --Kent

   ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~
   Kent W. England Six Sigma Networks
   1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400
   Encinitas, CA 92024 kwe@6SigmaNets.com
   Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

I would certainly publicize such a website. Although I think it would be
best if it was placed at some other site with info that ISP's should see
like perhaps www.ra.net.

So far I've only seen Cisco filters posted. We still need to see
instructions for Livingston IRX, Bay, and Linux/FreeBSD ipfwadm

Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com