Alternativas de puerto SFTP

SFTP, que a menudo se confunde con la abreviatura de "Protocolo seguro de transferencia de archivos", en realidad representa el Protocolo de transferencia de archivos SSH. SFTP fue desarrollado en los primeros días de Internet y se detalla en este Especificación RFC de SFTP. El protocolo SFTP se conocía originalmente como FTP simple (Protocolo de transferencia de archivos). El protocolo FTP admite la transferencia de archivos a través del puerto TCP 21; el puerto TCP 22 se usa para SFTP y el puerto 990 se usa para cifrado implícito TLS/SSL. SFTP es un protocolo básico de transferencia de archivos y, aunque puede ser bastante rápido debido a su simplicidad, no están definidas para el protocolo funciones adicionales como intercambio de archivos, colaboración, autenticación e inicio de sesión único.

Con el tiempo, el protocolo FTP se actualizó para agregar cifrado (SFTP), admitir el cifrado TLS/SSL y mejorar los problemas de firewall/seguridad, por ejemplo. RFC 1579 (febrero de 1994) habilita FTP compatible con cortafuegos (modo pasivo), RFC 2228 (junio de 1997) propone extensiones de seguridad, RFC 2428 (septiembre de 1998) agrega soporte para IPv6 y define un nuevo tipo de modo pasivo.[8].

SFTP

SFTP NAT y problemas transversales de cortafuegos

Normalmente, los proveedores de servicios de Internet bloquean los puertos SFTP para evitar problemas de seguridad y malware al impedir el acceso a archivos a través de los puertos SFTP. SFTP requiere que los puertos 22 o 990 estén abiertos, lo que es propenso a malware, incluidos delincuentes infames como Wannacry, Sasser, Nimda, Petya/NotPetya y más. Si los puertos STFP están abiertos, una computadora infectada buscará en su red Windows recursos compartidos del servidor que acepten tráfico en los puertos TCP 22 o 990, lo que indica que el sistema está configurado para ejecutar SFTP. Si bien los firewalls de aplicaciones web (WAFS) modernos se pueden ajustar para monitorear el tráfico HTTP, el tráfico SFTP no se monitorea tan fácilmente.

SFTP transfiere datos respondiendo del servidor al cliente después de que se haya enviado un comando PORT. Este es un problema para los cortafuegos que no permiten conexiones desde Internet hacia hosts internos. Este es un problema particular con Microsoft IIS que responde con un puerto aleatorio.

Los dos enfoques para resolver este problema son configurar el servidor SFTP para usar el comando PASV o usar una puerta de enlace de nivel de aplicación para alternar los valores de puerto.

Acceso remoto al puerto SFTP

Para facilitar el acceso remoto a los archivos, las empresas a menudo otorgan acceso a los usuarios mediante servidores SFTP. Esto proporciona cierto nivel de acceso remoto; sin embargo, los costos de soporte para capacitar a los usuarios e implementar el software del cliente SFTP son elevados. Además, SFTP no se integra fácilmente en los servidores de archivos existentes ni en Active Directory para presentar una experiencia unificada de intercambio de archivos. Al acceder a archivos de forma remota, el usuario espera acceder fácilmente a sus unidades domésticas y departamentos compartidos existentes a través de una unidad asignada estándar que admita totalmente el bloqueo de archivos, Office y otras aplicaciones. STFP nunca fue diseñado para compartir archivos o colaborar.

Puerto SFTP frente a HTTP/s

HTTP El puerto 443 es un protocolo actualizado que esencialmente corrige los errores en SFTP que hacían que su uso fuera inconveniente para muchas transferencias pequeñas.

SFTP utiliza una conexión de control con estado que mantiene un directorio de trabajo actual y cada transferencia requiere una conexión secundaria a través de la cual se transfieren los datos reales. En el modo "pasivo", esta conexión adicional es de cliente a servidor, mientras que en el modo "activo" predeterminado, esta conexión es de servidor a cliente. Este cambio de puerto SFTP cuando está en modo activo, y los números de puerto aleatorios para todas las transferencias, es la razón por la que los cortafuegos y las puertas de enlace NAT tienen tantas dificultades con SFTP.

La configuración de una conexión de control SFTP puede ser bastante lenta en comparación con HTTP debido a los retrasos de ida y vuelta del envío de todos los comandos requeridos mientras se espera una respuesta, por lo que normalmente la conexión se mantiene abierta para múltiples transferencias de archivos en lugar de desconectarse y volver a conectarse. -establecido cada vez.

HTTP en comparación es apátrida y multiplexa el control y los datos a través de una sola conexión del cliente al servidor en números de puerto bien conocidos, que pasa fácilmente a través de las puertas de enlace NAT y es fácil de administrar y escanear en busca de vulnerabilidades de seguridad para los firewalls.

¿Por qué SFTP podría quedarse corto como solución completa de transferencia de archivos a medida que aumentan los volúmenes de transferencia de archivos?

A medida que crece el volumen de transferencias de archivos, se hacen evidentes las limitaciones de SFTP como solución completa de transferencia de archivos. Las crecientes demandas de incorporar más socios, escalar la infraestructura y resolver problemas técnicos pueden llevar las capacidades de SFTP al límite, lo que podría abrumar a los equipos de TI. Además, la necesidad de mayores medidas de seguridad, un control estricto sobre las transacciones de archivos y una visibilidad sólida para cumplir con los estándares de seguridad y gobernanza puede exceder lo que SFTP por sí solo puede ofrecer.

Para abordar estos desafíos de manera efectiva, las organizaciones pueden encontrar que las soluciones de transferencia administrada de archivos (MFT) ofrecen un enfoque más integral. La utilización de un servicio basado en la nube como Thru, que aprovecha varios protocolos como SFTP, entre otros, puede proporcionar medidas de seguridad mejoradas de un extremo a otro, mecanismos de seguimiento precisos, registros detallados y configuraciones de retención a largo plazo. Además, las soluciones MFT como Thru pueden ofrecer una mayor disponibilidad para garantizar que las operaciones de transferencia de archivos sigan siendo fluidas incluso cuando los volúmenes continúan aumentando.

¿Cómo se autentica un servidor SFTP con un cliente?

Para autenticarse con un cliente, un servidor SFTP inicia un protocolo de enlace TCP de tres vías para establecer una conexión. Este proceso garantiza que tanto el servidor como el cliente tengan acceso al puerto correcto (normalmente 22) en la capa de transporte. Después de esta verificación, el servidor utiliza la autenticación de par de claves SSH para validar la identidad del cliente. El par de claves SSH consta de una clave pública (compartida entre las dos partes) y una clave privada (conocida sólo por el cliente autorizado). Una vez que la autenticación SSH se completa con éxito, la transferencia de archivos se realiza a través de un canal cifrado, con los datos empaquetados en paquetes individuales. Estos paquetes se transmiten y se reensamblan en el extremo receptor para reconstruir el archivo original de forma segura.

Alternativa de puerto SFTP

El protocolo SFTP existe desde 1980 como un mecanismo para transferir archivos. Las empresas, con razón, se mantendrán cautelosas al permitir o considerar los costos de soporte del acceso directo del puerto SFTP a cualquier recurso interno desde redes externas a través del protocolo FTP/SFTP.

Mientras tanto, MyWorkDrive ya convierte los archivos compartidos basados en Windows en archivos seguros. recursos compartidos de archivos al que se puede acceder de forma segura desde cualquier lugar utilizando TCP https/SSL puerto 443 sobre protocolos compatibles con RSA 4096 y TLS 1.2 FIPS altamente encriptados sin las preocupaciones de seguridad o capacitación de SFTP.

La alternativa al puerto SFTP de MyWorkDrive admite trabajadores remotos con nuestro acceso seguro basado en navegador web, Windows Mapped Drive y clientes móviles.

¿Necesita ayuda para planificar su alternativa SFTP? Reserve una llamada y estaremos encantados de ayudarle a planificar su implementación.

Daniel, fundador de MyWorkDrive.com, ha trabajado en varios roles de gestión de tecnología al servicio de empresas, gobierno y educación en el área de la bahía de San Francisco desde 1992. Daniel está certificado en tecnologías de Microsoft y escribe sobre tecnología de la información, seguridad y estrategia y ha sido galardonado con el premio US Patente #9985930 en Redes de Acceso Remoto