La regla de iptables no funciona con AWS NLB y Elastic IP, funciona con la IP pública de la instancia EC2

Question

Estoy un poco perdido.

Primero, un poco de contexto: tengo una instancia AWS EC2 detrás de un NLB. La NLB está utilizando una IP elástica. La instancia EC2 ejecuta un servidor DNS y escucha en UDP y TCP 53. El NLB está configurado para el puerto TCP y UDP 53. La instancia está en un grupo objetivo y está en buen estado a los ojos del NLB (y atiende solicitudes como se esperaba).

Problema que estoy tratando de resolver: quiero asegurarme de descartar todas las consultas DNS para el tipo de registro ANY(así como algunas otras reglas para calificar el límite y el filtro), así que agregué las siguientes iptablesreglas:

$ 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: "

Ahora el problema...

Si lo intento, dig some.domain -t any @public.ip.of.instancemi consulta se bloquea y veo la entrada del registro /var/log/kern.logcomo se esperaba.

Si lo intento dig some.domain -t any @elastic.ip.on.nlbla solicitud no se bloquea y obtengo respuesta. No hay entradas de registro en kern.log.

La parte más extraña para mí es que intenté eliminar el NLB de la imagen y asigné la misma IP elástica a la instancia directamente. Mismo resultado: la ANYconsulta enviada a EIPno se descarta incluso con las iptablesreglas anteriores implementadas. La misma ANYconsulta enviada desde otra instancia utilizando la IP privada en lugar de EIPse descarta como se esperaba.

Probé las mismas reglas en las tablas nat(también usando la PREROUTINGcadena) y filter(usando la INPUTcadena). ¿Me estoy perdiendo algo obvio en mis iptablesreglas?

¿Alguna otra idea?

Answer 1

Mirando alrededor de ServerFault encontré esta respuesta:Paquete de caída de iptables por coincidencia de cadena hexadecimalque muestra espacios entre los valores hexadecimales, sugeriría probar eso:

Ejemplo de esa pregunta:

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

Así que cambia tus ejemplos así:

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

Answer 2

Ok, mucho después.muchoshoras de solución de problemas, parece que la respuesta corta es que estuvo funcionando todo el tiempo...

Ejecuté tcpdump en la instancia EC2 detrás de NLB ( tcpdump udp port 53 -X -nn). Luego, desde mi Macbook (Catalina 10.15.2) ejecuté dig some.domain -t any @elastic.ip.on.nlby no solo obtuve una respuesta, sino que la consulta ni siquiera apareció en la captura de paquetes en la instancia EC2. Solo hay una instancia EC2 detrás del NLB que usa la IP elástica que utilicé en la consulta de excavación. Completamente desconcertado, ejecuté el mismo comando de excavación en una máquina Ubuntu y también en una computadora con Windows 10. Se agotó el tiempo de espera de ambas consultas (filtradas correctamente por iptables), las vi en tcpdump y el mensaje de registro estaba en /var/log/kern.log como se esperaba. Vuelvo a mi Macbook, ejecuto el mismo comando de excavación y todavía devuelve una respuesta y nada en tcpdump... ¡qué carajo!

Reinicié mi Macbook, verifiqué por millonésima vez que estaba usando las IP correctas y la misma consulta, probé diferentes dominios y probablemente cientos de cosas más. No sé por qué esto parece devolver una respuesta sin nada en la captura de paquetes proveniente de mi Macbook.

Entonces, en última instancia, parece un problema extrañamente aislado (tal vez algo de cojera de Apple...) y no una extraña manipulación de paquetes realizada por AWS o una regla de iptables rota como pensé inicialmente. Entonces la verdadera respuesta es: pruébelo en varias máquinas antes de publicar en StackExchange.

EDITAR: Para aclarar. Veo la consulta en tcpdump desde mi Macbook (y el tiempo de espera se agota como se esperaba) si uso la IP pública de la instancia y no la EIP. Es solo que con el EIP no veo la consulta y me devuelve respuesta...

Además, no estoy seguro de si esta debería ser una publicación de respuesta o si simplemente debería haber modificado mi publicación inicial. ¡Los mods hacen con él lo que quieran!