Un servidor FTP que recibe una conexión TCP a través de un proxy SOCKS ve el par que abrió la conexión saliente del proxy. La negociación SOCKS ocurrió entre el cliente y el proxy; no es una cabecera de identificación adicional entregada a FTP.

Registre la IP y el puerto de origen del par, la dirección y el puerto de destino, el protocolo de transporte y una marca de tiempo precisa con una base horaria clara. Una dirección de salida compartida puede representar a muchos clientes simultáneos, así que la IP por sí sola es una clave de correlación débil.

Emparejar la conexión saliente con una conexión de cliente anterior requiere registros del intermediario y de cualquier traducción de direcciones relevante. Esos registros pueden no existir o puede que ya no estén disponibles. Una captura de paquetes del lado del destino no puede reconstruir una correspondencia ausente.

Las cabeceras de reenvío HTTP son un mecanismo distinto y no acompañan al FTP ordinario. Incluso en HTTP, un campo declarado de cliente original necesita una procedencia confiable; el texto arbitrario que aporta el cliente no establece quién operó una conexión.

Artículos relacionados