Para algunos fines privados, necesito enriquecer el encabezado HTTP con información adicional (que será manejada por la aplicación en el lado del servidor HTTP). La idea básica era modificar el paquete recibido, enviarlo al destino y no preocuparse por la respuesta. El esquema muy simplificado de rutas de tráfico es
+---+ +------+ +---+
| +<<-----o MDFY +<<------o |
| R | +------+ | S |
| C | | N |
| V | | D |
| o--------------------->>+ |
+---+ +---+
El problema viene con los números TCP SEQ/ACK. Después del protocolo de enlace TCP, el remitente envía un paquete de 4 bytes de longitud, que llega al modificador donde la longitud cambia a 22, luego el paquete llega al receptor y envía el número ACK +23, mientras que el remitente espera +5. Esto sorprende al remitente y la sesión deja de sincronizarse. Veo esto cuando, por ejemplo, pruebo netcat para realizar pruebas: para paquetes no modificados, la sesión se cierra inmediatamente después del intercambio de datos, mientras que para paquetes modificados la sesión se estanca durante mucho tiempo (de hecho, la detengo presionando Ctrl-C).
No veo una manera fácil de lidiar con esta situación. Parece que una vez modificada en el medio, el Modificador debe manejar toda la sesión porque el Remitente no sabe nada sobre la modificación del número de secuencia y dependerá de sus propios números. Hacer esto afectará significativamente el rendimiento y aumentará la complejidad, ya que necesito mantener el estado de cada sesión y modificar cada paquete proveniente de ambos lados para mantener los números SEQ/ACK.
¿Quizás no veo otra forma que no sea escribir mi propio DPI? :-) Se agradece cualquier conocimiento, idea y sugerencia.
Gracias.
Respuesta1
La única opción más sencilla que veo es utilizar un proxy transparente.
En este caso, el cliente envía la solicitud al servidor de destino. El servidor proxy captura la solicitud, agrega el encabezado y crea otra solicitud al servidor de destino. El servidor de destino devuelve la respuesta al proxy, que luego la devuelve al cliente.
El inconveniente aquí es que el servidor no ve la dirección IP original del cliente, sino la dirección IP del proxy.
Luego, para el enfoque MITM a nivel TCP, pueden existir kits de herramientas que implementen la funcionalidad requerida, de modo que no se requiera una implementación completa.
Respuesta2
Esto parece una especie de NAT a medias; y el problema es precisamente que está a medias.
No puede MITM solo en una dirección de un flujo de paquetes TCP: necesita manejar ambos flujos, exactamente para manejar situaciones como esta (la NAT estándar generalmente solo se preocupa por las direcciones/puertos de origen y destino, pero el principio es el mismo; si Si desea manipular paquetes mientras están en tránsito y desea que esta manipulación sea transparente para ambos puntos finales, debe obtenertodobien).
Una vez que empiece a tener todo en cuenta, pronto tendrá una NAT completa: entonces no es necesario reinventar la rueda, hay muchas implementaciones que le permitirán manipular los paquetes como desee.
Las opciones reales disponibles dependerán, por supuesto, del sistema operativo y del software de enrutamiento/firewall que se utilice.