Securizando openssh MODE PARANOICO

El objetivo de esta entrada es securizar SSH, no obstante varias de las técnicas que vamos a ver se pueden utilizar para ayudarnos a securizar cualquier otro servicio.

SSH (Secure SHell, en español: intérprete de órdenes segura) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.

Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto archivos sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH.

En dos palabras: control absoluto. Ni que decir tiene las ventajas y los problemas que podemos solucionar teniendo el servicio activado en nuestro servidor... Pero, ¿estamos realmente tranquilos? ¿habremos puesto una contraseña suficientemente segura?... desde luego que no nos salva ni "el PIrri" de que nos den un par de achuchones si alguien ve el puerto 22 abierto .. en busca de tesoros...

Pues si no concilias bien el sueño pensando en tu ssh... sigue leyendo te ayudamos a configurarlo a nivel PARANOIDE...

Para ello utilizaremos el fichero de configuración de ssh, el programa fail2ban (para bannear indeseados), y la técnica portknocking ..

Las siguientes medidas las podemos implementar juntas o por separado según nuestro nivel de "paranoia".. 
 

1. Configurar adecuadamente ssh

/etc/ssh/sshd_config

Dentro de este archivo tenemos varias opciones para securizar nuestro ssh por ejemplo:

a) Ofuscación del puerto ssh (altamente aconsejable):

Normalmente el servicio lo tenemos por defecto en el puerto 22 esto lo podremos cambiar a nuestro criterio en el archivo de configuración de openssh . Sustituiremos el numero 22 por el que optemos por ejemplo 1247

port 1243

b) Restringir el acceso Root

Por ejemplo si no necesitamos en nuestro acceso remoto permisos de root, lo mas lógico es NO permitir acceso al mismo desde ssh.

PermitRootLogin no  

c) Restringir protocolos

Le diremos a ssh que sólo se utilizará Protocol 2, ya que Protocol 1 es considerado un tanto inseguro. 

protocol 2 

d) Limitar usuarios

Los ingresos de SSH pueden ser limitados a ciertos usuarios que necesitan acceso remoto. Agrega usuarios separados por espacio en /etc/ssh/sshd_config. 

Por ejemplo:

AllowUsers ana jose manu
 
otro ejemplo:

AllowUser pedro@217.158.45.*  

e) Limitar el número de reintentos

Por medio de la variable “MaxAuthTries”, podemos indicar el número de veces que nos podemos equivocar al introducir el nombre de usuario o la contraseña. Una vez superado el número que hayamos indicado, la conexión se perderá y habrá que empezar de nuevo el proceso de conexión. Con esto evitaremos ataques de persistencia de la conexión. 

Si queremos poner un máximo de 3 intentos, habría que indicarlo de la siguiente manera:

MaxAuthTries 3  

f) Limitar el número de pantallas de login

Limitar el número de ventanas de logueo simultáneas que podemos tener activas desde una misma IP, para de esta forma evitar ataques divididos.

Si queremos limitar a una única pantalla de logueo por IP, habría que hacerlo de la siguiente manera:

MaxStartups 1

g) Configurar el LogOut por tiempo de inactividad

Es recomendable configurar esta directiva para evitar sesiones SSH desatendidas.

ClientAliveInterval 300

h) Deshabilitar la autenticación basada en Host

Para deshabilitar este método de autenticación, modificamos o agregamos lo siguiente en sshd_config.

HostbasedAuthentication no

i) Utilizar autenticación mediante llaves públicas/privadas (SSH Public-Key / Private-Key Authentication)

Entrar con usuario y password está bien, pero podemos tener mas seguridad usando un par de claves pública y privada.

Creando nuestra clave publica (en nuestra máquina cliente)
 
ssh-keygen -t rsa
 
Al ejecutar este comando nos pide una clave. Le asignamos una y luego deberemos colocar en esa máquina remota la clave RSA pública que acabamos de generar ( /.ssh/id_rsa.pub ) en el directorio /.ssh/authorized_keys de el servidor ssh.

Habilitamos autenticación por clave (en el servidor)

Ahora es momento de volver a configurar /etc/ssh/sshd_config para habilitar la autenticación con las claves anteriormente añadidas /.ssh/authorized_keys del servidor ssh. En /etc/ssh/sshd_config :

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

2. Instalar Fail2Ban 

Fail2Ban es una aplicación que analiza continuamente los ficheros de log y bloquea las direcciones de Internet que hayan originado varias tentativas fallidas de acceso con una contraseña inválida.

Fail2Ban es extremadamente eficaz en la prevención de ataques de fuerza bruta y ataques de negación de servicio (DoS).

Además nos puede avisar de los intentos de "acceso" a nuestro correo.

Para instalarlo: 

root@server:~# aptitude install fail2ban whois

La documentación de fail2ban aconseja que toda la configuración se realice en archivos con la extensión .local. Estos pueden ser creados copiando el archivo de la configuración original, con la extensión .conf:

root@server:~# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

En una primera etapa, definimos cuáles son las direcciones que no estarán sujetas a restricciones (la dirección local y la red local), por cuánto tiempo estarán bloqueadas las direcciones de donde provengan las amenazas (1800 segundos (30 minutos) y después de cuántas tentativas (3 tentativas permitidas). Esta configuración debe realizarse en el archivo /etc/fail2ban/jail.local:


 También se define la dirección e-mail que recibirá las alertas en  /etc/fail2ban/jail.local:


Luego, debe configurarse la acción a realizar cuando se detecta un posible ataque. En este caso, la dirección IP del atacante es bloqueada y u e-mail es enviado al administrador del sistema.


Por último, se definen los parámetros del servicio que se pretende proteger. 

Para esto, se edita la sección JAILS del archivo /etc/fail2ban/jail.local: 

Una vez configurado e instalado hacemos un restart y ya lo tenemos en marcha:


/etc/init.d/file2band restart

3. Port Knocking ssh

Llegamos al final del viaje y con esto acabaremos de securizar nuestro servicio preferido...


Explicáremos brevemente en que consiste el port knocking ¡¡wikipedia!!

El golpeo de puertos (del inglés port knocking) es un mecanismo para abrir puertos externamente en un firewall mediante una secuencia preestablecida de intentos de conexión a puertos que se encuentran cerrados. Una vez que el firewall recibe una secuencia de conexión correcta, sus reglas son modificadas para permitir al host que realizó los intentos conectarse a un puerto específico.

La herramienta que vamos a utilizar es Knockd , una herramienta similar para windows seria knock knock.

Tras su instilación deberemos configurar el arranque del demonio knockd ;esto lo haremos facilmente en /etc/knockd.conf 

START_KNOCKD=1

El siguiente paso será definir la interfaz de red que vamos a utilizar...

# command line options 

 KNOCKD_OPTS="-i eth0"

Luego, tenemos que personalizar el fichero /etc/knockd.conf para especificar qué secuencia de puertos queremos y qué hacer cuando ésta llegue. En el “man knockd” encontramos interesantes ejemplos de uso, pero podemos centrarnos en el más típico que es el que instala Debian por defecto:

No hay que olvidar que lo que pretendemos es abrir un puerto de nuestro firewall, tras una secuencia de golpeo, y para abrir un puerto el requisito indispensable es que primero ha de estar cerrado, con lo que esto nos lleva a partir de que el puerto 22 ha de estar cerrado en nuestro firewall  por ejemplo la siguiente que solo permite conexiones salientes desde nuestra maquina y cierra todos los puertos de entrada...

iptables -P INPUT DROP
iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Tras configurar el /etc/knockd.conf a nuestro gusto, arrancamos el knockd con /etc/init.d/knockd start

Ya esta listo nuestro "PORTERO", ahora sólo necesitamos alguien o algo que le diga la contraseña para que nos deje pasar, lo que haremos es crearnos un script para hacer este proceso fácil en la maquina cliente... con la herramienta nmap podemos hacer la llamada de puertos fácilmente:

 
Para probar tan solo nos hace falta llamar a la puerta:

Con esto Knockd nos abrirá la puerta a ssh, tras hacer lo que tengamos que hacer la cerraremos con nuestra secuencia de cierre...

Knock 192.168.100.2 9000 8000 7000
 

Conclusión

Hemos conseguido securizar nuestro servicio SSH de tal forma que, para que alguien entre, necesitaría saber primero el puerto por el que estamos dando el servicio ssh, luego debería saber cual es nuestra secuencia de golpeo de puertos, saber el password de un usuario con permisos para utilizar ssh en remoto, saber su contraseña, y no podrá usar ssh con permisos de root.....una misión solo apta para "hackers muy aguerridos..."....