O comando iptables -F está me bloqueando do SSH?

Question

Estou criando algumas regras de firewall para um VPS usando o iptables. Meu shell script é parecido com isto:

#!/bin/sh
# My system IP/set ip address of server
SERVER_IP="1.2.3.4"

# Flushing all existing rules
iptables -F
iptables -X

# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Allow SSH on 22
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

# Default policy DROP
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

Se eu executar o comando iptables -F depois de executar este script, serei bloqueado do SSH (posso entrar de novo, mas nunca quero que o SSH seja desativado).

Eu tenho três perguntas.

1. Estou sendo bloqueado pelas políticas de filtro padrão que não estão sendo removidas quando eu executo o comando iptables -F ?
2. Eu não serei bloqueado se fizer iptables -FX ?
3. As políticas de filtro padrão são necessárias se eu adicionar a política de descarte padrão no final do script de shell mesmo assim?

Felicidades!

    

Answer 1

É claro que você está ficando bloqueado - você está definindo a política como negação padrão e depois liberando todas as regras que permitem que você entre.

1. Sim.
2. Não, porque -X tem tanto a ver com a política de encadeamento quanto -F (isto é, nada).
3. Sim, porque as regras podem ser excluídas, liberadas, spindled e mutiladas. Políticas em cadeia não podem.

Answer 2

Você só deve encontrar o ssh temporariamente bloqueado porque você permitiu que "ESTABELECIDO" nas regras. No entanto, a perda temporária de pacotes perturbará o ssh e levará 10 segundos ou mais para o tcp recuperar.

Eu mesmo, eu sempre coloco em um "iptables -A INPUT -m genérico - estado - estado, relacionado" regra no topo imediatamente após o comando flush para que o bloqueio seja muito curto!

você não está usando o conntrack para liberar estados também?

p.s. Se você estiver controlando conexões de um lan relativamente confiável, usar uma regra REJECT no final pode ser mais útil, pois novas tentativas de conexão que falharem serão imediatamente rejeitadas, em vez de terem que expirar.