Re: New Denial of Service Attack on Panix
I want to make it crystal clear that source address filtering does not fix the SYN flooding or other spoofed-source address security problems. It only makes it easier to track down the perpetrator. If the goal of an attacker is to damage the business for one or two hours such an attack can be launched from a throw-away staging point; after the hacker cleaned up after himself. Tell VISA or any other serious commercial customer that their operations can be stopped for an hour by any newbie who can retype a page from 2600. I think you'll be laughed at. Per-se reducing the number of clueless newbies trying to play hakerz is good and worthwhile; and as such source address filtering is a valuable tool and should be deployed ASAP. However, source address filtering is particularly hard to implement for large ISPs (it'll require quite extensive modifications to configurations). Having only 100 filter lists per cisco box doesn't help too much, too (there are boxes with more than 100 "logical" interfaces on MIP cards). For a large ISP, implementing source filtering is going to be a monumental task. Given the "tragedy of commons" nature of the problem (you work hard to implement filters, which do not benefit _you_) i'm quite sceptical that it will get us anywhere. Note that the significant progress in CIDR was achieved only after years of screaming, threats and all-out hand twisting (can you say Sean's filter?) That's why i tried to communicate the idea of creating such filters automagically, by using the reverse-route approach. That would allow to make it the default behaviour, at least for T-1s or less. Again, source filtering is only a part of solution. It does not eliminate the attack mechanism per se. That's why the statistical traffic monitoring for the traffic patterns showing on-going flooding attacks with consequent automatic shut-off is a valuable deterrent. It reduces the attack detection and prevention time to half-minute or less. For all practical purposes that will make attaks like that rather harmless, and will shift the burden of responsibility from targets of attacks to those who unwittingly or (worse) knowingly provide assistance to hackers by being lazy or simply clueless. The goal is to have the network to be able to contain anti-social behaviour on its own. The technology can do muhc better than an army of cops, so a technological solution should be preferred to any solution involving human (or, worse, lawyer) intervention. The network is great as a right to speak tool. Now we should think hard on how to support right to not listen. Deniability of communicaton is not a new concept, after all. --vadim
On Sat, 21 Sep 1996, Vadim Antonov wrote:
Given the "tragedy of commons" nature of the problem (you work hard to implement filters, which do not benefit _you_)
Source address filters do benefit the small ISP by making him less of a target for hackers looking for a staging point. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Hi Vadim! You are absolutely correct in your 'red flag' that source route filtering does not solve 'all the worlds ip-spoofing security problems', and a great deal of work needs to be done. On the other hand, if all end-user providers at least filter to help guarantee that only valid customer source addresses come from their sphere of influence, these type of denial-of-service attacks would be easier to trace, track, and plug, when necessary. You know how these types of issues are mitigated; one-step-at-a-time. The source route filtering from end-user providers needs to happen, just as ISPs used to demand new providers BGP 'in the old days'. It is not too difficult for higher tier providers to 'sniff and audit' to discover the 'non-compliant' providers, or to set up a mechanism to verify this automatically. One step at a time. Certainly, it is in the best interest of the performance of the Big I to have the filter lists as far down the routing tier as possible and to keep the higher level transit nets as 'filter clean as possible' (filtering 101) This sounds like a gloomly and extremely difficult task; and the reality is, that there is no 100 percent solution, but maybe .95 is achieveable in the short term? .98? Large transit carriers must 'say no' to mid-level providers that refuse to aggressively insure that filtering their customers take place, and this, in itself, is a very difficult to enforce task. Best Regards, Tim PS: Vadim! ......... The East coast is not the same without seeing you in the bookstores and computer stores from time to time.
-->modifications to configurations). Having only 100 filter -->lists per cisco box doesn't help too much, too (there are -->boxes with more than 100 "logical" interfaces on MIP cards). -->For a large ISP, implementing source filtering is going to -->be a monumental task. I don't doubt it will be a large task. With IOS 11.2, you have the option of using named access lists. THese can be used in packet filters as well as routing announcements. In the future, Cisco plans to alow the ability to edit an access list rather than having to retype the whole thing. This removes the limit of 100 access lists. -- ------------------------------------------- | Jeremy Hall Network Engineer | | ISDN-Net, Inc Office +1-615-371-1625 | | Nashville, TN and the southeast USA | | jhall@isdn.net Pager +1-615-702-0750 | -------------------------------------------
Having agreed with Vadim's message in its entirety, I want to add some more - as I see it, SYN-flood attacks are made real by inadequate TCP implementations on the majority of Internet-connected boxes, i.e. these said boxes just cannot keep up with the rate their network interfaces supply packets to them. Is it fixable on the host level? My gut feeling says "most probably, yes." Does it eliminate the need for the measures outlined by Vadim? Of course, not. Dima
participants (6)
-
dvv@sprint.net
-
Jeffrey Burgan
-
Michael Dillon
-
Mr. Jeremy Hall
-
Tim Bass
-
Vadim Antonov