Iptables: Correspondência de pacotes para interface em ponte

Question

Estou construindo uma ferramenta de configuração de firewall baseada em iptables e tentando fazer com que um cenário "bump in the wire" funcione.

Dada uma configuração com eth0 e eth1 em uma ponte br0 e uma terceira interface eth2 :

    |          |         |
   eth0       eth1      eth2
    | == br0== |         |
          |              |
          |              |
         --- linux node ---

Nesse cenário, digamos que eu queira que o tráfego da porta TCP 80 seja descartado se estiver indo para a rede anexada a eth0 , mas permita que ele seja eth1 .

Por isso, estou tentando corresponder de forma confiável os pacotes que saem da interface específica eth0 .

Se eu adicionar a seguinte regra iptables na tabela filter :

-A FORWARD -o br0 --physdev-out eth0 -j LOG

Dado um pacote que se origina de eth1 (a outra metade da ponte), então a regra corresponde muito bem, registrando:

... IN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 ...

No entanto, se o pacote for orignia de eth2 , a regra não será mais compatível.

Parece que o algoritmo de roteamento não pode determinar qual das interfaces interligadas escolher, portanto, o pacote é enviado por ambas as interfaces na ponte.

Se eu adicionar outra regra de log mais promíscua, obtenho a seguinte saída de log para esse pacote:

... IN=eth2 OUT=br0 ...

Meu palpite é que, no primeiro caso, o algoritmo de roteamento pode apenas escolher a outra interface na bridge, já que o pacote não deve sair do jeito que veio. No segundo caso, ele não escolheu uma interface específica e você não recebe nenhuma informação física!

No entanto, se a bridge tiver aprendido o endereço MAC de destino (como mostrado por brctl showmacs br0 ), então ele poderá determinar a interface correta e você obterá o physdev informatino novamente.

(Há também um terceiro caso: no qual a bridge é composta por três interfaces às quais isso parece se aplicar, então ainda não é possível estabelecer uma única interface para enviar o pacote, apenas excluindo a interface de origem.)

Então, a pergunta é: como posso combinar de forma confiável os pacotes com os eth0 , independentemente?

Dado o exemplo que dei no início, não basta apenas combinar os pacotes que serão roteados em várias interfaces, uma das quais é eth0 (embora isso seja útil em outros cenários). Quero ser capaz de tratar o tráfego de eth0 e eth1 de forma diferente, permitindo que o tráfego atinja eth1 , mas não eth0 .

    

Answer 1

Razões para o comportamento observado

O motivo pelo qual o iptables não obtém as informações da bridge física quando o pacote chega de uma interface sem ponte é que o pacote nunca esteve perto do mecanismo de bridging, embora neste ponto nós saibamos que estamos enviando o pacote a ponte.

No caso em que o pacote chegou através de uma porta de bridge, mas é uma ponte N > 2, o problema é que a extensão do PHYSDEV do iptables só fornece um valor para "out", então não faz nada Não nos incomodamos em dizer se há dois.

Solução

Use ebtables em vez de iptables. O ebtables OUTPUT chain saberá em qual interface física em ponte ele está enviando pacotes.

No cenário acima, onde você deseja filtrar os pacotes que saem por meio de uma interface específica em ponte ( eth0 ), independentemente de como ela chegou ao sistema, adicione uma regra de ebtables nas seguintes linhas:

-A OUTPUT -o eth0 -j <target>

Em um cenário mais complexo, onde você deseja filtrar pacotes que chegam de uma interface específica e sair por uma interface em ponte, fica mais difícil. Digamos que queremos descartar todo o tráfego de eth2 (sem ponte) para eth0 (como parte de br0 ) precisamos adicionar essa regra a iptables :

-A FORWARD -i eth2 -o br0 -j MARK --set-mark 1234

Isso marcará qualquer pacote que venha de eth2 e esteja vinculado à ponte. Em seguida, adicionamos essa regra a ebtables :

-A OUTPUT -physdev-out eth0 --m mark --mark 1234 -j DROP

Qual será DROP de qualquer pacote marcado pelo iptables (como sendo de eth2 ) que está saindo através da porta de ponte específica eth0 .

Agradecimentos

Obrigado a Pascal Hambourg na lista de discussão do iptables do netfilter por sua ajuda na criação desta solução.