PF "keep state" for ICMP
Travis H.
solinym at gmail.com
Wed Nov 16 22:44:42 PST 2005
(Any ICMP traffic is allowed back in after an outbound ICMP that keeps state)
> 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 there.
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?
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
More information about the freebsd-pf
mailing list