'conntrack' rastreando sessões TCP privadas entre VMs

Question

Temos um par de VMs sendo executadas como roteadores virtuais e pareamento BGP / TCP entre os dois roteadores virtuais (em execução no QEMU / KVM). Cada VM tem uma interface de toque conectada a uma ponte do Linux que possui apenas dois toques como membros.

Tudo funciona muito bem, exceto pelo fato de vermos que o conntrack parece estar relatando as sessões TCP entre essas duas VMs. Inicialmente pensamos que as sessões TCP estavam vazando e que isso era uma falha de segurança, mas o netstat não relata nada. Portanto, parece que não estamos alocando um TCB para isso no sistema operacional host (que está correto); ufa. O tráfego do sistema operacional convidado deve ser transparente para o sistema operacional host, o que parece ser; principalmente.

A razão pela qual esse comportamento do conntrack é um problema é que, se as duas VMs forem reconfiguradas ao mesmo tempo, não haverá ninguém em execução para enviar tráfego nas sessões TCP convidadas para causar uma redefinição do TCP; então nós temos um "vazamento" de conntrack no sistema operacional host. Com o tempo, isso se acumula e, eventualmente, o sistema operacional host fica sem recursos. Nós temos muitas sessões BGP neste teste. Parece que este é um caminho para um sistema operacional convidado para um DoS em um sistema operacional host ...

Este comportamento é válido para conntrack? Esta é uma comunicação privada de VM para VM em uma ponte L2. Por que o Linux deveria estar bisbilhotando e registrando essas sessões TCP? Isso é um bug ou um recurso?

A maioria das abordagens parece envolver iptables para parar isso; nós realmente não queremos ter que pedir ao cliente para fazer isso. Alguma outra sugestão?

    

Answer 1

Sim, esse comportamento é esperado , embora eu não saiba que é o problema que você antecipa. As conexões TCP e UDP na tabela conntrack expiram ao longo do tempo por conta própria. Você pode ver os valores de tempo limite em /proc/sys/net/netfilter/*timeout* e ajustar esses valores por meio de /proc ou sysctl. Note que isso pode ser diferente em kernels mais antigos, talvez /proc/sys/net/ipv4/netfilter/ .

Se isso não for resolvê-lo e você não estiver satisfeito com a solução NOTRACK iptables -t raw -j, será possível desativar o processamento de conexões em ponte pelo iptables definindo

sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=0

ou definindo os mesmos parâmetros em /etc/sysctl.conf . Ambos desabilitarão o tráfego em ponte até o iptables, o que deve ter o efeito de ignorar o conntrack.

Alternativamente, você pode desabilitar o ip_conntrack, se você não o estiver usando, colocando o módulo na lista negra ou desabilitando-o em seu kernel.