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:
1. Un servicio escrito en Ruby,
el cual monitoriza cualquier paquete que llega al equipo y busca una serie de
circunstancias en un paquete, como son la dirección IP de origen, el puerto
destino y que el flag TCP de SYN esté habilitado. Esto provoca que el sistema
sepa que se quiere levantar el servicio SSH, a modo de Port-Knocking.
2. Una vez llega el paquete “clave”,
nuestro servicio escrito en Ruby
comprobará el estado de Latch. Si el
cerrojo se encuentra abierto, se levantará el servicio SSH de cara al exterior,
comenzando el tiempo de exposición del servicio de gestión.
3. El usuario se tendrá que conectar por SSH al servicio y se le
solicitará el usuario y contraseña, o autenticación de clave pública, en
función de lo que esté configurado y, además, un token TOTP, el cual estaremos
generando con Latch Cloud TOTP.
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.
No hay comentarios:
Publicar un comentario