¿Por qué el acceso externo a un servidor a través de SSH se considera inseguro?

En primer lugar, cualquiera que diga "esto no es seguro, pero no sé por qué" está negando completamente el derecho a hablar desde una posición de autoridad sobre el tema.

Algunas personas se han referido a la razón por la cual a menudo se desaconseja abrir un vector de ataque, pero aquí hay algunas cosas que niegan la necesidad de miedo si se usan correctamente:

• VPN en la red, luego SSH al dispositivo
• Utilice un puerto no estándar
• Utilizar pares de claves privadas
• Implementar herramientas como fail2ban
• Denegar inicios de sesión de usuario root

Honestamente, solo una de esas opciones hace que la piratería sea mucho más difícil. Implementar al menos dos significa que puedes usar SSH sin preocupaciones.

Ese contratista de TI realmente debería considerar un nuevo comercio.

Por lo general,

SSH no se considera inseguro en sí mismo, pero es un protocolo administrativo y algunas organizaciones requieren dos o más niveles de control para obtener acceso a una consola administrativa . Por ejemplo, conectarse primero a través de una VPN y luego abrir una sesión SSH que se conecta a través de esa VPN. Esto simplemente proporciona múltiples capas de defensa en profundidad y evita que sus sistemas se vean directamente afectados por las últimas vulnerabilidades de SSH.

Nota: Esta NO es una debilidad en SSH en sí misma y muchas organizaciones seguirán exponiendo SSH en puertos TCP altos para su uso como servidores SFTP y luego tendrán un script para mover datos hacia y desde ese sistema (sin permitir el servidor SSH / SFTP externo para conectarse al resto de su red).

Todos los protocolos eventualmente tienen vulnerabilidades , por lo que si puede requerir el uso de dos diferentes (es decir, IPSEC VPN y SSH) y ser disciplinado acerca de los esfuerzos de remediación cuando se descubren vulnerabilidades, la ventana de tiempo donde se conoce Las vulnerabilidades que existen en ambos protocolos al mismo tiempo en su red deberían ser muy pequeñas. Estadísticamente, el requisito de usar dos protocolos debería reducir la cantidad de tiempo en el que tendría un solo protocolo expuesto con una vulnerabilidad conocida (asumiendo que realmente parchea / corrige las vulnerabilidades).

Como un gráfico de texto deficiente, observe lo siguiente:

Time ---> 

IPSEC ------------------------     ----------------

SSH   ---------       -----------------------------

Versus con solo SSH, o una VPN, por sí misma:

SSH   ---------       -----------------------------

En el primer ejemplo, cuando surgió una vulnerabilidad de SSH, no había una para IPSEC y viceversa, por lo que nunca hubo un momento, en este ejemplo simple, en el que sus sistemas tuvieran vulnerabilidades en ambas capas. Esta defensa en profundidad es lo que protege al sistema detrás de estos protocolos que, en ocasiones, pueden tener vulnerabilidades.

En el segundo ejemplo, SSH en sí mismo, en el momento en que se produce una vulnerabilidad, una violación de la contraseña o cualquier otro problema, un atacante puede acceder directamente a su sistema vulnerable durante la ventana de exposición.

Preguntaría si se está exponiendo algún otro protocolo administrativo y, si es así, puede cuestionar el sesgo de la tecnología, pero lo más probable es que esté en una organización que no permita el acceso directo de ningún protocolo administrativo desde Internet.

  

Pedí una explicación y, desafortunadamente, no la entendí. El contratista dijo que SSH no estaba seguro, pero no sabía por qué.

     

¿Por qué SSH es inseguro? Parece que me perdí algo durante nuestra conversación que quiero entender desesperadamente.

Tratar la seguridad como un binario "seguro" o "no seguro" refleja una mala comprensión de la seguridad; la seguridad es siempre un continuo, y nada es perfectamente seguro.

El contratista en cuestión parece tener una gran falta de información acerca de SSH si él / ella ni siquiera puede explicar por qué SSH es inseguro, pero cree firmemente que sí. La ignorancia engendra miedo, y mi conjetura es que el contratista está reaccionando al miedo en lugar del conocimiento.

SSH no es menos seguro que las VPN de los principales proveedores. Las VPN también tienen vulnerabilidades de seguridad y no están "hechas de magia". Sabemos esto por las diversas filtraciones de la NSA, y no hay razón para creer que estas vulnerabilidades están en manos de la NSA.

La verdadera pregunta se reduce a la necesidad de acceso frente a la necesidad de seguridad, no de un protocolo sobre otro. El acceso remoto probablemente disminuirá su seguridad un poco. Dos métodos de acceso remoto disminuirán aún más su método de seguridad. Si habilita uno o más métodos de acceso remoto debe ser juzgado por las compensaciones involucradas, no por mantener un falso sentido de "seguridad" como un concepto binario.

¿Qué es exactamente inseguro?

Para decirlo brevemente, "¿Por qué el acceso externo a SSH se considera inseguro?" : no es "SSH" lo que no es seguro, es el " acceso externo " parte de tu pregunta, que es.

SSH es solo un medio técnico, entre otros, para abrir su red interna al mundo exterior (lo cual es altamente riesgoso). Se puede usar, ya sea de manera independiente o asociada a otras tecnologías, para implementar su política de acceso remoto.

La política de acceso remoto es la definición formal que indica quién puede acceder a qué, cuándo y desde dónde, define todas las reglas que luego se implementarán utilizando varios controles técnicos que, a su vez, proporcionarán los servicios adecuados de autenticación, autorización y auditoría. . Todo esto, por supuesto, debe estar debidamente documentado y mantenido.

Por supuesto, podría continuar sin todas estas cargas administrativas y de mantenimiento, pero aquí está el punto: tomar ese atajo es precisamente lo que sería inseguro en su pregunta.

Entonces, ¿por qué el acceso externo a SSH se considera inseguro? porque costaría demasiado implementarlo adecuadamente en relación con el retorno de la inversión esperado por la empresa.

Pregunta de coste

El costo aquí no se trata de comprar software, sino de pagarle tiempo a las personas para que diseñen y configuren este servicio y luego lo mantengan a lo largo del tiempo (aunque estas personas están ocupadas con esto, existen otras tareas que no cumplirán). estar haciendo). Por lo tanto, el costo real dependerá en gran medida del salario, las competencias actuales y la complejidad de su infraestructura actual.

Desde un punto de vista técnico, la autenticación basada en clave y fail2ban es una solución buena y bien documentada. Ejecutar esto en puertos altos también lo sacará de la vista de la mayoría de los robots. Pero esto no impedirá, por ejemplo, que un empleado genuino se conecte a la red interna de la computadora de su familia llena de gusanos, virus y puertas traseras de todo tipo, por lo que, sin saberlo, comprende la red de la empresa. Este es uno de los riesgos que puede tener que abordar.

Desde la perspectiva de la administración, es probable que el "jefe" esté más interesado en ponderar (los riesgos) los diversos riesgos con el rendimiento esperado de las inversiones: ¿cuánto costará configurar y mantener esto? ¿Cuánto le permitirá esto a la empresa ganar o economizar? ¿Cuánto podría costar en caso de que ocurra un desastre?

El riesgo siempre está ahí, con todo. Si logra demostrar que, desde una perspectiva comercial, abrir la red interna (o quizás algunas partes bien definidas de la misma, lo que sería una forma efectiva de reducir el riesgo) será un movimiento rentable para la empresa, habrá hecho la mitad. Si no la mayor parte del viaje. La forma de hacerlo será solo una cuestión de opciones técnicas en función de lo que haya planeado hacer. Pero ciertamente debe resolver la pregunta desde un punto de vista empresarial y funcional antes de entrar en detalles técnicos.

SSH no es inseguro, sin embargo, no es necesariamente una buena práctica exponer a SSH a Internet por temor a un compromiso remoto. Al abrir SSH al mundo, usted invita a visitantes innecesarios que ejecutarán bots en contra de su implementación tratando de obtenerlo. Incluso si no tienen éxito, es innecesario; Si lo logran, podrías sufrir un mundo de dolor. Si el sistema expuesto se ve comprometido, es fácil instalar una puerta trasera persistente y usar este sistema como punto de apalancamiento para atacar a otros en la red.

Si lo expone en Internet, deshabilita la autenticación de contraseña y deshabilita el inicio de sesión de raíz, solo permita el acceso basado en clave. Si debe permitir las contraseñas, no las permita para root y use una solución de 2 factores con contraseñas generadas aleatoriamente.

SSH puede considerarse inseguro porque es posible que su organización no tenga políticas vigentes para controlar las credenciales.

Con el tiempo los empleados van y vienen. También pueden cambiar los roles. Si no hay un mecanismo para deshabilitar el acceso SSH cuando sea necesario, SSH sería inseguro. Esto no indica un problema con el protocolo o el software. Más bien es un problema general aplicable a cualquier acceso remoto.

Cualquier organización que permita el acceso a SSH probablemente querrá evitar que la contraseña se vea afectada por un ataque de diccionario (además de asegurarse de que el software de SSH esté actualizado). Podrían elegir limitar los intentos de inicio de sesión fallidos, tal vez por IP. Podrían elegir no permitir el inicio de sesión de contraseña a través de SSH en absoluto, o como otros mencionaron podrían requerir autenticación de doble factor. Sin embargo, si no tienen una política, la mejor política es no permitir el acceso remoto SSH.

Si el contratista no sabe por qué puede ser inseguro, es posible que estén tomando la mejor decisión para no permitir el acceso remoto.