> > > access-list 175 permit icmp any any
> > > int bleh/bleh
> > > rate-limit input access-group 175 128000 8000 8000 conform-action transmit exceed-action drop
> > > rate-limit output access-group 175 128000 8000 8000 conform-action transmit exceed-action drop
> >
> > I agree, the above isn't all that hard.
> >
> > However, I'd argue that the above is in some sense wrong.
> > There's no need to put all ICMP traffic in the same basket; some
> > ICMP traffic is required for e.g. path MTU discovery to work.
> > So, instead I'd use
> >
> > access-list 175 permit icmp any any echo-reply
>
> With all the smurf amplifiers available, it is of course easier to
> generate several Mbps of ICMP Echo Reply than it is to generate large
> amounts of other ICMP traffic.
>
> However, if your network is exposed to several Mbps of inbound ICMP
> *other* than Echo Reply, it may be equally bad for your network. So
> I prefer to leave it as 'icmp any any'.
I'll claim that the only real problem that is reasonable to CAR
is ICMP Echo Reply traffic. That (and UDP echo, possibly to a
lesser extent) are the only types of traffic where the attacker
can abuse remote amplifier networks, which contributes to the
"popularity" of these attacks.
However, just rate-limiting all ICMP traffic will cause a Smurf
attack of the current variety to have a larger impact than what
it would otherwise have:
o it will make network reachability testing via traceroute
difficult at best, since the ICMP TTL Exceeded messages will
also be rate-limited.
o it will cause "ICMP unreachable, fragmentation required but DF
set" messages as used by PMTU to be dropped, causing lousy
performance or "strange" connectivity problems for those
systems which depend on that type of feedback from the
network. (Assuming you have some capacity left after the
Smurfing, of course, which also goes for the above point...)
o it will also cause all other types of ICMP messages to be
dropped, some of which are important for proper operation
under normal circumstances.
If, however, the attack you're under is injected directly from
other well-connected hosts under the attackers control without
the assistance of amplifier networks, the attacker is free to
choose any type of traffic to inject, be it ICMP, UDP, TCP SYN or
any other IP protocol, and as far as I know there's no reasonable
way to use rate-limiting to counter that sort of traffic (?).
- HÃ¥vard
