¿FTPS (FTP + S) ofrece mejor seguridad que SFTP en el lado del servidor?

Desde la seguridad que proporcionan en teoría, FTPS y SFTP son similares. En la práctica, tiene las siguientes ventajas y desventajas:

• Con las aplicaciones de cliente FTPS a menudo no se pueden validar los certificados correctamente, lo que efectivamente significa que el hombre en el medio es posible. Con SFTP, los usuarios simplemente omiten información sobre la clave del host y aceptan cualquier cosa, por lo que el resultado es el mismo.
• Pero los usuarios y administradores con más conocimientos podrían usar las claves SSH correctamente y usarlas también para la autenticación, lo que hace que SFTP sea mucho más fácil de usar en comparación con el uso de contraseñas. Y si las contraseñas están prohibidas, entonces esto también es más seguro porque los ataques de contraseña de fuerza bruta ya no son posibles.
• FTP utiliza puertos dinámicos para las conexiones de datos y la información sobre estos puertos se transfiere dentro de la banda. Esto hace que el FTP simple (sin TLS) sea una pesadilla cuando se trata de firewalls, NAT o similares. Con FTPS (FTP + TLS), esto empeora aún más debido a que el cifrado de las aplicaciones auxiliares de conexión de control en el firewall ya no puede descubrir qué puertos deben abrirse. Esto significa que para pasar FTPS necesitaría abrir una amplia gama de puertos, lo que es malo para la seguridad (*). SFTP es mucho mejor porque usa una sola conexión para el control y los datos.
• Los servidores FTP (S) a menudo proporcionan acceso anónimo y los servidores SFTP generalmente no lo hacen. Varios servidores FTP (S) también ofrecen pseudo usuarios, es decir, usuarios tomados de la misma base de datos o similares que no son usuarios reales en el sistema. Si solo tienes usuarios adecuados, esto no importa.
• SFTP usa el protocolo SSH y debe configurar el sistema correctamente para permitir solo el acceso a SFTP y no también el acceso SSH (terminal) o incluso el reenvío SSH. Con FTP, esto es más fácil porque FTP puede hacer solo la transferencia de archivos de todos modos.

(*) Varios comentarios realmente no creen que tener una amplia gama de puertos abiertos sea malo para la seguridad. Así que permítanme explicar esto con más detalle:

• FTP utiliza conexiones TCP separadas para la transferencia de datos. Los puertos que se utilizan para estas conexiones son dinámicos y la información sobre estos se intercambia dentro de la conexión de control. Un servidor de seguridad que no sabe qué puertos están en uso actualmente solo puede permitir un amplio rango de puertos que tal vez se utilice a veces en FTP.
• Estos puertos deben permitir el acceso desde el exterior al interior porque en el modo pasivo de FTP, el cliente se conecta a algún puerto dinámico en el servidor (es decir, relevante para el servidor de seguridad del lado del servidor) y para el modo activo de FTP, el servidor se conecta a un puerto dinámico en el servidor. cliente (relevante para el servidor de seguridad del lado del cliente).
• Tener una amplia gama de puertos abiertos para el acceso sin restricciones desde afuera hacia adentro no es lo que alguien suele considerar un cortafuegos restrictivo que protege el interior. Esto es más parecido a tener un gran agujero en la puerta donde un ladrón podría entrar a la casa.
• Para solucionar este problema, la mayoría de los firewalls emplean "ayudantes" para FTP que analizan la conexión de control de FTP para determinar qué puertos deben abrirse para la siguiente conexión de datos. Un ejemplo es ip_conntrack_ftp para iptables. Desafortunadamente, con FTPS, la conexión de control está (generalmente) encriptada, por lo que estos ayudantes son ciegos y no pueden abrir dinámicamente los puertos requeridos. Esto significa que FTP no funciona o que una amplia gama de puertos deben estar abiertos todo el tiempo.

El administrador del sistema plantea un punto válido. (pero sus habilidades interpersonales pueden necesitar trabajo)

SSH es un protocolo complejo, y openssh implementa muchas funcionalidades. Toda esta funcionalidad ofrece vectores de ataque, y es muy difícil asegurarse de que ninguno de estos vectores sea explotable.

Incluso si openssh no tiene errores (que no lo es), conocer todas las posibilidades correctas para cerrar una funcionalidad no deseada y entender cómo estas opciones pueden interactuar requiere un esfuerzo significativo en sí mismo. Y estas interacciones pueden cambiar de una versión a otra.

Como ejemplo, considere el siguiente fragmento de código sshd_config , que tiene la intención de limitar a ciertos usuarios a solo SFTP (incluso pensamos en bloquearlos a sus directorios principales):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp

Y por supuesto:

% ssh somehost
This service allows sftp connections only.
Connection to somehost closed.

Pero espera ...

ssh -N -L 9000:localhost:80 somehost

Vaya, ahora he reenviado el puerto 80 en somehost al puerto 9000 en mi host. Eso significa que podemos conectarnos al puerto 80 en somehost como si viniéramos de localhost. Probablemente no sea un gran problema para el puerto 80, pero ¿qué pasa con los servicios que solo escuchan en localhost, como servicios administrativos o bases de datos?

Y eso es sólo el reenvío de TCP. Como mínimo, SSH también permite el reenvío X11 y el reenvío de agente SSH, y ni siquiera sé las implicaciones de esos dos.

Usamos mucho ssh / sftp, porque para nuestra situación las ventajas superan estos riesgos. Pero es una preocupación válida que no debe tomarse a la ligera. Terminamos con esto para casos de uso donde solo sftp es suficiente:

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand internal-sftp

Esperamos que esto sea adecuado para asegurar solo el acceso sftp, pero no podemos estar completamente seguros. (sugerencias bienvenidas;)

Ambos protocolos tienen ventajas y desventajas, como se explica muy bien en este artículo de comparación .

Dicho esto, dado que la pregunta está relacionada específicamente con la seguridad, hay algunas consideraciones que deben tenerse en cuenta al elegir qué protocolo es mejor en ciertas condiciones específicas.

FTPS y FTPES utilizan SSL o TLS para cifrar las conexiones de control / datos. La principal ventaja de estos canales seguros es que utilizan certificados X.509, que contienen mucha más información que un simple par de claves (nombre de host, dirección de correo electrónico, nombre de la organización, ISUER (CA), ...) y, por lo tanto, son una mucho más fácil de validar. Pero:

• SSL 1.0 , SSL 2.0 : obsoleto hace mucho tiempo (inseguro)
• SSL 3.0 : recientemente se desaprobó debido a POODLE
• TLS 1.0 : ya no es aceptable para el cumplimiento de PCI
• TLS 1.1 : carece de algunas de las extensiones de TLS 1.2 y tiene soporte limitado para el cliente, no hay razón para usarlo
• TLS 1.2 : estándar actual, hasta ahora considerado seguro / protegido

Y lo anterior solo cubre el protocolo de encriptación del canal, entonces hay consideraciones de seguridad con respecto al protocolo FTP en sí. El comando SITIO , por ejemplo, se ha usado una y otra vez para perpetrar ataques, y el diseño inherente del propio protocolo requiere abrir y NAT múltiples puertos en su firewall (lo que puede convertirse en una pesadilla para administrar ). Además, la mayoría de los firewalls no pueden realizar correctamente las conexiones de datos FTP NAT a menos que el cliente lo solicite y el servidor permita CCC (Clear Control Channel) que anula parte de la seguridad ejecutando la conexión de control sin cifrar.

Por otra parte, tenemos SFTP , que es un subsistema de SSH . El principal desafío aquí es que las claves SSH son "solo claves", no son emitidas por una CA y no se incluye ninguna declaración de emisor o llavero en ellas, por lo tanto, las claves del servidor SSH deben ser confiadas expresamente por el cliente .

Alguien puede argumentar que configurar un servidor SSH para que solo permita SFTP (sin shell, sin comandos, sin túneles de reenvío, sin X11) puede ser difícil. En realidad, eso depende: si está ejecutando Linux y OpenSSH, eso podría ser cierto, pero hay una gran cantidad de servidores SSH / SFTP por ahí que hacen que este tipo de configuración sea una brisa, por lo que no necesariamente lo enumeraré como una falla potencial. a menos que, como dije, se usen Linux / OpenSSH.

Un par de ventajas laterales notables de SFTP, sin embargo, incluyen:

• Intercambio de claves ECDSA : una clave ECDS (X) de 521 bits es equivalente a una clave RSA de 15,360 bits en términos de seguridad, y requiere 9 veces menos ciclos de CPU para el cálculo de firmas
• Inherente secreto hacia adelante : el protocolo SSH puede renegociar la clave de cifrado del canal real en la sesión, y proporciona un secreto hacia adelante inherente, a diferencia de cualquier servidor habilitado para SSL / TLS que requiera trabajo de configuración adicional para lograr esto

Entonces, en última instancia, la elección depende realmente de ustedes, pero el argumento que el administrador del sistema estaba haciendo es descaradamente inválido, y si hay un servidor SFTP que está bien configurado (como se explicó), no hay razón (especialmente) sin motivo relacionado con la seguridad) para cambiar a FTPS (o FTPES).

Muchas personas presentan puntos válidos sobre las diferencias entre los dos protocolos. Pero creo que para sus propósitos, la pregunta realmente es "¿SFTP es lo suficientemente seguro?" En lugar de "¿cuál es el más seguro"? Como usted ha dicho, tiene otras preocupaciones además de la seguridad.

Esto resulta ser un problema difícil de resolver. SSH ha sido utilizado extensivamente y estudiado extensivamente. No se conocen fallas en el diseño del protocolo. Sin embargo, las vulnerabilidades de seguridad a menudo no tienen nada que ver con el protocolo, y todo lo relacionado con la implementación. Después de todo, el SMTP en sí no es "inseguro" y tiene un diseño relativamente simple, pero hace 16 años, la aplicación común de SendMail era uno de los niños del póster de seguridad de software mal implementada, y tenía un agujero tras otro.

El punto es que, incluso si el protocolo está bien diseñado y es simple, la implementación puede ser un nido de complejidad, funciones adicionales y pesadillas de seguridad.

Entonces, creo que se trata más de elegir una buena IMPLEMENTACIÓN que de un buen protocolo. Cualquiera de los dos protocolos está bien, y cualquiera de las implementaciones puede implementarse pobremente.

No estoy completamente familiarizado con FTPS, así que no sé si hay implementaciones bien respetadas. Sin embargo, para SSH, OpenSSH generalmente se considera de alta calidad y fue diseñado teniendo en cuenta la seguridad desde el principio (separación de privilegios, etc.).

Al igual que usted, pensé que ambos eran casi los mismos que recorrí la web en busca de sus diferencias.

Sin embargo, en la vida real, es otra historia. A continuación fue mi experiencia:

1. Para mi NAS, activé la funcionalidad FTPS durante 3 meses. La configuración del cortafuegos estaba bien. Solo tuve que abrir el puerto FTP y algunos puertos más utilizados por la transferencia FTPS. Hasta ahora, bien, no es gran cosa.

2. Después de 3 meses, me imagino, meh, puede ser que también active el protocolo SFTP, ya que es más común y probablemente más fácil de administrar. Entonces sucedió algo interesante. 10 minutos después de abrir el puerto SFTP, mi NAS estaba bajo algunos ataques de fuerza de moretones. El NAS bloqueó automáticamente la IP de ataque después de 10 intentos fallidos de contraseña y me notificó por correo electrónico. Imagínese si el atacante tuviera el control de miles de computadoras con IP diferentes, mi NAS no podría detenerlas a todas. Además, si el personal de nuestra empresa decide configurar una contraseña realmente fácil, la persona que usa el ataque de fuerza de moretones puede eventualmente ingresar a nuestro sistema.

Ahora que deshabilité el SFTP, el ataque se detuvo y me alegro de que nadie esté intentando ingresar a nuestro servidor de archivos.

No, SSH y SSL usualmente usan el mismo código de cifrado. por ejemplo: RSA y AES, pero SSH puede usar DSA. Pero ssh usa el puerto 22. pero los FTP usan los puertos 21 y 22 para FTP y FTP. aunque en mi opinión es mejor configurable, tiene que abrir 2 puertos, lo que no solo es poco práctico considerando los cortafuegos, sino también un riesgo potencial de seguridad, porque tiene que abrir 2 puertos.

La respuesta es un tanto contundente, ya sea de qué manera vas en tu retórica. Los medios del lado del servidor están controlados por la persona que proporciona el archivo y, en teoría, son más seguros si se conocen todas las funciones de seguridad.

Un método del lado del usuario sería el mismo pero para el usuario. En estos días no cuestionamos la relación de los dos. Cada uno debe asegurarse de sus habilidades para protegerse suficientemente. Por lo tanto, los usuarios recurren a una opción de cortafuegos.

Cualquier opción que elija para el usuario puede ser fácilmente anulada por tales medios. Por lo tanto no nos preocupamos por el usuario (destinatario). Esta retórica está obsoleta ahora en este asunto.

Su preocupación debe estar en sus propios valores. Esto significaría el lado del servidor. Usted quiere el control de la información que libera. Cuánta preocupación después de su lanzamiento ya no es prudente. Simplemente no es tu responsabilidad más allá de ese punto. Solo lo que te afecta como consecuencia. Si todavía no tienes datos sobre esto, no tienes ninguna consecuencia.

Una solución realmente controlable sería utilizar una fuente FTP con cifrado, todo por su propio diseño. No confíe en terceros. Pero esto también es obsoleto, ya que es difícil construir sus propias bibliotecas de principio a fin.

Basándose en las terminologías que proporcionó inadecuadamente, desea un simple ssh ftp. Para eso, todo lo que puede hacer es proponer reglas de firewall y configuraciones de iptables (si están en Linux). Parece que estás atascado con WYSIWYG de cualquier manera que vayas.