| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sat, 27 Sep 2003 02:19:14 +0200 From: Daniel Hartmeier <daniel@...zedrine.cx> To: Darren Reed <avalon@...igula.anu.edu.au> Cc: bugtraq@...kerfactor.com, bugtraq@...urityfocus.com Subject: Re: ICMP pokes holes in firewalls... 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
Powered by blists - more mailing lists