Mejorando la seguridad del servicio SSH

Antonio Ognio antonio@linux.org.pe

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

Instalacin
Ubuntu, Debian y distros derivadas:

$ sudo apt-get install ssh

RHEL, CentOS, Fedora y distros derivadas:

$ sudo yum install ssh

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

Uso bsico:
Acceso a la shell en un servidor remoto:
usuario@desktop:~$ ssh usuario@servidor.com usuario@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 the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable 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.pe usuario@host:~$

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

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 usuario2@otro.servidor.com:/ruta usuario@desktop:~$ scp -r otro.servidor.com:carpeta1 .

Cliente del servicio de FTP seguro (sftp):

usuario@desktop:~$ sftp usuario5@mi-otro.servidor.com sftp> pwd Remote working directory /home/usuario5 sftp> _

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

SSH nos permite:

Administrar servidores remotamente por la lnea de comandos Ejecutar comandos individuales Iniciar una sesin interactiva Transferir archivos scp (secure copy) sftp (secure file transfer protocol) Abrir tneles Puerto remoto disponible en un puerto local Puerto local disponible localmente en servidor remoto

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Potenciales problemas de seguridad:

Acceso por parte de usuarios no autorizados Usuarios de correo que siguen una shell activa Muchas veces es la misma contrasea Ex-trabajadores que an mantienen una cuenta Atacante interno que averigua la clave: Por ingeniera social (ej. hacindose pasar por el jefe) Mirando sobre los hombros del administrador Ataques desde Internet Fuerza bruta (probar muchas contraseas hasta que ligue) Exploits del servicio SSH (se aprovecha de bugs) SSH es un programa ms y puede tener bugs Man-in-the-middle
FEBRERO 2010

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

Detalles por corregir:

Utilizar solo la versin ms 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 contraseas Utilizar llaves criptogrficas (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

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Dnde hacer los cambios?

Respaldamos el actual archivo de configuracin:
sudo cp /etc/ssh/sshd_config /etc/ssh/ssd_config.bak

Editamos el archivo de configuracin:

sudo vi /etc/ssh/sshd_config sudo nano /etc/ssh/sshd_config

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Defaults de una buena distro:

Si no los tiene cambiarlos de inmediato:
# Solo el protocolo en su versin 2 Protocol 2 # Separacin de privilegios en el demonio ssh UsePrivilegeSeparation yes # Venta de tiempo para intentar iniciar sesin LoginGraceTime 120 # No permitir acceso a carpetas $HOME en las que # terceros usuarios tiene permiso de escritura StrictModes yes

En Ubuntu y Debian como en otras distros vienen por omisin.

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

Escoger quien tiene acceso:

Mejoras a realizar en cualquier sistema UNIX: # Deshabilitar el acceso como root PermitRootLogin no # Limitar acceso a solo una lista # de cuentas de usuario o grupos AllowUsers jperez mgarcia AllowGroups administradores Dejamos fuera a usuarios de correo y otros usuarios de UNIX
MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

Deshabilitar contraseas:
Eliminamos ataques de fuerza bruta comunes:

# Autenticacin usando contraseas PasswordAuthentication no # Uso de llaves criptogrficas RSAAuthentication yes PubkeyAuthentication yes # Ruta del archivo con llaves autorizadas por usuario AuthorizedKeysFile %h/.ssh/authorized_keys

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Generando una llave criptogrfica:

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

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

Observando los archivos generados:

Conozcamos como son las llaves que usa SSH: $ ls -l .ssh/
total 28 -rw-r--r--rw-------rw-r--r--rw-r--r--rw-r--r-1 1 1 1 1 usuario usuario usuario usuario usuario usuario 531 usuario 668 usuario 942 usuario 604 usuario 8470 2010-02-18 2008-09-05 2008-09-05 2008-09-05 2010-02-20 12:00 15:15 15:15 15:15 00:34 config id_dsa id_dsa.keystore id_dsa.pub 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

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Observando los archivos generados:

Les presento a una llave privada: $ cat .ssh/id_dsa
-----BEGIN DSA PRIVATE KEY----MIIBuwIBAAKBgQDp8z4vPh5em02JIoCETf2/HaP7+bfYb315Dl49rcCjH7KTvIin zOub3R1mnJx7E+f+e2hMFX6EVZRSvNLAYN8SnB0NF1SNGj1JirYDiPhFsHfoq+bm 2C0KXvExIttkYDwQVTb9gFEGyGAVoaA/2DblQgerJbRUZQpcykCrC2C/FwIVALHR vgAOs7AbwfbLNAnaMp/uhAAxAoGBAKcDS1GmlM8s2qt7vC1/mNHnVAAeh7idI7wv KVsQ/jPkOa/P3mcqYt2HbK62cbTkJDbtc+Vtkun89f+QeBmPdiZ0g7C4E8vnV6RR UXA4lz/NTRXYWwLPJ5dvLnMaL8hmtSx4HhTu1GYtIs1KMJmHd5I+ZHjMiKItuX/o OsK98wRxAoGAUE6qf6rQk5DGJada9jof1Ddpq5GRuDAB4mAbfApp1MRwHeylbIle wvdo8bUNrUIGPdGwXoyzCZogzH5CLgwGtGOE8O816PdE+D6GmthZT+8Wgw9OOV8b nqWMyhN4JQbsiNmtyr6nfYeQegIaoIcP1dAoyT7kM11taoKhSwTQxS0CFBjc2TCc Y+vRyigR3p5DKJibmFWA -----END DSA PRIVATE KEY-----

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Observando los archivos generados:

Les presento a una llave pblica: $ cat .ssh/id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAOnzPi8+Hl6bTYkigIRN/b8do/v5t9hvfXkOXj2twKMfspO8iKfM 65vdHWacnHsT5/57aEwVfoRVlFK80sBg3xKcHQ0XVI0aPUmKtgOI+EWwd+ir5ubYLQpe8TEi 22RgPBBVNv2AUQbIYBWhoD/YNuVCB6sltFRlClzKQKsLYL8XAAAAFQCx0b4ADrOwG8H2yzQJ 2jKf7oQAMQAAAIEApwNLUaaUzyzaq3u8LX+Y0edUAB6HuJ0jvC8pWxD+M+Q5r8/eZypi3Yds rrZxtOQkNu1z5W2S6fz1/5B4GY92JnSDsLgTy+dXpFFRcDiXP81NFdhbAs8nl28ucxovyGa1 LHgeFO7UZi0izUowmYd3kj5keMyIoi25f+g6wr3zBHEAAACAUE6qf6rQk5DGJada9jof1Ddp q5GRuDAB4mAbfApp1MRwHeylbIlewvdo8bUNrUIGPdGwXoyzCZogzH5CLgwGtGOE8O816PdE +D6GmthZT+8Wgw9OOV8bnqWMyhN4JQbsiNmtyr6nfYeQegIaoIcP1dAoyT7kM11taoKhSwTQ xS0= usuario@desktop

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Copiando la llave pblica al servidor:

Debe terminar en el archivo authorized_keys del usuario:
$ ssh-copy-id -i .ssh/id_dsa.pub usuario@servidor.com:
Password: Now try logging into the machine, with "ssh 'usuario@servidor.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Copiando la llave pblica al servidor:

Una manera alternativa mas explcita: $ 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 la llave pblica en el archivo de llaves autorizadas Copiando la llave pblica al equipo remoto y luego agregndola al final del archivo de llaves autorizadas
FEBRERO 2010

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

Verificando ubicacin de lleve:

Iniciamos sesin en el servidor remoto: $ cat .ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBAOnzPi8+Hl6bTYkigIRN/b8do/v5t9hvfXkOXj2twKMfspO8iKfM 65vdHWacnHsT5/57aEwVfoRVlFK80sBg3xKcHQ0XVI0aPUmKtgOI+EWwd+ir5ubYLQpe8TEi 22RgPBBVNv2AUQbIYBWhoD/YNuVCB6sltFRlClzKQKsLYL8XAAAAFQCx0b4ADrOwG8H2yzQJ 2jKf7oQAMQAAAIEApwNLUaaUzyzaq3u8LX+Y0edUAB6HuJ0jvC8pWxD+M+Q5r8/eZypi3Yds rrZxtOQkNu1z5W2S6fz1/5B4GY92JnSDsLgTy+dXpFFRcDiXP81NFdhbAs8nl28ucxovyGa1 LHgeFO7UZi0izUowmYd3kj5keMyIoi25f+g6wr3zBHEAAACAUE6qf6rQk5DGJada9jof1Ddp q5GRuDAB4mAbfApp1MRwHeylbIlewvdo8bUNrUIGPdGwXoyzCZogzH5CLgwGtGOE8O816PdE +D6GmthZT+8Wgw9OOV8bnqWMyhN4JQbsiNmtyr6nfYeQegIaoIcP1dAoyT7kM11taoKhSwTQ xS0= usuario@desktop

Ahora ya podemos autenticarnos sin utilizar contraseas

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

Recomendaciones sobre llaves:

Si no tienes cuidado puedes quedar fuera de tu propio servidor

Deja habilitada la autenticacin por contraseas hasta que la autenticacin por llaves funciones perfectamente Deja abierto un emulador de terminal mientras configuras y pruebas la autenticacin por contraseas

Cuida adecuadamente tu llave privada

No utilizar un passphrase es cmodo 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
FEBRERO 2010

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

Cambiando de puerto:
Despistamos a atacantes poco sofisticados: (scanners / bots)
# Configuracin 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 tcnica es bastante efectiva a pesar de ser tan simple

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

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

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010

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 esto finalice la sesin inmediatamente para evitar que tomemos acciones legales en su contra.

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Observando el banner en accin:

El mensaje lo ve el usuario antes de iniciar sesin:

$ ssh root@www.servidor.com
Ud. esta intentando acceder a un servidor privado. Si Ud. no cuenta con autorizacion explicita para esto finalice la sesin inmediatamente para evitar que tomemos acciones legales en su contra. Password: _

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Habilitando el puerto dinmicamente:

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 puerto solo a la IP que envi los paquetes Se implementa en Linux con knockd o iptables Single Packet Authentication Es una tcnica mas compleja que busca evitar los problemas ms comunes de port knocking Requiere de un paquete especialmente armando para los propsitos de autenticacin En linux se implementa con fwknop
FEBRERO 2010

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

Restringiendo acceso por wrappers:

Es til si estamos en una red local hostil o como una medida general 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.deny sshd: ALL

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Conclusiones: SSH es un servicio muy til Es necesario hacer hardening luego de la instalacin 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

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

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

MEJORANDO LA SEGURIDAD DEL SERVICIO SSH

FEBRERO 2010

Mejorando la seguridad del servicio SSH

Gracias! Preguntas?
Antonio Ognio antonio@linux.org.pe
GRUPO DE USUARIOS DE LINUX DEL PERU -//- FEBRERO 2010