-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you want to experiment with strategies, and your C is OK, it should be quite easy to do. Look at allocate_rfd() in src/forward.c. That has two bits of code, the first makes a new random socket, and if that fails (kernel resource issues, or maximum number (RANDOM_SOCKS) in use) it falls through to the second bit, which uses an existing socket/port instead. All the reference-counting stuff to share random ports is already there, you just need to add some code to decide when to use an existing port instead of making a new one.
It would be interesting to hear if this actually improves things. Cheers, Simon. On 23/04/15 04:23, Eric Luehrsen wrote: > > On 22/04/15 03:49, Eric Luehrsen wrote: >>> I would like to propose that DNSMASQ move the 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. > > Simon Kelley Wed Apr 22 21:58:02 BST 2015 >> 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. > > My times proposed were terrible, yes. A better way to phrase this > would be: allow about 10 queries before switching client ports, > but obviously, don't hang out on 7th and switch ports also after > (very) short time. Again with the example use case of an ad happy > site or freemium game, a new page with ad banners, trackers, and > whatever would generate maybe only 3 query clients instead of 30. > Perhaps only allowing a "timed port" option with DNSSEC enabled > would keep the misguided from getting into trouble. > > The attacker would need a pirate server on a good sniffing > location, capable low pure time delay (lag more important than > bandwidth), the DNS client not using DNSSEC, or the target zone not > DNSSEC. If an ad hijacker had the internet connection and server so > capable, they would find way more profit just selling their > location to a high frequency stock trading company. Otherwise, they > couldn't inspect and sling shot bogus responses ahead of the actual > DNS responses. > > The use case is in some new products for home and small business > with cable ISP. These are a super-media-gateway-box with media > server, cable interface, two independent VOIP lines, cable modem, > and wireless gateway. MOCA serves TV through client media boxes. > One public IPV4 to do all of this. These are a great concept, but > the modem, firewall, and wireless are poorly implemented. However, > this combo may be the most economic offering for monthy cost. > > Super-gateways often don't provide even Primary and Guest networks > (ie isolate Coffee Shop POS and Guest Free WiFi). There's nothing > if you want to prevent neighbor business from free-loading into > your Guest Wifi, and so use beverage receipt passwords. An Install > must disable the media-box WiFi, and set permanent IP-DMZ to an > ether-wired standalone router (OpenWRT for example). Now you have > double NAT even with DMZ. Depending on the ISP firmware chosen > port stickiness, configured to best serve their video distribution > needs, then port clogging can become an issue. That means double > NAT, lots of port-holes for all the clients, and some weird > time-interleave entanglement > > Pinning DNSMASQ to one port defeats the other goals. Pinning > "min-port" extremely high still is in the ideal client area > (>32768), and begins to work towards the bookend of one port. A > "min-port" and "max-port" range might help but again that makes the > pirates job easier. So I am trying to noodle how a right-timed > random port hop using all the port space should be able to beat an > attacker but allow the NAT(s~s) to clear ports. > > _______________________________________________ Dnsmasq-discuss > mailing list Dnsmasqemail@example.com > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU8AAsACgkQKPyGmiibgrd0/QCgjLiYTx5m+USDlnrfc2OCIAZ/ +VAAmQE0ugHzHtVTu2Z9813O7N8sY+rt =o9ov -----END PGP SIGNATURE----- _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss