[Dnsmasq-discuss] NAT Congestion Enhancement for DNS Client Port Selection
Its been awhile since I could try to simulate a good use case. In short its peeling an onion and just exposed a whole bunch of bad factors. There are other issues in these gateways. They do a lot of stuff that has no customer tuning or even visibility. This confounds any honest testing. If port-mapping-connections, entanglement, and business-guest isolation double NAT ... ... and added fun carrier NAT, ugh ... were the only problems, then maybe this idea had a place. Considering all, its ready for the recycle bin. Eric 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. I would like to propose that DNSMASQ move [random per port# over short time] 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. .. 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. ... Eric ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] NAT Congestion Enhancement for DNS Client Port Selection
-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 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) iEYEARECAAYFAlU8AAsACgkQKPyGmiibgrd0/QCgjLiYTx5m+USDlnrfc2OCIAZ/ +VAAmQE0ugHzHtVTu2Z9813O7N8sY+rt =o9ov -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] NAT Congestion Enhancement for DNS Client Port Selection
On 22/04/15 03:49, Eric Luehrsen wrote: 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. 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 Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] NAT Congestion Enhancement for DNS Client Port Selection
-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
[Dnsmasq-discuss] NAT Congestion Enhancement for DNS Client Port Selection
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. (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.) ERIC ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
