Início / server / Perguntas / 1156197
Accepted
ange
Asked: 2024-03-13 20:30:34 +0800 CST

Ignorar regra de eliminação de nftables

  • 772

tldr; bridge (veja abaixo) não funciona se houver uma queda correspondente em outra tabela (como as regras padrão do firewalld).

Olá,
estou construindo minha própria biblioteca de VM (uma espécie de quickemu ).
Tenho um problema com as regras de firewall para ponte. Comecei com iptables-nft e funcionou bem até testar meus scripts no fedora. Não importa o que eu faça, o firewalld bloqueia tudo. Então optei pelo nftables para tentar ignorar as regras do firewalld diretamente, mas mesmo assim não consigo encontrar uma maneira de fazê-lo funcionar sem excluir as regras do firewalld.

Pelo que entendi, a prioridade afeta apenas a ordem em que as regras são testadas, se houver drop, mesmo no final o pacote é descartado?

Existe uma maneira de contornar esse comportamento que eu não conheço? Tentei pesquisar as marcas, mas não tenho certeza se é a solução certa.

Aqui estão as regras que uso para a ponte (funciona perfeitamente se não houver outra tabela no conjunto de regras):

#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:

table ip QEMU
delete table ip QEMU
table ip QEMU {
  chain input {
    type filter hook input priority filter - 1;

    ct state {established,related} iifname "virbr0" counter accept
  }

  chain forward {
    type filter hook forward priority filter - 1;

    ct state {established,related} iifname "virbr0" counter accept
  }

  chain postrouting {
    type nat hook postrouting priority srcnat;

    iifname "virbr0" counter masquerade
  }
}
firewall

1 respostas

  1. Best Answer

    Nitpicking: apesar de virbr0ser uma interface de ponte, trata-se de roteamento, não de ponte. O firewall acontece no lado do roteamento da ponte: na própria interface da ponte, não nas portas da ponte (o que exigiria um firewall table bridgeem vez de um table ipfirewall). Portanto, a palavra ponte não será mencionada novamente abaixo.

    Quando um pacote é descartado no netfilter, incluindo nftables , ele permanece descartado. Quando um pacote é aceito, ele continuará a atravessar ganchos adicionais, possivelmente fazendo com que esse pacote seja descartado mais tarde, conforme lembrado em nft(8):

    aceitar

    Encerre a avaliação do conjunto de regras e aceite o pacote. O pacote ainda pode ser descartado posteriormente por outro gancho , por exemplo, aceitar no gancho de encaminhamento ainda permite descartar o pacote posteriormente no gancho de pós-routeamento ou outra cadeia base de encaminhamento que tenha um número de prioridade mais alto e seja avaliada posteriormente no pipeline de processamento .

    derrubar

    Encerre a avaliação do conjunto de regras e descarte o pacote. A queda ocorre instantaneamente , nenhuma outra corrente ou gancho é avaliada. Não é possível aceitar novamente o pacote em uma cadeia posterior , pois eles não são mais avaliados para o pacote.

    Isso faz com que ferramentas de firewall tenham um comportamento padrão de descarte e aceitem apenas alguns fluxos (o que é um bom comportamento do ponto de vista de segurança) em vez de ferramentas com um comportamento padrão de aceitação e descarte de alguns fluxos (o que não é tão bom do ponto de vista de segurança) para ocultar a decisão de outras ferramentas de firewall: elas descartam coisas que outras ferramentas teriam escolhido aceitar.

    Portanto, para que duas ferramentas coexistam, geralmente é necessário realizar ações em ambas.

    Para este caso, pode-se dizer ao firewalld para ignorar (ou seja: aceitar ) fluxos relacionados a uma ou mais interface(s) específica(s), de forma que o tratamento desta interface específica permaneça sob o controle de outra ferramenta. Se esse tratamento não for feito em outro lugar, isso poderá abrir uma brecha de segurança, portanto, isso deve ser considerado adequadamente.

    Esta resposta requer firewalld >= 0.9.0 para aproveitar as políticas de firewall conforme introduzidas inicialmente :

    As políticas são aplicadas ao tráfego que flui entre zonas de maneira unidirecional e com estado. Isso permite políticas diferentes dependendo da direção do tráfego.

    +----------+     policyA     +----------+
|          |  <------------  |          |
| libvirt  |                 |  public  |
|          |  ------------>  |          |
+----------+     policyB     +----------+

    A zona é usada entre um lado remoto e o host, as políticas são usadas para roteamento entre zonas. Eles reutilizarão interfaces anexadas a zonas.

    Crie uma nova zona:

    firewall-cmd --permanent --new-zone=local-ignore

    Faça com que esta zona aceite qualquer coisa por padrão:

    firewall-cmd --permanent --zone=local-ignore --set-target=ACCEPT

    Adicione a interface de destino a esta zona:

    firewall-cmd --permanent --zone=local-ignore --add-interface=virbr0

    Isso cuidará do tráfego entre as VMs e o host (depois que as regras forem recarregadas).

    Adicione políticas de firewalld que usarão esta zona, uma vez para entrada e uma vez para saída, como ANYoutro lado e também defina-as para um comportamento padrão de ACCEPT:

    firewall-cmd --permanent --new-policy=local-ignore-from
firewall-cmd --permanent --policy=local-ignore-from --add-ingress-zone=local-ignore
firewall-cmd --permanent --policy=local-ignore-from --add-egress-zone=ANY
firewall-cmd --permanent --policy=local-ignore-from --set-target=ACCEPT

firewall-cmd --permanent --new-policy=local-ignore-to
firewall-cmd --permanent --policy=local-ignore-to --add-egress-zone=local-ignore
firewall-cmd --permanent --policy=local-ignore-to --add-ingress-zone=ANY
firewall-cmd --permanent --policy=local-ignore-to --set-target=ACCEPT

    Finalmente recarregue as regras:

    firewall-cmd --reload

    Isso garante que o tráfego relacionado seja virbr0desimpedido por firewalld .

    Agora a (enorme) mesa nftablesinet firewalld deve coexistir pacificamente com a mesa do OP ip QEMU. O fato de o firewalld estar em execução ou não (ou seja: suas regras foram removidas) não deve alterar o comportamento de nada relacionado ao virbr0. Todas as restrições devem ser tratadas na tabela ip QEMU.

    Atualmente a tabela ip QEMUnão restringe absolutamente nada (não há regra de descarte nem política de descarte), portanto deve ser corrigida corretamente. Não se deve usar uma política de drop ou isso causará novamente o problema que acabou de ser corrigido, na outra direção. Basta descartar qualquer tráfego indesejado relacionado virbr0(especialmente a virbr0) nele.

    Interfaces adicionais podem ser adicionadas à lista de ignorados, por exemplo para adicionar lxcbr0(ou seja: deixar o LXC livre de firewalld ):

    firewall-cmd --permanent --zone=local-ignore --add-interface=lxcbr0
firewall-cmd --reload
    • 1

relate perguntas