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.



 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

Version: GnuPG v2.0.22 (GNU/Linux)


Dnsmasq-discuss mailing list

Reply via email to