Transferencia de archivos segura desde la perspectiva de seguridad de la red

1

Supongamos una red simple con un servidor (Windows) y una estación de trabajo (Windows). Resulta que la pregunta de cómo transferir archivos de forma segura entre los dos no es obvia teniendo en cuenta:

  1. Defino secure en este contexto para evitar que un atacante con control de cualquiera de los dos dispositivos propague su control al segundo. La confidencialidad e integridad de los datos transmitidos es secundaria.
  2. Queremos configurar un filtrado estricto entre los dos dispositivos, utilizando un firewall L4. Por estricto quiero decir que queremos evitar cualquier otro uso que no sea la transferencia de archivos, forzada por el firewall. Piensa en ello como si solo tuviera un firewall entre dos compañías, y fui responsable de la seguridad del enlace entre las dos. Excepto, un hacker tiene el control de una de las dos compañías y trata de controlar a la segunda. Ahora, puedo hacer cumplir el protocolo utilizado ya que la otra compañía cumplirá y limitará el uso de los puertos de red que se abrirán solo al protocolo acordado, de modo que, por ejemplo, solo usará un cliente HTTPS para conectarse al puerto 443.
  3. El protocolo estaría mejor basado en estándares abiertos y no tendría ninguna dependencia de Internet; también, puntos de bonificación si la solución tiene implementación disponible en Windows.
  4. No estoy considerando el riesgo de vulnerabilidad ni en el cliente ni en el servidor.

2. nos impide utilizar algunos protocolos clásicos como SMB , ya que este protocolo no está dedicado a ser un protocolo de transferencia de archivos, sino también a recursos compartidos, control, etc. También nos impide usar SFTP / SCP / rsync over SSH , ya que estos se encapsulan sobre SSH , y no podríamos distinguir entre los dos en un nivel de red. Además, FTPS es horrible en términos de solicitudes de apertura de cortafuegos, ya que toma toda la hostilidad del cortafuegos de FTP .

Estaba pensando en un servidor HTTPS , porque podríamos crear un servidor que sea específico para un propósito , por lo que la propagación de una amenaza se haría más difícil. Pero me gustaría que el cliente también pueda eliminar archivos, por lo que se requerirá cierta lógica y probablemente será necesario mantener una aplicación específica. ¿Coincidiría WebDAV sobre SSL con autenticación Digest con los requisitos de seguridad?

Estoy empezando a sentir que no hay una respuesta fácil excepto decir: necesitamos limitar el énfasis en la seguridad de la red, ya que no hay un protocolo que nos permita garantizar el nivel de seguridad que queremos sin imponer requisitos de seguridad en las máquinas y, por ejemplo, asegurarse de que un servidor SSH esté configurado correctamente para permitir solo SFTP . Esto es una pena, ya que la pregunta original es bastante simple.

    
pregunta xdrrq 31.10.2017 - 11:43
fuente

1 respuesta

1

Desde una perspectiva de Firewall L4, FTPS, HTTPS y WebDAVS son indistinguibles entre sí; SSH, SFTP, SCP y RScync + SSH también son indistinguibles entre sí. Además, desde la perspectiva del Firewall L4, los protocolos TLS son esencialmente los mismos que los protocolos basados en SSH, ambos son protocolos de túnel que pueden llevar cualquier cosa que pongas en ellos. En otras palabras, sí, L4 Firewall es la herramienta incorrecta para el trabajo.

Lo que haría si estuviera en tu situación es ejecutar un servidor git, a través de https, utilizando Git SmartHttp / git-http-backend protocol . Cumple todas las casillas:

  1. Protocolo abierto, implementación de código abierto
  2. Guarda la historia. Puede optar por permitir la eliminación real, permitiendo el empuje forzado, o deshabilitar el empuje forzado y, por lo tanto, requiere el consentimiento explícito de ambos lados para eliminar realmente del historial de confirmación
  3. Transferencia eficiente si la mayoría de las actualizaciones son difiables y lo suficientemente eficientes, incluso si los archivos siempre son completamente diferentes
  4. Protegido con TLS, y mientras se ejecuta a través de HTTPS, puede revertir el proxy con un servidor web (por ejemplo, Apache) si lo desea. Puede agregar cualquier autenticación que desee que se pueda realizar a través de HTTPS utilizando el servidor web.
  5. Puede escribir un enganche previo o posterior a la recepción para agregar cualquier comprobación personalizada y comportamiento adicional.

Mi segunda elección sería git sobre ssh, luego rsync sobre ssh.

  

por ejemplo, asegúrese de que un servidor SSH esté configurado correctamente para permitir solo SFTP.

Esto puede ser más fácil de lo que piensas. Existe una cantidad de software de servidor FTP que solo admite SFTP sin el soporte de shell SSH, por lo que reduciría la posibilidad de configurarlos incorrectamente.

    
respondido por el Lie Ryan 31.10.2017 - 14:05
fuente

Lea otras preguntas en las etiquetas