iptables: deixe os clientes VPN alcançarem um só host e nada mais

A regra de que precisa está em FORWARD, não em INPUT. Permita um destino para o conjunto VPN, rejeite o resto e depois prove-o com contadores e um comando de reversão.

Dois tickets de suporte que parecem não ter relação acabam por partilhar uma causa. No primeiro, um administrador quer que o servidor aceite ligações apenas do túnel; no segundo, os utilizadores de VPN devem alcançar um único equipamento interno e nada mais. Ambas as políticas pertencem a FORWARD, e ambas são normalmente tentadas em INPUT. O resultado parece uma firewall e comporta-se como um marcador de posição.

Que cadeia responde à sua pergunta

Os pacotes que um cliente VPN envia para um equipamento da LAN, ou mais além para a internet, são reencaminhados pelo núcleo e avaliados em FORWARD. INPUT e OUTPUT só veem tráfego que termina no próprio servidor ou que nele se origina. Por isso, uma rejeição para tudo o que não chega por tun0 protege os próprios ouvintes do servidor e também terminará a sua sessão SSH, a menos que os fluxos estabelecidos sejam admitidos primeiro. Não altera nada quanto ao destino que os clientes podem alcançar.

Dê nome à pergunta primeiro: quem pode alcançar o servidor, ou para onde podem ir os clientes. A maioria das redes precisa das duas respostas, em cadeias diferentes.

Primeiro o estado, depois a permissão, depois a recusa

Uma lista de permitidos só funciona se a permissão específica estiver acima da recusa geral e se o tráfego de retorno for admitido acima de ambas. Insira as regras em posições explícitas e depois exporte a cadeia com iptables -S FORWARD para que a ordem fique visível em vez de pressuposta.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Dois detalhes decidem se isto sobrevive ao contacto com tráfego real. Sem a regra de estado, as respostas às ligações que acabou de permitir são elas próprias avaliadas contra a recusa e descartadas. Uma regra LOG sem limite pode esgotar uma partição pequena na primeira vez que uma análise a atinge, por isso acrescente -m limit --limit 10/min antes de continuar a registar. O REJECT devolve um erro imediatamente, o que é mais amigável enquanto ajusta a lista; o DROP descarta em silêncio, pelo que cada erro se apresenta como um tempo esgotado. Escolha um de propósito e registe a escolha no registo de alterações.

O encaminhamento e o NAT já devem funcionar

A filtragem não pode provar que existe um caminho. Confirme primeiro que o núcleo encaminha sequer, e torne esse parâmetro persistente em vez de um comando pontual na shell. O filtro é a última camada, não a primeira.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Onde fica o mascaramento depende de por onde saem os clientes. Se saírem para uma rede remota através do túnel, a regra NAT fica nessa interface e não na interface WAN. Depois olhe para os contadores: se o contador de POSTROUTING nunca se mexer enquanto o número de admissões em FORWARD sobe, o caminho de retorno está quebrado e o filtro está bem. Essa leitura poupa uma tarde a reescrever regras que nunca foram o problema.

O bloco de correio pertence à cadeia ao lado

Bloquear a porta 25 em INPUT só trava o correio endereçado ao servidor VPN. Um cliente comprometido que envie correio pelo túnel é reencaminhado, pelo que o bloco tem de estar em FORWARD ao lado de 465 e 587. Se uma aplicação reencaminhar correio de forma legítima, coloque o destino e a porta acima dessa regra.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Deixe o contador de rejeições correr uma semana antes de apertar mais alguma coisa. O número que deixa de subir é o fluxo legítimo que acabou de quebrar.

Leia tudo de volta e depois prove a partir de um cliente

Leia o conjunto de regras como o núcleo o relata, não como o seu script o escreveu. Comece por iptables -S FORWARD, depois a tabela NAT com iptables -t nat -L POSTROUTING -n -v, depois a entrada conntrack do fluxo que está a testar. Mantenha um comando de reversão ou um esvaziamento agendado enquanto durar o trabalho. Cada invocação precisa de -w, ou dois administradores colidem no bloqueio do xtables. Nada disso é opcional durante uma janela de alterações.

Termine testando a partir de um cliente dentro do conjunto e de outro fora dele. Uma regra que só funciona a partir da máquina onde a escreveu não é uma política.

Artigos relacionados