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