Posts Tagged ‘ linux

Cómo identificar claves privadas generadas por openSSL comprometidas

La gente de Ubuntu ha sacado un paquete llamado openssl-blacklist disponible como instalable desde sus repositorios de software que permite verificar si las claves privadas que tengamos generadas con openSSL están comprometidas o no por el fallo de implementación del generador de números aleatorios del paquete openssl distribuido por Debian y derivados.

Se instala directamente con apt, aptitude, synaptic o con dpkg y descargando el paquete:

[code]sudo apt-get update && sudo apt-get install openssl-blacklist[/code]

Su uso es muy sencillo, bastará con ejecutar el comando openssl-vulnkey. Toma como parámetros de entrada los ficheros con las claves privadas en formato PEM.

[code]sudo openssl-vulnkey /etc/apache2/ssl/apache.test.pem
COMPROMISED: 9c4d589707a08ed65508032b41a999a810173592 /etc/apache2/ssl/apache.test.pem[/code]

Lo que no me queda muy claro es qué pasa cuando tiene una “validez desconocida”…

[code]sudo openssl-vulnkey /etc/apache2/ssl/apache-ssl-key.pem
Key has unknown validity: /etc/apache2/ssl/apache-ssl-key.pem[/code]

Este pequeño comando complementa estupendamente al ssh-vulnkey que verifica en el formato con el que almacena las claves openSSH si alguna de las claves del servidor o los clietnes SSH está comprometida.

Para instalar el paquete en Debian, por ahora se puede descargar directamente desde http://xillion.org/openssl-blacklist/ el paquete y sus firmas digitales para verficarlo.

Bloqueando ataques continuos con fail2ban y denyhosts

Una de las cosas que uno puede hacer con su conexión a Internet es montarse un servidor de acceso remoto para conectarse a casa desde cualquier parte del mundo IP. Sin embargo, abrir servicios a Internet expone a tu equipo a las inclemencias propias de la red como son ataques remotos. Salvo errores muy críticos en los programas que se ejecutan, y manteniendo el equipo actualizado, llegar a colarse en tu máquina por un exploit es difícil, pero eso no quita que a diario puedas recibir continuos intentos de acceso no autorizados, sobre todo desde máquinas zombies de una botnet.

Esto es justo lo que le pasa a mi servidor SSH, cuyos registros de acceso fallidos están rebosando de intentos:

[code]
Apr 23 02:20:52 teroknor sshd[31336]: Invalid user noah from 217.126.56.236
Apr 23 02:20:52 teroknor sshd[31336]: pam_unix(ssh:auth): check pass; user unknown
Apr 23 02:20:52 teroknor sshd[31336]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=236.red-217-126-56.staticip.rima-tde.net
Apr 23 02:20:54 teroknor sshd[31336]: Failed password for invalid user noah from 217.126.56.236 port 17228 ssh2
Apr 23 02:20:56 teroknor sshd[31339]: Invalid user joseph from 217.126.56.236
Apr 23 02:20:56 teroknor sshd[31339]: pam_unix(ssh:auth): check pass; user unknown
Apr 23 02:20:56 teroknor sshd[31339]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=236.red-217-126-56.staticip.rima-tde.net
[/code]

Una solución muy fácil de instalar en el equipo es un sistema de prevención de intrusión o HIPS basado en analizar periódicamente los registros de acceso con dos programas: denyhosts y fail2ban.

Leer mas