Ayer, de nuevo, un amigo mio fue víctima de un ‘dictionary-based attack’, afortunadamente, parece que el atacante lo único que hizo fue cambiarle la password del usuario en cuestión. Aun así, si alguna vez alguien se “cuela” en tu equipo, la única manera de asegurarse que la seguridad del equipo no esta comprometida es formatear y reinstalar el sistema.
Hoy voy a detallar un pelin mas como blindar nuestro servidor de ssh para disminuir el riesgo de éxito de este tipo de ataques.
Una conexión Shh consta al menos de dos elementos basicos; cliente y servidor. Las distribuciones basadas en Debian Linux, el cliente se llama ssh y su fichero de configuración se encuentra en “/etc/ssh/ssh_config”. Y el servidor se llama sshd y su configuración se encuentra en “/etc/ssh/sshd_config”. Como deberes, echale un ojo y navega entre la opciones enterandote de para que sirven cada una de las opciones, deshabilitando aquellas que no sean necesarias.
Los cambios realizados en el servidor no se harán efectivos mientras no se reinicie el servicio (“/etc/init.d/ssh restart”)!
Cambia el puerto de escucha. El puerto estándar de escucha de los servidores ssh es el 22. Mi consejo es que siempre que puedas lo cambies. Si tu servidor esta detrás de un router basta con que cambies el puerto de escucha en la NAT. Si también quieres que el cambio afecte al área local, entonces tendrás que actualizar el parámetro “Port” en “/etc/ssh/ssh_config”.
Ventajas:
Eliminas completamente las posibilidades de éxito de scripts que se dedican a ‘barrer’ ips (La gran mayoría de los intentos)
Desventajas:
En sistemas con un elevado numero de usuarios, el cambiar de puerto solo complicara la vida de los usuarios (un parámetro mas que memorizar). Siendo no siempre posible de cambiar.
Complica ligeramente el mantenimiento del sistema.
Deshabilita aquellas opciones que no se usen. Shh nos proporciona una gran cantidad de opciones y posibilidades; autenticación mediante llaves criptográficas, uso de passwords vacías, root loging, X11Fordwarding, etc. Cuanto mas controladas tengamos dichas opciones mejor (o por lo menos que sepamos lo que están activadas). Una cosa que mucha gente olvida es que con el de llaves criptográficas el uso de passwords deja de ser necesario, y el cambiar de password algún usuario no le impedirá el acceso al sistema si tiene configurada dicha opción.
Ventajas:
Conocimiento y control de todo aquello que se podrá hacer a través de ssh y por tanto eliminación de posibles sorpresas.
Desventajas:
Ninguna
Restringir el acceso a determinadas ips. Ssh nos permite dos tipos de poéticas; denegación de acceso a determinadas ips (o rangos de ips), o autorización a uno o varios rangos de ips.
En caso de que quisiéramos bloquear a todos los usuarios de telefónica, lo único que debemos hacer es denegar el acceso al rango de ips reservado para telefónica. De la misma manera si quisiéramos permitir el acceso a usuarios de Brasil, aceptaríamos aquellas ips provenientes de Brasil.
Cuidado al ser demasiado permisivos o restrictivos a la hora de permitir o limitar acceso, ya que puede ser que bloquemos a gente a la que no debamos bloquear. además recordar que mediante el uso de proxys se puede enmascarar la ip de origen y saltarse dicha limitación.
Ventajas:
Pocas
Desventajas:
Este método suele resultar problemático. El motivo por el que lo nombro es para que sepáis de su existencia, es equivalente al filtrado de MAC en redes wifi.
Uso de llaves criptográficas. Esta es la forma mas segura de conectarse a un servidor ssh. Cada usuario posee una llave publica y una privada. La llave publica se guarda en el servidor (para encriptar), y la privada es guardada por el usuario (para desencriptar). Cada vez que nos conectemos al servidor este se encargara de comprar si la nuestra llave privada concuerda con alguna de las llaves publicas alojadas almacenadas en dicho servidor. Si alguna de estas concuerda entonces nos permitirá el acceso (evitando el introducir passwords).
Ventajas:
Muy cómodo en caso de múltiples accesos desde un mismo equipo.
Evita ataques “man in the middle”.
Cada usuario se encarga de mantener, y actualizar sus llaves.
Muy complicado de acceder por fuerza bruta.
Desventajas:
Necesidad de transportar la llave privada de un sitio a otro (algo engorroso si cambias constantemente de equipo).
Responsabilidad de mantener segura la llave privada (ya que en caso de que alguien se haga con ella podrá acceder al sistema).
Puede resultar algo abstracto para gente con conocimientos limitados en criptografía.
Limitar el número de intentos fallidos. Esta técnica es independiente del servidor de ssh. Consiste en bloquear el acceso a una determinada ip después de n intentos fallidos. Aquí os dejo un link de cómo implementarlo con iptables. Lo importante es que sepáis que esta existe y se puede implementar con relativa facilidad.
Ventajas:
Reduce drásticamente la posibilidad de éxito de ‘dictionary-based attacks’.
Desventajas:
Posibilidad de bloquear a nuestros propios usuarios.
Abierto a ataques DoS.
Conclusión:
Una buena gestión de usuarios y passwords es clave. Eliminar usuarios en desuso, el uso de aplicaciones como “Johnny the ripper” para localizar passwords “vulnerables”, y el cambio periódico de passwords son la mejor manera de mantener un sistema seguro!
Como en todo el peor enemigo de cualquier administrador es el desconocimiento del sistema. Por lo general, para el típico servidor de archivos casero, con cambiar el puerto de escucha y limitar los servicios disponibles es suficiente, aunque no siempre posible. Para equipos donde la seguridad es critica mi consejo es el uso exclusivo de llaves criptográficas como método de acceso. El restringir el acceso de ips puede parecer una buena idea, sin embargo no lo recomiendo bajo ninguna circunstancia.
Hace tiempo, trasteando con las 
