Si tenéis un servidor SSH corriendo y alguna vez os habéis parado a mirar los logs, habréis visto una gran cantidad de intentos de acceso no autorizados. Si estudiáis más detenidamente los logs descubriréis que la mayoría de veces son ataques basados en diccionarios o similares, por tanto a no ser que nuestros passwords sean muy débiles es difícil que consigan acceder a nuestra máquina. Pero para que arriesgarnos...vamos a ver como protegernos de estos seres malignos e indeseables que intentan entrar en nuestro sistema.
Comentarios
Una preguntilla curiosa, ¿para el ssh no es mejor utilizar el mecanismo de clave pública? es un poco más pesado de administrar pero en teoría mucho más seguro.
#1 Imagino que te refieres a fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page
Para estos ataques automaticos es MUY útil iptables si tienes kernel 2.6 y soporte para netfilter con recent, me lo acaba de enseñar un compañero y es realmente útil:
iptables -A INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –name SSHD –set
iptables -A INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –name SSHD –update –seconds 60 –hitcount 4 -j DROP
Esto limitará a 4 conexiones a tu puerto SSH desde la misma IP durante 60 segundos. Es decir, que por minuto solo permites 4 conexiones de SSH, con lo cual, un ataque automático parará a los 4 intentos porque no podrá llegar al puerto.
Me ha gustado esa "nueva" sintaxis para ipv4, ah y lo mismo para los pings, realmente MUY útil y recomendable.
Ahora, haciendome un poco de autobombo, otra herramienta que he desarrollado yo: http://serhost.com/banfromlog (en base al log genera las sentencias iptables).
Yo me quedo con fail2fan, fácil, sencillo de instalar, configurable, y no vale sólo para ssh, sino para ftp ,etc. Y además, funciona
Cuanto complicarse, los administradores usamos el APF+Brute force detection y cambiamos el puerto del SSH por otro y ya no hay mas ataques de este tipo.
Sinceramente, la opción de #4 es mucho mas segura, aunque eso no implica aplicar tambien técnicas como las de #6.
#4: Lo de que es mas pesado de administrar es hasta cierto punto. Una vez configurado correctamente y con buenas prácticas de administración no se hace pesado, se hace seguro.
Por otro lado, si dispones de firewall, tu numero de clientes es reducido, y no son usuarios con IP dinámica (más dificil), aplicas una política en el firewall y asi ni siquiera les das la oportunidad de intentarlo, ya que cambiar el puerto del 22 a otro solo supone quitarse de encima a los 'chicos de los scripts'. Un buen barrido de puertos con Nmap delatará el servidor SSH sin necesidad de nada mas que un poco de tiempo.
Pero me reitero, la combinación #6 + #4 es una de las mejores opciones, y creo que pesa mas la opinión de #4 que la de #6, sin descartarla.
Independientemente de cuál eligais por lo menos es bueno para ver que alternativas tiene la gente, probar y quedarse con el mejor que nos convenga
#8 no permitir acceso al root o cambiarle el nombre a root en /etc/passwd
Me quedo con #6, y, además, añado lo más importante:
NO PERMITIR LOS LOGINS COMO ROOT!!!!!!!!
Eso
Hoy dia cualquier herramienta de seguridad es poca, yo solo digo que (refiriendome al titulo) cambiar el puerto te evita los dichosos escaneos, siempre que se pueda cambiar, si no pues habria que estudiar otras posibilidades.
Tambien es importante cuando se detecten estos scaneos hacer un whois de la IP y enviar el log al departamento de abuse, ultimamente yo al menos estoy recibiendo muchos ataques de servidores dedicados, algo que me preocupa bastante.
#1 Este puede bloquear cualquier servicio, no solo ssh
#16 Los pasos creo que serían:
0 Cerrar el puerto si se puede (o limitarlo a donde conectemos)
1 Cambiar el puerto a uno alto
2 Aplicar iptables como he explicado en #15
3 Usar llave pública
4 En caso de no querer sólo llave pública tener contraseñas seguras
5 Poner permitrootlogin a no
6 Mirar que ningún usuario típico: ssh, ftp, oracle, webmaster, admin etc tenga contraseñas por defecto o sus cuentas no estén deshabilitadas
7 Si se puede usar port-knocking: http://en.wikipedia.org/wiki/Port_knocking
8 Mirar los logs, para esto es muy útil logcheck (te envía por emails los logs relevantes).
el "knock" es otra posibilidad.
#19 Lo malo es que no es tan comodo, hay que especificar la opción -p en ssh y -P en scp (hay que acordarse que una es mayúscula y la otra minúscula, que es una tontería, pero al menos yo, siempre me confundo), además si conectas desde algún entorno con proxy/iptables/restricciones, puede que te dejen salir por el 22 pero no por el 2222.
Pues yo cambie el puerto en mis servidores WEB a uno alto, y mano de santo. Ni un solo login que no sea mi ip.
mmm, algo tan simple como cambiar el puerto a uno bastante alto mi me funciona ^^
El DenyHost es una herramienta totalmente recomendable, en mi host por ejemplo recibo ataques diarios por fuerza bruta. Aunque estos ataques rara vez pueden llegar a hacerte daño en ocasiones mas vale prevenir que lamentar no?
...
Si que doy cierto consejo y es activar el PURGE_DENY, yo lo tengo en 2 días, esto quiere decir que todas las ips baneadas a los dos dias se desbanean, yo lo tengo así porque el BLOCK_SERVICE lo tengo puesto a ALL (es decir si intentas entrar por ssh te banea en todo, http, ftp, etc... ) así evito banear ips dinámicas demasiado tiempo.
También y ya que estamos aconsejo el Firewall APF, el servidor VsFtp, repasar el directorio /tmp para ponerlo como noexec, y dar un repasito al etc/password para desactivar el shell en usuarios innecesarios... bueno y mil cosas mas
Bien ya puedo protegerme.
#6 Si, fail2Ban, jeje
#1 Si lees el comentario ya lo digo que no vale sólo para ssh...
Yo apostaría mas por el portknocking, pero bueno. A punto de votarlo como spam...
damian
#3 Y esos negativos????????