4

There's this nice saying from Ubuntu: no open ports on the default install. Other Linux OS's look the same, including Fedora. No-one wants to worry about firewalls, if they don't need to. Yuck, firewalls.

Ubuntu specifically exempt DHCP client (essential) and mDNS. (Without firewall zones to distinguish, mDNS is nice to leave enabled. Poettering did put some work into locking down avahi-daemon, I think specifically for this reason).

So I can turn off firewalld and play with bridged / routed networking for Virtual Machines. Except - what about these dnsmasq ports, for the default virbr0? Will they be exposed to the outside network?

$ sudo ss -ultp  # List TCP and UDP listening sockets
Netid  State      Recv-Q Send-Q                    Local Address:Port                                     Peer Address:Port                
udp    UNCONN     0      0                                     *:mdns                                                *:*                     users:(("avahi-daemon",pid=897,fd=12))
udp    UNCONN     0      0                         192.168.122.1:domain                                              *:*                     users:(("dnsmasq",pid=1669,fd=5))
udp    UNCONN     0      0                         192.168.100.1:domain                                              *:*                     users:(("dnsmasq",pid=1521,fd=5))
udp    UNCONN     0      0                              *%virbr0:bootps                                              *:*                     users:(("dnsmasq",pid=1669,fd=3))
udp    UNCONN     0      0                                     *:bootpc                                              *:*                     users:(("dhclient",pid=4646,fd=6))
udp    UNCONN     0      0                             127.0.0.1:323                                                 *:*                     users:(("chronyd",pid=859,fd=1))
udp    UNCONN     0      0                                     *:47683                                               *:*                     users:(("dhclient",pid=4646,fd=20))
udp    UNCONN     0      0                                     *:47754                                               *:*                     users:(("avahi-daemon",pid=897,fd=13))
udp    UNCONN     0      0                                    :::12282                                              :::*                     users:(("dhclient",pid=4646,fd=21))
udp    UNCONN     0      0                                   ::1:323                                                :::*                     users:(("chronyd",pid=859,fd=2))
tcp    LISTEN     0      5                         192.168.122.1:domain                                              *:*                     users:(("dnsmasq",pid=1669,fd=6))
tcp    LISTEN     0      5                         127.0.0.1:ipp                                                 *:*                     users:(("cupsd",pid=2288,fd=11))
tcp    LISTEN     0      5                                   ::1:ipp                                                :::*                     users:(("cupsd",pid=2288,fd=10))
2

On 23/11/12 12:50, Gene Czarcinski wrote:

Libvirt is in the process of changing for using bind-interface to using bind-dynamic to fix a security related issue where dnsmasq was responding to port 53 queries which did not occur on an address on the virtual network interface that instance of dnsmasq was supporting.

Checking ps -ax|grep dnsmasq, it's using the conf-file /var/lib/libvirt/dnsmasq/default.conf:

## dnsmasq conf file created by libvirt
strict-order
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
#...

So they have indeed moved to bind-dynamic from bind-interfaces. See also src/network.c in dnsmasq:

In --bind-interfaces, the only access control is the addresses we're listening on. There's nothing to avoid a query to the address of an internal interface arriving via an external interface where we don't want to accept queries, except that in the usual case the addresses of internal interfaces are RFC1918...

The fix is to use --bind-dynamic, which actually checks the arrival interface too. Tough if your platform doesn't support this.

Note that checking the arrival interface is supported in the standard IPv6 API and always done.

We already saw the DHCP socket ends up bound to a specific interface. So we don't need to worry about DHCP, only DNS. (dnsmasq only ever uses one DHCP socket. It listens to all addresses, but when there's exactly one interface it's able to bind to that using SO_BINDTODEVICE. Don't ask me to explain why it only uses one DHCP socket; doing DHCP is generally weird and low-level).

Testing dnsmasq from a second machine:

$ ip route add 192.168.124.1 via $FEDORA_IP
$ sudo nmap -A -F 192.168.124.1

Starting Nmap 6.47 ( http://nmap.org ) at 2016-01-18 16:11 GMT

Nmap scan report for 192.168.124.1
Host is up (0.0023s latency).
Not shown: 98 closed ports
PORT   STATE SERVICE    VERSION
22/tcp open  ssh        OpenSSH 7.1 (protocol 2.0)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
53/tcp open  tcpwrapped
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.11 - 3.14
Network Distance: 1 hop

TRACEROUTE (using port 8888/tcp)
HOP RTT     ADDRESS
1   0.80 ms 192.168.124.1

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.42 seconds

So I can see an open TCP port. However it responds as if it's "tcpwrapped". That implies if you connect over a different interface from virbr0, dnsmasq closes the connection without reading any data. So data you send to it doesn't matter; it can't e.g. exploit a classic buffer overflow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.