☰

O que há de errado com esse firewall iptables de saída?

tag-icon • tag-icon firewall iptables tcpip
O que há de errado com esse firewall iptables de saída?

Eu tenho um servidor de e-mail que gostaria de proteger, permitindo apenas conexões OUTBOUND nas várias portas que ele usa. As regras de entrada estão funcionando bem - elas são tratadas pelo host da VM.

Não consegui descobrir muito sobre isso e, embora o script abaixo quase funcione, ele está descartando pacotes, por exemplo, aqui para a porta 993:

Mar 25 16:08:11 lorina kernel: [200590.714226] IPTables-Dropped: IN= OUT=ens18 SRC=[local IP here] DST=[remote IP here] LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=37253 DF PROTO=TCP SPT=993 DPT=14826 WINDOW=243 RES=0x00 ACK PSH FIN URGP=0

Aqui está o roteiro. Observe que ens19 é a interface LAN (que gostaria de manter aberta) e ens18 é a WAN.

iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A OUTPUT -o ens19 -p all -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

ip6tables -A OUTPUT -o lo -p all -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

while read h; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT &> /dev/null
        iptables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT
done < /usr/local/etc/hosts-to-allow.list

while read p; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
        iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
done < /usr/local/etc/ports-to-allow.list

ip6tables -A OUTPUT -o ens18 -j LOGGING
ip6tables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -o ens18 -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

iptables -A OUTPUT -o ens18 -j REJECT
ip6tables -A OUTPUT -o ens18 -j REJECT

Nota de rodapé interessante

Os pacotes descartados dessas regras podem ser normais e ainda os vejo ocasionalmente. Uma explicação foi fornecida pelo usuário Doug S nos Fóruns de Suporte do Ubuntu:

Seu exemplo de linha de log é para um pacote que não é "NOVO". Você pode saber pelos sinalizadores TCP no final da linha.

Meu melhor palpite é que este é um pacote remanescente de uma sessão TCP já fechada e esquecida, caso contrário, ele teria atravessado o caminho RELATED,ESTABLISHED.

Isso acontece muito com o iptables, dependendo do seu roteador e/ou outras coisas nas viagens dos pacotes. Por que? Porque para conexões TCP, o Linux tende a usar uma sequência de fechamento "half-duplex" onde qualquer lado da sessão pode iniciar o encerramento da conexão através de um único handshake FIN-ACK bidirecional (que coloca a conexão no estado CLOSE_WAIT), em vez de um handshake FIN-ACK completo de 4 vias.

Observe sempre as bandeiras para saber com certeza o que está acontecendo. Eu acho que você está bem

Até agora, no arquivo /var/log/syslog de hoje, tenho 115 entradas que terminam em "RES=0x00 ACK FIN URGP=0", e 93 delas são da minha LAN.

Responder1

Suponho que seu ports-to-allow.list contém a porta 993, e é por isso que você não esperava a entrada de log citada. Observe, entretanto, que você parece estar usando a lista de portas para colocar na lista de permissõesdestinoporta enquanto seu log mostra 993 como ofonteporta do pacote bloqueado.

informação relacionada