SecNot

Instalación

En el huésped en el que se van a alojar las maquinas, son necesarios los siguientes paquetes:

$ sudo apt-get install ubuntu-virt-server qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

desde donde vayas gestionar las maquinas, es recomendable instalar:

$ sudo apt-get install virt-manager

Configuracion de red

El siguiente paso es modificar la configuración de red del anfitrión, yo prefiero usar bridging de manera que las maquinas virtuales tengan asignadas direcciones de red validas. El funcionamiento es ingenioso, se crea un switch virtual usando la tarjeta de red física, al que los huéspedes se conectan como si se tratara de una conexión real.

Solo es necesario modificar en archivo /etc/network/interfaces, por ejemplo si este es el archivo original:

#/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.0.42
    network 192.168.0.0
    netmask 255.255.255.0
    broadcast 192.168.0.255
    gateway 192.168.0.1
    dns-nameserver 80.53.60.25

Debemos convertir el interfaz eth0 en br0 y añadir las opciones:

#/etc/network/interfaces

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
    address 192.168.0.42
    network 192.168.0.0
    netmask 255.255.255.0
    broadcast 192.168.0.255
    gateway 192.168.0.1
    dns-nameserver 80.53.60.25
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 4

Tras esto reinicia el sistema o el servicio de red.

$ /etc/init.d/networking restart
$ reboot

Configuración del sistema

Añade un usuario al grupo de libvirtd y kvm para que pueda manipulas las maquinas, sin necesidad de ser root:

$ sudo adduser `id -un` libvirtd
$ sudo adduser `id -un` kvm

Crea un directorio donde almacenar las imágenes KVM, por ejemplo:

$ mkdir /home/kvm-images
$ chown libvirt-qemu:libvirtd /home/kvn-images

Adicionalmente puedes crea un par de claves ssh para el usuario, de forma que no tengas que introducir la clave cada vez que administras remotamente la máquina. En este post explico como se hace.

Crear la máquina virtual

Con todo configurado ya estamos listos para crear la máquina con el comando ubuntu-vm-builder:

$ sudo ubuntu-vm-builder kvm trusty \
    --domain servidor \
    --hostname kvm1 \
    --arch amd64 \
    --mem 2048 \
    --cpus 1 \
    --rootsize 20000 \
    --swapsize 2048 \
    --destdir /home/kvm-images/kvm2 \
    --user secnot \
    --pass secreto \
    --bridge br0 \
    --ip 192.168.0.201 \
    --mask 255.255.255.0 \
    --net 192.168.0.0 \
    --bcast 192.168.0.255 \
    --gw 192.168.0.1 \
    --dns 80.53.60.25 \
    --components main,universe \
    --addpkg acpid \
    --addpkg openssh-server \
    --addpkg linux-image-generic \
    --addpkg unattended-upgrades \
    --libvirt qemu:///system ;

Aunque todos esos parámetros parecen muy complicados, sólo la primera linea es necesaria, las demás permiten especificar la configuración para el huésped:

• destdir - Directorio en el que quieres que se cree la imagen.
• domain, hostname - Dominio y nombre de host del huésped.
• arch - Arquitectura de la maquina a instalar.
• mem, cpus - Cuanta memoria y CPUs son asignadas al huésped.
• rootsize, swapsize - Tamaño del disco raíz en MB (por defecto 4000MB), y de la partición de intercambio.
• user, pass - Nombre de usuario y clave para la primera cuenta de usuario en el huésped.
• bridge - Indica a que bridge conectar el interfaz de red del huésped.
• ip, mask, bcast, gw, dns - Configuración de red para el huésped.
• mirror, components - Indica al huésped de que repositorio descargar los paquetes, útil para acelerar la instalacion si tienes copias locales.
• addpkg - Paquetes a instalar en el huesped durante su creación. Algunos paquetes son imprescindibles, acpid para poder apagar la maquina, openssh-server para poder conectarse remotamente, y linux-image-generic para evitar el error "This kernel does not support a non-PAE CPU"
• libvirt - Indica al instalador en que host debe instalar la maquina.
• ssh-key - Añade la clave pública suministrada (ruta absoluta) a la lista de claves autorizadas del root.

Podemos comprobar que está funcionando correctamente con virsh:

$ virsh list --all
Id    Nombre                         Estado
----------------------------------------------------
1     kvm1                           ejecutando

Si no fue arrancado automáticamente, puedes hacerlo a mano con:

$ virsh start kvm1
Se ha iniciado el dominio kvm1

y detenerlo con:

$ virsh shutdown kvm1
El dominio kvm1 está siendo apagado

Gestión remota

Si además quieres gestionar de forma remota todos los huéspedes KVM, instala virt-manager, y añade la dirección ip del anfitrión con Archivo>Añadir conexión... usando como nombre de usuario la cuenta que añadiste a los grupos de kvm. El resultado debería ser similar a esto:

Si haces doble click en cualquiera de las máquinas, puedes abrir una consola, o la página de detalles de configuración seleccionando vista en la barra de tareas:

Enlaces

• Pagina oficial de KVM
• Manual ubuntu-vm-builder
• Virtualization With KVM On Ubuntu 12.04 LTS

Instalación

La instalación es sencilla la única dependencia del paquete, es un servidor de correo para poder enviar los informes y alertas al root, o a la dirección especificada, asegurate de que esta funcionando correctamente, antes de continuar con la configuración.

sudo apt-get install aide

Configuración

Antes de modificar la configuración por defecto de aide, vamos a comprobar que funciona correctamente, para ello generamos la primera base de datos. Este proceso puede ser muy lento dependiendo del ordenador, y del numero de archivos a monitorizar.

sudo aideinit

Una vez generada, la copiamos para instalarla:

sudo cp /var/lib/aide.db.new /var/lib/aide.db

Ahora podemos modificar la configuración para incluir cualquier directorio que necesitemos monitorizar, o eliminar algún directorio en el que no estemos interesados. Los archivos de configuración de AIDE en Debian/Ubuntu, son /etc/aide/aide.conf y el directorio /etc/aide/aide.conf.d/ , estos no son usados directamente por AIDE, sino que el script update-aide.config recopila toda la información y, crea el archivo final /var/lib/aide/config.autogenerated.

Para añadir nuestros directorios a la configuración, tenemos que crear un archivo en el directorio /etc/aide/aide.conf.d

sudo touch /etc/aide/aide.conf.d/60_aide_custom
sudo chmod 644 /etc/aide/aide.conf.d/60_aide_custom

El número al inicio indica el orden en el que el archivo es cargado, hay que asegurarse de que el numero de nuestro archivo es el mayor del directorio, de esta manera nuestra configuración sea la última en cargar y no tengamos conflictos.

Cada archivo contiene la lista de directorios y archivos que tienen que ser monitorizados por AIDE, por ejemplo los archivos de configuración de una aplicación, el directorio de contenidos estáticos de una pagina web, o el directorio donde se guardan los backups, etc. Tras cada una de esas rutas, se añade la lista de aspectos que tiene que ser monitorizados, usando el mismo formato definido en el manual de AIDE

En el siguiente ejemplo se pueden ver algunas de las posibilidades que ofrece AIDE, otra buena fuente son los archivos de configuración en /etc/aide/aide.conf.d/

# Parametros que pueden ser comprobados
#
# p:      permissions
# ftype:  file type
# i:      inode
# n:      number of links
# l:      link name
# u:      user
# g:      group
# s:      size
# b:      block count
# m:      mtime
# a:      atime
# c:      ctime
# S:      check for growing size
# I:      ignore changed filename
# md5:    md5 checksum
# sha1:   sha1 checksum
# sha256: sha256 checksum
# sha512: sha512 checksum
# rmd160: rmd160 checksum
# tiger:  tiger checksum
# haval:  haval checksum
# crc32:  crc32 checksum
# R:      p+ftupe+i+l+n+u+g+s+m+c+md5
# L:      p+ftype+i+l+n+u+g
# E:      Empty group
# >:      Growing logfile p+ftype+l+u+g+i+n+S
# The following are available if you have mhash support enabled:
# gost:   gost checksum
# whirlpool: whirlpool checksum
# The following are available and added to the default groups R, L and >
# only when explicitly enabled using configure:
# acl:    access control list
# selinux SELinux security context
# xattrs:  extended file attributes
# e2fsattrs: file attributes on a second extended file system

# Creamos nuestras reglas.
MinimalCheck = p+i+u+g
FullCheck = p+i+n+u+g+s+b+c+sha256

# Directorios a monitorizar
/home/secnot/private/website MinimalCheck
/home/secnot/chroot FullCheck

# Archivo a monitorizar
# a diferencia de los directorios los archivos son terminados en '$'
# antes de '.' hace falta un caracter de escape '\'
/home/secnot/mi_aplicacion\.conf$       FullCheck

# Usar las reglas no es necesario pero es más legible
/etc/mi_otra_aplicacion\.conf$          p+i+g+d

# Podemos usar las reglas definidas en /etc/aide/aide.conf,
# como en los otros archivos de configuración
/home/webuser/webapp    VarLog

# Forzamos que se ignore un archivo o varios
!/etc/app\.conf$
!/var/log/.*

Por último solo nos queda editar /etc/default/aide, en el cual podemos definir donde deseamos que lleguen los informes generados periódicamente (por defecto root), junto algunas opciones más sobre los mismos.

Uso

Cada vez que realicemos alguna modificación, instalemos, o eliminemos algún programa, generamos una nueva base de datos, a partir de ese momento cada vez que se ejecute AIDE se comprobará que nada ha sido alterado con respecto al estado almacenado en la base de datos.

sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Como medida de seguridad adicional, es recomendable calcular un hash de la base de datos, para poder comprobar manualmente que no ha sido modificada por un atacante. Guarda una copia del hash en un lugar seguro.

sha256sum /var/lib/aide/aide.db

AIDE es ejecutado automáticamente todos los días por cron, a través de un script en /etc/cron.daily/, este ejecuta update-aide.config para generar un archivo de configuración actualizado, y después llama aide. Una vez la comprobación ha terminado, almacena la información en los archivos de log /var/log/aide/aide.log y de errores /var/log/aide/error.log, por último envía un informe a la dirección de correo configurada si es que una existe.

Si queremos comprobar si ha habido alguna modificación manualmente, primero es recomendable comprobar que la base de datos no ha sido modificada usando sha256sum, después podemos ejecutar el script:

sudo /usr/bin/aide.wrapper

O podemos generar manualmente el archivo de configuración, y después ejecutar aide.

sudo update-aide.config
sudo aide -c /var/lib/aide/aide.conf.autogenerated --check

Enlaces

• AIDE Manual
• Debian Aide Guide
• nixCraft AIDE Guide
• Ubuntu Aide Help Page

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.

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