Re: Smurf tone down

[Havard.Eidnes () runit sintef no]

> > > 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