Como exigir que todas as atividades de rede passem por um firewall guest KVM antes de chegar ao host?

Question

A maioria das informações que eu encontrei tende a configurar um firewall KVM usando uma conexão de ponte.

Pelo que entendi, é um risco de segurança se o tráfego de rede puder alcançar o host sem ter que passar primeiro pelo firewall.

Já vi a NIC principal (por exemplo, eth0 ) ser definida como a NIC da máquina virtual, mas isso exclui o host de acessar eth0 ?

A outra opção que me vem à mente é uma passagem PCI da NIC, mas tive problemas com o método.

Existem outras abordagens para exigir que o tráfego do host passe pelo firewall primeiro? Qual método você recomenda usar?

    

Answer 1

A primeira ideia é separar quais interfaces são usadas para adicionar acesso à rede às VMs e quais são usadas para controlar o host. Geralmente, o terceiro conjunto de interfaces é usado para acessar as imagens da VM em algum tipo de armazenamento compartilhado na rede. Então, você tem, idealmente, 6 interfaces: 4 de Gigabit Ethernet e 2 de 10 Gigiabit Ethernet.

A segunda ideia é que você pode usar diferentes 802.1q VLANs para host e para máquinas virtuais. Eu construí uma rede onde tínhamos VMs em três VLANs diferentes e, às vezes, uma VM poderia ter participação em várias VLANs (criando várias NICs virtuais e conectando-as com várias VLANs diferentes no host)

O hadrware do servidor de anotações tem um BMC, que é usado para controlar o host fora da banda. Essencialmente, este é um pequeno computador que tem acesso aos sensores do computador host, ele pode ver valores (temperatura, ventilador rpms), ligar / desligar / redefinir host como se você apertar o botão, ainda tem funcionalidade IP KVM e assim por diante, e tem endereço de rede por conta própria. Também geralmente implementa o protocolo IPMI. Ela é exposta freqüentemente como compartilhada com LAN1 (ou seja, como um pequeno comutador, não comutador - host e BMC não podem se comunicar, mas ambos comutam com dispositivos externos) ou com tomada ethernet independente que é roteada exclusivamente para o BMC. Sistemas blade podem ter um ou dois (redundantes) BMC por gaiola, não em cada servidor blade.

A configuração segura é assim:

bond0 é (eth0, eth1) combinada pelo LACP, tem um endereço IP no host e é usado para controlar o host.

a ligação 1 é (eth2, eth3) combinada pelo LACP. É dividido com vlans, ou seja, o host tem bond1.10, bond1.552 subinterfaces virtuais etc. Existem bridges criadas: br10 bridges bond1.10 e todas as interfaces do lado do host VM para VMs que participam do vlan 10, br552 bridges bond1.552 e todo o lado do host do VM para vlan 522 e assim por diante. Nenhuma dessas interfaces tem um endereço IP, portanto, as VMs não puderam se comunicar com o host.

bond2 é (eth4, eth5) combinado e usado para acessar imagens de disco da VM via iSCSI, CEPH, para sincronizar o DRBD e assim por diante. Ele tem um IP no host, mas está conectado a uma rede de armazenamento completamente separada com seus requisitos especiais.

bond0 e bond1 devem ser separados fisicamente, para que as VMs não sejam capazes de se comunicar com o host, mas até saturar a rede de controle do host. Essa rede é usada, por exemplo, para transferir o conteúdo da memória da máquina virtual no caso de migração ao vivo para outro host, e nenhuma VM pode saturar o desempenho desse processo.

Mesmo se você estiver criando apenas um pequeno sistema com uma interface física para hospedar cinco máquinas virtuais e tiver que combinar funcionalidade de bond0 e bond1, você poderá ter endereço IP apenas na interface física (acessível como padrão / native vlan) e subinterfaces participando de pontes com adaptadores do lado do host da VM, todos marcados. Ainda assim, as VMs não podiam acessar diretamente o host, e o switch inteligente L2 e um dispositivo de firewall separado ou o switch L3 sozinho podiam fazer o roteamento entre as rotas e a filtragem de tráfego.

    

Answer 2

Como uma ponte Linux cria uma interface de rede correspondente (por exemplo, br0 ) no host, não acho que haja uma maneira de tornar a ponte completamente inacessível a partir do sistema operacional host. Com sua VM de firewall em execução, brctl show dirá que as interfaces eth0 e vnet0 estão anexadas a ela, mas na verdade está agindo como um comutador três -port: uma porta vai para eth0 , um vai para vnet0 (a VM), e um vai para a interface br0 no host.

Você provavelmente pode configurar algumas regras ebtables para bloquear todos os quadros que vão da interface br0 do host. Essa pode ser a melhor abordagem, mas eu não sei o suficiente sobre ebtables para fornecer detalhes sobre como fazer isso.

Outra opção é simplesmente não configurar endereços IP na interface da bridge, o que deve impedir que aplicativos normais se comuniquem através dela. Ele ainda estará acessível para aplicativos como o Wireshark com privilégios de root (e isso pode ser útil).

Em sistemas baseados em Debian (como o Ubuntu), você pode colocar o seguinte em /etc/network/interfaces :

auto br0
iface br0 inet manual
  bridge_ports eth0
  bridge_stp off

O "manual" significa "não atribuir endereços ao trazer a interface para cima"; Ele é destinado a configurações em que algo mais atribuirá um endereço mais tarde, mas também funciona quando você simplesmente não quer um endereço.

A única exceção é um endereço IPv6 link-local, que é atribuído automaticamente pelo kernel, e não pelos scripts de configuração de rede da distribuição, de modo que você obtém um mesmo com a configuração "manual". Você pode evitar isso desabilitando o IPv6 completamente na interface. Crie um arquivo em /etc/sysctl.d e coloque isso nele:

net.ipv6.conf.br0.disable_ipv6=1

(Seria bom se você pudesse desabilitar completamente o IPv4 na interface também, mas não há nenhuma opção correspondente para isso.)