mejorando la seguridad del servicio ssh - hardening

Mejorando la seguridaddel servicio SSH

Antonio [email protected]

GRUPO DE USUARIOS DE LINUX DEL PERU -//- FEBRERO 2010

InstalaciónUbuntu, Debian y distros derivadas:

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

$ sudo apt-get install ssh

RHEL, CentOS, Fedora y distros derivadas:

$ sudo yum install ssh

Uso básico:Acceso a la shell en un servidor remoto:


usuario@desktop:~$ ssh [email protected]@servidor.com's password:Linux host.servidor.com 2.6.18.8-srv #1 SMP Tue Nov 10 16:12:12 UTC 2009 i686

The programs included with the Ubuntu system are free software;the exact distribution terms for each program are described in theindividual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted byapplicable law.

To access official Ubuntu documentation, please visit:http://help.ubuntu.com/Last login: Fri Feb 19 22:27:15 2010 from desktop.empresa.com.peusuario@host:~$

Otros usos comunes:Ejecutar comandos en un servidor remoto:


usuario@desktop:~$ ssh mail.miempresa.com "uptime"12:18:15 up 2 days, 1:57, 0 users, load average: 0.00, 0.01, 0.00

Copiar archivos a / desde un servidor remoto:

usuario@desktop:~$ scp -r carpeta1 [email protected]:/ruta

usuario@desktop:~$ scp -r otro.servidor.com:carpeta1 .

Cliente del servicio de FTP seguro (sftp):

usuario@desktop:~$ sftp [email protected] sftp> pwdRemote working directory /home/usuario5sftp> _

SSH nos permite:● Administrar servidores remotamente por la línea de comandos

● Ejecutar comandos individuales● Iniciar una sesión interactiva

● Transferir archivos● scp (secure copy)● sftp (secure file transfer protocol)

● Abrir túneles● Puerto remoto disponible en un puerto local● Puerto local disponible localmente en servidor remoto


Potenciales problemas de seguridad:● Acceso por parte de usuarios no autorizados

● Usuarios de correo que siguen una shell activa● Muchas veces es la misma contraseña

● Ex-trabajadores que aún mantienen una cuenta● Atacante interno que averigua la clave:

● Por ingeniería social (ej. haciéndose pasar por el jefe)● Mirando sobre los hombros del administrador

● Ataques desde Internet● Fuerza bruta (probar muchas contraseñas hasta que ligue)● Exploits del servicio SSH (se aprovecha de bugs)

● SSH es un programa más y puede tener bugs● Man-in-the-middle


Detalles por corregir:● Utilizar solo la versión más segura del protocolo

● Deshabilitar el acceso como root● Utilizar sudo para convertirse en root

● Limitar el acceso solo a cuentas autorizadas

● Deshabilitar por completo el uso de contraseñas● Utilizar llaves criptográficas (DSA / RSA)

● Utilizar un puerto distinto● Despistar a muchos atacantes no muy sofisticados

● Advertir adecuadamente a potenciales usuarios no autorizados● Colocar un banner que mencione las leyes locales

● Abrir el puento solo a IPs autorizadas● TCP wrappers● Port knocking● Single Packet Authorization


¿Dónde hacer los cambios?


Respaldamos el actual archivo de configuración:

sudo cp /etc/ssh/sshd_config /etc/ssh/ssd_config.bak

Editamos el archivo de configuración:

sudo vi /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

Defaults de una buena distro:


Si no los tiene cambiarlos de inmediato:

# Solo el protocolo en su versión 2Protocol 2

# Separación de privilegios en el demonio sshUsePrivilegeSeparation yes

# Venta de tiempo para intentar iniciar sesiónLoginGraceTime 120

# No permitir acceso a carpetas $HOME en las que # terceros usuarios tiene permiso de escrituraStrictModes yes

En Ubuntu y Debian como en otras distros vienen por omisión.

Escoger quien tiene acceso:


Mejoras a realizar en cualquier sistema UNIX:

Dejamos fuera a usuarios de correo y otros usuarios de UNIX

# Deshabilitar el acceso como root

PermitRootLogin no

# Limitar acceso a solo una lista # de cuentas de usuario o grupos

AllowUsers jperez mgarciaAllowGroups administradores

Deshabilitar contraseñas:


Eliminamos ataques de fuerza bruta comunes:

# Autenticación usando contraseñasPasswordAuthentication no

# Uso de llaves criptográficasRSAAuthentication yesPubkeyAuthentication yes

# Ruta del archivo con llaves autorizadas por usuarioAuthorizedKeysFile %h/.ssh/authorized_keys

Generando una llave criptográfica:


Eliminamos ataques de fuerza bruta comunes:

$ ssh-keygen -t dsa

Generating public/private dsa key pair.Enter file in which to save the key (/home/usuario/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/usuario/.ssh/id_dsa.Your public key has been saved in /home/usuario/.ssh/id_dsa.pub.The key fingerprint is:~3d:43:8e:52:ac:e1:8c:97:da:16:d4:9b:37:4d:ba:80 usuario@desktop

IMPORTANTE: Guarda tu llave privada en un lugar seguro

Observando los archivos generados:


Conozcamos como son las llaves que usa SSH:

$ ls -l .ssh/

total 28-rw-r--r-- 1 usuario usuario 531 2010-02-18 12:00 config-rw------- 1 usuario usuario 668 2008-09-05 15:15 id_dsa-rw-r--r-- 1 usuario usuario 942 2008-09-05 15:15 id_dsa.keystore-rw-r--r-- 1 usuario usuario 604 2008-09-05 15:15 id_dsa.pub-rw-r--r-- 1 usuario usuario 8470 2010-02-20 00:34 known_hosts

$ file .ssh/id_dsa.ssh/id_dsa: PEM DSA private key

$ file .ssh/id_dsa.pub .ssh/id_dsa.pub: ASCII text, with very long lines



Les presento a una llave privada:

$ cat .ssh/id_dsa

-----BEGIN DSA PRIVATE KEY-----MIIBuwIBAAKBgQDp8z4vPh5em02JIoCETf2/HaP7+bfYb315Dl49rcCjH7KTvIinzOub3R1mnJx7E+f+e2hMFX6EVZRSvNLAYN8SnB0NF1SNGj1JirYDiPhFsHfoq+bm2C0KXvExIttkYDwQVTb9gFEGyGAVoaA/2DblQgerJbRUZQpcykCrC2C/FwIVALHRvgAOs7AbwfbLNAnaMp/uhAAxAoGBAKcDS1GmlM8s2qt7vC1/mNHnVAAeh7idI7wvKVsQ/jPkOa/P3mcqYt2HbK62cbTkJDbtc+Vtkun89f+QeBmPdiZ0g7C4E8vnV6RRUXA4lz/NTRXYWwLPJ5dvLnMaL8hmtSx4HhTu1GYtIs1KMJmHd5I+ZHjMiKItuX/oOsK98wRxAoGAUE6qf6rQk5DGJada9jof1Ddpq5GRuDAB4mAbfApp1MRwHeylbIlewvdo8bUNrUIGPdGwXoyzCZogzH5CLgwGtGOE8O816PdE+D6GmthZT+8Wgw9OOV8bnqWMyhN4JQbsiNmtyr6nfYeQegIaoIcP1dAoyT7kM11taoKhSwTQxS0CFBjc2TCcY+vRyigR3p5DKJibmFWA-----END DSA PRIVATE KEY-----



Les presento a una llave pública:

$ cat .ssh/id_dsa.pub

ssh-dss AAAAB3NzaC1kc3MAAACBAOnzPi8+Hl6bTYkigIRN/b8do/v5t9hvfXkOXj2twKMfspO8iKfM65vdHWacnHsT5/57aEwVfoRVlFK80sBg3xKcHQ0XVI0aPUmKtgOI+EWwd+ir5ubYLQpe8TEi22RgPBBVNv2AUQbIYBWhoD/YNuVCB6sltFRlClzKQKsLYL8XAAAAFQCx0b4ADrOwG8H2yzQJ2jKf7oQAMQAAAIEApwNLUaaUzyzaq3u8LX+Y0edUAB6HuJ0jvC8pWxD+M+Q5r8/eZypi3YdsrrZxtOQkNu1z5W2S6fz1/5B4GY92JnSDsLgTy+dXpFFRcDiXP81NFdhbAs8nl28ucxovyGa1LHgeFO7UZi0izUowmYd3kj5keMyIoi25f+g6wr3zBHEAAACAUE6qf6rQk5DGJada9jof1Ddpq5GRuDAB4mAbfApp1MRwHeylbIlewvdo8bUNrUIGPdGwXoyzCZogzH5CLgwGtGOE8O816PdE+D6GmthZT+8Wgw9OOV8bnqWMyhN4JQbsiNmtyr6nfYeQegIaoIcP1dAoyT7kM11taoKhSwTQxS0= usuario@desktop

Copiando la llave pública al servidor:


Debe terminar en el archivo authorized_keys del usuario:

$ ssh-copy-id -i .ssh/id_dsa.pub [email protected]:

Password:Now try logging into the machine, with "ssh '[email protected]'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Copiando la llave pública al servidor:


Una manera alternativa mas explícita:

$ cat ~/.ssh/id_dsa.pub |ssh equipo_remoto 'mkdir -p ~/.ssh; cat - >> ~/.ssh/authorized_keys'

Otras forma de hacerlo:

● Copiando y pegando directamente el contenido de lallave pública en el archivo de llaves autorizadas

● Copiando la llave pública al equipo remoto y luego agregándola al final del archivo de llaves autorizadas

Verificando ubicación de lleve:


Iniciamos sesión en el servidor remoto:

$ cat .ssh/authorized_keys

ssh-dss AAAAB3NzaC1kc3MAAACBAOnzPi8+Hl6bTYkigIRN/b8do/v5t9hvfXkOXj2twKMfspO8iKfM65vdHWacnHsT5/57aEwVfoRVlFK80sBg3xKcHQ0XVI0aPUmKtgOI+EWwd+ir5ubYLQpe8TEi22RgPBBVNv2AUQbIYBWhoD/YNuVCB6sltFRlClzKQKsLYL8XAAAAFQCx0b4ADrOwG8H2yzQJ2jKf7oQAMQAAAIEApwNLUaaUzyzaq3u8LX+Y0edUAB6HuJ0jvC8pWxD+M+Q5r8/eZypi3YdsrrZxtOQkNu1z5W2S6fz1/5B4GY92JnSDsLgTy+dXpFFRcDiXP81NFdhbAs8nl28ucxovyGa1LHgeFO7UZi0izUowmYd3kj5keMyIoi25f+g6wr3zBHEAAACAUE6qf6rQk5DGJada9jof1Ddpq5GRuDAB4mAbfApp1MRwHeylbIlewvdo8bUNrUIGPdGwXoyzCZogzH5CLgwGtGOE8O816PdE+D6GmthZT+8Wgw9OOV8bnqWMyhN4JQbsiNmtyr6nfYeQegIaoIcP1dAoyT7kM11taoKhSwTQxS0= usuario@desktop

Ahora ya podemos autenticarnos sin utilizar contraseñas

Recomendaciones sobre llaves:● Si no tienes cuidado puedes quedar fuera de tu propio servidor

● Deja habilitada la autenticación por contraseñas hasta que la autenticación por llaves funciones perfectamente

● Deja abierto un emulador de terminal mientras configuras● y pruebas la autenticación por contraseñas


● Cuida adecuadamente tu llave privada

● No utilizar un passphrase es cómodo pero inseguro● Utilizar un passphrase agrega un segundo factor de seguridad

● La llave: algo que tu tienes● El passphrase: algo que tu sabes

● Respalda tu llave en un sitio seguro

Cambiando de puerto:


Despistamos a atacantes poco sofisticados: (scanners / bots)

# Configuración del puerto del servicio SSH# Un valor entre 10000 y 65535 es bueno

Port 62131

# Solo escuchamos en la interfaz de red necesaria

Listen 208.34.51.190

# Para escuchar en todas# ListenAddress 0.0.0.0

Esta técnica es bastante efectiva a pesar de ser tan simple

Aprovechando el archivo config:


Facilita el tener que recordar usuarios, puertos, direcciones IP:

host cloudserver-18 hostname 201.230.200.47 user jperez port 62163 Compression yes

host firewall-lima hostname 192.168.1.254 user administrador port 22

Este archivo se ubica en $HOME/.ssh/config

Colocando un banner:


Puede ser necesario para reforzar la defensa legal:

# Banner /etc/motd

Banner /etc/banner-ssh

Contenido del archivo:

Ud. esta intentando acceder a un servidor privado.

Si Ud. no cuenta con autorizacion explicita para estofinalice la sesión inmediatamente para evitar que tomemos acciones legales en su contra.

Observando el banner en acción:


El mensaje lo ve el usuario antes de iniciar sesión:

$ ssh [email protected]. esta intentando acceder a un servidor privado.

Si Ud. no cuenta con autorizacion explicita para estofinalice la sesión inmediatamente para evitar que tomemos acciones legales en su contra.

Password: _

Habilitando el puerto dinámicamente:● Port Knocking

● Consiste en enviar una secuencia de paquetes a una lista previamente conocida de puertos

● Si la secuencia es la esperada se abre el puertosolo a la IP que envió los paquetes

● Se implementa en Linux con knockd o iptables

● Single Packet Authentication● Es una técnica mas compleja que busca evitar los

problemas más comunes de port knocking● Requiere de un paquete especialmente armando para

los propósitos de autenticación● En linux se implementa con fwknop


Restringiendo acceso por wrappers:


Es útil si estamos en una red local hostil o como una medidageneral de seguridad:

## /etc/hosts.allow ## This file describes the names of the hosts which are# allowed to use the local INET services, as decided# by the '/usr/sbin/tcpd' server.sshd: 192.168.1.0/255.255.255.0

## /etc/hosts.denysshd: ALL

Conclusiones:● SSH es un servicio muy útil● Es necesario hacer “hardening” luego de la instalación

● Solo se debe autorizar a una lista de usuarios● Es buena idea permitir solo acceso por llaves● Es buena idea cambiar de puerto a uno no estandar

● Es buena idea colocar un banner antes del acceso

● Lo ideal es habilitar el puerto solo a la IP del administrador


Algunos enlaces:

http://rnt.cl/tutoriales/como-crear-llaves-ssh/

http://www.linuxjournal.com/article/9565

http://www.securecentos.com/basic-security/hardening-sshd/

http://www.daemonforums.org/showthread.php?t=74

http://www.medorion.net/p/11.xhtml

http://linuxhelp.blogspot.com/2005/10/using-tcp-wrappers-to-secure-linux.html


http://rnt.cl/tutoriales/como-crear-llaves-ssh/

http://www.linuxjournal.com/article/9565

http://www.securecentos.com/basic-security/hardening-sshd/

http://www.daemonforums.org/showthread.php?t=74

http://www.medorion.net/p/11.xhtml

http://linuxhelp.blogspot.com/2005/10/using-tcp-wrappers-to-secure-linux.html

Mejorando la seguridaddel servicio SSH

Antonio [email protected]

GRUPO DE USUARIOS DE LINUX DEL PERU -//- FEBRERO 2010

¡Gracias!

¿Preguntas?

mejorando la seguridad del servicio ssh - hardening

Technology