Versión de SSH desactualizada: ¿cerrando el puerto lo suficiente?

9

recibimos un informe de seguridad semanal para nuestros sitios web. Dijo que nuestra versión de SSH no está actualizada (tenemos OpenSSH_6.7p1, recomiendan 7.5 o posterior).

Como todavía no hay una versión estable para nuestra distribución, pensamos que solo cerraríamos el puerto 22 en todas las máquinas con acceso a Internet (de todas formas, una buena práctica, ¿no?).

Hoy llegó el nuevo informe. Todavía establece 10 problemas con respecto a la versión SSH.

Así que mis preguntas son:

  1. ¿Cómo pueden averiguar la versión de SSH si el puerto está cerrado?
  2. ¿el cierre del puerto no mitigaría con éxito todos los problemas de seguridad de SSH, sin importar la versión?
pregunta Michael Niemand 11.09.2017 - 10:45
fuente

2 respuestas

20

"La versión SSH está desactualizada" no es necesariamente un problema de seguridad. Su recomendación es instalar la última versión, pero no hay ningún beneficio en ejecutar la última versión a menos que desee las últimas funciones. Por seguridad, lo que importa es que tiene todas las correcciones de seguridad aplicadas . Muchas distribuciones aplican correcciones de seguridad a la versión que envían. Por ejemplo, CentOS 6 aún envía OpenSSH 5.3p1 y recibirá actualizaciones de seguridad hasta 2020; CentOS 7, la versión actual, incluye OpenSSH 6.6.1p1. Debian jessie envía OpenSSH 6.7p1 y también recibirá actualizaciones de seguridad hasta 2020, mientras que la última versión se envía OpenSSH7.4p1.

En general, no debe instalar paquetes fuera de su distribución para componentes de infraestructura críticos como OpenSSH. Si lo hace, asegúrese de suscribirse a los boletines de seguridad y de aplicar las actualizaciones de seguridad tan pronto como sea posible. Si acaba de instalar OpenSSH 7.5 ahora y lo olvida más tarde, está debilitando considerablemente su seguridad.

Si obtiene un informe que solo dice "la versión está desactualizada" y ni siquiera intenta determinar si se han aplicado los parches de seguridad adecuados, es un informe incorrecto.

Cerrar el acceso SSH externo en servidores que no los necesitan es una buena idea, independientemente. Una máquina en la que las actualizaciones de seguridad se están retrasando, o una máquina en la que la contraseña o la clave de un usuario se hayan visto comprometidas, podría llevar al atacante a su red. A menudo es una buena idea limitar el acceso externo a una sola máquina de pasarela (o un pequeño conjunto de máquinas para redundancia) donde las actualizaciones y las cuentas se supervisan más de cerca. Cerrar el puerto en el firewall mitigará el problema del acceso directo. El acceso indirecto (donde el atacante ingresa a la red en una máquina que no hace nada importante, y usa eso como un relé para ingresar a una máquina más importante) seguirá siendo una preocupación.

Puede verificar el acceso a SSH por sí mismo ejecutando ssh -v MACHINENAME desde afuera. Si MACHINENAME está ejecutando un servidor SSH y el firewall no lo bloquea, verá una línea como

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3

Eso, mientras escribo, es la versión actual en Debian jessie y está perfectamente bien.

    
respondido por el Gilles 11.09.2017 - 13:40
fuente
3

Puede intentar ejecutar nmap -sV IP -p 22 para verificar si el puerto todavía está abierto. Tal vez es un problema en la presentación de informes? ¿Continúan informando la versión hasta que puedan validar que ha cambiado?

Cerrar el puerto efectivamente mitigará los problemas en SSH. Si SSH todavía está disponible en la red interna, esto podría ser un problema si no puede confiar en la red interna. ¿Debería SSH estar disponible en la máquina? Si no, deshabilítelo. Si estuviera disponible, debería colocarlo en una VLAN separada para su administración.

    
respondido por el Silver 11.09.2017 - 10:50
fuente

Lea otras preguntas en las etiquetas