Esta publicación trata sobre el endurecimiento de la configuración de SSH
Introducción
SSH se ha convertido en la herramienta estándar para la gestión remota de sistemas basados en UNIX. El demonio SSH (sshd ) está instalado en casi todos los sistemas principales de forma predeterminada. Además, sshd también nos proporciona muchas opciones de configuración.
Nota :Este artículo es una continuación de mi tema anterior sobre Lynis. Aunque he tratado de hacer esto legible por sí solo. Es posible que desee considerar leer el anterior para obtener algo de contexto.
La configuración predeterminada de openssh (la versión de SSH desarrollada por el proyecto OpenBSD) sigue la filosofía de "seguro por defecto", por lo que la mayoría de las configuraciones son seguras por sí mismas. Sin embargo, al realizar el escaneo de auditoría de Lynis, recibí algunas sugerencias sobre las configuraciones. Así que repasemos las sugerencias para fortalecer aún más nuestro demonio SSH. También comentaré si apagar o encender algunos de ellos mejora la seguridad.
Reforzamiento de la configuración de SSH
Las sugerencias incluyen modificar nuestro sshd configuración. Como ruta predeterminada para sshd la configuración es /etc/ssh/sshd_config , ahí es donde debemos buscar.
TCP y reenvío de agentes
Como se puede ver en la captura de pantalla, lynis recomienda que establezcamos AllowTCPForwarding y AllowAgentForwarding en no. Es un buen consejo usar solo lo que se requiere, por lo que debemos deshabilitar esta opción si no la estamos usando. Sin embargo, deshabilitar esto no mejorará la seguridad si un usuario tiene acceso de shell, en cuyo caso puede configurar sus propios reenviadores (como se indica en sshd_config(5) página del manual).
ClientAliveCountMax
ClientAliveCountMax y ClientAliveInterval son dos opciones relacionadas. El recuento máximo, multiplicado por el intervalo de vida del cliente en segundos, determina cuándo una conexión deja de responder. No veo cómo afectaría esto a la seguridad. Tal vez, necesito investigar más. No obstante, bajar el valor no debería doler.
Compresión
SSH nos permite comprimir los datos enviados después de la autenticación a través de esta opción. En módems lentos, la compresión puede mejorar las velocidades de conexión. Sin embargo, en la mayoría de los sistemas modernos, habilitar esto no debería tener ningún efecto. Además, también puede introducirnos a los ataques BREACH como se señala en este comentario de GitHub. Por lo tanto, tomemos lynis' sugerencia.
Nivel de registro
sshd registra mensajes en journald por defecto en la mayoría de las distribuciones GNU/Linux. Esta opción controla el nivel de detalles que se va a registrar. lynis recomienda configurar esto de INFO a VERBOSE, lo que puede ayudar en la resolución de problemas, etc. La página del manual de sshd_config(5) señala, sin embargo, que la configuración a un nivel superior (por ejemplo, DEBUG) puede violar la privacidad de sus usuarios. Por lo tanto, realmente no veo ninguna mejora en la seguridad ajustando esta configuración.
Máx. de intentos de autenticación
Este valor determina cuántos intentos de autenticación se permiten por conexión. Además, cuando los intentos fallidos de conexión alcanzan la mitad de este valor, sshd comenzará a registrar los errores. Ergo, tiene sentido reducir este valor.
Sesiones máximas
El valor de esta opción especifica cuántas sesiones de shell se permitirán por conexión. No creo que uno necesite ssh en un solo servidor varias veces a la vez. Además, también está tmux lo que nos permite hacer la multiplexación que queramos sin abrir múltiples sesiones. Entonces, tiene sentido tomar esta sugerencia.
Puerto
Mi interpretación de esta sugerencia es que debemos establecer el sshd puerto de escucha a algún otro valor. Esto resultará útil para defenderse de la mayoría de las botnets que escanean Internet en busca de máquinas vulnerables en los puertos predeterminados. Sin embargo, cualquiera que conozca los conceptos básicos del mapeo de redes (herramientas como nmap ) sabrá que esto no ayudará. No obstante, establezcamos un valor no predeterminado.
TCP Mantener Vivo
Establecer esta opción en SÍ ayudará al servidor a notar cuando una conexión ha muerto. De esa manera, las sesiones no se cuelgan indefinidamente en el servidor. Por lo tanto, creo que es mejor no deshabilitar esta opción.
X11Reenvío
Aunque, la mayoría de ssh Las sesiones están destinadas a ser solo basadas en texto. Sin embargo, openssh también proporciona la función para abrir aplicaciones GUI en el servidor que se mostrarán en el cliente. La forma en que funciona es que el servidor X abre un canal de regreso al cliente. El problema con esto es que X11 nunca se diseñó pensando en la seguridad. Asume que todos los programas son confiables ya que fueron ejecutados por nosotros. Pero, como señala esta respuesta, con X11Forwarding, el servidor puede controlar al cliente y, por lo tanto, ejecutar comandos de shell en el cliente. Por lo tanto, es mejor que activemos esta función si no la necesitamos.
Conclusión
Como siempre, la seguridad es un tema muy complicado. No siempre podemos saber cuándo un sistema es seguro. Además, la apariencia de seguridad es incluso peor que no tener seguridad.
En este artículo, repasé las diversas configuraciones, incluidos incluso los detalles más pequeños que podrían ayudar a mejorar la seguridad de nuestro servidor ssh. Pero como siempre, fortalezca su sistema según su modelo de amenazas.
Así que ya sabes sobre el endurecimiento de la configuración de SSH