Dónde termina la protección de la VPN camino de un servidor FTP

Una VPN protege un camino, y todo camino tiene un final. Cuando el túnel termina en una puerta de enlace corporativa, la transferencia de archivos continúa desde allí con la protección que ofrece su propio protocolo. Esa distinción decide si una transferencia está protegida de extremo a extremo o solo hasta la puerta de enlace. El indicador Connected no dice nada sobre ninguna de las dos cosas.

Dos ubicaciones, dos caminos restantes

Tome un portátil que se une a la VPN corporativa y luego abre una sesión FTP hacia un servidor interno separado. El túnel se detiene en la puerta de enlace, y el tramo desde la puerta de enlace hasta ese servidor queda fuera de él.

El FTP simple no adquiere cifrado porque sus paquetes hayan llegado por un túnel. En ese tramo restante, los comandos, las credenciales y el contenido de los archivos viajan exactamente como define el protocolo, es decir, en claro. Si eso importa depende de la topología y de qué más protege el tramo, y llamar privada a la dirección no responde la pregunta. El mismo razonamiento vale a la inversa cuando el servidor vive en una red de nube a la que la puerta de enlace llega por otro salto.

Ponga el punto final de la VPN y el servicio FTP en una sola máquina y no hay ningún tramo posterior que preocupar. Esa es otra ubicación, no una prueba de que los procesos, los archivos y las credenciales del host sean seguros.

FTP simple, FTPS y SFTP son tres decisiones

El FTP simple no cifra nada, ni siquiera la contraseña. FTPS añade TLS a FTP, de modo que el canal de control y, cuando se negocia, el canal de datos quedan protegidos. SFTP es un protocolo distinto transportado dentro de SSH, y no es otra forma de escribir FTPS.

El servidor tiene que admitir esa elección, porque un cliente no puede inventar un escucha que no está. Elegir SFTP no convierte un servicio solo FTP en un punto final SSH, y renombrar un marcador o cambiar un puerto no demuestra nada sobre lo que se negoció. Confirme el protocolo tanto desde el lado del servidor como desde el del cliente. El candado de un gestor de archivos es una afirmación sobre la sesión, no sobre el escucha que hay detrás.

Lea la última columna cuando la transferencia importe, porque es donde aparece un cambio de identidad inesperado.

La conexión de datos es una segunda conexión

FTP abre una conexión de control y luego conexiones de datos separadas para listados y transferencias. Un inicio de sesión protegido no dice nada sobre esas conexiones posteriores, salvo que el despliegue exija protección también para ellas.

Con FTPS, el cliente pide un canal de datos protegido mediante un comando concreto, y una política del servidor puede rechazar la alternativa en claro. Verifique que la política lo exija en lugar de suponer que el valor predeterminado del cliente basta. El modo pasivo añade una segunda complicación, porque el servidor anuncia una dirección y un puerto para la conexión de datos. Un cortafuegos o un dispositivo NAT que reescriba o bloquee ese anuncio produce una sesión que se autentica y luego se cuelga en el primer listado.

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

El segundo comando muestra qué presenta el servidor en el canal de control antes de tocar ningún archivo. El tercero muestra si alguna vez se estableció una conexión de datos, que es la diferencia entre un fallo de autenticación y un fallo del modo pasivo.

Las comprobaciones de identidad sobreviven al túnel

Un cliente FTPS valida la identidad de un servidor TLS, y un cliente SFTP valida una clave de host SSH. Ambas comprobaciones pertenecen al protocolo de transferencia de archivos, y ninguna la realiza la VPN.

Esa separación importa cuando algo en medio quiere inspeccionar la sesión. Desactivar TLS para que un dispositivo de red pueda leer los comandos cambia el modelo de protección en lugar de completarlo, y lo mismo vale para aceptar una clave de host sin explicación porque el túnel se levantó. Mantenga la configuración de confianza prevista y obtenga el material correcto del operador. Un túnel que se autentica no dice nada sobre el servidor de su extremo lejano.

El material de clave privada y certificado para estos protocolos es un tercer secreto más, separado de la credencial de la VPN.

Anote lo que verificó realmente

Elija un archivo inofensivo que tenga autorización para mover y anote cuatro hechos sobre el intento: qué protocolo se ejecutó, qué identidad del otro extremo se comprobó, qué camino se pretendía y si la transferencia terminó.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

Un listado de directorio, un inicio de sesión en el túnel y una transferencia terminada son tres observaciones separadas, y solo la última dice que el camino funciona para archivos. Si el diseño confía solo en la VPN para la confidencialidad en el salto restante, escríbalo como la decisión que es. Una nota de aceptación que nombre el salto y su supuesto de confianza vale más que una captura de pantalla de un cliente conectado.