Re[2]: SYN floods (was: does history repeat itself?)
Perry, This is actually quite simple to implement on Dial Access Routers, and obviously this is the best place to add the filtering. Pat R. Calhoun e-mail: pcalhoun@usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: SYN floods (was: does history repeat itself?) Author: "Perry E. Metzger" <perry@piermont.com> at Internet Date: 9/9/96 1:19 PM Re: SYN floods PANIX, a large public access provider in New York, was badly hit with SYN flood attacks from random source addresses over the last few days. It nearly wrecked them. I think its time for the larger providers to start filtering packets coming from customers so that they only accept packets with the customer's network number on it. Yes, its a load on routers. Yes, its nasty for the mobile IP weenies. Unfortunately, the only known way to stop this. Many TCPs go belly up as soon as they get SYN flooded -- its a defect in the protocol design, and other than Karn style anti-clogging tokens ("cookies") being put into a TCP++ and mass implemented worldwide soon, the only reasonable way to stop this sort of terrorism is provider filtering. Perry
Pat Calhoun writes:
Perry,
This is actually quite simple to implement on Dial Access Routers, and obviously this is the best place to add the filtering.
Sure, that's a place to start. Except for a few problems: 1) The people doing this are not necessarily using a dialup IP connection. 2) Many of us don't have dial access routers that can handle this. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access Internet and UNIX| |Network Administrator/Architect | New York City, NY | +------------------------------------+--------------------------------------+
Alec H. Peterson writes:
Pat Calhoun writes:
This is actually quite simple to implement on Dial Access Routers, and obviously this is the best place to add the filtering.
Sure, that's a place to start. Except for a few problems:
1) The people doing this are not necessarily using a dialup IP connection.
True. That's why you need to filter upstream of public-access unix boxes (like our own).
2) Many of us don't have dial access routers that can handle this.
Also true. As I said before, I don't know about the Ascends, but I do know that the Xylogics boxes we use have the capability but probably not the capacity. When all ports are connected at 28.8, CPU usage can hover in the high 80% range. Adding filters would probably be a bad idea. That's why I was talking about filtering at a router just upstream from the dial-access box. FWIW, even with a thousand very busy modems, I'm pretty sure that even a small cisco is up to the job. They just don't generate all that much traffic. /a
Alexis Rosen writes:
Also true. As I said before, I don't know about the Ascends, but I do know that the Xylogics boxes we use have the capability but probably not the capacity. When all ports are connected at 28.8, CPU usage can hover in the high 80% range. Adding filters would probably be a bad idea.
Yes, packet filters would certainly be a Bad Idea[tm].
That's why I was talking about filtering at a router just upstream from the dial-access box.
FWIW, even with a thousand very busy modems, I'm pretty sure that even a small cisco is up to the job. They just don't generate all that much traffic.
Could be, although I'd want to see this before I bet the farm on it. I'm not sure how efficient crisco's filtering algorithm is... Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access Internet and UNIX| |Network Administrator/Architect | New York City, NY | +------------------------------------+--------------------------------------+
Alec H. Peterson writes:
Alexis Rosen writes:
That's why I was talking about filtering at a router just upstream from the dial-access box.
FWIW, even with a thousand very busy modems, I'm pretty sure that even a small cisco is up to the job. They just don't generate all that much traffic.
Could be, although I'd want to see this before I bet the farm on it. I'm not sure how efficient crisco's filtering algorithm is...
I would. As a point of reference, we have filters on two fairly busy T1s, which between them account for more then 500 modems worth of traffic and a *lot* more besides (all of VTW's traffic, for example). Putting filters on these, both an an AGS+/4, didn't make an enormous difference in CPU- it's still <30%. Surely a 2500 series box could handle that much. (It's 68030 vs. 68040, but we're at 30% utilization, and we're doing other things on that box.) /a --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix & Internet, NYC. alexis@panix.com
In message <233128C0.3000@usr.com>, Pat Calhoun writes:
This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details.
--IMA.Boundary.388702248 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part
Perry,
This is actually quite simple to implement on Dial Access Routers, and obviously this is the best place to add the filtering.
Pat R. Calhoun e-mail: pcalhoun@usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp.
I agree with you completely -- sort of. Only problem is there are thought to be some 3,000 dial access providers. Many of them barely know what a TCP SYN is, let alone why they need to block ones with random source addresses and how. Unless of course you are volunteering to explain it and help them. Thanks in advance. :-) Curtis
______________________________ Reply Separator ______________________________ ___ Subject: Re: SYN floods (was: does history repeat itself?) Author: "Perry E. Metzger" <perry@piermont.com> at Internet Date: 9/9/96 1:19 PM
Re: SYN floods
PANIX, a large public access provider in New York, was badly hit with SYN flood attacks from random source addresses over the last few days. It nearly wrecked them.
I think its time for the larger providers to start filtering packets coming from customers so that they only accept packets with the customer's network number on it.
Yes, its a load on routers. Yes, its nasty for the mobile IP weenies. Unfortunately, the only known way to stop this. Many TCPs go belly up as soon as they get SYN flooded -- its a defect in the protocol design, and other than Karn style anti-clogging tokens ("cookies") being put into a TCP++ and mass implemented worldwide soon, the only reasonable way to stop this sort of terrorism is provider filtering.
Perry --IMA.Boundary.388702248 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers"
Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 233028F0; Sun, 8 Sep 96 12:29:51 -0500 Received: from merit.edu by usr.com (8.7.5/3.1.090690-US Robotics) id MAA17658; Mon, 9 Sep 1996 12:33:14 -0500 (CDT) Received: from localhost (daemon@localhost) by merit.edu (8.7.5/merit-2.0) wi th SMTP id NAA17064; Mon, 9 Sep 1996 13:20:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Sep 1996 13:19:08 -0400 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id NAA16987 for nanog-outgoing; Mon, 9 Sep 1996 13:19:08 -0400 (EDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by merit.edu (8.7.5/merit-2.0) with ESMTP id NAA16982 for <nanog@merit.edu>; Mon , 9 Sep 1996 13:19:05 -0400 (EDT) Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6. 12) with SMTP id NAA24855 for <nanog@merit.edu>; Mon, 9 Sep 1996 13:19:02 -0400 (EDT) Message-Id: <199609091719.NAA24855@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't us e HELO protocol To: nanog@merit.edu Subject: Re: SYN floods (was: does history repeat itself?) In-reply-to: Your message of "Mon, 09 Sep 1996 12:47:13 EDT." <199609091647.MAA01458@tomservo.mindspring.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 09 Sep 1996 13:19:02 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: owner-nanog@merit.edu --IMA.Boundary.388702248--
At 1:44 PM -0400 9/12/96, Curtis Villamizar wrote:
I agree with you completely -- sort of. Only problem is there are thought to be some 3,000 dial access providers. Many of them barely know what a TCP SYN is, let alone why they need to block ones with random source addresses and how. Unless of course you are ^^^^^^^^^^^^^^^^^^^^^^^^ volunteering to explain it and help them. Thanks in advance. :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Curtis, this is a great point. USR and other NAS vendors are actually in a great position to do exactly this, by changing their boxes to block random addresses *by default* on dial-up ports. This is of course exactly the point Vadim and others keep making, and of course as they point out there ought to be a knob to disable it if desired. Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist the knobs, defaulting filtering to "block spoofed addresses" seems like the best and maybe only way to get them to do it. How about it, USR &al? --John -- John Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 669-8800 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 41804 www: http://www.ieng.com
What you propose is a Good Thing (tm), but I don't think it's sufficient. It still doesn't protect the 'net from antisocial behavior perpetrated by someone who has penetrated a system with dedicated access to the 'net. It seems like it would still be necessary for anyone selling dedicated access to install Good Neighboor (tm) anti-spoofing filters on their inbound interfaces (which probably requires MIPS that the routers in the field don't have). Regards, Joel On Thu, 12 Sep 1996, John G. Scudder wrote:
At 1:44 PM -0400 9/12/96, Curtis Villamizar wrote:
I agree with you completely -- sort of. Only problem is there are thought to be some 3,000 dial access providers. Many of them barely know what a TCP SYN is, let alone why they need to block ones with random source addresses and how. Unless of course you are ^^^^^^^^^^^^^^^^^^^^^^^^ volunteering to explain it and help them. Thanks in advance. :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Curtis, this is a great point. USR and other NAS vendors are actually in a great position to do exactly this, by changing their boxes to block random addresses *by default* on dial-up ports. This is of course exactly the point Vadim and others keep making, and of course as they point out there ought to be a knob to disable it if desired.
Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist the knobs, defaulting filtering to "block spoofed addresses" seems like the best and maybe only way to get them to do it.
How about it, USR &al?
--John
-- John Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 669-8800 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 41804 www: http://www.ieng.com
On Thu, 12 Sep 1996, John G. Scudder wrote:
Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist the knobs, defaulting filtering to "block spoofed addresses" seems like the best and maybe only way to get them to do it.
If we can get config instructions for all the popular NAS boxes like Ascend, Livingston, USR etc. posted to a web page somewher then we can get the word out to a lot of ISP's via the 7 or 8 ISP mailing lists, Boardwatch magazine and USENET. But for the benefit of those maginally clueful people out there we need to have some fairly explicit instructions. I know ra.net has an ISP section on their WWW server and it wouldn't hurt to point more ISP's at www.ra.net anyway. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
On Thu, 12 Sep 1996, John G. Scudder wrote:
Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist the knobs, defaulting filtering to "block spoofed addresses" seems like the best and maybe only way to get them to do it.
If we can get config instructions for all the popular NAS boxes like Ascend, Livingston, USR etc. posted to a web page somewher then we can get the word out to a lot of ISP's via the 7 or 8 ISP mailing lists, Boardwatch magazine and USENET. But for the benefit of those maginally clueful people out there we need to have some fairly explicit instructions.
Don't forget Linux and the various BSD stuff. Quite a few people run modems with these as terminal servers. Certainly this would be trivial in Linux, from experience. It would probably be advisable to be able to disable this on a per i/f basis as there are a few people who intentionally have locally assymetric routing (pile of Maxen with 2 routers for redundancy and load-sharing for instance) but could still work with spoofed source IP address filtering on the modem ends. Alex Bligh Xara Networks
On Thu, 12 Sep 1996 20:44:10 +0100 "Alex.Bligh" <amb@xara.net> alleged:
Don't forget Linux and the various BSD stuff. Quite a few people run modems with these as terminal servers. Certainly this would be trivial in Linux, from experience.
I think this could be prevented using ipf. I've been working on this problem on the 4.4BSDlites for a while, it doesn't look like there is an ideal solution for everyone but I have a few ideas. Neil -- Neil J. McRae. Alive and Kicking. Easynet Group PLC neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
participants (9)
-
Alec H. Peterson -
Alex.Bligh -
Alexis Rosen -
Curtis Villamizar -
Joel Gallun -
John G. Scudder -
Michael Dillon -
Neil J. McRae -
pcalhoun＠usr.com