Temporariamente negar todo tráfego recebido com firewalld

1

Estou procurando um equivalente a ufw default deny para o firewalld; A ideia é que, depois de fazer o login no SSH para o meu novo servidor, eu quero bloquear todas as novas conexões de entrada para que eu tenha tempo para atualizar e proteger o sistema. Eu uso o CentOS7 com firewalld.

    
por Grobeu 04.11.2016 / 13:45

1 resposta

0

Parece a partir desta postagem de falha do servidor que limitar o tráfego a este nível superior requer regras" ricas ".

Para implementar uma regra avançada que é promulgada na zona padrão que baixa todo e qualquer tráfego IPv4:

firewall-cmd --zone=$(firewall-cmd --get-default-zone) \
  --add-rich-rule='rule family=ipv4 source address=0.0.0.0/0 drop'

Isso emula o comportamento ufw default deny ; para enviar uma mensagem de rejeição de ICMP, altere o drop para reject . A regra acima é específica para o IPv4; para IPv6, use:

firewall-cmd --zone=$(firewall-cmd --get-default-zone) \
  --add-rich-rule='rule family=ipv6 source address=::/0 drop'

Após a investigação, isso adiciona uma entrada ao iptables que vem após as conexões "accept RELATED e ESTABLISHED", para que não quebre a sessão ssh existente. Nos meus testes, a "cadeia" resultante do iptables vai (para uma zona padrão de 'público'):

INPUT -> INPUT_ZONES -> IN_public -> IN_public_deny

Se você espera reinicializar como parte das atualizações, adicione o sinalizador --permanent .

Se você não espera reinicializar como parte das atualizações, use o sinal --timeout , que aceita valores como 5s , 10m ou 15h para "5 segundos", " 10 minutos "ou" 15 horas ", respectivamente. Essa regra será excluída após esse período de tempo limite.

Quando quiser remover a regra que você adicionou, basta executar o mesmo firewall-cmd como antes, mas substituindo --add-rich-rule por --remove-rich-rule ; para um exemplo de IPv4:

firewall-cmd --zone=$(firewall-cmd --get-default-zone) \
  --remove-rich-rule='rule family=ipv4 source address=0.0.0.0/0 accept'

Referência: link

    
por 23.11.2016 / 20:21