* Vincent Deffontaines: > One solution is to let another device do the port randomization, to > protect your DNS clients.
This is correct, but the device needs to know about the DNS protocol, so that it ties QNAME/QCLASS/QTYPE and transaction ID and source port to a particular request. > If you run a Netfilter NAT firewall, you can use the source port NAT > randomization feature of Netfilter. This feature is available in Linux > vanilla kernel since 2.6.21.1 Thanks, very interesting. This seems to trivially leak ten bits from the net_random PRNG per newly NATted connection (perhaps more if you do proper cryptanalysis). net_random is linear and has only got 96 bits of internal state, so after just 10 packets, you should be able to predict the next source port choices with high accuracy (at least on a relatively idle single-processor system). For stub resolvers, this seems to be less relevant, but for caching resolvers, it's a problem because the source port information trivially leaks to the attacker. Note that using --random with a patched resolver (one that uses stronger random numbers for source ports) makes it vulnerable again. By default, Netfilter tries to preserve source ports, so its NAT does not destroy the effort put into BIND et al. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
