Re: ICMP pokes holes in firewalls...

[Daniel Hartmeier <daniel@xxxxxxxxxxxxx>]

On Fri, Sep 26, 2003 at 10:13:56AM +1000, Darren Reed wrote:

> There's also a general problem here, that needs attention and that
> is you really shouldn't allow more ICMP error packets through than
> you see normal connection packets.  ie. one UDP packet out should
> not allow more than one ICMP error message back in.

Technically, a single packet may cause multiple legitimate ICMP errors.
As per RFC 792, an ICMP redirect does not imply that the packet was dropped
(quite the contrary) and ICMP source quench may be sent without dropping
the packet. Hence, further hops may send further ICMP errors for the
same packet.

Rate limiting the ICMP errors with a strict 1:1 ratio would break
traceroute through a gateway that forwards back to the same network, or
one operating near its capacity limit, for instance.

Since, as you explained, stateful filtering verifies the referred-to
packet's details (addresses, ports, sequence numbers for TCP), an
attacker trying to flood the filtered peer with ICMP errors would have
to know those details (be on the connection path). In that case,
obviously, he could just as well generate a flood of TCP/UDP packets
matching the state entry (or, worse, hijack or tear down the connection).
So, what do we gain by rate limiting the ICMP errors?

Daniel