Regra IPTables para permitir conexões SSH de entrada


11

O objetivo deste script é permitir apenas o tráfego pela VPN, exceto o localhost <-> localhost e o tráfego SSH de entrada. Mas quando executo o script no SSH, sou desconectado e forçado a reiniciar o vm. O que há de errado com o meu script?

#!/bin/bash
iptables -F

#Allow over VPN
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

#Localhost
iptables -A INPUT -s 127.0.0.1/8 -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1/8 -j ACCEPT

#VPN
iptables -A INPUT -s 123.123.123.123 -j ACCEPT
iptables -A OUTPUT -d 123.123.123.123 -j ACCEPT

#SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

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

Respostas:


10

A cadeia de saída é responsável por qualquer pacote que sai.

Seu script permite apenas pacotes de saída para encapsular interface, host local e host remoto em 123.123.123.123.

Se você estiver se conectando ao servidor de uma maneira que exija que o daemon SSH envie pacotes para o destino que não seja um dos acima, o tráfego não poderá sair.

Para permitir pacotes de saída do seu daemon SSH para o cliente SSH, você precisa adicionar a seguinte regra:

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Você também pode adicionar critérios de IP de destino à regra acima, se estiver conectando apenas a partir de um único local. Essa regra precisa vir antes da regra final 'DROP any else' para a cadeia de saída.


+1 Isso funcionará e é mais específico do que usar uma regra relacionada e estabelecida (tornando-a mais ou menos útil, dependendo do contexto).
Goldilocks

Ambas as ótimas respostas, eu aprendi muito! Testei a resposta do @SkyDan e funciona bem!
Steven

Nitpick: a cadeia de saída não é responsável pelos pacotes encaminhados .
Björn Lindqvist

13

Sua #SSHregra implica que ssh é uma forma de comunicação unidirecional, que não é. Os dados estão sendo enviados e retornados.

A maneira normal de lidar com isso, já que você não pode saber o número da porta no lado do cliente com antecedência, é permitir conexões consideradas "estabelecidas" ou "relacionadas" a uma conexão estabelecida. Para fazer isso, você precisa:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Antes de suas DROPregras (e de preferência na parte superior, pois as regras são processadas em ordem e essas duas se aplicam à maioria dos pacotes).

Há uma explicação de como uma conexão TCP se torna ESTABELECIDA aqui ; essencialmente, o fato de o servidor responder ao pacote permitido por sua #SSH INPUTregra o faz.


1
Isso não vai funcionar. Estabelecido significa que pacotes em ambas as direções para uma determinada conexão TCP foram vistos. Se você adicionar apenas essa regra, o primeiro pacote de saída ainda será bloqueado.
911414

2
@SkyDan Aqui está uma referência para isso . Observe no diagrama que quando o servidor envia um syn / ack de volta ao cliente após receber o syn de abertura, a conexão é estabelecida, o iptables permitirá que o pacote de resposta seja enviado: "Depois de ver um pacote (o SYN), ele considera a conexão como NEW. Depois de ver o pacote de retorno (SYN / ACK), considera a conexão como ESTABELECIDA ". -> novamente: iptables o pacote de retorno que o servidor deseja enviar, define a conexão como estabelecida e permite a resposta.
Goldilocks

1
Ok, vejo por que isso funcionará. É um pouco obscuro, já que o homem do iptables apenas fala em ver pacotes nas duas direções, nem uma palavra sobre os pacotes de handshake TCP serem uma exceção. Obrigado pela referência!
911414

2
@SkyDan De fato, a lógica não se aplica apenas ao tcp - eu estava errado em -p tcpfazer alguma diferença nesse sentido, e veja a explicação subsequente para o UDP nessa página (é a mesma). O ponto é que o servidor responde sem saber se o iptables permitirá ou não, e quando o iptables recebe essa resposta do servidor no sistema local , agora ele vê tráfego nas duas direções (mesmo que o cliente ainda não o tenha), considera a conexão estabelecida e deixa a resposta sair. O "tecnicismo" aqui depende do firewall estar no meio das duas partes.
precisa

1
Você está correto lá. Alguém provavelmente deve incluir esta informação no homem do iptables.
911414
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.