Would anyone be willing to post an operational example of CAR for ICMP. I would like to see what others are doing to combat the problem. Dan -----Original Message----- From: Jared Mauch [mailto:jared@puck.Nether.net] Sent: Tuesday, October 29, 2002 13:12 To: Jeff Shultz Cc: nanog@nanog.org Subject: Re: ICANN Targets DDoS Attacks On Tue, Oct 29, 2002 at 01:03:52PM -0800, Jeff Shultz wrote:
On 10/29/2002 at 3:40 PM Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Oct 2002 22:25:44 +0200, Petri Helenius <pete@he.iki.fi> said:
Why would you like to regulate my ability to transmit and receive data using ECHO and ECHO_REPLY packets? Why they are considered harmful?
Smurf.
Okay. What will this do to my user's ping and traceroute times, if anything? I've got users who tend to panic if their latency hits 250ms between here and the moon (slight exaggeration, but only slight).
I just love it when I've got people blaming me because the 20th hop on a traceroute starts returning * * * instead of times.
that's icmp ttl expired messages.
I know that, and I try to explain it to my customers... but it doesn't
answer the first part of the question - what will throttling ICMP do to ping and traceroute times? My gut reaction is that it will a. slow them
ICMP? Or only icmp echo and icmp echo-reply messages? In a well behaved router, nothing. Obviously if you have a 7500 or older GSR linecards that are incapable of doing this due to design problems from day one in pps rates and feature path, there may be a hit. I'm not saying rate-limit anything other than echo+reply.
down and/or b. discard a lot of them making the circuit look unreliable to ping. But I don't know enough about the underlying technology to be sure of that.
Once again, i'd like to see (other than a performance checking customer) generate more than 2Mb/s of icmp.echo and icmp.echo-reply packets that are legit and not part of a DoS. This is quite rare. Do your own stats and test your hardware. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Tue, Oct 29, 2002 at 01:24:11PM -0800, Dan Lockwood wrote:
Would anyone be willing to post an operational example of CAR for ICMP. I would like to see what others are doing to combat the problem.
Dan
rate-limit input access-group 2000 1536000 200000 200000 conform-action transmit exceed-action drop access-list 2000 permit icmp any any echo access-list 2000 permit icmp any any echo-reply POS0/1 <peer interface> Input matches: access-group 2000 params: 1536000 bps, 200000 limit, 200000 extended limit conformed 96374566 packets, 19474M bytes; action: transmit exceeded 16609350 packets, 1446M bytes; action: drop last packet: 28ms ago, current burst: 0 bytes last cleared 7w5d ago, conformed 33230 bps, exceeded 2467 bps POS0/2 <peer interface> Input matches: access-group 2000 params: 1536000 bps, 200000 limit, 200000 extended limit conformed 37773899 packets, 6325M bytes; action: transmit exceeded 5222953 packets, 399165438 bytes; action: drop last packet: 52ms ago, current burst: 0 bytes last cleared 7w5d ago, conformed 10794 bps, exceeded 681 bps As you can see by looking at your 'current burst' information, you can find out if there is an active attack/exceeding. These rates are typically quite low as you can see. - Jared
On Tue, Oct 29, 2002 at 04:31:50PM -0500, Jared Mauch wrote:
On Tue, Oct 29, 2002 at 01:24:11PM -0800, Dan Lockwood wrote:
Would anyone be willing to post an operational example of CAR for ICMP. I would like to see what others are doing to combat the problem.
Dan
rate-limit input access-group 2000 1536000 200000 200000 conform-action transmit exceed-action drop
access-list 2000 permit icmp any any echo access-list 2000 permit icmp any any echo-reply
POS0/1 <peer interface> Input matches: access-group 2000 params: 1536000 bps, 200000 limit, 200000 extended limit conformed 96374566 packets, 19474M bytes; action: transmit exceeded 16609350 packets, 1446M bytes; action: drop last packet: 28ms ago, current burst: 0 bytes last cleared 7w5d ago, conformed 33230 bps, exceeded 2467 bps POS0/2 <peer interface> Input matches: access-group 2000 params: 1536000 bps, 200000 limit, 200000 extended limit conformed 37773899 packets, 6325M bytes; action: transmit exceeded 5222953 packets, 399165438 bytes; action: drop last packet: 52ms ago, current burst: 0 bytes last cleared 7w5d ago, conformed 10794 bps, exceeded 681 bps
As you can see by looking at your 'current burst' information, you can find out if there is an active attack/exceeding.
These rates are typically quite low as you can see.
here is a juniper example: firewall { filter icmp-car-ge-6-1-0 { policer echo-reply-ge-6-1-0 { if-exceeding { bandwidth-limit 2250000; burst-size-limit 256k; } then discard; } term icmp-echo-reply { from { protocol icmp; icmp-type [ echo-request echo-reply ]; } then { count echo-reply-ct-ge-6-1-0; policer echo-reply-ge-6-1-0; accept; } } term remainder { then accept; } } } You need to do per-interface buckets on juniper otherwise it will do an overall aggregate. You then would also set a input (or output) filter on the interface to match the firewall filter. eg: # show interfaces ge-6/1/0 description "Exchange Interface"; link-mode full-duplex; unit 0 { family inet { no-redirects; filter { input icmp-car-ge-6-1-0; } address 10.1.2.3/24 { primary; } } } -- snip -- -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (2)
-
Dan Lockwood -
Jared Mauch