Port Knocking: Ocultar y mejorar la seguridad en conexiones SSH

Port knocking o golpeteo de puertos es un método que proporciona seguridad frente ataques de servicios de red, consiste en realizar una serie de peticiones de conexión con una secuencia ordenada de puertos para poder habilitar una regla previamente configurada en el máquina remota que nos permita abrir una comunicación única entre cliente/servidor y establecer finalmente una conexión abierta SSH hacia el servidor remoto. El uso de esta implementación puede ser catalogado como seguridad por oscuridad. 

¿Cómo funciona una conexión SSH usando Port knocking? 

1. Tenemos un servidor SSH que expone el puerto por defecto 22 o bien otro un puerto específico como por ejemplo 4422 (será el puerto que se trate en este escenario).
2. Se añade una regla a nivel de firewall del propio servidor para rechazar todas conexiones entrantes sobre el puerto SSH previamente configurado 4422.
3. Para poder conectarnos a este servidor usando una técnica de port kockning de hasta tres "golpeteos" de puertos para establecer una conexión SSH, necesitamos realizar una petición a estos puertos, en este escenario mostraré tres formas de hacerlo (knockd, telnet y nmap).
4. Una vez realizado el knocking de puertos en el orden establecido (que veremos posteriormente en el fichero de configuración) este disparará la acción de ejecutar un comando, este comando no será más que establecer una nueva regla en este caso vía iptables para permitir la conexión SSH únicamente desde la IP origen que realizó la secuencia de golpeteo de puertos y no desde ninguna otra IP alcanzable de la misma red.
5. Finalmente para volver aplicar la regla de bloqueo y restablecer esta configuración al terminar nuestra sesión, se lanzará el golpeteo de puertos de salida de SSH. De modo que la configuración vuelva a restablecerse y vuelva a cerrarse el puerto hacia el exterior.

Configurando Iptables

Bloquear puerto SSH configurado vía Iptables

En este escenario el servidor SSH se ejecuta en un entorno Debian y expone el puerto 4422 (en vez del puerto 22 por defecto).

Añadimos un regla iptables para rechazar todas las conexiones entrantes hacia el puerto 4422 del servidor SSH configurado. 

sudo iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset

Iptables: diferencias entre DROP y REJECT (estado de puertos "filtered" o "closed")

La teoría nos dice que uso de DROP no hará nada con el paquete recibido, simplemente lo descartará sin enviar ningún tipo de respuesta. Al contrario de REJECT donde se genera un paquete de respuesta rechazando la conexión, si no se especifica el tipo de respuesta por defecto este paquete sería un "ICMP Destination port unreachable".

En la práctica esto no es del todo cierto. Cuando la regla es DROP es cierto que el paquete se descarta y no se envía ningún paquete de respuesta, sin embargo una regla DROP anunciará que existe un control de puertos y los escáneres sabrán que se está haciendo uso de un firewall devolviendo un estado de puerto "filtered". Ocurre lo mismo si solo usamos REJECT sin especificar un tipo concreto de respuesta, este responderá con un paquete "ICMP Destination port unreachable" anunciando así el filtrado de dicho puerto.

Si lo que queremos es ocultar el puerto y devolver un estado "closed" como resultado en un escaneo de puertos, haciendo creer que el puerto o servicio que se ejecuta en el lado servidor no se está usando o simplemente no existe, debemos especificar un tipo de respuesta en una regla REJECT. 

Cuando usamos TCP o UDP sobre un puerto la respuesta debe responder con los flags RST/ACK, de este modo estaremos indicando a los escáneres un estado de puerto "closed".

• TCP: iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset
• UDP: iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable

Capturando este tipo de tráfico de red con un sniffer como Wireshark, en la siguiente captura de pantalla se muestran todas las combinaciones posibles para este caso donde se puede ver el tipo de paquete de respuesta que genera según el tipo de regla aplicada en el lado servidor.

Reglas DROP y REJECT con estado "FILTERED" (TCP/UDP)

iptables -A INPUT -p tcp --dport 4422 -j DROP

Figura 1: Estado de puerto "filtered" usando DROP en TCP.

iptables -A INPUT -p udp --dport 4422 -j DROP

Figura 2: Estado de puerto "open|filtered" usando DROP en UDP.

iptables -A INPUT -p tcp --dport 4422 -j REJECT

Figura 3: Estado de puerto "filtered" usando REJECT en TCP.

Reglas DROP y REJECT con estado "CLOSED" (TCP/UDP)

iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset

Figura 4: Estado de puerto "closed" usando REJECT en TCP.

iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable

o

iptables -A INPUT -p udp --dport 4422 -j REJECT

Figura 5: Estado de puerto "closed" usando REJECT en UDP.

Guardado y persistencia de reglas Iptables después de reiniciar la máquina

Instalamos el paquete iptables-persistent.

sudo apt-get install iptables-persistent

Guardamos y cargamos reglas configuradas de Iptables.

sudo netfilter-persistent save
sudo netfilter-persistent reload

Para proporcionar la persistencia de las reglas configuradas de Iptables después un reinicio de la máquina. En el fichero /etc/crontab añadimos la ejecución para cargar las reglas guardas después cada arranque del sistema.

sudo echo "@reboot sudo netfilter-persistent reload &" >> /etc/crontab

Implementación de Port Knocking - knockd

Instalamos el servicio de knockd

sudo apt install -y knockd

Configuración de knockd

Editamos el fichero de configuración de /etc/knockd.conf.

[options]
        #UseSyslog
        logfile     = /var/log/knockd.log

[openSSH]
        sequence    = 7500,8200,9800
        seq_timeout = 5
        command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9300,4500,6200
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT
        tcpflags    = syn

Por cuestiones de monitorización y depuración de posibles errores establecemos un logfile específico para este servicio con el path donde se almacenarán los logs de knockd. Comentamos UseSyslog ya que si mantenemos esto por defecto los logs se almacenarán en el fichero de sistema /var/log/syslog.

Disponemos de dos principales directivas. Una para abrir la conexión SSH (openSSH) y otra para cerrar y restablecer la configuración de la conexión SSH (closeSSH).

Sección openSSH:

• sequence: Se define la configuración secreta de puertos a golpear. Se puede especificar tres o más puertos y su vez indicar el tipo de protocolo, bien sea por tcp o udp. Por defecto se estable a tres puertos en protocolo tcp. En este caso modifiqué los puertos y secuencia en el siguiente orden: 7500,8200,9800.
• seq_timeout: Tiempo de esperará entre la ejecución de un golpeteo a otro de puertos. Por defecto se establece a 5 segundos, aunque podemos aumentarlo si no fuese suficiente. No se recomienda establecer grandes intervalos de tiempo para evitar ataques de fuerza bruta que realizan esta acción de forma automatizada intentando encontrar la combinación correcta de puertos. Una herramienta utilizada podría ser KnockIt - https://github.com/eliemoutran/KnockIt.
• command: Comando que el servidor ejecutará cuando detecte la combinación correcta de puertos previamente golpeados. En este caso se agregará en una nueva regla (iptables -I) en el primer orden de la jerarquía de prioridad de la tabla INPUT de iptables para permitir únicamente desde la dirección IP origen la la conexión hacia el puerto 4422 configurado para este servidor SSH.
• tcpflags: Tipo de paquetes que reconocerá el servidor como válidos para el port knocking (en este caso con un flag syn).

Sección closeSSH:

Los parámetros son los mismos que las anteriores con la diferencia de indicar otro número de secuencia distinta (en este caso: 9300,4500,6200) para ejecutar otra regla en el parámetro de command.

• command: Se eliminará (iptables -D) la regla añadida anteriormente. De modo que el servidor vuelva a "restablecer" con la configuración inicial rechazando todas las solicitudes origen hacia el puerto 4422 de SSH.

Habilitar el daemon knockd

Editamos el fichero /etc/default/knockd. Establecemos START_KNOCKD a valor "1" para habilitar el servicio y en KNOCKD_OPTS indicamos la interfaz de red que que usará el servicio, en este caso enp0s3.

START_KNOCKD=1
KNOCKD_OPTS="-i enp0s3"

Iniciamos el servicio knockd y habilitamos un tipo de inicio automático del servicio en el arranque del sistema.

sudo systemctl start knockd
sudo systemctl enable knockd

¿Cómo conectarse a un servidor SSH usando Port Knocking?

Analizando el escenario actual

• Máquina Debian - Cliente: 10.0.0.23
• Máquina Debian - Servidor: 10.0.0.22

En la siguiente captura se muestra un intento de conexión SSH desde la máquina cliente (10.0.0.23) sin el uso de Port knocking y vemos como la conexión ha sido rechazada.

Si comprobamos el estado de puerto con Nmap vemos que el puerto se muestra en un estado cerrado "closed". Esto es así porque previamente habíamos especificado el tipo de respuesta en REJECT con un tcp-reset el cual nos devuelve un paquete RST/ACK (ver figura 1 para más detalles).  

Si revisamos la configuración de reglas de iptables en la máquina servidor (10.0.0.22) vemos como hay una regla que rechaza cualquier tipo de conexión por el puerto 4422 desde cualquier IP origen.

Figura 6: Intento de conexión SSH usando knockd sin el uso de secuencia Port Knocking.

Opción 1: usando knock con Port Knocking

Desde la máquina cliente instalamos knockd. Para conectarnos al servidor remoto ejecutamos lo siguiente.

$ knock -v 10.0.0.22 7500 8200 9800
hitting tcp 10.0.0.22:7500
hitting tcp 10.0.0.22:8200
hitting tcp 10.0.0.22:9800

Una vez golpeado los puertos el orden de secuencia de correcto, ejecutamos ssh para conectarnos al servidor por el puerto configurado 4422.

ssh -p 4422 user@10.0.0.22

En la siguiente captura de pantalla podemos ver como después realizar el intento de conexión SSH al servidor remoto usando la combinación correcta de golpeteo de puertos este ejecuta el comando establecido en la directiva "openSSH" configurado en el fichero /etc/knockd.conf donde se indica que se añada en primer orden una nueva regla iptables para permitir la comunicación únicamente a la IP origen de la máquina cliente permitiendo así la conexión SSH hacia la máquina servidor remota.

Como prueba podemos comprobar el estado de conexión de puertos con Nmap, desde la máquina cliente permitida vemos como el puerto 4422 está en estado abierto "open", sin embargo si comprobamos lo mismo desde otra máquina de la red con otra IP origen distinta vemos como para esa otra máquina el estado del puerto 4422 es "closed". Por lo tanto podemos decir que las reglas están funcionando correctamente y estamos "ocultando" o más bien filtrando el uso de las comunicaciones en un puerto concreto entre otras máquinas, la máquina cliente origen y la máquina servidor.

Si revisamos la máquina servidor vemos como ahora existe una nueva regla de iptables en el orden de prioridad 1 (será la primera regla que interprete el firewall) permitiendo la conexión al puerto 4422 desde la IP origen 10.0.0.23 (máquina cliente). Si analizamos los logs /var/log/knockd.log también verificamos que se ejecutó correctamente el orden de secuencia de golpeteo de puertos y el comando que agrega esta regla al firewall local de iptables.

Finalmente salimos de la sesión SSH remota, para volver restablecer las reglas iptables de la máquina servidor y así volver rechazar las conexiones por el puerto 4422 a todas las máquinas e incluida la máquina cliente. Ejecutamos la secuencia de golpeteo de puertos establecida en la directiva de "closeSSH". De esta forma si volvemos a revisar las reglas en la máquina servidor vemos como esta se elimina y se vuelve establecer con prioridad 1 la regla de bloqueo que rechaza todas las conexiones desde cualquier IP origen.

Figura 7: Intento de conexión SSH usando knockd con la secuencia correcta de Port Knocking.

Opción 2: usando telnet con Port Knocking

Otra forma de realizar port knocking es hacer uso del comando telnet. Recibirá un mensaje de "Connection refused", pero está bien, ya que telnet está deshabilitado en ese puerto y solo queremos enviar un paquete con flag "TCP SYN". 

$ telnet 10.0.0.22 7500

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

$ telnet 10.0.0.22 8200

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

$ telnet 10.0.0.22 9800

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

Una vez se concluya el comando telnet durante las tres secuencias de puertos, la conexión SSH por el puerto 4422 se abrirá para la máquina cliente.

Figura 8:  Intento de conexión SSH usando telnet con la secuencia correcta de Port Knocking.

Opción 3: usando Nmap con Port Knocking

Otra forma de realizar port knocking es hacer uso de la herramienta de escaneo de puertos Nmap. Con el parámetro -sS podemos enviar hacia el servidor paquetes con flag "TCP SYN". Concatenando la secuencia de comandos correcta podemos lanzar este tipo de paquetes ejecutando así la regla que nos permite establecer conexión con el servidor SSH remoto.

sudo nmap -sS -p7500 10.0.0.22 ; nmap -sS -p8200 10.0.0.22 ; nmap -sS -p9800 10.0.0.22

Figura 9: Intento de conexión SSH usando Nmap con la secuencia correcta de Port Knocking.

Conclusiones

Añadir este mecanismo como método de autenticación SSH en servidores es una buena medida de seguridad por oscuridad. Si bien este proceso es divertido de implementar y verlo en acción, es posible que no sea factible implementarlo en entornos de producción donde hay una gran cantidad de servidores SSH o si se necesita automatizar accesos SSH.

Considero que es una buena medida de seguridad a implementar solamente para aquellos servidores realmente críticos y que tengan una cierta exposición externa en los que dado su diseño de arquitectura subyacente de red no permita ser protegido en capas anteriores con un firewall o DMZ. Incluso podríamos añadir una segunda capa de protección como sería la implementación de un segundo factor de autenticación 2FA en conexiones SSH.

Saludos!

Segundo factor de autenticación 2FA en conexiones SSH

Implementar un segundo factor de autenticación 2FA en servicios SSH sin duda es una muy buena opción de seguridad no solo para servidores expuestos a internet sino para aquellos usuarios que pueden elevarse a un contexto privilegiado de sudo y servidores críticos en una red interna corporativa. 

Con este mecanismo de autenticación en dos pasos se estaría reduciendo en gran medida la superficie de ataque de los vectores de entrada a estos sistemas por parte de un posible atacante.

Implementación 2FA en SSH (Google Authenticator)

Instalar el paquete del módulo PAM para 2FA libpam-google-authenticator de Google Authenticator, también se instalará el paquete libqrencode4 que permite generar códigos QR en la propia terminal. 

sudo apt install libpam-google-authenticator -y

Configurar SSH para que haga uso de este módulo PAM. Añadir la siguiente línea en el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so

Habilitar esta configuración el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. Añadimos o modificamos si ya existe la siguiente política a un valor "yes".

ChallengeResponseAuthentication yes

Reiniciamos el servicio sshd para aplicar los cambios realizados en el servicio de SSH.

sudo systemctl restart sshd

Finalmente vinculamos la cuenta de usuario en la que queremos habilitar 2FA. Se nos mostrará un código QR el cual debemos vincular con nuestra App de doble factor, ya sea Google Authenticator u otra que utilicemos para generar códigos de un solo uso basado en tiempo TOTP.

google-authenticator

Se lanzará el asistente de configuración donde asociaremos la clave secreta con nuestra App de segundo factor. También se generarán "5 códigos de emergencia de un solo uso" los cuales los almacenaremos de forma segura en caso de perder el acceso a nuestra App de TOTP instalada en un dispositivo físico.

Figura 1: Creación de código QR - Asistente de vinculación para habilitar 2FA. 

Una vez finalizado el asistente de vinculación. Si nos intentamos autenticar en el servidor nos solicitará la contraseña de usuario y un código de verificación TOTP.

Figura 2: Verificación del uso de 2FA en la autenticación SSH al servidor. 

En este caso se ha vinculado con la App de Google Authenticator donde cada 30 segundos se generará un nuevo código TOTP. 

Figura 3: Código TOTP en la App de Google Authenticator.

Aclarar que aunque tengamos la política de "PasswordAuthentication no" establecida en nuestro fichero de servicio SSH al implementar 2FA será ignorada y será exigido introducir la contraseña de usuario para autenticarse en el servidor.

Paranoid Mode 3FA: Combinar autenticación SSH Public Key + Password + TOTP 

¿Qué pasa si previamente tenemos configurado una autenticación de clave pública en nuestro servicio de conexión SSH hacia el servidor y añadimos 2FA TOTP?

Si ya tenemos configurado un tipo de autenticación asimétrico de clave pública y añadimos un segundo factor bastado en TOTP a priori con esta configuración actual, no nos funcionará.

Si queremos combinar un tipo de factor TOTP junto con nuestra autenticación de clave pública en SSH debemos añadir la siguiente política en el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. 

AuthenticationMethods publickey,keyboard-interactive

Reiniciamos el servicio SSH para aplicar los cambios.

sudo systemctl restart sshd

De este modo cuando nos conectamos al servidor SSH no solo estaremos combinando SSH Public Key y TOTP sino que también debemos introducir la contraseña de usuario. Por lo que estaremos usando tres factores de autenticación (3FA) para acceder al servidor vía SSH.

• Autenticación con clave pública/privada.
• Autenticación password de la cuenta de usuario.
• Autenticación con código de verificación TOTP.

Aunque en el fichero de configuración del servicio SSH tengamos establecida la política "PasswordAuthentication no" al combinarla con "keyboard-interactive" nos obligará a introducir la password de la cuenta de usuario con el que nos autenticamos.

Figura 4: Verificación del uso de 3FA en la autenticación SSH al servidor.

Permitir autenticación SSH sin 2FA para usuarios que aún no configuraron Google Authenticator

Si en la máquina servidor hay más usuarios que necesiten autenticarse vía SSH y, por el momento, estos usuarios aún no han configurado 2FA para sus cuentas, o si son usuarios sin privilegios para los que no se considera la implementación de 2FA, pero que igualmente deben poder autenticarse e iniciar sesión en el servidor sin necesidad de utilizar TOTP como segundo factor.

Podemos añadir el valor nullock a la siguiente directiva del módulo de PAM editando el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so nullok

Saludos!

Hydra, Medusa y Ncrack: Password cracking a servicios por fuerza bruta en profundidad y en anchura (Password spraying)

THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc.

Para mostrar el uso de estas herramientas usaré el siguiente escenario de ejemplos. Escaneando con nmap los equipos remotos y puertos empleados para cada tipo de servicio.

nmap -p 21 10.0.0.16      # Windows 7 servicio FTP
nmap -p 3389 10.0.0.16    # Windows 7 servicio RDP
nmap -p 445 10.0.0.16     # Windows 7 servicio SMB/CIFS
nmap -p 22 10.0.0.40      # Linux servicio SSH

Figura 1: Escaneo de puertos a máquina en servicios SSH, RDP, FTP y SMB.

THC-Hydra

Hydra es una de las herramientas más conocidas para este tipo de ataques a servicios online. Hay que tener en cuenta que este tipo de ataques son activos y no pasivos, por lo que hay una interacción con el servicio que vamos comprometer mediante un intento de autenticación de credenciales.

Esto creará un evento en el log de la máquina remota servidora del servicio, en el caso de tener algún tipo de control de eventos en el endpoint se podrían detectar intentos de conexión con credenciales erróneas y disparar alertas.

Principalmente se pueden definir 3 tipos de ataques:

• Fuerza bruta por diccionario con múltiples usuarios y passwords
• Fuerza bruta en profundidad
• Fuerza bruta en anchura o Password spraying

Fuerza bruta por diccionario con múltiples usuarios y passwords

Este tipo de ataques se caracterizan por usar un wordlist tanto para un conjunto de usuarios y de contraseñas en plano previamente definidos. En el siguiente ejemplo hay nombres de usuarios y contraseñas definidos en los ficheros "users" y "wordlist" respectivamente a un intento de conexión a la máquina remota 10.0.0.16 que será un Windows 7 con un servicio FTP.

hydra -L users -P wordlist -vV 10.0.0.16 ftp

• -L: Fichero que contiene la lista de usuarios.
• -P: Fichero que contiene la lista de passwords.
• -v: Modo verbose
• -V: Muestra el intento por cada login+pass
• 10.0.0.16 ftp: Especificamos la IP de la máquina remota y el tipo de servicio.

El usuario "ventas" y la password "Pa$$w0rd123" serán las credenciales válidas para acceder al servicio FTP. Hydra probará intentos de conexión al servicio haciendo un barrido entre las distintas posibilidades combinatorias entre los distintos usuarios y contraseñas definidas.

Figura 2: Hydra - Fuerza bruta por diccionario con múltiples usuarios y passwords al servicio FTP.

Como ya comenté anteriormente, estos ataques son reconocimiento activos por lo que dejan un rastro en el log del servidor remoto. En la siguiente captura se puede ver el intento de conexión fallida al intentar autenticarse con el usuario "luis" y su password en el servidor FTP remoto.

Figura 3: Log en el servidor FTP del intento de autenticación.  

Fuerza bruta en profundidad

Fuerza bruta en profundidad o fuerza bruta, a secas: Se trata utilizar muchas contraseñas para una sola cuenta de usuario.

Como ejemplo se realiza un ataque de fuerza bruta al servicio RDP a una cuenta concreta llamada "maria" y probar un wordlist con varias contraseñas posibles.

hydra -l maria -P wordlist -vV 10.0.0.16 rdp

• -l: Nombre de usuario único.
• -P: Fichero de lista de contraseñas.

Un detalle a tener en cuenta cuando realice los intentos de conexión es que si el user/pass son correctos cerrará la sesión del usuario actual que esté conectado a la máquina si lo hubiese. 

Figura 4: Hydra - Fuerza bruta en profundidad al servicio RDP.

Al igual que el servicio anterior RDP también dejará un evento registrado en equipo remoto. Pudiendo ver la IP y puerto del equipo que intentó realizar la conexión así como que usuario intentó autenticarse.

Figura 5: Log en el equipo remoto por un intento de autenticación al servicio RDP.

Fuerza bruta en anchura o Password spraying

Fuerza bruta en anchura o Password spraying: Se trata de usar la misma contraseña para muchas cuentas de usuario.

Aprovechando el mismo escenario que en el ejemplo anterior, se muestra un ataque de password spraying en el servicio de recursos compartidos de Windows SMB. 

hydra -L users -p M4ria.12 -vV 10.0.0.16 smb

• -L: Fichero de lista de usuarios.
• -p: Contraseña única.

Haciendo referencia a un fichero llamado "users" que contiene una lista de usuarios se le especifica una misma contraseña única.

Figura 6: Hydra - Fuerza bruta en anchura o password spraying al servicio SMB.

Como cualquier servicio de Windows de un protocolo conocido, al igual que los casos anteriores, se creará un evento relacionado obteniendo el nombre de usuario y equipo desde donde se intentó realizar la conexión de autenticación. 

Figura 7: Log en el equipo remoto por un intento de autenticación al servicio SMB.

En cualquier caso cuando un usuario o password específico se usarán los argumentos -l o -p en minúscula y en el caso de hacer referencia a wordlists serán -L o -P en mayúscula.

Fuerza bruta en servicios web como Facebook o Instagram

Servicios que permitan una autenticación web, por ejemplo redes sociales como Facebook o Instagram también es posible realizar ataques de fuerza bruta, aunque el número de intentos es muy limitado y en el caso de fallar varias veces consecutivas es muy probable que la cuenta con la que estamos probando se desactive temporalmente como medida de seguridad, precisamente para evitar este tipo de ataques.

Lo primero sería conocer la IP que nos está respondiendo, no siempre será la misma, puede variar según la zona geográfica y el balanceador que nos responda. Con un simple "ping facebook.com" o "ping insgram.com" obtendremos la IP en ese momento.

Para protocolo HTTPS puerto 443 (https-get).

hydra -L users -P pass -vV <FACEBOOK_IP> -s 443 -f https-get /login

hydra -L users -P pass -vV <INSTAGRAM_IP> -s 443 -f https-get /accounts/login/

Para protocolo HTTP puerto 80 (http-get).

hydra -L users -P pass -vV <FACEBOOK_IP> -s 80 -f http-get /login

hydra -L users -P pass -vV <INSTAGRAM_IP> -s 80 -f http-get /accounts/login/ 

Figura 8: Ataque de fuerza bruta a servicios web como Facebook o Instagram.

Medusa

Medusa es otra alternativa a THC-Hydra. Los tipos de servicios son reconocidos por el tipo de protocolo que usan. 

Medusa utiliza módulos para referirse al protocolo del servicio, es posible implementar diversos módulos a parte de los que trae por defecto. 

Estos módulos están disponibles en el path.

/usr/lib/x86_64-linux-gnu/medusa/modules

Repositorio: https://github.com/jmk-foofus/medusa

Para el siguiente ejemplo cambiaremos de escenario. Un servidor SSH expuesto en un sistema Linux se intentará un ataque de fuerza bruta con wordlists de un conjunto de usuarios y passwords.

medusa -U users -P wordlist -h 10.0.0.40 -M ssh

• -U: Fichero de lista de usuarios
• -P: Fichero de lista de contraseñas
• -h: Host remoto
• -M: Tipo de módulo.

En la siguiente captura se pueden ver los intentos de conexión con las distintas combinaciones posibles entre user/pass. 

Figura 9: Medusa - Fuerza bruta en profundidad al servicio SSH.

Al tratarse de un ataque de fuerza bruta, son ataques activos por lo que este tipo de conexiones también dejan un registro de log en el fichero /var/log/auth.log mostrando fecha, nombre de usuario, IP y puerto desde donde se intentó realizar la conexión de autenticación.

Figura 10: Log en la máquina remota del intento de autenticación al servicio SSH.

Ncrack

Ncrack desarrollada por nmap.org es otra herramienta alternativa a THC-Hydra y Medusa. Se caracteriza por su gran velocidad, su enfoque modular y la capacidad de escalar a múltiples hosts. Su sintaxis es similar a nmap. 

• Manual de referencia: https://nmap.org/ncrack/man.html
• Repositorio: https://github.com/nmap/ncrack

Continuando el ejemplo anterior, realizamos un ataque de fuerza bruta al servicio SSH con un mismo usuario usando una wordlist de contraseñas.

ncrack -p 22 --user pepe -P wordlist 10.0.0.40

• -p: Puerto estándar usando por el servicio.
• --user: Nombre de usuario único.
• -P: Fichero de lista de contraseñas.

Al igual que THC-Hydra y Medusa, Ncrack también deja su registro en el log. En la siguiente captura se observa como en un primer intento con el usuario juan no fue posible realizar la conexión con el usuario juan pero si con el usuario pepe, lo cual es correcto. Con una lista de 8 contraseñas posibles, en ambos el tiempo de comprobación fue de 3 segundos.

Figura 11: Ncrack - Fuerza bruta en profundidad al servicio SSH. 

Saludos!

Password cracking en hashes Linux (John The Ripper y Hashcat)

En otro artículo comentara el proceso y técnicas para realizar Passwords cracking de hashes NTLM ntds.dit de Active Directory en sistemas Windows.

En esta ocasión para poder llevar a cabo un ataque por fuerza bruta, diccionario o Rainbow tables a los hashes de contraseñas de sistemas Linux. Es necesario obtener un acceso root para copiar o volcar el contenido de los ficheros /etc/passwd y /etc/shadow.

Si tenemos acceso físico a la máquina o un entorno de hipervisor donde podemos elevarnos a root abriendo una terminal usando Grub, explotar una vulnerabilidad que nos permita conseguir acceso con root o en una fase de post-explotación crear un usuario y hacerlo miembro del grupo sudo o colocarlo en /etc/sudoers.

Extracción de los ficheros /etc/passwd y /etc/shadow

Una vez accedido al sistema como root. Podemos realizar la extracción de los ficheros /etc/passwd y /etc/shadow. Podríamos copiarlos a una unidad externa USB.

fdisk -l                           # Vemos los discos conectados al sistema

mkdir /mnt/usb                     # Creamos directorio para montar la unidad USB

mount -t vfat /dev/sda1 /mnt/usb/    # Montamos la unidad USB

df -h                             # Nos aseguramos de que está montado

cp /etc/passwd /mnt/usb/passwd.txt   # Copia del fichero /etc/passwd

cp /etc/shadow /mnt/usb/shadow.txt   # Copia del fichero /etc/shadow

umount /mnt/usb                    # Desmontamos la unidad USB

Si en el momento de desmontar la unidad USB nos muestra un mensaje del tipo "umount: /mnt/usb: device is busy". Podemos ver que proceso está siendo usado para /mnt/usb, finalizarlo e intentar desmontar de nuevamente la unidad.

fuser -vm /mnt/usb # Ver los procesos existentes.

fuser -k /mnt/usb # Matar los procesos existentes.

umount /mnt/usb # Desmontar la unidad (forzar con el argumento -l).

unshadow: Combinar los ficheros passwd y shadow

Una vez conseguidos ambos ficheros y volcados en una máquina controlada y aislada sin riesgo a ser bloqueados o detectados, podemos tomarnos más tiempo para el proceso de descifrado de passwords. 

# tail -n 3 /etc/passwd

pepe:x:1005:1005::/home/pepe:/bin/bash

maria:x:1006:1006::/home/maria:/bin/bash

admin:x:1007:1007::/home/admin:/bin/bash

# tail -n 3 /etc/shadow

pepe:$6$yQVL/XM8/ZZ9S2IR$yOiJozomFYVYkdeOiXO7OGrceqiVdc6aBeb9yO4QnW.DiQQf9yEBKtm8J4F0Vu2JDXwIJtTKWfUyqMoqKqDNv/:18420:0:99999:7:::

maria:$6$2t4URKFkY/8Maj.I$mo2yfY0iAMXE60qWxiuKwXMOhexJiPIHYPVL6A7iBNBqV7H5IRLySeTc6dqREkBSflbjuQJlZO2tXEFXYidkK/:18420:0:99999:7:::

admin:$6$0tr5dcVdjueqvQna$LQu.ul4LmYbaNG8/lnx7LBwlW5RxFBEUqjE.sLRlYHeeGkKzz5TZHZ5foe.HEW2hrjNw0Q3sxTMRHFkYmp9uN0:18419:0:99999:7:::

Debemos fusionarlos en un mismo fichero. Este fichero será el que le pasaremos a las herramientas de cracking para el descifrado de passwords.

Para combinar el fichero /etc/passwd y /etc/shadow usamos el comando unshadow.

unshadow passwd.txt shadow.txt > passwords

Password cracking con John The Ripper

John The Ripper es una de las herramientas más populares usada para el cracking de contraseñas.

Con el fichero único creado anteriormente. Sin indicar ningún diccionario previamente, con John podemos realizar un ataque por fuerza bruta por defecto. Dependiendo la complejidad de la contraseña esto puede tardar unos minutos o muchas horas. 

john passwords

Si no disponemos de un buen diccionario. John cuenta con el modo --incremental se trata del modo más potente y también el más costoso en tiempo de procesamiento. Es aconsejable establecer a este modo un límite de longitud y comprobaciones de contraseñas (dígitos, mayúsculas, minúsculas, símbolos, etc.) para intentar que el proceso no tarde exageradamente tanto tiempo. Donde "passwords" sería el fichero creado con unshadow.

john --incremental passwords

Podemos consultar los logs de John para ver a tiempo real el proceso de cracking.

tail -f /root/.john/john.log                   # Opción con tail

less /root/.john/john.log (pulsar shift + f)   # Opción con less

John crea un directorio oculto ~/.john en el home de usuario donde es ejecutado. Aquí almacena varios ficheros.

• ~/.john/john.log: Almacena el proceso de cracking, podemos consultarlo en tiempo real.
• ~/.john/john.pot: Almacena los hashes y las passwords encontradas. Podemos ver su contenido ejecutando "john --show <fichero_passwords_hashes>'.
• ~/.john/john.rec: Guarda el estado del proceso de cracking en el que caso de que sea interrumpido ('q' o 'ctrl+c' pulsado una sola vez, si lo pulsamos dos veces el proceso se abortará por completo), de todos modos John realiza un autoguardado del proceso en este fichero cada 10 minutos.

Para mostrar o visualizar las contraseñas encontradas. Donde "passwords" sería el fichero creado con unshadow.

john --show passwords

Para mostrar el estado del proceso.

john --status

Obtener una lista de los tipos de formatos de cifrado compatibles en el caso de especificar uno concreto dependiendo tipo de hashes.

john --list=formats
john --format=sha512crypt

 Para realizar un ataque por diccionario y aplicar el estilo de reglas por defecto.

john --wordlist=diccionario.lst --rules password

En la siguiente captura se puede ver un proceso de craking por defecto y de contraseñas débiles a través de John The Ripper.

Figura 1: Password cracking en Linux con John The Ripper.

Password cracking con Hashcat

Hashcat es otra herramienta archiconocida para el craking a una amplia variedad de tipos de hashes de passwords.

Código Hashcat del tipo de hash de cifrado comunes en sistemas Linux

• DES (Unix) = 1500
• MD5 = 0
• MD5 (Unix $1$) = 500
• Blowfish (Unix $2*$) = 3200
• SHA1 = 100
• SHA-256 = 1400
• SHA-256 (Unix $5$) = 7400
• SHA-512 = 1700
• SHA-512 (Unix $6$) = 1800 (usado en la mayoría de distribuciones actualizadas a día de hoy)

Ejemplo de uso en un ataque por diccionario con Hashcat.

hashcat -m 1800 -a 0 passwords diccionario.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule -o cracked.txt --force

• -m (--hash-type): Tipo de hash de cifrado (https://hashcat.net/wiki/doku.php?id=example_hashes)
• -a (--attack-mode): Modo de ataque. 0 como el modo directo predeterminado (ataque por diccionario).
• passwords: Fichero que contiene los hashes generado con unshadow.
• diccionario.txt: Diccionario -wordlist-.
• -r (--rules-file): Reglas de combinación que aplicará a cada palabra del diccionario. Intenta encontrar contraseñas candidatas aplicando funciones para modificar, cortar o extender palabras y tiene operadores condicionales para omitir algunas, etc. (https://hashcat.net/wiki/doku.php?id=rule_based_attack). Reglas disponibles en el paquete de Hashcat https://github.com/hashcat/hashcat/tree/master/rules.
• -o (--outfile): Fichero de salida
• --force: Ignora las advertencias.

Referencia: https://hashcat.net/wiki

En la siguiente captura se muestra un ataque por diccionario, estableciendo el formato del tipo de hash de cifrado 1800 (sha-512 - unix $6$), añadir el fichero de reglas "InsidePro-PasswordsPro.rule" incluido en el paquete de Hashcat y guardar el resultado de las contraseñas encontradas en un fichero de salida llamado cracked.txt.

Figura 2: Password cracking en Linux con Hashcat.

Password hash cracking Online

Existen multitud de sitios web en Internet que contienen grandes bases de datos con todo tipo de hashes donde pueden comparar y obtener un match en base al hash introducido. Algunas webs usan servidores potentes para realizar consultas a tablas Rainbow consiguiendo resultados más rápidamente.

• https://crackstation.net/
• https://gpuhash.me/
• https://www.onlinehashcrack.com/ (de pago para una mayor rapidez, dispone de la posibilidad de usar rainbow tables muy efectivas).

Figura 3: Descifrar hashes SHA512crypt (Unix) en sitios web online.

Saludos!

El riesgo del periodo de gracia de sudo y evitar que los usuarios sudo o wheel puedan cambiar la contraseña de root

El uso del comando sudo permite a otros usuarios ejecutar acciones o programas con los privilegios de un usuario root. Es una buena práctica utilizar un usuario regular y en el momento de realizar alguna acción que requiera de elevación anteponer el comando sudo. 

Nos pedirá las credenciales del usuario actual, si el usuario tiene capacidad de manejarse en un contexto de super-usuario, es decir pertenece al grupo sudo o está agregado en el fichero /etc/sudoers (o través de visudo), de este modo el usuario podrá utilizar sudo y ejecutar las tareas necesarias como si de root se tratase. Sería algo similar al uso de UAC en Windows. 

Como ventaja nos facilita la vida en el uso y no tener que introducir siempre la contraseña si lo estamos usando de forma continua. Pero esto tiene un inconveniente o riesgo desde un punto de vista de seguridad y es que cuenta con el llamado "Periodo de gracia". Sudo nos otorga durante un tiempo limitado (por defecto 5 minutos) los mismos privilegios de los que dispone el usuario "root". 

Esto quiere decir que si volvemos a utilizar sudo durante ese corto periodo de tiempo no nos solicitará la contraseña. En el supuesto de que estemos trabajando en una oficina o donde haya más personal, nos levantamos de nuestro sitio y dejamos nuestro equipo a disposición física de cualquiera existe el riesgo de que alguien pueda realizar tareas de root con sudo si aún estamos dentro de ese periodo de gracia. Por lo que es una buena práctica de seguridad deshabilitar o eliminar este periodo de gracia del comando sudo.

Deshabilitar o reducir el periodo de gracia de sudo

Podemos aplicar un hardening para evitar esto siendo más restrictivos. Editamos el fichero /etc/sudores. 

sudo nano /etc/sudoers

Para deshabilitarlo y que siempre no solicita la contraseña en el uso de sudo. Agregamos la siguiente directiva al final del fichero.

Defaults timestamp_timeout=0

Si no queremos deshabilitarlo del todo pero si reducir su tiempo de gracia, establecemos en valor numérico el tiempo en minutos. Por ejemplo 1 minuto.

Defaults timestamp_timeout=1

Salimos y guardamos el fichero /etc/sudoers y los cambios se aplicarán al momento.

Figura 1: /etc/sudoers - Deshabilitar el periodo de gracia de sudo.

Evitar que los usuarios del grupo sudo o wheel puedan cambiar la contraseña de root

Los usuarios del grupo sudo o wheel, en el caso de sistemas basados en Red Hat Enterprise Linux, CentOS o Fedora, obtienen privilegios de root temporalmente. Esta autorización incluye la posibilidad de realizar el cambio de la contraseña del usuario root. Para evitar esto, podemos escribir lo siguiente el archivo sudoers.

Sistemas basados en Debian

%sudo ALL=(ALL) ALL, !/usr/bin/passwd root

Sistemas basados en RHEL o CentOS

%wheel ALL=(ALL) ALL, !/usr/bin/passwd root

Después de esta operación, el usuario no puede cambiar la contraseña de root incluso si el usuario pertenece a los grupos sudo o wheel.

Saludos!

Gestión de política de contraseñas en Linux: login.defs y pam_pwquality (pam_cracklib)

Antes de entrar en materia y comentar donde se definen las directivas de contraseñas en entornos Linux, es necesario conocer los campos que estructuran al fichero donde almacenan cifradas las contraseñas de usuarios locales /etc/shadow.

Este fichero nos muestra el estado actual de como se están aplicando estas directivas a los usuarios y que nos resulta útil en procesos de auditoria interna para conocer esta información.

Estructura del fichero /etc/shadow

Figura 1: Estructura del fichero /etc/shadow.

• 1. Nombre de usuario.
• 2. Contraseña cifrada. Se establece con la estructura $id$salt$hashed. El tipo de algoritmo utilizado se define en el inicio en números entre los símbolos $.
• $1$ - MD5.
• $2a$ - Blowfish.
• $2y$ - Blowfish.
• $5$ - SHA-256.
• $6$ - SHA-512.
• 3. Último cambio de contraseña desde el 1/Enero/1970 (epoch).
• 4. Cantidad de días restantes para que el usuario cambie su contraseña. -1 significa que nunca expira.
• 5. Número máximo de días que la contraseña es válida después del cambio de contraseña por parte del usuario.
• 6. Días antes de que caduque la contraseña, advierte al usuario para que la cambie.
• 7. Días después de que caduque la contraseña, esa cuenta estará deshabilitada.
• 8. Días desde el 1/Enero/1970. Fecha absoluta que especifica cuando ya no se pueda usar el inicio de sesión para esa cuenta.

Comando chage (caducidad en las contraseñas)

Con el comando chage (change age) podemos establecer la caducidad de contraseñas y cuentas de usuario. Esto no afecta a los nuevos usuarios, se establece de forma nominal a usuarios existentes.

Para aplicar estas opciones a nuevos usuarios y así generar estas directivas por defecto habría que hacer uso de login.defs que se comenta más adelante en este artículo.

Opciones del comando chage:

• -d, --lastday: Establece el día del último cambio de la contraseña.
• -E, --expiredate: Establece la fecha de caducidad.
• -I, --inactive: Deshabilita la cuenta después inactividad de días de la fecha de caducidad.
• -l, --list: Muestra la información de la edad de la cuenta.
• -m, --mindays: Establece el número mínimo de días antes de cambiar la contraseña.
• -M, --maxdays: Establece el número máximo de días antes de cambiar la contraseña.
• -R, --root: Directorio en el que hacer chroot.
• -W, --warndays: Establece los días de aviso de expiración.

Con el parámetro -l podemos ver información sobre las cuentas.

# chage -l pepe
Last password change                                    : Apr 18, 2020
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires       : 5 

Más información sobre el comando chage: https://linux.die.net/man/1/chage

Cumplimiento de directivas de seguridad en la calidad de contraseñas seguras de usuarios

Al igual que en sistemas Windows es necesario implementar un mínimo cumplimiento de seguridad en el hardening de contraseñas estableciendo directivas a nivel de dominio para definir la complejidad de contraseña, longitud mínima, días de expiración, contraseñas no repetidas respecto a las anteriores, etc.

En sistemas Linux, aplicaciones de terceros o servicios exógenos que hacen uso de usuarios Linux, también es necesario establecer políticas de seguridad estrictas al tratarse de cuentas que pueden tener el mismo riesgo de ser vulneradas y poder pivotar a otros sistemas que sean de un mayor interés para los atacantes.

Lógicamente también dependerá de la infraestructura y su ecosistema. En entornos de producción no sería conveniente provocar la desactivación o bloqueo de una cuenta de usuario y dejar inoperativo un servicio crítico que dependa de dicha cuenta. Independientemente de estos casos es recomendable y diría que necesario establecer este tipo de criterios para garantizar y elevar un poco más las medidas de seguridad de los sistemas de la empresa.

Se pueden establecer políticas por defecto en el momento de creación de nuevas cuentas en el sistema, sin la necesidad de usar chage nominalmente a cada usuario como vimos anteriormente.

login.defs

Se trata de un fichero de texto situando en /etc/login.defs de forma nativa se encuentra en cualquier entorno Linux. Se definen las políticas de gestión de contraseñas para la creación de nuevos usuarios. También podemos establecer otros directivas como el valor umask por defecto, si el usuario tendrá un home para el si no se le especifica en su creación (useradd -m), cambiar la secuencia de ID (por defecto suelen ser 1000 y algo para usuarios normales), mensaje de bienvenida del inicio de sesión del usuario (motd_file), etc.

El motivo de este artículo será enfocado únicamente a las que tengan que ver con las políticas de contraseñas.

Algunas de las directivas más comunes que podemos establecer:

• PASS_MAX_DAYS: Número máximo de días que se puede usar una contraseña.
• PASS_MIN_DAYS: Número mínimo de días permitido entre cambios de contraseña
• PASS_WARN_AGE: Número de días de advertencia antes de que caduque una contraseña.
• PASS_MIN_LEN y PASS_MAX_LEN: Número mínimo y máximo de caracteres que debe tener la contraseña.
• PASS_ALWAYS_WARN: Advierte sobre contraseñas débiles.
• PASS_CHANGE_TRIES: Número máximo de intentos de cambiar la contraseña si se rechaza por que es demasiado "fácil".
• ENCRYPT_METHOD: Tipo de cifrado que tendrá la contraseña (SHA256 $5$ o SHA512 $6$).
• LOGIN_RETRIES: Número máximo de reintentos de inicio de sesión en el caso de que la contraseña sea incorrecta.
• LOGIN_TIMEOUT: Tiempo máximo en segundos para iniciar sesión

Más información sobre login.defs: https://linux.die.net/man/5/login.defs

pam_cracklib y pam_pwquality

Si queremos tener una mayor nivel de detalle en la personalización de las directivas en la complejidad de contraseñas para las cuentas de usuarios sería más interesante hacer uso de los módulos PAM (Pluggable Authentication Modules) pam_cracklib y pam_pwquality.

pwquality es una versión más actual y mejorada de cracklib. pwquality llama a una rutina cracklib para verificar si la contraseña es parte de un diccionario si este se especifica en la directiva dictpath. En este caso haré referencia siempre a pam_pwquality.

En entornos RHEL/Centos se incorpora de forma nativa, es compatible con derivados Debian pero será necesario instalarlo.

sudo apt install -y libpam-cracklib libpam-pwquality libpwquality-tools

Una vez instalado el módulo de libpwquality podemos editar sus opciones en el fichero "/etc/security/pwquality.conf".

Opciones para definir las políticas: 

• difok: Número de caracteres en una nueva contraseña que no deben estar presentes en la contraseña anterior.
• minlen: Tamaño mínimo aceptable para la nueva contraseña.
• dcredit: Crédito máximo por tener dígitos en la nueva contraseña.
• ucredit: Crédito máximo por tener letras mayúsculas en la nueva contraseña.
• lcredit: Crédito máximo por tener letras minúsculas en la nueva contraseña.
• ocredit: Crédito máximo por tener otros caracteres en la nueva contraseña.
• minclass: Número mínimo de clases de caracteres requeridas para la nueva contraseña
• maxrepeat: Número máximo de caracteres repetidos.
• maxclassrepeat: Número máximo de caracteres consecutivos en la misma clase.
• gecoscheck: Verifica si las palabras individuales de más de 3 caracteres del campo passwd GECOS (campo de comentarios) del usuario están contenidas en la nueva contraseña.
• dictpath: Ruta a los diccionarios de clacklib.
• badwords: Lista de palabras separadas por espacios que no deben incluirse en la contraseña.

Sistema de créditos, valores negativos y clases en pwquality

Créditos

Para definir la calidad y complejidad de las contraseñas se utiliza un sistema de créditos. Esto es muy interesante, básicamente se obtienen créditos por la complejidad. Una contraseña más corta podría ser aceptable si es más compleja en otras formas.

Por ejemplo una contraseña "ahwouwtdye" podría pasar una prueba minlen = 10. Si dcredit se establece en 2, una contraseña "ahwouw12" pasaría la prueba por que obtendríamos 2 créditos por cada dígito, entonces 8 caracteres más 2 créditos se valoran como 10 caracteres. Esto dependerá de como se establezcan los parámetros ucredit, lcredit, dcredit y ocredit.

Valores negativos

Establecer valores de créditos negativos significa que debe tener al menos ese tipo de carácter. Por ejemplo, establecer dcredit a -1 significaría que debe incluir al menos un dígito para que se acepte una contraseña. Es decir, no se trata de una suma de créditos sino de un requerimiento obligatorio.

Clases (minclass)

Otra configuración interesante es minclass. Determina cuántas clases diferentes de caracteres se deben usar para que una contraseña sea aceptable. Hay 4 tipos de clases: minúsculas, mayúsculas, dígitos, caracteres especiales (símbolos o signos).

Por ejemplo, un minclass = 2 exige que una contraseña contenga la combinación de dos tipos de clases. Ya sean mayúsculas o minúsculas, mayúsculas y caracteres especiales, minúsculas y dígitos, etc. Lo mismo pasaría si se establece a minclass = 4, la contraseña debería contener

También se puede establecer un límite al número máximo de caracteres de cualquier tipo de clase. Por ejemplo, con el parámetro maxclassrepeat = 4 indicamos que las contraseñas no pueden contener más de 4 minúsculas, mayúsculas, dígitos y otros caracteres especiales. 

Más información sobre el uso de directivas del fichero de pwquality: https://linux.die.net/man/8/pam_pwquality

Probando el cumplimiento de requisitos con varias contraseñas.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña tiene menos de 8 caracteres.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña no supera la verificación de diccionario - No contiene suficientes caracteres DIFERENTES.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña no supera la verificación de diccionario - Es demasiado simple/sistemática.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña contiene más de 3 caracteres de la misma clase en forma consecutiva

pwscore

pwquality (libpwquality-tools) dispone de una herramienta llamada pwscore que podemos usar para comprobar la complejidad de una contraseña en base a los criterios establecidos en pwquality. Algunos ejemplos de uso.

# echo 123 | pwscore
Falló la comprobación de calidad de la contraseña:
 La contraseña tiene menos de 8 caracteres

# echo abc123.. | pwscore
Falló la comprobación de calidad de la contraseña:

 La contraseña no supera la verificación de diccionario - Es demasiado simple/sistemática.

# echo L3h5as/2a$-ls=72 | pwscore
100

Conclusiones

Estos módulos PAM también pueden comprobar si las contraseña son un palíndromo o si solamente se cambió un solo carácter de mayúscula a minúscula o viceversa, si las contraseñas anteriores son similares o ya han sido usadas anteriormente, si contiene el nombre del usuario, o si hay alguna coincidencia con el campo passwd GECOS (campo de comentarios) de /etc/passwd. Dependiendo el nivel de complejidad que se establezca sería difícil establecerse una mala contraseña.

En definitiva, ofrecen una serie de comprobaciones que ayudan a garantizar un nivel de robustez y calidad de las contraseñas. Así como en la mayoría de compañías se aplican para entornos Windows, intentar aplicar estas políticas de seguridad en sistemas Linux y que no habiten en el olvido.

Saludos!