O que o -P INPUT ACCEPT significa em relação ao iptables?

Question

Sou relativamente novo no iptables e estou tentando descobrir se configurei meu conjunto de regras adequadamente. Com relação à parte -P INPUT ACCEPT da minha pergunta, estou tentando determinar se isso é válido no contexto das regras que desejo aplicar. Por favor, veja abaixo para mais detalhes.

Eu usei iptables-restore com um arquivo contendo as seguintes regras. Essencialmente, estou tentando permitir o tráfego de loopback, conexões estabelecidas / relacionadas, SSH e HTTP. Todo o outro tráfego deve ser rejeitado.

*filter
:fail2ban-ssh - [0:0]

# Input chain rules
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
# Reject all other inbound traffic
-A INPUT -j REJECT   

# Output chain rules
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Forward chain rules
-A FORWARD -j REJECT                                    

# fail2ban-ssh chain rules
-A fail2ban-ssh -s 146.0.77.33/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -s 62.75.236.76/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -j RETURN

COMMIT

Se eu executar iptables -S , recebo a seguinte saída:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A fail2ban-ssh -s 146.0.77.33/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -s 62.75.236.76/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -j RETURN

Eu fiz um pouco de leitura no iptables, e meu entendimento é que as primeiras linhas (por exemplo, " -P INPUT ACCEPT ") significam essencialmente que a ação padrão se nenhuma das outras regras aplicáveis é aceitar o tráfego (nesse caso, para entrada, encaminhamento e saída).

Se este for o caso, devo colocar explicitamente as seguintes linhas no meu arquivo de regras e restaurar o iptables novamente?

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

Muito obrigado antecipadamente a todos que lerem esta pergunta completa! É um pouco longo, mas achei que seria necessário incluir todos os detalhes acima para explicar adequadamente meu cenário.

    

Answer 1

Para responder à pergunta que você realmente fez, as políticas devem aparecer em um arquivo normal iptables-save , mas não como o argumento para as regras -P .

Em vez disso, eles devem aparecer no início, junto com sua declaração de qualquer cadeia personalizada, com suas políticas, da seguinte forma:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:fail2ban-ssh - [0:0]

O hífen de sua cadeia personalizada é um argumento de política ausente, porque as cadeias definidas pelo usuário não têm políticas.

Observe que, com o seu firewall escrito, se você alterar todas as políticas para DROP , seu servidor terá dificuldades em fazer pesquisas de DNS e muitas coisas falharão imprevisivelmente.

    

Answer 2

A propósito, acabei de despejar suas regras (a INPUT chain) em fffuu para extrair uma versão simplificada. Só mostra quem pode estabelecer conexões:

ACCEPT     all  --  127.0.0.0/8          0.0.0.0/0    
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 80
DROP       tcp  --  146.0.77.33/32       0.0.0.0/0    dports: 22
DROP       tcp  --  62.75.236.76/32      0.0.0.0/0    dports: 22
DROP       all  --  0.0.0.0/0            0.0.0.0/0    
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Você pode ver que sua abordagem fail2ban está realmente quebrada: A segunda regra aceita todas as conexões ssh; as regras número 4 e 5 (as regras DROP) são sombreadas (nunca podem ser alcançadas).

Suponho que sua política padrão seja ACCEPT , que você pode ver como a última regra na listagem simplificada. Como você também pode ver, a política padrão para INPUT não importa aqui porque a segunda última regra já descarta todos os pacotes que não correspondiam a uma regra anterior. Isso é por causa da sua regra -A INPUT -j REJECT .

    

Answer 3

Basicamente, diferente de qualquer bloco fail2ban, suas regras atuais significam que você não tem firewall.
Considere como seu firewall responderia no seguinte cenário:

Você está executando o MySQL ou algum outro banco de dados que está escutando em uma conexão TCP para conexões locais - mas você não quer conexões remotas. Em seguida, uma máquina remota maliciosa tenta acessar um servidor mysql na porta 3306 .
Assumindo que o fail2ban não os bloqueou, a questão é Alguma das suas regras existentes ajudará você? o que dizer:

• -A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable - NOPE
• -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT - NOPE
• -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT - NOPE

etc ... nada corresponde e DROP a conexão para que sua política INPUT se aplique e a conexão seja aceita.
Em seguida, considere o mesmo cenário para todo e qualquer outro serviço em execução na sua máquina - se o fail2ban não tiver sido bloqueado, seu servidor os permitirá entrar.
Então, sim, sugiro que você adicione às suas regras iptables-restore

-P INPUT DROP
# Any unmatched packets  on FORWARD chain will be dropped
-P FORWARD DROP

Nota: embora as regras do iptables normalmente não persistam além de uma reinicialização, uma política o fará. Nesse caso, a regra acima bloqueará uma sessão SSH se não houver regra ACCEPT correspondente que foi carregada depois de uma reinicialização do servidor - ou seja, essa diretiva o bloquearia.
Pessoalmente eu ainda usaria a política de drop, mas algumas pessoas gostam de manter o -P INPUT ACCEPT e usar

-A INPUT DROP

como regra, na parte inferior da sua cadeia INPUT, como uma política "quase". Você tem que ter cuidado com isso e continuar relendo suas regras quando você modifica sua parede de arquivos, mas se você não configurou o iptables para restaurar suas regras na reinicialização, isso significaria que você poderia voltar à sua máquina.