IPtables issues - Assistência apreciada

Question

Estou tentando criar um firewall para o meu pi de framboesa. As regras que eu quero são

1. Permitir o SSH recebido - isso funciona

2. Permitir ssh de saída - isso NÃO funciona e é o meu principal problema

3. Permitir entrada e saída VNC - atualmente este semi-funciona onde eu sou capaz de se conectar, mas não posso fazer qualquer ação. Não é realmente uma prioridade
4. Permitir https de saída - posso visitar um site, mas acho que preciso adicionar outra linha de DNS para que isso funcione corretamente na inicialização.
5. Permitir emails enviados - isso funciona
6. Permitir pings de saída e receber uma resposta - isso funciona
7. Largue tudo - Acho que isso funciona porque não consigo fazer o SSH de saída, portanto acredito que o problema esteja na minha regra.

Eu sei que meu ssh funciona em geral, pois sem o firewall carregado eu posso fazer um SSH de saída de um pi para outro.

    #!/bin/sh

    #Flush all rules
    iptables -F

    #Allow incoming and outgoing SSH
    sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    sudo iptables -A OUTPUT  -p tcp --sport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

    #Allow VNC sessions
    sudo iptables -A INPUT -s 10.10.10.1,192.168.0.150 -m state --state NEW,ESTABLISHED -m tcp -p tcp -m multiport --dports 5900:5905,6000:6005 -j ACCEPT
    sudo iptables -A OUTPUT -d 10.10.10.1,192.168.0.150 -m state --state NEW,ESTABLISHED -m tcp -p tcp -m multiport --sports 5900:5905,6000:6005 -j ACCEPT

    #Accept only incoming etstablished and allow new or established outgoing
    sudo iptables -A OUTPUT -o eth0 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
    sudo iptables -A INPUT -i eth0 -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

    #Accept port 587 for email
    sudo iptables -A INPUT -p tcp --sport 587 -j ACCEPT
    sudo iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT

    #Allow ping requests to go out and get a reply
    sudo iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
    sudo iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

    #Drop all other packets and protocols
    sudo iptables -P INPUT DROP
    sudo iptables -P FORWARD DROP
    sudo iptables -P OUTPUT DROP

    

Answer 1

Seu problema com a linha SSH é que você está tentando permitir a porta de origem 22 de sua máquina local. No entanto, quando você se conecta a um servidor SSH remoto, sua máquina não usa a porta 22 para isso. Está usando uma porta aleatória, geralmente no intervalo de portas mais alto. Isso faz sentido porque, se fosse usar a porta 22 para conexões SSH de saída, você só poderia se conectar a um servidor SSH de cada vez.

Para corrigir isso, a maneira mais simples é usar --dport em vez de --sport , permitindo cada conexão que tenha uma porta de destino de 22 (ssh).

sudo iptables -A OUTPUT  -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Por favor, note que você tem que adicionar esta linha em vez de substituí-la, como @ bcs78 apontou nos comentários.

Também é geralmente uma má ideia bloquear o tráfego para a conexão de loopback interna. Alguns programas dependem dessa conexão e não funcionam corretamente sem ela. Adicione isso ao início do seu script:

sudo iptables -A INPUT -i lo -j ACCEPT

    

Answer 2

Adicione, uma vez por cadeia, uma regra stateful que simplifique a maioria das outras regras:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -F

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Além da regra usual de interface lo para permitir todos os serviços locais, remova-o se achar que não é realmente necessário:

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Agora você não precisa duplicar suas outras regras (estou deixando o estado NEW quando estava lá, mesmo que não seja muito útil e não esteja presente de forma consistente):

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -s 10.10.10.1 -m tcp -p tcp -m multiport --dports 5900:5905,6000:6005 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -s 192.168.0.150 -m tcp -p tcp -m multiport --dports 5900:5905,6000:6005 -m conntrack --ctstate NEW -j ACCEPT

iptables -A OUTPUT  -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

Tudo é resolvido pelas duas primeiras regras, não há necessidade de duplicar todas as regras, e agora a direção inicial do fluxo é clara: INPUT ou OUTPUT , apenas uma vez. Portanto, fica mais claro que o --sport 22 para SSH não estava ajudando no caso de saída ( --dport 22 é necessário). RELATED teria sido útil se houvesse udp de regras para respostas de erros icmp relacionadas. Nesse cenário, pode não ser necessário.