Re: [Dnsmasq-discuss] How to declare dnsmasq as authoritative for the 10.x subnet?

2018-09-08 Thread Simon Kelley 
On 06/09/18 15:36, Wojtek Swiatek wrote:
> Hello everyone,
> 
> Following the documentation for auth-zone, I tried to declare my dnsmasq
> server as authoritative for the 10.0.0.0/8  zone (I
> server several IP sub-ranges in 10.x). Unfortunately, whatever I try I
> end up with
> 
> Sep 06 16:29:28 bind named[4677]: zone 10.in-addr.arpa/IN: refresh:
> non-authoritative answer from master 10.100.10.254#53 (source 0.0.0.0#0)
> 
> on the secondary bind server (the direct zones are transferred OK).
> 
> How should I set this up? I tried
> 
> auth-zone=10.0.0.0/8 
> auth-zone=10.in-addr.arpa
> 
> but none of them worked (no errors in dnsmasq, just the bind message above).
> 
> Thanks for any pointers!
> 
>

auth-zone specifies the zone within the domain-name tree first, then
(optionally) the subnet range which gets serverd for reverse queries, so
something like

auth-zone=swtk.info/0.0.0.0/8

would do the trick.

The important thing to understand about dnsmasq is that it continues to
work as a normal DNS forwarder, and only acts as an authoritative server
when queries arrive at a particular interface or address. Typically,
it's acting as DNS forwarder on "internal" networks, and as
authoritative when queries arrive from the "internet" side of the router
it's running on. To tell it which queries to answer in authoritative
mode, you need to use the --auth-server configuration.


There's quite a long step-by-step guide to setting up auth mode as a
separate  section of the man page. It's worth reading that.


Cheers

Simon.

Cheers,

Simon.



> ___
> 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] CERT Vulnerability VU#598349

2018-09-08 Thread Simon Kelley 
https://www.kb.cert.org/vuls/id/598349

The essence of this is that an attacker can get a DHCP lease whilst
claiming the name "wpad" and thus insert the name wpad.example.com in
the local DNS pointing the attacker's machine. The presence of that A
record allows control of the proxy settings of any browser in the network.

It's already possible to mitigate this: adding

0.0.0.0 wpad wpad.example.com
:: wpad.wpad.example.com

to /etc/hosts will generate harmless A and  records which override
those that may be created by DHCP leases.


The currently unreleased 2.80 version of dnsmasq adds the
dhcp-name-match option, which allows

dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore

Which stops the attack at source.


The question is, should the above configuration be "baked in" to the code?



Cheers,

Simon.








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

Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-09-08 Thread James Feeney 
Hey Simon

On 9/8/18 11:17 AM, Simon Kelley wrote:
> The question is, should the above configuration be "baked in" to the code?

As I understand, this vulnerability arises from the Web Proxy Automatic 
Discovery (WPAD) protocol, not from dnsmasq itself.  And, dnsmasq configuration 
provides - or will provide - a configuration mechanism to obviate the 
shortcomings of the WPAD protocol.  My inclination would be to *not* change the 
code, on the off-chance that someone might consider this specific function of 
the WPAD protocol to be a "feature", and instead, to rely upon the proper 
dnsmasq configuration, which would make overt to the network administrator just 
how the "wpad" sub-domain is being handled.  And then, for instance, as you say,
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
could be recommended in the default dnsmasq configuration file.

Also, the CERT note says "Other autodiscovery names, such as, ISATAP, 
autodiscovery and autoconf may also be exploitable."  And dnsmasq could be 
playing "wack-a-mole" with sub-domain names in the code, if handled that way.  
It's easier to play "wack-a-mole" from the configuration file.

My first thoughts...

James

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

Re: [Dnsmasq-discuss] Support for adding CNAME query result to IPSET

2018-09-08 Thread Simon Kelley 
No, that's a different problem. your target name "vpnin.swtk.info" is
coming from the DHCP subsystem, because you have a DHCP lease for a host
called "vpnin" and have set the domain to swtk.info.


It would be possible, to fix this, and may be even sensible, but it's
not the same that the OPs problem with CNAMES.

Given that when the result comes from DHCP, it's pretty much guaranteed
to be within the firewall, does it make sense to have such names checked
by the ipset system? Genuine question. I'm unsure what people are using
the ipsets facility for, so I don't know the answer.


Cheers,


Simon.

On 07/09/18 13:49, Wojtek Swiatek wrote:
> I incidentally have the same problem (I started to tackle ipset today).
> Taking your example:
> 
> root@srv ~# dnsmasq -d --log-queries --ipset=/vpnin.swtk.info/vpnin
> 
> dnsmasq: started, version 2.79 cachesize 150
> dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6
> no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
> dnsmasq-dhcp: DHCP, IP range 10.200.0.1 -- 10.200.0.230, lease time 10d
> dnsmasq-dhcp: DHCP, IP range 10.10.10.1 -- 10.10.10.200, lease time 10d
> dnsmasq-dhcp: DHCP, IP range 10.1.1.1 -- 10.1.1.100, lease time 10d
> dnsmasq-dhcp: DHCP, IP range 10.100.20.1 -- 10.100.20.230, lease time 10d
> dnsmasq-dhcp: DHCP, IP range 10.100.10.1 -- 10.100.10.230, lease time 10d
> dnsmasq: using nameserver 8.8.4.4#53
> dnsmasq: using nameserver 1.1.1.1#53
> dnsmasq: read /etc/hosts - 8 addresses
> dnsmasq: query[A] vpnin.swtk.info  from 127.0.0.1
> dnsmasq: DHCP vpnin.swtk.info  is 10.200.0.2
> 
> the vpnin ipset is already created (and stays empty):
> 
> root@srv ~# ipset vpnin
> ipset v6.34: No command specified: unknown argument vpnin
> Try `ipset help' for more information.
> root@srv ~# ipset list vpnin
> Name: vpnin
> Type: hash:ip
> Revision: 4
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 88
> References: 0
> Number of entries: 0
> Members:
> 
> 
> Cheers,
> Wojtek
> 
> 
> Le mar. 4 sept. 2018 à 01:21, Simon Kelley  > a écrit :
> 
> Are you sure? It seems to work for me.
> 
> 
> 
> srk@holly:~/dnsmasq/dnsmasq$ src/dnsmasq -d -p 1 --log-queries
> --ipset=/www.comcast.com/test
> dnsmasq: started, version 2.80test4 cachesize 150
> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN
> DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect
> inotify dumpfile
> dnsmasq: reading /etc/resolv.conf
> dnsmasq: using nameserver 127.0.1.1#53
> dnsmasq: read /etc/hosts - 8 addresses
> dnsmasq: query[A] www.comcast.com from 127.0.0.1
> dnsmasq: forwarded www.comcast.com to 127.0.1.1
> dnsmasq: reply www.comcast.com is 
> dnsmasq: reply www.comcast.com.edgekey.net is 
> dnsmasq: ipset add test 2.22.99.93 e523.dscb.akamaiedge.net
> dnsmasq: reply e523.dscb.akamaiedge.net is 2.22.99.93
> 
> Cheers,
> 
> Simon.
> 
> 
> On 26/08/18 08:48, esinpublic-2...@yahoo.com.hk wrote:
> > Hi, 
> >
> > When running with the ipset configuration, e.g.
> >
> > ipset=/example.com/whitelist
> >
> >
> > If the query result is a CNAME of differnet domain e.g.
> >
> > example.com.                                     
> >  300  INCNAME  d123456789abcdefg.cloudfront.net.
> > d123456789abcdefg.cloudfront.net.    60   
> > INA123.123.123.123
> >
> > The IP address 123.123.123.123 would not be added to the IPSET. May I
> > ask if it is possible to have dnsmasq to add the final reolved ip into
> > the ipset?
> >
> > Thank you!
> >
> >
> > ___
> > 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