☰

A regra iptables não funciona com AWS NLB e Elastic IP, funciona usando IP público da instância EC2

tag-icon • tag-icon amazon-web-services amazon-ec2 iptables firewall amazon-elb
A regra iptables não funciona com AWS NLB e Elastic IP, funciona usando IP público da instância EC2

Estou um pouco perdido.

Primeiro, algum contexto: tenho uma instância AWS EC2 atrás de um NLB. O NLB está usando um Elastic IP. A instância EC2 está executando um servidor DNS e escutando UDP e TCP 53. O NLB está configurado para TCP e porta UDP 53. A instância está em um grupo de destino e está íntegra aos olhos do NLB (e atendendo solicitações conforme esperado).

Problema que estou tentando resolver: quero garantir a eliminação de todas as consultas DNS para tipo de registro ANY(bem como algumas outras regras para limite de taxa e filtro), por isso adicionei as seguintes iptablesregras:

$ iptables -t raw -I PREROUTING -p udp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 40 -j DROP

$ iptables -t raw -I PREROUTING -p tcp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 52 -j DROP

$ iptables -t raw -I PREROUTING -p udp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 40 -j LOG \
    --log-prefix "BLOCKED ANY: "

$ iptables -t raw -I PREROUTING -p tcp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 52 -j LOG \
    --log-prefix "BLOCKED ANY: "

Agora o problema...

Se eu tentar, dig some.domain -t any @public.ip.of.instanceminha consulta será bloqueada e vejo a entrada de log /var/log/kern.logconforme o esperado.

Se eu tentar, dig some.domain -t any @elastic.ip.on.nlba solicitação não será bloqueada e recebo uma resposta. Nenhuma entrada de log no kern.log.

A parte mais estranha para mim é que tentei tirar o NLB de cena e atribuí o mesmo Elastic IP diretamente à instância. Mesmo resultado - a ANYconsulta enviada para EIPnão é descartada mesmo com as iptablesregras acima em vigor. A mesma ANYconsulta enviada de outra instância usando o IP privado em vez do EIPé descartada conforme esperado.

Eu tentei as mesmas regras nas tabelas nat(também usando a PREROUTINGcadeia) e filter(usando a INPUTcadeia). Estou faltando algo óbvio em minhas iptablesregras?

Alguma outra ideia?

Responder1

Olhando em volta do ServerFault, encontrei esta resposta -iptables descarta pacote por correspondência de string hexadecimalque mostra espaços entre os valores hexadecimais, sugiro tentar isso:

Exemplo dessa pergunta:

$ iptables --append INPUT --match string --algo kmp \
    --hex-string '|f4 6d 04 25 b2 02 00 0a|' --jump ACCEPT

Então mude seus exemplos assim:

$ iptables -t raw -I PREROUTING -p udp --dport 53 -m string \
    --hex-string "|00 00 FF 00 01|" --algo bm --from 40 -j DROP

Responder2

Ok, bem depoismuitoshoras de solução de problemas, parece que a resposta curta é que estava funcionando o tempo todo ...

Executei o tcpdump na instância EC2 atrás do NLB ( tcpdump udp port 53 -X -nn). Então, no meu Macbook (Catalina 10.15.2), executei dig some.domain -t any @elastic.ip.on.nlbe não apenas obtive uma resposta, mas a consulta nunca apareceu na captura de pacotes na instância EC2. Há apenas uma instância EC2 atrás do NLB usando o Elastic IP que usei na consulta dig. Ficando completamente estranho, executei o mesmo comando dig em uma máquina Ubuntu e também em um computador com Windows 10. Ambas as consultas expiraram (filtradas corretamente pelo iptables), eu as vi no tcpdump e a mensagem de log estava em /var/log/kern.log conforme esperado. Volto para o meu Macbook, executo o mesmo comando dig e ele ainda retorna uma resposta e nada no tcpdump... wtf!

Reiniciei meu Macbook, verifiquei pela milionésima vez se estava usando os IPs corretos e a mesma consulta, tentei domínios diferentes e provavelmente uma centena de outras coisas. Não sei por que isso parece retornar uma resposta sem nada na captura de pacotes vindo do meu Macbook.

Então, no final das contas, parece um problema estranhamente isolado (talvez alguma claudicação da Apple acontecendo ...) e não uma confusão estranha de pacotes feita pela AWS ou uma regra de iptables quebrada como eu pensei inicialmente. Portanto, a verdadeira resposta é: experimente em várias máquinas antes de postar no StackExchange.

EDITAR: Para esclarecer. Vejo a consulta no tcpdump do meu Macbook (e atinge o tempo limite conforme esperado) se eu usar o IP público da instância e não o EIP. Só que com o EIP não vejo a consulta e ela retorna uma resposta...

Além disso, não tenho certeza se esta deveria ser uma postagem de resposta ou se eu deveria apenas ter alterado minha postagem inicial. Os mods fazem com ele o que quiserem!

informação relacionada