Fortificar un sistema puede ser algo difícil hoy día. Seguir buenas prácticas, cumplir con los requisitos de mínimo privilegio, mínima exposición, proteger la confidencialidad, la integridad y la disponibilidad de la información, proteger las identidades digitales, utilizar segundos factores de autenticación, y un largo etcétera de condiciones que debemos cumplir para constituir un ecosistema lo más seguro posible. Los sysadmin lo tienen difícil, pero la protección de activos es un trabajo interesante, a la par de constructivo.

En muchas ocasiones, los servicios deben estar expuestos, es decir, éstos tienen que estar disponibles en cualquier instante. Por ejemplo, un servidor web debe encontrarse 24x7 disponible. Por otro lado, los denominados servicios de gestión pueden tener una exposición menor, aunque, generalmente, los tengamos expuestos el mismo número de tiempo. Por ejemplo, un servicio SSH, FTP o, incluso, una VPN, pueden ser servicios críticos y de gestión que no deberían estar expuestos el 100% del tiempo, y sí solo cuando se utilicen, ya que su exposición pone en riesgo gran parte de la organización. Este hecho puede quedar confirmado con SSHowDown Attack y las repercusiones mundiales que esto tuvo.

Tal y como se puede ver en el artículo SSH Brute Force – The 10 Year Old Attack That Still Persists, no es nueva la existencia de bots que se encargan de realizar fuerza bruta sobre servicios SSH expuestos en Internet. Este hecho también se relaciona con lo anteriormente comentado.

El Port-Knocking es una solución conocida, la cual permite minimizar el tiempo de exposición de un servicio. Imagina que un administrador de sistemas quiere acceder al menos una vez al día por SSH a sus sistemas para comprobar que todo está correctamente o realizar cualquier otra gestión. El administrador no quiere que el servicio SSH esté expuesto constantemente. El Port-Knocking le permite configurar la posibilidad de utilizar un puerto no Well-Known, por ejemplo, para "tras golpear" el puerto conseguir que el servicio SSH esté accesible desde Internet. En otras palabras, el puerto 22 de SSH se encontrará cerrado, pero cuando el administrador envíe, por ejemplo, un paquete TCP a un puerto concreto será la señal necesaria para activar el servicio SSH en el puerto 22. El puerto 22 de SSH solo estará abierto mientras dure la conexión del administrador de sistemas. Una vez se cierre dicha conexión, de nuevo el puerto quedará oculto. Esto es interesante, ya que el nivel de exposición queda rebajado al mínimo.

El pasado mes de enero, escribí un artículo en el blog de Eleven Paths explicando e implementando esto, lo cual fue denominado modo paranoia. El Port-Knocking era utilizado como un primer factor de autenticación para la habilitación del servicio SSH. Para ello, se utiliza el valor de la dirección IP de origen y el valor del puerto como si fueran una sola clave. En otras palabras, crearemos una aplicación que estará sniffando todo el tráfico que llega a la máquina y cuando la dirección IP origen y el puerto sean iguales a lo buscado se habrá pasado correctamente el primer factor.

Una vez es validado que la dirección IP y el puerto son los esperados, por ejemplo, dirección IP 8.8.8.8 y puerto 9000, se activa el servicio SSH. Pero esto dejaba a merced de cualquier usuario malintencionado que quisiera jugar con nuestro SSH, la posibilidad de capturarnos el paquete de IP Spoofing y poder levantar nuestro servicio. Por esta razón, se decide meter un segundo factor de autorización, el cual sería Latch.

Cuando el sistema que estamos montando recibe un paquete TCP con las condiciones apropiadas, nuestro sistema consultará el estado del cerrojo o del Latch asociado a la aplicación. En caso de que el cerrojo esté cerrado, el sistema no levantara el servicio SSH, pero si el cerrojo está abierto, significa que estamos autorizando el arranque del servicio SSH, ya que se han cumplido estas dos condiciones.

SSH y Latch Cloud TOTP

Aún podemos fortificar un poco más el uso del servicio SSH. Nuestro compañero Diego Samuel Espitía escribió un artículo sobre cómo integrar Latch Cloud TOTP en un servicio SSH. En primer lugar, es importante tener instalado en el sistema la librería libpam-google-authenticator, la cual puede instalarse a través de apt-get install.

El proceso para llevar a cabo el intercambio de semilla es fácil: ejecutar la instrucción google-authenticator en el terminal. Esto generará un gran QRCode, el cual debe ser leído con la aplicación de Latch.

Desde Latch hay que ir a añadir servicio y pulsar sobre ‘Proteger con Cloud TOTP’. Esto hará que tengamos que leer el QRCode anterior, con la aplicación de Latch. Una vez es reconocido el QRCode, se tendrá listo Latch Cloud TOTP para utilizarlo con nuestro servicio SSH.

Una vez, se generó el QRCode, se puede leer la siguiente información, dónde se almacenará el secreto, el tiempo de refresco, las limitaciones de login, etcétera.

Ahora, hay que configurar la autenticación con el TOTP en el servicio SSH. Para ello, vamos al fichero de configuración de PAM y añadimos esta línea auth required pam_google_authenticator.so. El fichero de configuración se encuentra en /etc/pam.d/sshd. Hay que tener en cuenta que la línea debe ser introducida en la primera línea.

Una vez hecho esto, hay que modificar una directiva del servicio SSH, por lo que para ello debemos editar el fichero /etc/ssh/sshd_config. Buscamos la directiva ChallengeResponseAuthentication y la ponemos a yes. Veremos algo así. Primero nos pide el TOTP y, posteriormente, la clave del usuario.

PoC: Ejemplo final

Al final tenemos lo siguiente:

Como se puede ver, tenemos distintos elementos de seguridad y distintas capas, haciendo que la exposición sea mínima, y utilizando varios factores de autenticación, tanto en el propio servicio SSH, como en el levantamiento del servicio.