Tenéis un servidor accesible desde Internet por ssh y ¿le habéis echado alguna vez un vistazo al fichero de logs? Pues ya tardais en hacerlo. Si usas Debian está en el archvo /var/log/auth.log. Los ataques son constantes y, con facilidad, os encontraréis decenas de líneas como esta que provienen, como podeis imaginar, de ataques por fuerza bruta:
Failed password for invalid user anna from 118.219.232.208 Failed password for invalid user anne from 118.219.232.208 Failed password for invalid user anneliese from 118.219.232.208 Failed password for invalid user annemarie from 118.219.232.208 Failed password for invalid user annette from 118.219.232.208 Failed password for invalid user annike from 118.219.232.208 Failed password for invalid user antje from 118.219.232.208 Failed password for invalid user arianne from 118.219.232.208 Failed password for invalid user astrid from 118.219.232.208 Failed password for invalid user barbara from 118.219.232.208
La mejor forma de proteger tu servidor de estos ataques es deshabilitar los accesos a ssh a través de passwords y sólo permitir los autenticados mediante claves RSA y/o habilitar las IP’s válidas para realizar una conexión a través del fichero /etc/hosts.allow denegando todas las demás, pero esto no siempre es posible. A veces necesitamos permitir el acceso desde cualquier sitio a personal autorizado y no podemos usar ni una cosa ni la otra. Denyhosts es, en estos casos, una gran ayuda.
Se trata, básicamente, de un script escrito en python que analiza tus ficheros de log del servidor ssh, detecta los ataques al mismo e incluye las direcciones IP de las que provienen los mismos en el fichero /etc/hosts.deny para bloquearlas. Además, si habilitamos esta característica, permite sincronizar los datos recogidos por nuestra máquina con los de todos los usuarios que están usando este producto de forma que las IP’s desde las que se lanzan ataques a otros servidores son bloqueadas de forma automática cuando tratan de acceder a nuestro servidor, y viceversa.
Instalarlo en Debian es tan fácil como ejecutar un apt-get install denyhosts con privilegios de root. El paquete debian instala Denyhosts como un daemon (existen otras opciones como ejecutarlo manualmente o de forma periódica a través de cron). Después del primer arranque, que se ejecuta de forma automática, Denyhosts rastreará nuestro fichero de log más reciente y ya incluirá las primeras direcciones atacantes en el fichero hosts.deny:
sshd: 201.6.117.169 sshd: 216.77.98.235 sshd: 59.188.7.108 sshd: 200.161.135.135 sshd: 88.208.203.130 sshd: 58.241.40.66
El fichero de log de Denyhosts está en el fichero /var/log/denyhosts y en él podemos ver como va recogiendo las direcciones peligrosas, tanto provenientes de este primer análisis como de su posterior funcionamiento en tiempo real:
2008-11-01 23:04 - denyhosts : INFO new denied hosts: ['201.6.117.169', '216.77.98.235', '59.188.7.108', '200.161.135.135', '88.208.203.130', '58.241.40.66'] ... 2008-11-02 01:57 - denyhosts : INFO new denied hosts: ['200.111.154.196'] 2008-11-02 05:15 - denyhosts : INFO new denied hosts: ['122.200.102.6'] 2008-11-02 05:51 - denyhosts : INFO new denied hosts: ['66.80.59.131']
La sincronización con otros usuarios no está habilitada inicialmente en el paquete que nos distribuye Debian. Para activarla basta con editar el fichero de configuración (/etc/denyhosts.conf) y descomentar las siguientes líneas que habilitan la configuración por defecto:
SYNC_SERVER = http://xmlrpc.denyhosts.net:9911 SYNC_INTERVAL = 1h SYNC_UPLOAD = yes SYNC_DOWNLOAD = yes SYNC_DOWNLOAD_THRESHOLD = 3 SYNC_DOWNLOAD_RESILIENCY = 5h
Ahora reiniciamos el daemon (/etc/init.d/denyhosts restart) para que lea la nueva configuración y, al cabo de una hora como le hemos indicado, podremos ver la primera sincronización de datos:
2008-11-02 12:53 - denyhosts : INFO received new hosts: ['65.254.53.75', '83.19.41.182', '69.25.47.134', '86.219.230.217', '211.73.25.85', '201.6.252.150', '222.68.193.131', '62.213.23.138', '220.225.237.150', '75.125.196.226', '150.46.222.121', '61.150.114.76', '86.1.114.15', '75.127.83.114', '218.211.38.66', '60.164.220.15', '200.6.102.30', '66.104.77.34', '66.231.237.116', '61.184.142.98', '219.128.143.133', '88.198.158.42', '148.243.212.136', '85.17.169.129', '125.21.50.228', '210.205.217.77', '122.116.38.188', '200.253.218.210', '212.43.80.163', '83.98.220.52', '200.27.109.99', '201.6.126.232', '202.62.0.150', '122.224.108.216', '195.133.227.107', '219.142.114.254', '216.35.7.109', '196.217.243.13', '60.217.32.83', '211.22.147.18', '60.18.147.36', '210.75.200.9', 202.179.252.102', '125.88.102.23', '80.13.215.199', '61.100.180.19', '66.175.118.55', '208.43.145.242', '75.101.243.23', '193.137.226.2']
Las estadísticas de atacados y atacantes recogidas por el programa y sincronizadas mediante este servicio son públicas y pueden verse en esta página.
Si quieres alternativas, en El rincón de Tolito nos hablan de otros dos scripts similares: Blocksshd y Fail2ban.
Hola! Hace 2 días unicamente que descubrí tu blog y realmente esta muy bueno, no solo por la información útil que dejás sino también por su variedad en contenido.
Este articulo habla sobre un problema recurrente cuando dejas abierto un ssh en una ip pública, la solución más simple que yo encontré y realmente anda MUY bien es el sshblack ( http://www.pettingers.org/code/sshblack.html ), un script en perl que esta monitorizando el auth del debian o el secure de otros (RH y derivados) y bloqueando POR IP mediante la utilización de IPTables. Si no lo conocias hechale una mirada.
Otra cosa para segurizar un remote shell como el ssh también puede ser el port knocking ( http://es.wikipedia.org/wiki/Golpeo_de_puertos ), aunque me parece demasiado paranoico. Salvo que sea un servidor demasiado crítico.
Buenisimo el blog. Desde Argentina, Richard.
Cabos atados Mariache. He pasado por el blog del cultureta (¡quién iba a despistarse con ese dato!) y, una vez valorado superficialmente el muchacho, coincido con vosotras en que destaca su carne sobre su verbo. Un besote y mucha suerte.
a) Te juro por todos los dioses del Olimpo que soy una persona.
b) De antemano aviso: no voy a decir nada sobre Denyhosts ni SSH, que ni sé que son y probablemente morderán.
c) Lo de Kant y el muchacho es una broma que viene de otro blog; es que un cultureta que nosotras conocemos (y tú también) colgó una reseña de un libro junto con la foto del autor, y nosotras nos quedamos con lo bonito que era el antesdicho autor, y pasamos de la cosa profunda e intelectual, y sólo hicimos comentarios sobre su belleza, y como consecuencia nuestro valor en bolsa cayó en picado.
d) Mi piso nuevo va bastante bien, gracias, pero como siga en paro no sé cuánto tiempo más podré pagarlo, porque el gobierno da «ayudas» y «moratorias» a las hipotecas, pero no a los alquileres.
e) Besitos.
Efectivamente Dabo. En el mismo fichero
/etc/denyhosts.confdesde donde se hace toda la configuración tenemos los parámetros para ello:ADMIN_EMAIL = administrador@midominio.orgSMTP_HOST = localhost
SMTP_PORT = 25
SMTP_USERNAME= xxxxx
SMTP_PASSWORD= xxxxx
SMTP_SUBJECT = DenyHosts Report
Como siempre perfectamente explicado, sólo comentar que además se puede configurar para que envíe un aviso al mail (o a varias direcciones) cada vez que se bloquee un intento de ataque lo cual puede resultar muy útil.
Saludos -;)
Muy interesante… 🙂
Yo tuve un servidor FTP activado dos días y ya tuve que aguantar a un par de aspirantes de hackers intentando entrar…
Me lo apunto, puede ser interesante en el futuro.