Mejorando la seguridad
      del servicio SSH

                 Antonio Ognio
              antonio@linux.org.pe



GRUPO ...
Instalación

 Ubuntu, Debian y distros derivadas:



    $ sudo apt-get install ssh

 RHEL, CentOS, Fedora y distros deriv...
Uso básico:

 Acceso a la shell en un servidor remoto:
   usuario@desktop:~$ ssh usuario@servidor.com
   usuario@servidor....
Otros usos comunes:

 Ejecutar comandos en un servidor remoto:
   usuario@desktop:~$ ssh mail.miempresa.com "uptime"
   12...
SSH nos permite:
 ●
     Administrar servidores remotamente por la línea de comandos
     ●
       Ejecutar comandos indiv...
Potenciales problemas de seguridad:
 ●
     Acceso por parte de usuarios no autorizados
     ●
       Usuarios de correo q...
Detalles por corregir:
 ●
     Utilizar solo la versión más segura del protocolo

 ●
     Deshabilitar el acceso como root...
¿Dónde hacer los cambios?

 Respaldamos el actual archivo de configuración:

   sudo cp /etc/ssh/sshd_config /etc/ssh/ssd_...
Defaults de una buena distro:
 Si no los tiene cambiarlos de inmediato:
   # Solo el protocolo en su versión 2
   Protocol...
Escoger quien tiene acceso:
 Mejoras a realizar en cualquier sistema UNIX:

   # Deshabilitar el acceso como root

   Perm...
Deshabilitar contraseñas:
 Eliminamos ataques de fuerza bruta comunes:


   # Autenticación usando contraseñas
   Password...
Generando una llave criptográfica:
 Eliminamos ataques de fuerza bruta comunes:


   $ ssh-keygen -t dsa

   Generating pu...
Observando los archivos generados:
 Conozcamos como son las llaves que usa SSH:

   $ ls -l .ssh/

   total 28
   -rw-r--r...
Observando los archivos generados:
 Les presento a una llave privada:

   $ cat .ssh/id_dsa
   -----BEGIN DSA PRIVATE KEY-...
Observando los archivos generados:
 Les presento a una llave pública:

   $ cat .ssh/id_dsa.pub
   ssh-dss
   AAAAB3NzaC1k...
Copiando la llave pública al servidor:

 Debe terminar en el archivo authorized_keys del usuario:

   $ ssh-copy-id -i .ss...
Copiando la llave pública al servidor:

 Una manera alternativa mas explícita:

   $ cat ~/.ssh/id_dsa.pub |
   ssh equipo...
Verificando ubicación de lleve:
 Iniciamos sesión en el servidor remoto:

   $ cat .ssh/authorized_keys
   ssh-dss
   AAAA...
Recomendaciones sobre llaves:
●
    Si no tienes cuidado puedes quedar fuera de tu propio servidor

    ●
        Deja hab...
Cambiando de puerto:
 Despistamos a atacantes poco sofisticados: (scanners / bots)

   # Configuración del puerto del serv...
Aprovechando el archivo config:
 Facilita el tener que recordar usuarios, puertos, direcciones IP:

   host cloudserver-18...
Colocando un banner:
 Puede ser necesario para reforzar la defensa legal:

   # Banner /etc/motd

   Banner /etc/banner-ss...
Observando el banner en acción:
 El mensaje lo ve el usuario antes de iniciar sesión:

   $ ssh root@www.servidor.com
   U...
Habilitando el puerto dinámicamente:
 ●
     Port Knocking
     ●
       Consiste en enviar una secuencia de paquetes a un...
Restringiendo acceso por wrappers:
 Es útil si estamos en una red local hostil o como una medida
 general de seguridad:

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

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

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

 http://www...
Mejorando la seguridad
      del servicio SSH

                 ¡Gracias!

            ¿Preguntas?
                  Anton...
Upcoming SlideShare
Loading in …5
×

Mejorando la seguridad del servicio SSH - Hardening

8,113 views

Published on

Una introducción de nivel intermedio al "hardening" o mejoramiento de las políticas que afectan la seguridad de un servicio SSH.

Presentada en las reuniones del Grupo de Usuarios de Linux del Perú el mes de Febrero de 2010.

Más información en http://www.linux.org.pe

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,113
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
218
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Mejorando la seguridad del servicio SSH - Hardening

  1. 1. Mejorando la seguridad del servicio SSH Antonio Ognio antonio@linux.org.pe GRUPO DE USUARIOS DE LINUX DEL PERU -//- FEBRERO 2010
  2. 2. Instalación 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
  3. 3. Uso básico: 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
  4. 4. 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
  5. 5. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  6. 6. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  7. 7. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  8. 8. ¿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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  9. 9. Defaults de una buena distro: Si no los tiene cambiarlos de inmediato: # Solo el protocolo en su versión 2 Protocol 2 # Separación de privilegios en el demonio ssh UsePrivilegeSeparation yes # Venta de tiempo para intentar iniciar sesión 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 omisión. MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  10. 10. 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
  11. 11. Deshabilitar contraseñas: Eliminamos ataques de fuerza bruta comunes: # Autenticación usando contraseñas PasswordAuthentication no # Uso de llaves criptográficas 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
  12. 12. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  13. 13. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  14. 14. 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
  15. 15. Observando los archivos generados: Les presento a una llave pública: $ 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
  16. 16. Copiando la llave pública 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
  17. 17. 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 la llave 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  18. 18. Verificando ubicación de lleve: Iniciamos sesión 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 contraseñas MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  19. 19. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  20. 20. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  21. 21. 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
  22. 22. 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 sesión inmediatamente para evitar que tomemos acciones legales en su contra. MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  23. 23. Observando el banner en acción: El mensaje lo ve el usuario antes de iniciar sesión: $ ssh root@www.servidor.com Ud. esta intentando acceder a un servidor privado. Si Ud. no cuenta con autorizacion explicita para esto finalice la sesión inmediatamente para evitar que tomemos acciones legales en su contra. Password: _ MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  24. 24. 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 puerto solo 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  25. 25. 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
  26. 26. 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 MEJORANDO LA SEGURIDAD DEL SERVICIO SSH FEBRERO 2010
  27. 27. 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
  28. 28. Mejorando la seguridad del servicio SSH ¡Gracias! ¿Preguntas? Antonio Ognio antonio@linux.org.pe GRUPO DE USUARIOS DE LINUX DEL PERU -//- FEBRERO 2010

×