Securizar SSH mediante Latch en Raspbian.

Hola amantes de la seguridad!!

En esta entrada vamos a ver como instalar Raspbian en la Raspberry Pi y securizar el servicio ssh para evitar posibles ataques mediante Latch y Fail2Ban.

Para quien no conozca la Raspberry Pi dejo unos enlaces con información:

• Web Oficial: https://www.raspberrypi.org/
• Info e historia: https://es.wikipedia.org/wiki/Raspberry_Pi
• Proyectos: http://www.omicrono.com/tag/raspberry-pi/
• Sistemas Operativos: https://raspberryparatorpes.net/raspberry-pi-sistemas-operativos/

Tenemos dos opciones para la instalación de Raspbian:

• NOOBS: se trata de un instalador de sistemas operativos para Raspberry.

• Descargamos la imagen desde este enlace.
• Lo descomprimimos en la raíz de una tarjeta SD previamente formateada.
• Introducimos la tarjeta en la Raspberry y la arrancamos (enchufamos).

• Basta con elegir el/los sistema/s operativo/s que queramos instalar y pinchar en Install.
• Cuando termine el proceso, nos mostrará un grub donde elegir el sistema operativo.

• RASPBIAN: descargar la imagen directamente.
• Descargamos la imagen del siguiente enlace. 
• A continuación tenemos que "copiar" la imagen en una tarjeta SD de forma que sea booteable. En Windows podemos usar Win32DiskImage, en Linux Startup Disk Creator.

LATCH

Con Raspbian ya instalado, vamos a securizar el servicio SSH con Latch.

Lo primero que necesitamos es crear una cuenta de Desarrollador en la web de Latch. Con la cuenta ya creada y logueados, añadiremos una nueva aplicación indicando un nombre, obtendremos esta pantalla con los datos de la misma.

• Nombre: nombre de la aplicación.
• Id Aplicación: número que identifica la aplicación.
• Secreto: clave secreta, podemos renovarla si creemos que está comprometida.
• Imagen: icono de la aplicación, no debe superar 1Mb de tamaño y se recomienda que esté en formato png de 24 bits sin canal alfa, con unas proporciones 1:1.
• Las opciones OTP y Bloquear tras consultar, solo están disponibles en las cuentas de pago.
• Operaciones: cada una de las acciones incluidas en el servicio y que se quieren proteger.

Añadiremos una operación para proteger el login del servicio SSH. Pinchamos en añadir y le ponemos un nombre. Dejamos la web abierta para copiar algunos datos que necesitaremos para la configuración de Latch.

A continuación descargamos el plugin de Latch para Unix del Github de Eleven Paths. Descomprimimos y nos situamos en la raiz de la carpeta resultante.

Ejecutamos el siguiente comando para instalar el plugin:

./configure prefix=/usr sysconfdir=/etc && make && sudo make install

Tras la instalación, tendremos el módulo pam_latch.so en el directorio /usr/lib. Debemos mover dicho módulo al directorio PAM del sistema operativo, en el caso de Raspbian se encuentra en /lib/arm-linux-gnueabihf/security/.

El siguiente paso es modificar la configuración PAM del servicio SSH, para ello modificamos el archivo /etc/pam.d/sshd añadiendo la siguiente linea:

auth required pam_latch.so config=/etc/latch/latch.conf accounts=/etc/latch/latch.accounts operation=<NOMBRE OPERACION> otp=no

Donde NOMBRE OPERACION es el nombre que pusimos al crear la operación (sshd-login) en la web de Latch.

En la carpeta del plugin de Latch que descargamos anteriormente, hay una carpeta "examples" con ejemplos de los archivos a modificar para cada servicio, echarles un vistazo en caso de tener problemas.

A continuación configuramos el plugin editando el archivo /etc/latch/latch.conf.

• app_id: id de la aplicación.
• secret_key: clave secreta ("Secreto" en la web).
• sshd-login: este es el nombre que le dimos a la operación anteriormente, aquí introducimos el número id de la misma.

Por último configuramos SSH para uso del plugin, esto lo haremos editando el archivo /etc/ssh/sshd_config, añadiendo o modificando las siguientes lineas:

• UserPAM yes
• ChallengeResponseAuthentication yes
• PasswordAuthentication no

Reiniciamos el servicio (sudo service sshd restart) para cargar la nueva configuración.


Con Latch configurado, solo nos falta parear un usuario para así activar o desactivar el acceso a SSH desde nuestro móvil, además recibiremos notificaciones de bloqueo, accesos, etc.
 Instalamos Latch en el móvil desde Google Play, abrimos la aplicación y nos logueamos con la cuenta creada en la web. Añadimos un nuevo servicio y Generamos nuevo código.

Como podéis ver en la captura anterior, tenemos un tiempo para usar el código, usamos el siguiente comando en la terminal de la Raspberry para parear el servicio:  latch -p <CODIGO>

Recibiremos un aviso en el móvil confirmando que el servicio ha sido pareado. Ahora nos aparecerá el nuevo servicio creado en la pantalla principal de la aplicación, desde aquí podemos bloquear o permitir el login SSH.

Ya disponemos de un segundo factor de autenticación mediante Latch. Ni que decir tiene que esto mismo se puede realizar para el login de una máquina, comando sudo, servicio vnc y un largo etc.


FAIL2BAN

Como complemento tenemos Fail2Ban, una aplicación escrita en Python para la prevención de intrusos penalizando las ips que intentan el acceso por fuerza bruta en servidores SSH, FTP, HTTP, etc.

Fail2Ban bloquea las ips que intenten loguearse un determinado número de veces (indicado por el usuario) por un tiempo determinado (indicado por el usuario), evitando así ataques por diccionario.

Su instalación es muy sencilla, descargamos el paquete correspondiente a nuestra distribución Linux desde la web oficial y lo instalamos.

Para configurarlo tenemos que editar dos archivos.

• /etc/fail2ban/fail2ban.conf

 

• loglevel: elegimos los datos que mostrará el archivo log.
• logtarget: ruta y nombre del archivo log.
• pidfile: podemos elegir el número de proceso de fail2ban-server.

•  /etc/fail2ban/jail.conf

• bantime: tiempo en segundos que estará baneada la ip.
• maxretry: número de intentos antes de ser baneado.
• ignoreip: lista de ips que serán ignoradas y por tanto no baneadas.
• protocol: protocolo por defecto (TCP/UDP).

 Éstas son algunas de las opciones disponibles, recomiendo echar un vistazo a todas detenidamente.

Reiniciamos el servicio (sudo service fail2ban restart) y ya lo tenemos todo listo. Para ver el log en tiempo real, podemos hacer uso del comando less +F /var/log/fail2ban.log para ver el archivo completo o tail -f /var/log/fail2ban.log para ver solo las últimas lineas.

Como véis ya he recibido algunos ataques...


Hasta aquí la entrada de hoy, espero os haya gustado y que sea de utilidad.

Un saludo, vasco.

Pentesting Moodle III - Hardening Moodle

Buenas compañeros,

Este post es la tercera parte de la entrada Pentesting Moodle relacionado con la investigación que hice en mi trabajo de fin de grado. En la primera parte Pentesting con Moodle I - Desde fuera el pentesting se basó en un enfoque de caja negra, es decir, sin tener ningún tipo de conocimiento emulando el rol de un posible atacante.

Mientras que en la segunda parte Pentesting Moodle II - Desde dentro se tomo el rol de caja blanca o caja negra con acceso a la parte privada de la aplicación web con mínimos privilegios, es decir, se está emulando el rol de un alumno o de un profesor (una cuenta con un nivel intermedio de privilegios).

En este caso, se basa en la parte más "defensiva" que se tiene que tener en cuenta si uno es administrador de Moodle y desea securizar su plataforma en la medida de lo posible para hacer más complicado la actividad a los "malos".

¡Vamos a ello!

El Hardening o securización es el proceso de asegurar un sistema mediante la reducción de posibles vulnerabilidades en el mismo. Para conseguir ese objetivo, se elimina software obsoleto, servicios, usuarios, actualizaciones, políticas de backup,… Innecesarios en el sistema así como cerrando puertos en el exterior en la medida de lo posible.

Es imprescindible revisar las políticas de seguridad del sitio web pues uno de los principales “agujeros” de los servidores web reside en la instalación por defecto, que es objetivo de los atacantes.

La gran mayoría de exploits se basan en explotar las vulnerabilidades que se detectan en frameworks, plataformas, versiones desactualizadas de programas,…que acompañan en las instalaciones por defecto.

Del mismo modo existen herramientas especializadas en explotar vulnerabilidades asociadas a la instalación por defecto, en este caso Moodle, como por ejemplo el fuzzing Flunym0us.

Por ello, es necesario revisar y modificar en caso necesario dichas políticas para mantener el sitio web lo más protegido posible.

En esta parte se toma el rol de administrador principal. Una vez autenticado, en administración del sitio en la pestaña de seguridad se tienen las siguientes ventanas:

-Políticas del sitio

En este apartado se enumeran el estado de las políticas de seguridad del sitio indicando su descripción y su configuración por defecto.

Como se observa, POR DEFECTO:

 - No se fuerza a los usuarios a loguearse en la aplicación para poder ver contenidos.

 - Opcionalmente, se permite recordar nombre de usuario.

 - No se bloquea la cuenta de usuario tras N intentos consecutivos fallidos de inicio de sesión.

 - Ejecución del script cron.php habilitado mediante vía web. En este caso, es imprescindible habilitar   la opción de ejecutarlo solamente por comandos desde el terminal del servidor, o al menos      establecer una contraseña para su ejecución vía web, pero existe el peligro de sufrir ataques de fuerza   bruta.

-Notificaciones

Analizando su configuración por defecto, se afirma que son correctas y cumplen el criterio de confidencialidad, por lo que no requieren ser modificadas.

-Bloqueador de IP

Posibilita bloquear direcciones IP que soliciten conexiones al servidor. Además permite añadir listas blancas de direcciones IP permitidas, así como la adición de blacklist de direcciones IP maliciosas.


Esta opción es muy útil contra blacklists conocidas y publicadas que pueden ser botnets.

-Seguridad HTTP

Se basa en la configuración HTTP. Posibilita introducir mejoras de seguridad como pueden ser: habilitar cifrado mediante el protocolo SSL/TLS a HTTP pasando a emplear HTTPS o el uso de flags para las cookies, como secure o HTTPOnly.

Para securizar las comunicaciones con el servidor es imprescindible habilitar HTTPS y adicionalmente emplear cookies con flags seguros, por lo que se requiere modificar la configuración por defecto de seguridad HTTP.

Adicionalmente para incrementar el nivel de seguridad del sitio, Moodle permite el uso de CAPTCHA en el proceso de autenticación y registro, así como la incorporación del antivirus Clam AV. En la configuración por defecto no se encuentran habilitados.

Para su habilitación se requieren del registro del sitio web en Moodle.org, así como la inclusión de claves para el CAPTCHA.

Configuración correcta de Moodle

De las opciones de seguridad anteriormente descritas y analizadas, requieren especial atención la configuración correcta algunas políticas del sitio y la seguridad HTTP.

A continuación se muestra una configuración correcta de las políticas mal configuradas que presenta la configuración por defecto que en el apartado anterior se han citado:


Habilitar “Forzar a los usuarios a autenticarse”: De esta manera ya no se permite el acceso a invitados (usuarios sin autenticar: null sesión).

Habilitar “Umbral de bloqueo de cuenta”: Entre 3 y 5 fallos consecutivos permitidos. Para esta configuración hay que aunar la usabilidad y la seguridad (los dos ámbitos tan peleados siempre) puesto que si se bloquean las cuentas de usuario durante un espacio temporal demasiado grande se puede generar una denegación de servicio (DoS) a nivel de usuarios.

Siendo el nuevo resultado del estado de la cuenta para un atacante que emplea fuerza bruta: el bloqueo.

Configurar ejecución de cron: Dos alternativas de mayor a menor seguridad.

-Sólo mediante comandos: Sólo desde el terminal del servidor o conexión SSH se permite la ejecución del script de mantenimiento cron.php. De las dos opciones, ésta es la alternativa más segura.

Siendo el resultado al acceder vía web:

-Ejecución de cron mediante acceso remoto con contraseña: No es la opción más recomendable debido a la criticidad del script. Sin embargo, es mejor opción a la establecida por la configuración por defecto. La seguridad del acceso al script radica en la fortaleza de la contraseña, por lo que no se debe elegir contraseñas típicas como admin, sino contraseñas complejas y robustas.

Siendo el resultado la acceder vía web:

Introduciendo una posible contraseña:

El hecho de establecer una contraseña incrementa la seguridad, sin embargo, como se ha podido observar en las opciones de configuración no se permite algún tipo de bloqueo (por ejemplo a nivel de IP) para prevenir ataques de fuerza bruta.

Adición de mecanismos de securización externos

En busca de mejorar la seguridad de la plataforma Moodle, se incorporan plugins como mecanismos de seguridad, ahora bien al ser extensiones externas hay que asegurarse que estén actualizadas y no contengan vulnerabilidades conocidas, pues sino en lugar de incrementar la securización del sitio, se estará abriendo una vía de ataque.

Como mecanismos de autenticación y gestión de cuentas de usuario se ha empleado el plugin Latch desarrollado por Eleven Paths.

Latch se basa en un factor de autenticación, controla cuándo es posible acceder a los servicios digitales a un usuario. Permite implementar un “pestillo” de seguridad, tal que se puede bloquear temporalmente funcionalidades del servicio como el mecanismo de inicio de sesión.

En este caso, Latch se emplea para controlar cuándo un usuario (administrador, profesor y alumno) pueden acceder a los servicios de la plataforma online Moodle, es decir, en el proceso de autenticación de tal manera que se añade un segundo factor de autenticación.

Para más información sobre descarga e instalación os dejo el vídeo tutorial de ElevanPaths: 

https://www.youtube.com/watch?v=EvxmAJ4SB3o 

Auditoría de securización

Tan importante es conocer las vulnerabilidades de un sistema como llevar a cabo una configuración importante de la configuración por defecto que presenta la mayoría de aplicaciones una vez son instaladas.

En este proyecto Moodle se encuentra implementado sobre el sistema operativo Linux. Como mecanismo de Hardening se emplea Lynis, que consiste en una herramienta muy completa encarga de realizar auditorías de sistemas Linux.


Para más información, os recomiendo revisar la entrada que se hizo en el blog anteriormente Lynis: Auditando la seguridad de tu Linux

Finalmente, os recomiendo la lectura de las recomendaciones de seguridad del equipo de Moodle (citar que las vulnerabilidades que esta plataforma tiene debido a la mala configuración por defecto ni las citan...)

https://docs.moodle.org/all/es/Recomendaciones_de_Seguridad 
https://docs.moodle.org/all/es/Seguridad

Espero que os haya gustado :) ¡Para cualquier cosa, usad el apartado de comentarios!

La mejor defensa es un buen ataque.

NaxHack5