Re: ICMP pokes holes in firewalls...

From: Darren Reed (
Date: 09/27/03

  • Next message: Q?=Ilya TeterinQ=20?=: "Re: base64"
    To: (Daniel Hartmeier)
    Date: Sat, 27 Sep 2003 19:21:36 +1000 (Australia/ACT)

    In some mail from Daniel Hartmeier, sie said:
    > 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.

    Only if a sending host is misbehaving will you ever get more than 1
    redirect per packet flow as routers beyond the first hop should not
    be sending redirects that make it back to the origin.

    So what if a source quench gets dropped ? In situations where it's
    likely to be sent, it getting dropped is more likely than normal.

    And since you're quoting RFC's...

    I have to wonder whether or not you read the OpenBSD source code before
    saying this or maybe the OpenBSD source code is missing this comment
    that I can see in NetBSD's IP code:

                     * a router should not generate ICMP_SOURCEQUENCH as
                     * required in RFC1812 Requirements for IP Version 4 Routers.
                     * source quench could be a big problem under DoS attacks,
                     * or if the underlying interface is rate-limited.

    RFC 1812, section (page 57) discusses this.

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

    It won't break any version of traceroute that I'm aware of.

    > So, what do we gain by rate limiting the ICMP errors?

    If I send 1 UDP packet out, how many ICMP errors should I ever
    receive that match it ? 1 ? 10 ? 100 ? Up to the ttl value
    of the packet as it passed through ? What does your experience
    tell you? What do you consider "normal" vs what should be
    considered "acceptable" ?

    On the other end of this, have *you* had any experience with rate
    limited ICMP error message generation ? If you did, did traceroute
    not work because it was present ?


  • Next message: Q?=Ilya TeterinQ=20?=: "Re: base64"

    Relevant Pages

    • [UNIX] Linux NetFilter NAT/ICMP Code Information Leak
      ... first packet of a connection is hitting a NAT rule, ... the NAT box itself to reply with an ICMP error message, ... They are working on a new patch. ... included in the Linux kernel source. ...
    • Re: nmap 113/auth on shorewall
      ... The assumption is that you are running nmap from some remote location. ... use a packet sniffer on the remote system you ... Compare that response with a legitimate ICMP error generated by ...
    • RE: Active response... some thoughts.
      ... generate a random TTL for both TCP resets and ICMP error ... error message packet doesn't become a signature that you're using Snort ...
    • Re: iptables: DROP or REJECT?
      ... > Rossz wrote: ... REJECT discards the packet and sends an ICMP ERROR message back to the ... > originator of the packet (in conformance with the requirements of the TCP/IP ... > does nothing to minimize your profile. ...