Date: Thu, 17 Nov 2005 00:44:41 -0600 From: "Travis H." <solinym@gmail.com> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: PF "keep state" for ICMP Message-ID: <d4f1333a0511162244y3121fcf7n16596d78fef9b86e@mail.gmail.com> In-Reply-To: <20051108095903.GB6116@insomnia.benzedrine.cx> References: <20051108074236.18256.qmail@web32602.mail.mud.yahoo.com> <20051108095903.GB6116@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
(Any ICMP traffic is allowed back in after an outbound ICMP that keeps stat= e) > Assuming you're a malicious A, what do you gain, though? You're already > getting pinged by C, so you know it's there. You could already deliver > an arbitrary amount of reply packets. Fingerprinting sillyness? Oooh, a challenge in creative thinking! First, remember that src IPs are eminently spoofable. So no protection the= re. Next let's handle the issue of the IDs. They appear to be 16-bit values, so if the number sent out during a state expiry period is P, and the attacker sends Q responses, then we expect that a reply will get back in if PQ is close to 65536, and this assumes perfectly random IDs in both the outbound and inbound... i.e. a perfect world. Lemme see, anything that handled net/host unreach intelligently could be fooled into thinking C doesn't exist causing DoS... You could send net redirect messages to reroute traffic to arbitrary places= ... You could query the timestamp on A which may reveal system uptime and thus help distinguish between machines who may be behind NAT and appear to share same IP... The attacker could force the source host to fragment packets for C, which may do something interesting. At least it would reduce the bandwidth from A to C, but it may be a DoS since something in between may be dropping fragments. It could induce such short UDP/TCP fragments such that they don't contain src/dst port information, and thus are dropped by a firewall causing DoS... or possibly allocate reassembly buffers, which could cause DoS in pathological cases.... You could query the address (subnet) mask.... of the internal network. Not scandalous, but do outside hosts really need that information?=20 That's enough to get your subnet-directed broadcast address, and thus use your network as an amplifier. Hmm, nothing too earthshaking but lots of DoS possibilities and some information disclosure. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d4f1333a0511162244y3121fcf7n16596d78fef9b86e>