New Internet-draft on DDOS defense...
Hi All, I'd like to bring your attention to a recent Internet-draft. The URL is: http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt This draft proposes a specific (simple) change to RFC1122 which would help reduce the use of Smurf amplification in DDOS attacks. This is augments ingress filtering; it is designed specifically for the case where the attacker (source) is using broadcast on the local LAN as part of a DDOS attack. This is a case where ingress filtering does not help. We are proposing that it be an addition to the standard set by RFC1122. We'd very much like to hear comments from people on this draft. Vipul
How is this substantially different than RFC2644, "Changing the Default for Directed Broadcasts in Routers"? http://www.ietf.org/rfc/rfc2644.txt - paul At 10:13 PM 05/10/2000 -0600, Vipul Shah wrote:
Hi All,
I'd like to bring your attention to a recent Internet-draft. The URL is:
http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt
This draft proposes a specific (simple) change to RFC1122 which would help reduce the use of Smurf amplification in DDOS attacks. This is augments ingress filtering; it is designed specifically for the case where the attacker (source) is using broadcast on the local LAN as part of a DDOS attack. This is a case where ingress filtering does not help.
We are proposing that it be an addition to the standard set by RFC1122. We'd very much like to hear comments from people on this draft.
Vipul
Paul Ferguson wrote:
How is this substantially different than RFC2644, "Changing the Default for Directed Broadcasts in Routers"?
http://www.ietf.org/rfc/rfc2644.txt
- paul
He's suggesting a change in host stacks to not respond to broadcast/multicast ICMP ECHO packets which originate outside of the local IP subnet(s) known to a host's local interface(s). I have some concerns with this draft. The proposed change does lower the risk of damages if one system on a shared-media LAN is compromised, but only for this one type of attack. It seems to me it'd be possible to generate other types of packets which are broadcast/multicast which could elicit an ICMP response, and such attacks are not something which can be cured without breaking a lot of functionality. While ICMP ECHO packets are a preferred mechanism today, they're far from the only types of packets which are problematic. Where RFC2644 prevents ALL types of directed broadcast traffic, this draft will only have a useful impact on ICMP ECHO, and only in a limited case. I have to question whether there's sufficient benefit here to warrant opening up the IP stacks on end stations. An alternative to the suggested approach is the use of packet filters on end stations. For example, with Linux systems (and probably others) ipchains can be used to filter the types of traffic a host will respond to, regardless of what a border router or firewall ahead of it allows. I generally advocate the use of such facilities where possible as it adds an extra line of defense. Rate limiting of certain types of traffic (e.g. ICMP) is also a way to address the type of problem this draft is concerned with, and again is capable of addressing all ICMP, rather than just ICMP ECHO/ECHO REPLY. Overall impression of the draft: not a terrible idea, but unclear if it's sufficiently beneficial to warrant the effort to implement. Dan
At 10:13 PM 05/10/2000 -0600, Vipul Shah wrote:
Hi All,
I'd like to bring your attention to a recent Internet-draft. The URL is:
http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt
This draft proposes a specific (simple) change to RFC1122 which would help reduce the use of Smurf amplification in DDOS attacks. This is augments ingress filtering; it is designed specifically for the case where the attacker (source) is using broadcast on the local LAN as part of a DDOS attack. This is a case where ingress filtering does not help.
We are proposing that it be an addition to the standard set by RFC1122. We'd very much like to hear comments from people on this draft.
Vipul
-- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
At 08:02 AM 05/11/2000 -0400, Daniel Senie wrote:
Where RFC2644 prevents ALL types of directed broadcast traffic, this draft will only have a useful impact on ICMP ECHO, and only in a limited case. I have to question whether there's sufficient benefit here to warrant opening up the IP stacks on end stations.
That was my point. ;-) - paul
----- Original Message ----- From: Vipul Shah <svipul@novell.com>
I'd like to bring your attention to a recent Internet-draft. The URL
is:
http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt
This draft proposes a specific (simple) change to RFC1122 which would help reduce the use of Smurf amplification in DDOS attacks. This is augments ingress filtering; it is designed specifically for the case where the attacker (source) is using broadcast on the local LAN as part of a DDOS attack. This is a case where ingress filtering does not help.
The proposal suggests that hosts not respond to ICMP Echo broadcasts if the source address is not within the same subnet as the workstation. The rational is that even with "no ip directed-broadcast" (or it's equivalent on non-Cisco routers), smurf attacks can still be launched by a local machine on the local subnet (provided that there are no filters in place to prevent forged source-addresses from that subnet). Such an attack would only be useful where the aggregate bandwidth to the Internet from the subnet of the compromised host is signifigantly larger than the aggregate bandwidth to the Internet from the compromised host itself. In the traditional case of a simple shared media ethernet, this is obviously not the case -- rather than launching a "local smurf" attack to generate 10Mbps worth of flooding, the attacker could simply have the local machine generate 10 Mbps worth of flooding. In modern networks, a switch of some sort is likely to be involved, so there is some potential for amplification. However, given that the individual devices in such an environment are likely to be attached with a minimum of 100 Mbps Ethernet (and, assuming they are running a reasonable IP stack, they should then be able to generate a minimum of, say, 80Mbps of flooding), the cases where a "local smurf" would be beneficial to an attacker are limited to sites with switched ethernet and OC-3 or better connectivity. Experience has shown that such sites are not generally problematic smurf amplifiers. (OC-3 is actually just a low end number. Given that any such site is likely to have a lot of other traffic competing for bandwidth, I think 25% is a good high end number for maximum amplication effect you'd get. You'll need OC-12 or higher for any serious level of amplification.) I think the exposure that you seek to eliminate here is not an exposure that is large enough to justify changing the behavior of host IP stacks. -- Brett
participants (4)
-
Brett Frankenberger -
Daniel Senie -
Paul Ferguson -
Vipul Shah