linux - Packet mangling utilities además de iptables?
networking packet-mangling (2)
Estoy buscando una utilidad de Linux que pueda alterar las cargas útiles de los paquetes de red según un conjunto de reglas. Idealmente, usaría iptables y el módulo netfilter kernel, pero no son compatibles con la manipulación genérica de carga útil: iptables alterará varios campos de encabezado (direcciones, puertos, TOS, etc.) y puede hacer coincidir bytes arbitrarios dentro de un paquete, pero aparentemente no puede alterar datos arbitrarios dentro del paquete.
Un módulo kernel sería una gran ventaja, ya que la eficiencia es una preocupación, pero me complace explorar cualquier otra opción que haga el trabajo.
Gracias por tus ideas!
Actualización largamente vencida:
Elegimos usar el módulo NFQUEUE , que es la última implementación de los módulos QUEUE que sugirió Robert Gamble. Parecía ser bastante simple, con una bonificación de seguridad para permitir que nuestro código se ejecutara en el usuario, no en el núcleo, en el espacio.
La implementación habría sido casi trivial si simplemente hubiéramos querido modificar la carga útil sin cambiar su tamaño. En ese caso, definiríamos una regla de iptables para seleccionar los paquetes "interesantes" para nosotros y les enviaremos un objetivo NFQUEUE . NFQUEUE una función de devolución de llamada que inspeccionaba los paquetes desde NFQUEUE , modificaba los datos según fuera necesario y recalculaba las sumas de comprobación en sus encabezados de TCP e IP.
Sin embargo, nuestro caso de uso implica inyectar caracteres adicionales en la secuencia de datos. Esto tiene el efecto secundario algo obvio de aumentar los números de SEQ / ACK correspondientes en la secuencia de TCP, y el efecto secundario no tan obvio de confundir el módulo de conntrack suficiente como para romper NAT por completo. Después de una gran cantidad de investigaciones, arañazos y experimentación, la solución más conveniente fue deshabilitar el seguimiento de conexiones para estos paquetes en particular (con el objetivo NOTRACK en la tabla sin raw ) y manejarlo en nuestra devolución de llamada. Guarde sus tomates y odie el correo; No me enorgullece en absoluto dejarlo pasar, pero era la única forma de obtener un producto confiable para el cliente antes de la próxima Ice Age. Y es una buena historia Pero realmente aprecio y comparto sus sentimientos más sentidos.
La versión 2 aprovechará nuestra nueva iluminación al reemplazar nuestra devolución de llamada y varias reglas de iptables con un NAT personalizado y / o conntrack helper . Confiamos en que el ejercicio actual nos haya dado suficiente experiencia para crear un módulo kernel que se ajuste orgánicamente a la arquitectura netfilter para resolver los problemas que encontramos.
¡Gracias de nuevo por su interés y sugerencias!
No lo he usado, pero el objetivo de NETfilter QUEUE podría funcionar. Utiliza un socket nflink y una aplicación de espacio de usuario registrada en el socket para realizar las modificaciones de la carga útil.
La página del manual de libipq contiene detalles sobre cómo usar esto y proporciona un ejemplo simple.
Resolución:
Terminamos con un módulo personalizado para netfilter, que es claramente la herramienta "correcta" para el trabajo.