¿Tcpdump omite iptables?

¿Tcpdump omite iptables?

Por error configuré un servidor DNS de resolución abierta, que pronto se usó para una serie de ataques DDoS originados en algún lugar desde/hacia Rusia. Por esa razón bloqueé completamente el puerto 53 en ambos servidores DNS para todos excepto para las IP confiables. Funciona, ya que ya no puedo conectarme a ellos, pero lo que me parece extraño es que cuando ejecuto tcpdump eth1(que es una interfaz en el servidor con Internet público) veo muchos paquetes entrantes del atacante al puerto 53. .

¿Es normal que tcpdump muestre estos paquetes incluso si iptables los descarta? ¿O configuré mal iptables?

Por otro lado, no veo ningún paquete saliente de mi servidor, cosa que sí ocurría antes, así que supongo que el firewall está funcionando. ¿Me sorprende que el kernel no elimine los paquetes por completo? ¿O está tcpdumpconectado al kernel de manera que ve los paquetes incluso antes de que lleguen a iptables?

Respuesta1

Ésta es una buena pregunta.

Como una cuestión de hecho,tcpdumpes el primer software que se encuentra después del cable (y la NIC, por así decirlo) en el caminoEN, y el último en caminoAFUERA.

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Por lo tanto, ve todos los paquetes que llegan a su interfaz y todos los paquetes que salen de su interfaz. Dado que los paquetes al puerto 53 no reciben respuesta, como lo ve tcpdump, ha verificado con éxito que sus reglas de iptables se han configurado correctamente.

EDITAR

Quizás debería añadir algunos detalles.tcpdumpestá basado enlibcap, una biblioteca que crea unsocket de paquete. Cuando se recibe un paquete normal en la pila de la red, el kernelprimerocomprueba si hay un socket de paquete interesado en el paquete recién llegado y, si lo hay, reenvía el paquete a ese socket de paquete. si la opciónETH_P_ALLes elegido, entoncestodoLos protocolos pasan a través del socket del paquete.

libcapimplementa uno de esos sockets de paquetes con la opción activada, guarda una copia para su propio uso y duplica el paquete nuevamente en la pila de la red, donde el núcleo lo procesa de la manera habitual, incluido pasarlo primero afiltro de red, la contraparte del espacio del kernel deiptables. Lo mismo, en orden inverso (es decir, primero netfilter y luego último paso a través del socket del paquete), al salir.

¿Es esto propenso a ser pirateado? Pero por supuesto. Ciertamente existen rootkits de prueba de concepto que utilizanlibcappara interceptar las comunicaciones destinadas al rootkitantesel cortafuegos puede ponerles la mano encima. Pero incluso esto palidece en comparación con el hecho de que una simple consulta en Google revelalaboralcódigo que oculta el tráfico incluso desdelibcap. Aún así, la mayoría de los profesionales piensan que las ventajas superan ampliamente las desventajas al depurar filtros de paquetes de red.

Respuesta2

Hoy practiqué un poco para el análisis de paquetes. Estoy especialmente interesado en IPsec y tcpdump. Entonces encontré esta página web que hablaba sobre la relación entre el tapping y el flujo de paquetes. Creo que podría ser útil para resolver tu confusión.

Figura 9: Solicitud de eco ICMP h1 → h2, recorrido de r1, cifrado+encapsulado: Figura 9

Fuente:Nftables: flujo de paquetes Netfilter y VPN/IPsec

información relacionada