Re: [Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-22 Thread Robie Basak
On Mon, Apr 14, 2014 at 08:39:01PM -, Jeroen van der Ham wrote:

[...]

   ...I'm now
 trying to convince all package maintainers to use the --local-service
 option by default.

AIUI, you've effectively convinced Ubuntu, by virtue of having convinced
Debian. But this change didn't make Trusty, since the upstream
--local-service feature hadn't filtered down. I think it probably will
be in by the next release.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1306646

Title:
  dnsmasq provides recursive answers to the Internet by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1306646/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-14 Thread Ryan Beisner
Curiosity fueled a couple of tests on this.  In checking 2 common
scenarios, at least one use case confirms.

Aside from this confirmation, a bigger-picture question could be:  in
principle, how is 53 being open and interactive by default any different
than 80, 22, or 137-139 being open and interactive by default, when
dnsmasq is not installed by default?  If a user chooses to add a
service, whether that is ssh, samba, apache, dnsmasq, or others, in what
scenarios are we to protect the user against him/herself?  One could
argue that all of those protocols are subject to abuse.  In other words
- this could be a slippery slope.

Having said that little devil's advocate bit, I am *all for* making sure
our default behavior is to not have an open recursive DNS server.

Here's what I found:

[test0]: Trusty default server install + Virtual Machine Host package 
selection (ok)
[test1]: Trusty default server install + install dnsmasq (CONFIRMS open 
recursive DNS condition)

# [test0] #
Trusty default server install + Virtual Machine Host package selection

* This method does not result in an open recursive DNS server.

* The default ip interface layout follows; eth0 is connected and has
obtained an address via dhcp;  libvirt has created virbr0 interface, and
dnsmasq is listening only on the virbr0 interface (192.168.122.1).

rbeisner@isotest0:~$ sudo ip addr | grep gl
inet 10.4.5.132/24 brd 10.4.5.255 scope global eth0
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0

rbeisner@isotest0:~$ sudo netstat -taupn | egrep ':22|:53'
tcp0  0 192.168.122.1:530.0.0.0:*   LISTEN  
1148/dnsmasq
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN  
852/sshd
tcp6   0  0 :::22   :::*LISTEN  
852/sshd
udp0  0 192.168.122.1:530.0.0.0:*   
1148/dnsmasq  

* The default iptables firewall rules for this use case follow;
Destination ports 53 tcp  udp are explicitly allowed in the virbr0
interface.  DNS ports are not disallowed anywhere, and there isn't a
default drop or reject rule in the input chain.  But because dnsmasq is
only bound to the virbr0 interface, it should not be accessible on any
other interface, even if all iptables rules are flushed.

beisner@isotest0:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 19526 packets, 29M bytes)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/00.0.0.0/0   
 udp dpt:53
0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/00.0.0.0/0   
 tcp dpt:53
0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/00.0.0.0/0   
 udp dpt:67
0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/00.0.0.0/0   
 tcp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  virbr0  0.0.0.0/0
192.168.122.0/24 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all  --  virbr0 *   192.168.122.0/24 0.0.0.0/0   

0 0 ACCEPT all  --  virbr0 virbr0  0.0.0.0/00.0.0.0/0   

0 0 REJECT all  --  *  virbr0  0.0.0.0/00.0.0.0/0   
 reject-with icmp-port-unreachable
0 0 REJECT all  --  virbr0 *   0.0.0.0/00.0.0.0/0   
 reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 10169 packets, 592K bytes)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT udp  --  *  virbr0  0.0.0.0/00.0.0.0/0   
 udp dpt:68

* Flush iptables, all traffic allowed:

rbeisner@isotest0:~$ sudo iptables -F
rbeisner@isotest0:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 39 packets, 2712 bytes)
 pkts bytes target prot opt in out source   destination 


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 


Chain OUTPUT (policy ACCEPT 20 packets, 1792 bytes)
 pkts bytes target prot opt in out source   destination 


* Port scans from a neighboring node confirm that tcp and udp 53 are
closed on the world-facing interface:

rbeisner@bcu:~$ sudo nmap -sU -p 53 10.4.5.132 | grep 53
53/udp closed domain

rbeisner@bcu:~$ sudo nmap -sT -p 53 10.4.5.132 | grep 53
53/tcp closed domain

rbeisner@bcu:~$ sudo nmap -sT -p 22 10.4.5.132 | grep 22
22/tcp open  ssh
...


# [test1] #
Trusty default server install + install dnsmasq (CONFIRMS open recursive DNS 
condition)

* CONFIRMS the default condition to be an open recursive DNS server /!\.

* DNS query from a neighboring host 

Re: [Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-14 Thread Robie Basak
On Mon, Apr 14, 2014 at 03:02:44PM -, Ryan Beisner wrote:
 Aside from this confirmation, a bigger-picture question could be:  in
 principle, how is 53 being open and interactive by default any different
 than 80, 22, or 137-139 being open and interactive by default, when
 dnsmasq is not installed by default?  If a user chooses to add a
 service, whether that is ssh, samba, apache, dnsmasq, or others, in what
 scenarios are we to protect the user against him/herself?  One could
 argue that all of those protocols are subject to abuse.  In other words
 - this could be a slippery slope.

I think that a key difference for DNS is that there are multiple common
modes of operation, and for dnsmasq an open recursive server seems to be
an uncommon mode to me. Users may want dnsmasq provision for some
local networking setup (this is common - see lxc and libvirt), or want
to authoritatively serve a zone, and in both of these cases there's no
need to serve recursively to outside requests at all.

And when one does serve recursive queries, it's still considered a
generally bad idea (AIUI) to serve the Internet in general. You'd want
to configure it to serve a limited network instead.

So the difference is where (and if) the default isn't useful in the
majority of cases. This might apply to bind and unbound also, but does
not apply to a public web server where the point of installing it is to
serve pages publicly.

An exception is that for a server that doesn't have a publicly reachable
interface (via RFC1918, or as blocked by a firewall, or whatever), it
might be easier to just answer recursively to all requests, given that
it is separately known that these requests cannot be coming from the
Internet at large. In this case, this kind of default might be useful.
samba is an example of this type of case, as it typically is installed
on an internal network that is already somehow unreachable from the
Internet.

I'm not arguing either way here, just answering your where do we draw
the line? question. Perhaps dnsmasq also fits into this latter
category.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1306646

Title:
  dnsmasq provides recursive answers to the Internet by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1306646/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-14 Thread Ryan Beisner
Yep, I'm with ya Robie.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1306646

Title:
  dnsmasq provides recursive answers to the Internet by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1306646/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-14 Thread Jeroen van der Ham
I completely agree that it is difficult and hard to draw the line. My
initial approach was to convince the author to change the default
behaviour, but unfortunately I did not succeed with that.

Serving DNS requests to only the intended audience is a better
alternative. This has been the intended approach of other bug reports,
but it is actually very hard to determine from outside of the daemon.
Since dnsmasq also usually has the role of DHCP provider, and also has
to know about which interfaces it servers on, it is in the perfect
position to know about the intended audience.  This argument finally won
over the author to at least implement the option.

Since I've personally seen dozens of reports of exploited dnsmasq
instances, and even experts who overlooked its role in installs, I'm now
trying to convince all package maintainers to use the --local-service
option by default.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1306646

Title:
  dnsmasq provides recursive answers to the Internet by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1306646/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-14 Thread Ryan Beisner
I think you're right, and I think that is indeed the place to do it.
I've seen other people, on similar topics, debate 'the line.'  This very
discussion will be valuable in this change because it shows that we are
assessing that aspect.  Thanks again for filing this.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1306646

Title:
  dnsmasq provides recursive answers to the Internet by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1306646/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1306646] Re: dnsmasq provides recursive answers to the Internet by default

2014-04-11 Thread Bug Watch Updater
** Changed in: dnsmasq (Debian)
   Status: Unknown = Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1306646

Title:
  dnsmasq provides recursive answers to the Internet by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1306646/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs