FTP es un protocolo de transferencia de archivos heredado que usa canales de control y de datos separados. Mientras el tráfico web y de API moderno está protegido por tokens, TLS, política de sesión y controles WAAP, FTP en la mayoría de las organizaciones todavía opera al nivel de «abrir puerto, comprobar usuario y contraseña». Los flujos de trabajo EDI, las transferencias por lotes, el intercambio de archivos con socios, los puentes mainframe y los sistemas de documentos heredados funcionan por tanto fuera de la visibilidad de seguridad.
La seguridad de red tradicional ofrece dos opciones débiles para FTP. O se abre el puerto 21 y nadie puede ver qué comandos pasan, o se elimina FTP por completo y comienza un proyecto de integración de varios meses. Muchos sistemas heredados no pueden absorber esa transición rápidamente.
Usar FTPS por sí solo tampoco es suficiente. El tráfico puede estar cifrado, pero las preguntas siguen siendo las mismas: qué usuario está ejecutando qué comando, qué archivo se está recuperando o enviando, a qué backend se está accediendo, si la conexión de datos viene del origen correcto y cuánto tiempo lleva abierta la sesión.
El diseño del protocolo FTP crea una superficie de ataque específica. El comando PORT puede dirigir conexiones de datos a direcciones de terceros, las transferencias de servidor a servidor al estilo FXP pueden ser abusadas, y las cuentas anónimas débiles o compartidas pueden permanecer abiertas durante períodos prolongados. Estos riesgos son difíciles de observar en la capa de red; se requiere consciencia de sesión FTP a nivel de aplicación.
La capa del Proxy de Seguridad FTP de TR7 WAAP opera los servicios FTP clásicos — sin eliminarlos — bajo lista blanca de comandos, política por usuario, mitigación bounce/FXP, control de sesión y auditoría forense.
TR7 WAAP trata FTP no como una decisión de apertura de puerto sino como una sesión de aplicación que se autoriza por usuario y se audita comando a comando.
Los comandos FTP como RETR, STOR, DELE, MKD, RMD, LIST, NLST, RNFR, RNTO, SIZE y MDTM se colocan en una lista individual de allow/deny. Los comandos desconocidos o ausentes de la política se rechazan por defecto.
El nombre de usuario FTP puede usarse como clave de política. Los distintos usuarios que se conectan a través de la misma VIP pueden operar con diferentes conjuntos de comandos, diferentes timeouts y diferentes pools de backend.
El origen de la conexión de datos se correlaciona con la conexión de control. Los intentos de PORT dirigidos a direcciones de terceros o el comportamiento de transferencia de servidor a servidor se bloquean por defecto; las excepciones se definen mediante una decisión de política explícita.
Cada sesión, comando y transferencia de archivos se escribe en el log de auditoría. El modo monitor hace visible la ruta completa del archivo; el modo filecopy puede almacenar una copia con marca de tiempo de cada archivo transferido.
El Proxy de Seguridad FTP lleva las debilidades de comandos, usuarios, canal de datos, sesión y auditoría del protocolo FTP clásico bajo el modelo de política WAAP.
TR7 gestiona los comandos FTP estándar como decisiones allow/deny a nivel de política. En un rol de solo lectura, comandos como RETR, LIST, NLST, SIZE, MDTM y STAT permanecen abiertos mientras STOR, DELE, RMD o RNTO pueden denegarse. En un rol de carga, solo se permiten STOR y los comandos de directorio necesarios. Esto garantiza que «tiene acceso FTP» no se traduzca en permisos de archivos ilimitados.
El nombre de usuario se lee en la fase de login y se alimenta en el motor de política WAAP. Dos usuarios que se conectan a la misma VIP pueden operar con diferentes conjuntos de comandos, diferentes duraciones de sesión, diferente profundidad de auditoría y diferentes pools de backend. Esta arquitectura consolida las transferencias de archivos basadas en socios, departamentos o tenants en un único punto de entrada. Los equipos de operaciones definen los límites de seguridad por usuario.
Un usuario puede dirigirse a un pool de backend específico mientras otro se enruta a un pool diferente. Puede usarse el patrón de selección del lado del cliente `user@server`, o TR7 puede resolver el usuario al backend apropiado a través de una tabla central. Esto elimina la necesidad de abrir muchas VIPs separadas para FTP de socios B2B, uso compartido departamental o separación de tenants. El enrutamiento controlado ocurre bajo un único punto de entrada.
Los modos activo y pasivo de FTP se comportan de forma diferente con respecto a la conexión de datos. TR7 correlaciona los flujos PORT y PASV con la sesión para garantizar que el canal de datos se establezca correctamente. El rango de puertos pasivos puede restringirse por política; la IP de origen hacia el backend puede fijarse. Esto reduce los fallos de transferencia para servicios FTP detrás de NAT y firewalls.
En los ataques de bounce FTP el comando PORT intenta dirigir conexiones de datos a un tercer destino. TR7 puede rechazar este comportamiento haciendo coincidir la conexión de datos con el endpoint real de la conexión de control. El comportamiento de transferencia de servidor a servidor similar a FXP puede mantenerse desactivado por defecto. Las excepciones necesarias se definen explícitamente; una brecha de seguridad nunca es el comportamiento predeterminado.
Las sesiones FTP pueden evaluarse por IP de origen, país, ASN, ventana de tiempo o información de usuario. Las conexiones desde fuera de países de socios específicos o rangos de IP corporativos pueden rechazarse. Esto lleva el enfoque de control de acceso usado en el lado web y de API a FTP también. Los flujos de transferencia de archivos heredados se vinculan a la política de acceso moderna.
Las sesiones FTP pueden permanecer abiertas durante largos períodos y consumir sockets en el backend. TR7 puede gestionar límites como el timeout de login, el timeout de inactividad y la duración total de sesión a nivel de política. Puede usarse una duración de sesión predeterminada de 900 segundos como base y ajustarse según sea necesario. Las sesiones inactivas se cierran sin mantener esperando al backend.
Los clientes FTP pueden cambiar de directorio con CWD y luego emitir comandos de archivo relativos. El modo monitor rastrea el directorio de trabajo dentro de la sesión y registra comandos como `RETR file.csv` con su ruta de archivo completa. El registro de auditoría muestra por tanto no solo el comando sino la ubicación real del archivo. La investigación posterior al incidente aclara exactamente qué archivo se recuperó o se envió.
Para necesidades de cumplimiento o forenses, puede escribirse una copia de cada archivo transferido en un área de almacenamiento separada. Los archivos pueden mantenerse en una estructura de directorio basada en fechas y correlacionarse con el log de auditoría. Esto significa que la pregunta «¿qué archivo se envió?» puede responderse no solo con una entrada de log sino con el propio archivo. La evidencia de auditoría se fortalece en sectores regulados.
Cuando se usa FTPS el canal de control está cifrado, pero los comandos deben entenderse para aplicar la política de seguridad. La capa del Proxy de Seguridad FTP de TR7 WAAP termina la sesión FTPS en la capa de seguridad y puede inspeccionar los comandos. Bajo AUTH TLS, el reenvío al backend puede volver a cifrarse o adaptarse al modelo de red interna. La política de certificados y TLS se alinea con el pool de gestión central.
El Proxy de Seguridad FTP se opera junto con el procesamiento de comandos, el ciclo de vida de la conexión de datos, el comportamiento HA, el streaming de auditoría, los límites de recursos y las políticas de retención para cumplimiento.
Cada comando FTP se recibe del canal de control, se parsea, se evalúa contra la lista ValidCommands y la política de usuario. Un comando permitido se reenvía al backend. Un comando rechazado devuelve una respuesta de error compatible con el protocolo (502 o 550); el cliente permanece compatible con el protocolo.
Cuando se ve un comando PORT o PASV, TR7 asocia la conexión de datos con la sesión. Existen conexiones de datos separadas entre el cliente y TR7, y entre TR7 y el backend. Esta estructura hace posible cerrar la sesión de forma controlada si se detecta una violación de política durante una transferencia.
Las nuevas sesiones FTP se abren en el nodo activo con la misma política. Las transferencias de datos grandes en curso pueden interrumpirse en un evento de failover debido a la naturaleza del protocolo; si el cliente admite la reanudación, la transferencia puede reiniciarse o continuarse. Por tanto las transferencias críticas deben probarse en cuanto al comportamiento del cliente antes del despliegue en producción.
Pueden producirse logs separados a nivel de sesión, comando y transferencia. Los logs pueden enviarse al streaming SIEM en un formato estructurado. El modo monitor agrega la ruta completa del archivo a la línea de log; el modo filecopy agrega la ubicación de la copia del archivo almacenada.
El recuento de sesiones concurrentes, las sesiones por usuario, las sesiones por IP, el tamaño de archivo y la tasa de transferencia pueden restringirse todos por política. Esto evita que un único usuario o un trabajo por lotes defectuoso agote la infraestructura FTP. El ancho de banda y el timeout deben planificarse juntos para transferencias de archivos grandes.
La ruta completa, la marca de tiempo, la información de usuario y, si es necesario, una copia del archivo de cada archivo transferido pueden conservarse. La duración de retención se establece según la política de cumplimiento de la organización. Durante una auditoría, el tráfico FTP deja de ser un área oscura.
Una institución financiera o agencia gubernamental puede intercambiar archivos EDI con socios a través de FTP. TR7 enruta cada socio detrás de una única VIP a su propio pool de backend, abre solo los comandos permitidos y coloca cada transferencia bajo auditoría.
Si una plataforma de documentos heredada solo admite carga FTP, TR7 puede colocarse al frente sin tocar el sistema. La política abre solo STOR y los comandos de directorio necesarios mientras rechaza los comandos de eliminación y renombrado.
En las integraciones que recuperan archivos de un sistema mainframe, el usuario puede limitarse a comandos de solo lectura como RETR, LIST y SIZE. STOR, DELE, RNFR, RNTO, MKD y RMD se rechazan, reduciendo el riesgo de modificación de datos.
Cuando un equipo de sanidad o investigación envía conjuntos de datos a socios externos, cada transferencia puede conservarse con filecopy. Los límites de tamaño de archivo, la política por usuario y el streaming de logs SIEM hacen que el proceso de intercambio sea auditable de extremo a extremo.
Lista blanca de comandos, política por usuario, protección bounce/FXP y auditoría forense. Le mostramos una configuración en vivo en su propia infraestructura FTP.