SecNot

ene 17, 2014

Seguridad en SSH parte II

Continuamos Seguridad SSH parte I con más trucos para hacer el servicio un poco más seguro. En esta segunda parte tratamos de mejorar la seguridad de las claves, y dificultar la vida de un aracante que consiga acceso.

5. Limitar el acceso ssh a los usuarios

Por defecto todos los usuarios del sistema pueden conectarse usando ssh, pero si no todos los usuarios necesitan acceso ssh, por ejemplo tiene un usuario sólo para acceder por ftp, es posible restringir su acceso en el archivo /etc/ssh/sshd_config

DenyUsers ftpuser1, ftpuser2

o aún más seguro, restringir el acceso a todo los usuarios excepto los especificados:

AllowUsers secnot, juan

6. Desactivar claves vacías

Comprobar que usuarios con claves vacías no puedan hacer login, normalmente esta incluido en la configuración por defecto, pero es mejor comprobarlo en /etc/ssh/sshd_config:

PermitEmptyPasswords no

7. Firewall para el puerto SSH

Si las conexiones a SSH van a ser siempre desde una ip fija, es posible configurar el firewall para que permita conexiones sólo desde esa ip. Esto no es una guía de iptables, pero para acceso exclusivo desde la ip 82.168.100.7, podría ser algo similar a esto:

iptables -A INPUT -i eth0 -p tcp -s 82.168.100.7 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

antes de modificar iptables asegúrate que sabes lo que haces, porque te puedes quedar sin acceso remoto, si bloqueas el puerto por error.

8. Caducidad de sesiones inactivas

Cuando exista la posibilidad de que usuarios dejen abiertas sesiones ssh en ordenadores inseguros, es recomendable configurar sshd, para que las sesiones se cierren automáticamente tras un periodo de inactividad. En sshd_config añadimos o modificamos:

# Log Out tras 5 minutos
ClientAliveInterval 300
ClientAliveCountMax 0

Esto establece un periodo de 5 minutos (300 segundos). Cuando la sesión de un usuario está inactiva más de este intervalo, es cerrada automáticamente.

9. Fortaleza de las claves

Aunque no relacionado directamente con el servicio ssh, las claves de los usuarios son uno de sus principales puntos débiles, un usuario con una clave débil puede hacer todo el sistema vulnerable, aunque la mejor solución es desactivar login con claves y usar exclusivamente autenticación pública, desgraciadamente esto no es siempre posible, en estos casos se puede paliar el problema obligando a los usuarios a elegir mejores claves.

Pluggable Authentication Modules (PAM) es el encargado de proporcionar autenticación para usuarios y servicios en linux, y nos permite mediante distintos módulos, configurar prácticamente todos los aspectos del proceso. En este caso el modulo que nos interesa esta en /etc/pam.d/common-passwd donde tendremos que editar la linea:

#password       [success=1 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_unix.so obscure sha512 minlen=8

Así forzamos a que las claves sean al menos de 8 caracteres. Si esto no es suficiente, puedes probar el modulo pam_cracklib

secnot@servidor:~$ sudo apt-get install libpam-cracklib

Tras instalar cracklib editamos /etc/pam.d/common-password:

password requisite    pam_cracklib.so    retry=3 minlen=10 difok=3 ucredit=1 lcredit=1 dcredit=1

Esto forzará que las claves sean como mínimo de 10 caracteres, que al menos 3 caracteres cambiaron respecto a la clave anterior, al menos un carácter esté en minúsculas, uno en mayúsculas, y uno sea un número. Se pueden usar políticas mucho más restrictivas usando cracklib, pero llevado al extremo comienza a ser contraproducente, las claves resultantes son demasiado complejas para recordar, y acaban apuntadas en un post-it pegado al monitor.

10. Apparmor

En muchos casos los usuarios no necesitan tener más acceso que a su directorio personal, y siempre es buena política dar a los usuarios exactamente los mínimos privilegios posibles, tradicionalmente restringir el directorio se ha hecho con chroot, pero hoy en día apparmor me parece una solución más limpia y flexible.

Vamos a restringir el usuario juanjo, lo primero será crear una un link del shell bash a jailbash, para poder modificar las opciones de apparmor de forma independiente.

secnot@servidor:~$ sudo ln /bin/bash /usr/local/bin/jailbash

Añadimos jailbash a la lista de shells disponibles en /etc/shells

Y se asigna el nuevo shell al usuario a restringir

secnot@servidor:~$ sudo chsh -s /usr/local/bin/jaiblash juanjo

Tras esto creamos /etc/apparmor.d/usr.local.bin.jailbash que contiene el perfil apparmor para el nuevo shell, incluyo un ejemplo como patrón del contenido, pero es necesario adaptarlo a las necesidades de cada sistema y las restricciones del usuario.

#include <tunables/global>

/usr/local/bin/jailbash {
        #include <abstractions/base>
        #include <abstractions/bash>
        #include <abstractions/consoles>
        #include <abstractions/nameservice>
        #include <abstractions/user-manpages>
        #include <abstractions/user-tmp>

        deny /bin/df r,
        deny /etc/bash_command_not_found r,

        /bin/ r,
        /bin/bash rix,
        /bin/cat rix,
        /bin/chmod rix,
        /bin/chown rix,
        /bin/cp rix,
        /bin/date rix,
        /bin/egrep rix,
        /bin/grep rix,
        /bin/gunzip rix,
        /bin/gzip rix,
        /usr/local/bin/jailbash rix,
        /bin/ln rix,
        /bin/ls rix,
        /bin/mkdir rix,
        /bin/mktemp rix,
        /bin/more rix,
        /bin/mv rix,
        /bin/ping rix,
        /bin/readlink rix,
        /bin/rm rix,
        /bin/rmdir rix,
        /bin/sed rix,
        /bin/sleep rix,
        /bin/tar rix,
        /bin/touch rix,
        /bin/uname rix,
        /bin/vim rix,
        /bin/vim-normal rix,
        /bin/zcat rix,
        /dev/null rw,
        /dev/urandom r,
        /etc/ r,
        /etc/manpath.config r,
        /etc/opt/ r,
        /etc/sysconfig/console r,
        /etc/sysconfig/mail r,
        /etc/sysconfig/news r,
        /etc/vimrc r,

        owner /home/*/ r,
        owner /home/*/** rwl,
        /opt/ r,
        owner /proc/*/cmdline r,
        owner /proc/*/exe r,
        owner /proc/*/mounts r,

        /tmp/** rw,
        /proc/loadavg r,
        /usr/bin/ r,
        /usr/bin/groups rix,
        /usr/bin/lesspipe rix,
        /usr/bin/cut rix,
        /usr/bin/whereis rix,
        /usr/bin/sort rix,
        /usr/bin/basename rix,
        /usr/bin/head rix,
        /usr/bin/id rix,
        /usr/bin/less rix,
        /usr/bin/man rix,
        /usr/bin/manpath rix,
        /usr/bin/mc rix,
        /usr/bin/scp rix,
        /usr/bin/screen rix,
        /usr/bin/ssh rix,
        /usr/bin/ssh-add rix,
        /usr/bin/ssh-agent rix,
        /usr/bin/ssh-copy-id rix,
        /usr/bin/ssh-keygen rix,
        /usr/bin/ssh-keyscan rix,
        /usr/bin/tail rix,
        /usr/bin/tty rix,
        /usr/bin/vim rix,
        /usr/bin/wget rix,
        /usr/bin/which rix,
        /usr/lib*/mc/cons.saver rix,
        /usr/lib*/ssh/ssh-keysign rix,
        /usr/local/bin/ r,
        /usr/share/mc/** r,
        /usr/share/vim/** r,
}

Por último activamos apparmor para jailbash:

secnot@servidor:~$ sudo aa-enforce jailbash
Setting /etc/apparmor.d/usr.local.bin.jailbash to enforce mode.
Click to read and post comments

ene 14, 2014

Seguridad en SSH parte I

SSH (Secure Shell) es un protocolo de comunicación cifrado, que permite el acceso remoto, y la ejecución remota de comandos. Probablemente sea el único servicio disponible en todo servidor, y aunque el protocolo es seguro, la configuración por defecto no suele ser la más adecuada.

Aparte se usar claves de calidad para los usuarios del servidor, hay muchas pequeñas modificaciones que pueden incrementar sustancialmente la seguridad del servicio.

1. Cambiar el puerto por defecto

Por defecto ssh escucha el puerto 22, de manera que es fácil para cualquier atacante escanear el puerto para determinar si ssh se está ejecutando. Cambiando el puerto se soluciona parcialmente el problema, los escaneos automáticos no encontrarán el puerto, en cambio un atacante interesado específicamente en tu servidor, puede escaneará todos los puertos hasta encontrar ssh.

Aun así este cambio es muy sencillo, nos protege de ataques automáticos, e hipotéticos exploits remotos que puedan aparecer algún día.

Para modificar el puerto sólo es necesario editar /etc/ssh/sshd_config añadiendo o modificando la linea:

# Nuevo puerto ssh
Port 7544

y reiniciar el servicio sshd

secnot@servidor:~$ sudo service sshd restart

para conectar ahora hay que usar

secnot@cliente:~$ ssh servidor -p 7544

2. Desactivar login al root

Acceder como root a cualquier sistema es una mala practica, especialmente en logins remotos, siempre es preferible tener un usuario con permisos sudo para ejecutar comandos como root. Si este es tu caso, es recomendable prohibir el acceso por ssh al usuario root.

El primer paso es asegurarnos que tenemos al menos un usuario con permisos para usar sudo, si no es así nos quedaríamos sin acceso como root al servidor.

secnot@servidor:~$ whoami
secnot
secnot@servidor:~$ sudo whoami
[sudo] password for secnot:
root

Si da algun problema al ejecutar sudo no continuar con este paso. Para modificar la configuracion editamos /etc/ssh/sshd_config:

# Desactivar login para root
PermitRootLogin no

y reiniciamos el servicio

secnot@servidor:~$ sudo service sshd restart

3. Desactivar protocolo 1

SSH puede usar dos protocolos 1 y 2, el protocolo 1 es el más antiguo y fue remplazado por el 2, cuando se descubrieron ciertas vulnerabilidades, pero algunas distribuciones de unix/linux, aún continúan permitiendo usar ambos para mantener compatibilidad hacia atrás. Es recomendable desactivar el protocolo 1, para ello editamos /etc/ssh/sshd_config:

# Protocol 2,1
Protocol 2

y reiniciamos el servicio

4. Usar autenticación de clave Publica

Tiene dos ventajas, la primera es que es posible hacer login sin introducir la clave, y la segunda, es que podremos desactivar completamente el login con claves, haciendo imposibles los ataques por fuerza bruta o diccionario. El primer paso es generar un par del claves publica/privada en el cliente:

secnot@cliente:~$ ssh-keygen -b 4096 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/secnot/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/secnot/.ssh/id_rsa.
Your public key has been saved in /home/secnot/.ssh/id_rsa.pub.
The key fingerprint is:
0d:d2:94:07:93:a9:dd:b9:33:73:fb:f1:6e:3e:ce:d7 secnot@client
The keys randomart image is:
+--[ RSA 4096]----+
|     ..          |
|      .. .  .    |
|      .oo o. o   |
|     .+o.=. . .  |
|     ..oSo   .   |
|       ooo. .    |
|        E..  .   |
|         . .  .. |
|            ..o. |
+-----------------+

Primero pregunta en que directorio deseas guardar el par de claves, a no ser que tengas otro par y no quieras confusiones, usa el directorio por defecto.

En el segundo paso te pide un passphrase (una clave para proteger el par de claves), si no se la proporcionas cualquiera que consiga acceso al par de claves, tendrá acceso automático al servidor, a cambio no tendrás que introducir una clave cuando hagas login. En cambio si proporcionas un passphrase si que tendrás que introducir una clave para hacer login, pero si el par de claves es robado, no podrán usarlo para acceder al servidor. Tu decisión

Por último queda subir las claves al servidor, para ello hay que añadir el contenido de la clave pública id_rsa.pub al archivo ~/.ssh/authorized_keys de tu usuario en el servidor. Para facilitar la tarea existe la utilidad ssh-copy-id:

secnot@cliente:~$ ssh-copy-id -i .ssh/id_rsa.pub secnot@servidor
secnot@servidor's password:
Now try logging into the machine, with "ssh 'secnot@servidor'", and check in:

~/.ssh/authorized_keys

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

Si ssh-copy-id no está disponible en tu sistema, puedes hacerlo manualmente, si no existe creamos el directorio .ssh en el servidor

secnot@servidor:~$ mkdir .ssh
secnot@servidor:~$ chmod 700 .ssh

copiamos el archivo de clave publica .ssh/id_rsa.pub al servidor:

secnot@cliente:~$ scp ~/.ssh/id_rsa.pub secnot@servidor:./

añadimos id_rsa.pub a ~/.ssh/authorized_keys, y nos aseguramos que los permisos del archivo sean los correctos

secnot@servidor:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
secnot@servidor:~$ chmod 600 ~/.ssh/authorized_keys
secnot@servidor:~$ rm id_rsa.pub

Una vez tengas comprobado que todo funciona correctamente, y que puedes hacer login usando ssh, ya sea sin clave o con tu passphrase, puedes dar el ultimo paso, desactivar la autenticación por clave, modificando el archivo /etc/ssh/sshd_config

# Desactivar logins usando claves
PasswordAuthentication no

Por ultimo, asegúrate de guardar una copia de el par de claves id_rsa e id_rsa.pub, si las pierdes no podrás acceder al servidor remotamente.

Seguridad SSH parte II

Click to read and post comments