A libvirt dnsmasq está exposta à rede, se eu executar o Fedora sem um firewall?

Question

Existe um bom ditado do Ubuntu: sem portas abertas na instalação padrão. Outros sistemas operacionais Linux são parecidos, incluindo o Fedora. Ninguém quer se preocupar com firewalls, se não precisarem. Sim, firewalls.

O Ubuntu especificamente isenta o cliente DHCP (essencial) e o mDNS. (Sem zonas de firewall para distinguir, é bom deixar o mDNS habilitado. Poettering colocou algum trabalho no bloqueio do avahi-daemon, acho que especificamente por esse motivo).

Para que eu possa desativar firewalld e jogar com a rede de ponte / roteada para máquinas virtuais. Exceto - e essas portas dnsmasq, para o padrão virbr0 ? Eles serão expostos à rede externa?

$ 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))

    

Answer 1

Em 23/11/12 12:50, Gene Czarcinski escreveu:

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.

Verificando ps -ax|grep dnsmasq , está usando o 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
#...

Então eles realmente mudaram para bind-dynamic de bind-interfaces . Veja também 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.

Já vimos o soquete DHCP ser ligado a uma interface específica. Portanto, não precisamos nos preocupar com o DHCP, apenas o DNS. (O dnsmasq usa apenas um soquete DHCP. Ele ouve todos os endereços, mas quando há exatamente uma interface, ele pode se ligar a isso usando SO_BINDTODEVICE . Não me peça para explicar por que ele usa apenas um soquete DHCP; geralmente esquisito e de baixo nível).

Testando o dnsmasq a partir de uma segunda máquina:

$ 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

Para que eu possa ver uma porta TCP aberta. No entanto, responde como se fosse "tcpwrapped". Isso significa que, se você se conectar através de uma interface diferente de virbr0 , dnsmasq fechará a conexão sem ler nenhum dado. Portanto, os dados que você envia para ele não importam; não pode, e. explorar um estouro de buffer clássico.