Re: [Dnsmasq-discuss] CVE-2015-7547 tcp path mitigation hack

2016-02-18 Thread Jim Alles 
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 ;)

I would appreciate a review of these steps:
1) Override the upstream DNS server on the router to OpenDNS.
https://engineering.opendns.com/2016/02/17/2980/

2) Using input filter rules, block TCP port 53. This protects dnsmasq.

3) Add a configuration line into dnsmasq.conf of: 'edns-packet-max=1023'
(rationale: two responses cannot overflow the 2048 buffer).

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.

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.

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'.

Question:

regarding Simon's point 2) Malformed packets _will_not_ generally be
rejected.
can you confirm that, and elaborate?

Do you think Google's success was based mainly on limiting edns-packet-max?

Do you think it is too much to expect dnsmasq to act as a shield for this
exposure?

Thanks,

Jim Alles
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).



This email has been sent from a virus-free computer protected by Avast.
www.avast.com 
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Feb 18, 2016 at 2:35 PM, Rick Jones  wrote:

> On 02/18/2016 10:24 AM, Louis Munro wrote:
>
>> This is what I have come up with for now:
>>
>> iptables -I INPUT -p tcp -m tcp --sport 53 -m length --length 1024:4096
>> -j DROP
>> iptables -I INPUT -p udp -m udp --sport 53 -m length --length 1024:4096
>> -j DROP
>>
>> 4096 is really just some large number here.
>> I could go higher if jumbo frames might be involved.
>>
>
> 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.
>
> Of course, this is a band-aid solution.
>> There is no substitute for updating glibc in the end.
>>
>
> Indeed.
>
> But I digress, this is getting off track and is not really relevant to
>> this list.
>>
>
> Perhaps, but it does go to how long one might be expected to carry along
> bandaids/kludges in the likes of dnsmasq.
>
> rick jones
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CVE-2015-7547 tcp path mitigation hack

2016-02-18 Thread Rick Jones 

On 02/18/2016 10:24 AM, Louis Munro wrote:

This is what I have come up with for now:

iptables -I INPUT -p tcp -m tcp --sport 53 -m length --length 1024:4096
-j DROP
iptables -I INPUT -p udp -m udp --sport 53 -m length --length 1024:4096
-j DROP

4096 is really just some large number here.
I could go higher if jumbo frames might be involved.


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.



Of course, this is a band-aid solution.
There is no substitute for updating glibc in the end.


Indeed.


But I digress, this is getting off track and is not really relevant to
this list.


Perhaps, but it does go to how long one might be expected to carry along 
bandaids/kludges in the likes of dnsmasq.


rick jones


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CVE-2015-7547 tcp path mitigation hack

2016-02-18 Thread Louis Munro 

> On Feb 18, 2016, at 12:23 , Simon Kelley  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> That would do it. Or just block port-53/TCP
> 
> Cheers,
> 
> Simon.


This is what I have come up with for now: 

iptables -I INPUT -p tcp -m tcp --sport 53 -m length --length 1024:4096 -j DROP
iptables -I INPUT -p udp -m udp --sport 53 -m length --length 1024:4096 -j DROP

4096 is really just some large number here.
I could go higher if jumbo frames might be involved.


Of course, this is a band-aid solution.
There is no substitute for updating glibc in the end.

But I digress, this is getting off track and is not really relevant to this 
list.

Thanks everyone,
--
Louis Munro


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] DNSMasq as DHCP Proxy Issue.

2016-02-18 Thread Mahmoud Ramadan 
Hi dears,
I'm trying to configure DNSMasq as DHCP Proxy on my LTSP server according
to the following link https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP

I want to diable DHCP server on the LTSP server and configure it externaly
on a Cisco router also i want the server to act as DHCP.

I tried the instructions above but whenever i add the "
dhcp-range=10.160.31.10,proxy " where 10.160.31.10 is my DNSMasq / LTSP
server and then restart my DNSMasq service the service stops TFTP which is
NOT what i want and as a result i get "TFTP Server Timeout " after
rebooting my LTSP Clients.

So I'm wondering what I'm missing , any help will be appreciated and thanks
in advance.

Best Regards,

Mahmoud Ramadan Ali

Network and VOIP Specialist.

Mobil: (+2) 01276877112

Blog | Website
| LinkedIn

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CVE-2015-7547 tcp path mitigation hack

2016-02-18 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

That would do it. Or just block port-53/TCP

Cheers,

Simon.


On 18/02/16 04:30, starli...@binnacle.cx wrote:
> UDP path mitigation covered by
> 
> edns-packet-max=512
> 
> Ugly but effective TCP fix:
> 
> 
> --- src/forward.c.orig  2011-02-17 10:30:15.0 -0500 +++
> src/forward.c   2016-02-17 23:16:03.792233438 -0500 @@ -966,14
> +966,17 @@ unsigned char *tcp_request(int confd, ti /* In case of
> local answer or no connections made. */ if (m == 0) m =
> setup_reply(header, (unsigned int)size, addrp, flags,
> daemon->local_ttl); }
> 
> check_log_writer(NULL);
> 
> +  /* mitigate CVE-2015-7547, truncate beyond 1023 bytes */ +
> m &= 0x3FF; + c1 = m>>8; c2 = m; if (!read_write(confd, &c1, 1, 0)
> || !read_write(confd, &c2, 1, 0) || !read_write(confd, packet, m,
> 0)) return packet; }
> 
> 
> ___ 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)

iQIcBAEBCAAGBQJWxf4SAAoJEBXN2mrhkTWiJHgP/3M+0+Npg1pY/vEfGlTX48pb
4bjbsvybys46knY6Ik1ry6IyV2ee73KI9lTO6B4PUhaVqwNkKBt99+VjgrPwQe87
PhpGDQRHL9q9KRGwCOCfyUZWE0/ERYCu+53J3mFL6lXTRaFM5HRHy66W96/OhFuf
buMaz01iudiOF3+aYgOg9Ks/H/ih2eay/VLJ3oQ+iwljoxAmiEii7dmYwHneOuyj
RmFfuVNaABxQXSekpGbx44JeRWQU94tGECHnUdn3WFpbsP1DUxG9YBgHx9cUfXis
h/Kcs5ukaTNfWr2W2tizx4sFi7bGqYevELYT1vjXbh7//S9FXPaUeK7ZVfBEmPah
1Cz19f7v/ZSMLCpVqOvz6JOlTrwbJsrG2aBEaXaQsiCcycvkHk37EAQB3CPLHDRO
98ji1GZ8XUTxuUMVItHljKE1WveQr7qR17nNkFAk3BTnfWAdcyyED0/EFtNGajpg
pnNYY8bCmjEwF0G4ORQR+cIvjzS8kpMnviK9H01x3NseJfPK51EOR8Io3CMNTw0r
lO7FHBkG787/JXYixuSoL/g3FAmvI3DL1HqsULDMlQgiv2iIPkRPTSoOtplvAzXB
aJKlpwiyrC7cQso7ql1FbOOoqs2LeanXarZYWlb8MHCGHrsyoGqerpAiLAvt/ETO
FRT8y0TmHH6Bx0HfytrE
=2XLw
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] disabling reverse dns lookup in dnsmasq

2016-02-18 Thread Simon Kelley 
--server=/0.168.192.in-addr.arpa/#
--server=/in-addr.arpa/


should do it. It would make more sense to use --rev-server, but that
doesn't support empty server-ip or '#' to specify the standard server.


Cheers,

Simon.



On 17/02/16 20:12, Guy Wijnants wrote:
> Hi Simon,
> 
> Is there a way to enable reverse lookup for a certain type of network in 
> dnsmasq? Like requests comming from 192.168.0.0/24 and disable reverse lookup 
> for the rest?
> 
> Best Regards,
> 
> Guy
> 
>> Op 17 feb. 2016 om 18:34 heeft Simon Kelley  het 
>> volgende geschreven:
>>
>> You mean you don't want dnsmasq to forward any DNS queries and only
>> answer stuff locally? Just don't configure any upstream servers, and use
>> --no-resolv to stop dnsmasq find upstream servers in /etc/resolv.conf.
>>
>> cheers,
>>
>> Simon
>>
>>
>>
>>> On 17/02/16 12:57, green krypton wrote:
>>> sorry i mean recursive lookups :)
>>>
>>> On Wed, Feb 17, 2016 at 6:25 PM, green krypton 
>>> wrote:
>>>
 Hi is there any way i can stop dnsmasq from doing reverse dns lookups. I
 am trying not to use a firewall instead block at application layer.Can any
 one help me with that?


 using dnsmasq-2.68-5
>>>
>>>
>>>
>>> ___
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CVE-2015-7547 and dnsmasq

2016-02-18 Thread Simon Kelley 
The edns-packet-max does _not_ apply to TCP replies. Looking through the
CVE, those are vulnerable (for instance is an attacker returns a reply
with the trucated bit set, forcing fallback to TCP). For most cases, a
quick and effective fix would be simply to block port-53/TCP

The default value of edns-packet-max was 1280 in dnsmasq release 2.51
and earlier. From 2.52, this increased to 4096, so protection is not
automatic - the value of edns-packet-mac needs to be reduced below 2048.

Cheers,

Simon.





On 17/02/16 16:46, Louis Munro wrote:
> Hello,
> 
> Buffer overflows are in the news again as I am sure people have heard by now.
> 
> The post on the google security blog about it seems to indicate that dnsmasq 
> may be used to mitigate the problem, at least until patching could be done.
> 
> See: 
> https://googleonlinesecurity.blogspot.ca/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
> 
> I have some production servers running both dnsmasq (2.48) and the affected 
> glibc.
> 
> Do I understand correctly that running dnsmasq in its default configuration 
> should limit dns replies handled to 1280 bytes?
> I see this in the manpage: 
> 
>-P, --edns-packet-max=
>   Specify the largest EDNS.0 UDP packet which is supported by the 
> DNS forwarder. Defaults to 1280, which is
>   the RFC2671-recommended maximum for ethernet.
> 
> Since the vulnerability relies on a reply of at least 2048 bytes, can I 
> assume I am fine until I can update these systems and reboot them (which 
> should be soon, but just not yet…)? 
> Does that setting also apply to TCP replies?
> 
> 
> Best regards,
> --
> Louis Munro
> lmu...@inverse.ca  ::  www.inverse.ca 
> +1.514.447.4918 x125  :: +1 (866) 353-6153 x125
> Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence 
> (www.packetfence.org)
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss