<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">I am putting together a 'how-to' document to leverage dnsmasq to mitigate the risk of this CVE, in a router product known as Untangle Next Generation FireWall (NGFW) - another brand of bandaid, I suppose ;)</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">I would appreciate a review of these steps:</div><div class="gmail_default" style="font-family:georgia,serif">1) Override the upstream DNS server on the router to OpenDNS. <a href="https://engineering.opendns.com/2016/02/17/2980/">https://engineering.opendns.com/2016/02/17/2980/</a></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">2) Using input filter rules, block TCP port 53. This protects dnsmasq.<br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">3) Add a configuration line into dnsmasq.conf of: '<span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">edns-packet-max=1023' (rationale: two responses cannot overflow the 2048 buffer).</span></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">2) Assign DNS to the clients using the router(gateway) IP address that runs dnsmasq (generally by DHCP) and using that LAN address in both primary & secondary assignments.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">3) Using forward filter rules, block TCP/UDP port 53 on the external interface (WAN). This does not impact dnsmasq. It would be a good idea to wait until all of the clients' DHCP lease have renewed.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Now, clients behind the firewall can only get DNS answers from dnsmasq. Services that depend on edns0 like DNSSEC; or IPv6 are likely to be negatively affected by this type of 'shield'.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Question:</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">regarding Simon's point <span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">2) Malformed packets _will_not_ generally be rejected.</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">can you confirm that, and elaborate?</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif"><br></span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">Do you think Google's success was based mainly on limiting </span><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">edns-packet-max?</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif"><br></span></div><div class="gmail_default"><font color="#000000"><span style="white-space:pre-wrap">Do you think it is too much to expect dnsmasq to act as a shield for this exposure?</span></font></div><div class="gmail_default"><br></div><div class="gmail_default"><font color="#000000"><span style="white-space:pre-wrap">Thanks,</span></font></div><div class="gmail_default"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="white-space:pre-wrap">Jim Alles</span></font></div><div class="gmail_default"><font color="#000000"><span style="white-space:pre-wrap">disclaimer: I do not represent Untangle, and this concept remains my own, anyone who takes it is then responsible for any consequences, good or bad (tag - you're it).</span></font></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div></div><div id="DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top:1px solid #aaabb6">
<tr>
<td style="width:470px;padding-top:20px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">This email has been sent from a virus-free computer protected by Avast. <br><a href="https://www.avast.com/sig-email" target="_blank" style="color:#4453ea">www.avast.com</a>
</td>
</tr>
</table><a href="#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 2:35 PM, Rick Jones <span dir="ltr"><<a href="mailto:rick.jones2@hpe.com" target="_blank">rick.jones2@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/18/2016 10:24 AM, Louis Munro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is what I have come up with for now:<br>
<br>
iptables -I INPUT -p tcp -m tcp --sport 53 -m length --length 1024:4096<br>
-j DROP<br>
iptables -I INPUT -p udp -m udp --sport 53 -m length --length 1024:4096<br>
-j DROP<br>
<br>
4096 is really just some large number here.<br>
I could go higher if jumbo frames might be involved.<br>
</blockquote>
<br></span>
Generic Receive Offload (GRO) may be sufficient to get larger segments even without JumboFrames. If you want duct-tape added to the belt and suspenders, you might consider taking it out to 65535 - I'm pretty sure that nothing will "GRO" beyond that size.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Of course, this is a band-aid solution.<br>
There is no substitute for updating glibc in the end.<br>
</blockquote>
<br></span>
Indeed.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I digress, this is getting off track and is not really relevant to<br>
this list.<br>
</blockquote>
<br></span>
Perhaps, but it does go to how long one might be expected to carry along bandaids/kludges in the likes of dnsmasq.<span class="HOEnZb"><font color="#888888"><br>
<br>
rick jones</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</div></div></blockquote></div><br></div>