-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/04/15 03:49, Eric Luehrsen wrote: > A while ago, DNSMASQ changed to roaming client ports to prevent > from being a sitting duck for [various response] attacks. Each new > request forward is assigned a new client return port. This is a > good. Further, the minimum port in the selection of ports can be > pushed away from extended low-range server ports (min-port). This > was fine in the days of homes with one desktop and maybe one laptop > computer. However, this does not scale well for larger user bases > behind an IPV4 NAT. Lets say a large house hold with various mobile > devices or a coffee shop. > > With so many ad happy sights, one browser click can kick off 50 > new DNS look-ups for each ad panel and tracker-collector. Lets not > forget ad happy "freemium" games on smart phones either. These > port openings in the NAT have some period of stickiness and create > blocks on other devices generating client ports for normal NAT > return. The NAT bumps the inner-device client port about to be > remapped-of-the-remap. This then affects even NAT intelligent > applications requiring mutual server or per connections like > skype. While the collisions probability may seem low, it can cause > weird and indeterminate behavior (to the end user). It needs to be > recognized how "magically" the apparently random statistics can > align. > > DNSMASQ does allow single address like its old behavior, but we > don't want that for the while ago reason. > > I would like to propose that DNSMASQ move the port every 6-60 > seconds random per port# and also DNSMASQ move client ports when so > many requests have processed (max-concurrent reused or %10 of cache > or random again?). This will keep its profile on the NAT down and > it will maintain the moving target against attacks. Random doesn't > have to be rand(), it could just be 6 bits of the port XOR with the > CPU clock or something cheap for embedded devices.
I think that would probably defeat the object of having random ports. The attack works by doing something which causes dnsmasq to forward a particular query, and then spraying bogus answers at dnsmasq in the hope that the attacker picks the correct query-id/source-port combination once and gets his answer accepted into the cache _before_ the correct answer comes back. In that context, 60s is forever. You may as well have a static port number. I'm not sure I understand exactly what the problem is here, filling the NAT table, or clashes between ports randomly selected by dnsmasq and ports selected by the NAT. Could you explain more? > > (Please, I want avoid flame over IPV6 because reality is adoption > is just slow still. Lets just assume that some will be stuck with > ISP providing only IPV4 for a while yet.) Here at project dnsmasq, we like to support IPv4 and IPv6. Cheers, Simon. > > > ERIC > > > > _______________________________________________ Dnsmasq-discuss > mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU4C1oACgkQKPyGmiibgrct5gCfU5JQJczHZ6kdgDoKEWg/waEK v7AAmwYrORju/ycThEcNA7QhsgUMA7L/ =65V7 -----END PGP SIGNATURE----- _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
