nftables (parte 5) - Criar regras de firewall (continuação)


Neste tutorial vamos fazer diferente, vamos criar dentro da mesma tabela, uma cadeia que por padrão permite a entrada de pacotes no servidor local. A deia é ilustrar como este processo funciona e também vamos nos deparar com uma situação onde vamos perceber que a ordem em que as regras são adicionadas importa.
 
Vamos então criar está cadeia incorporada a tabela servidor1, e vamos nomear esta cadeia como in_servidor2. Vejamos abaixo.

 
 

Vamos tentar perceber as imagens acima:
  • primeiro adicionamos a cadeia in_servidor2 à tabela servidor1.
  • Depois listamos as cadeias e regras dentro ta tabela servidor1, notamos lá a presença da cadeia in_servidor2, o que indica que foi adionada com sucesso.
  • por fim, como está cadeia por padrão permite a entrada de pacotes, o teste de conectividade resultou com sucesso.
Vamos adicionar dentro desta cadeia, uma regra que descarta tudo que é pacote e depois fazer novamente o teste de conectividade. 

 

Explicando as duas imagens acima:
  • primeiro colocamos o teste de conectividade em accção, o que numa primeira fase resulta em sucesso.
  • até que adicionamos a regra para descartar tudo que é pacote, daí que o teste de conectividade parou de retonar pacotes o que indica que não é mais possível alcançar o servidor.
  • e não só, também caiu a ligação ssh, com que então teremos que ir até a interface do servidor para adicionar uma regra que permite conexão pela porta configurada para o serviço ssh.
 
Vamos então até a interface do servidor adicionar a porta (30050 neste caso)  ssh.
 

Embora já adicionamos a porta associada ao serviço ssh à nossa cadeia de regras, continuamos sem acesso ao servidor remotamente. Isto acontece porque a ordem inporta, regras dentro de uma cadeia são processadas em ordem sequencial estrita, da primeira à última. Neste caso teriamos que adicionar a regra usando uma função especial que é o insert. Vamos acompanhar abaixo.

O primeiro passo é listar regras exibindo seus "handles" (que podemos chamar identificadores), e para esse feito usamos a opção -a logo após o comando nft.

Segundo a imagem acima:
  • a regra que descarta todos pacotes tem o identificador 22.
  • a regra que permite a entrada de pacotes pela porta associada ao serviço ssh tem o identificador 23.
Vamos agora adicionar está mesma regra de modo que se encontre antes da regra que descarta todos pacotes, quando se fizer a leitura de cima para baixo.
  

A regra foi adicionada com sucesso, temos a regra com o handle 23 duplicada e agora com o handle 24 e ocupando a posição antes da regra com o handle 22, está que por padrão descarta todos pacotes.
E conexão ssh desta vez é feita com sucesso. Veja a imagem abaixo.

Vamos seguir a mesma ideia do exemplo acima, adicionar uma regra que permite a entrada de pacotes icmp. E para que esta regra tenha o efeito desejado, devemos adicionar antes da regra que bloquea/descarta todos pacotes por padrão, seguindo a lógica usada anteriormente.
Para este exemplo vamos fazer difente, vamos adiconar a regra de modo que esta esteja depois da regra com o handle 24, isso porque o nosso objectivo é manter a regra antes da posição da regra que descarta pacotes. Vejamos o comando abaixo.
 


E abaixo segue o resultado do teste de conectividade. Lançamos o teste de conectividade antes de adicionar a regra que até este momento não era possível alcançar o servidor, e depois de adicionar começamos a receber pacotes do servidor. 

Uma nota que podemos tomar para este caso em específico é que, se por acaso usassemos o insert para adicionar a regra antes da regra que bloquea pacotes (handle 22), está regra adicionada ia aparecer na mesma posição, isto poque não tinhamos nenhuma outra regra entre as regras com os handles 22 e 24.

Comentários

  1. Leituras adicionais:

    https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/getting-started-with-nftables#configuring-nat-using-nftables

    ResponderEliminar