Desgooglearse (III). ssh y https


Entradas anteriores

Configuración inicial del servidor

Es quizás un paso obvio, pero no está de más comentarlo. Creamos los registros A y AAAA que resuelvan las direcciones IPv4 e IPv6 del servidor, instalamos la distro que prefiramos (en mi caso Debian estable siempre) y accedemos por ssh al servidor recién creado, configuramos adecuadamente la resolución estática de nombres, definimos nombre corto y FQDN de la máquina y verificamos que la hora está sincronizada correctamente.

ssh

Vamos a crear un usuario, que pertenezca a sudo y que sea el único que pueda acceder por ssh a la máquina. Accedemos inicialmente por ssh al servidor, creamos el usuario que va a administrar la máquina, copiamos la clave pública ssh que vayamos a utilizar en ~/.ssh/authorized_keys y borramos la contraseña del usuario y de root en el caso que estuvieran creadas:

passwd -d root
passwd: password expiry information changed.

Modificamos la configuración de ssh para que sólo sea posible acceder por clave pública y no se pueda acceder en ningún caso como root:

grep -v '^$\|^#' /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PrintMotd no
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/lib/openssh/sftp-server

Con esta configuración, cuando alguien intente acceder y no tenga una clave pública válida, la conexión será inmediatamente rechazada:

ssh root@...
root@...: Permission denied (publickey).

Instalación de fail2ban

Fail2ban es un programa que permite denegar el acceso a las direcciones IPs desde las que se detecte un intento repetido de acceso a determinados servicios de forma inadecuada y en el caso de ssh permite quitar mucho ruido de los logs. La instalación por defecto de fail2ban habilita el bloqueo de los accesos erróneos de ssh:

apt install fail2ban

Aunque la configuración previa de ssh ya limita bastante el acceso, no sobra fail2ban.

Servidor web

El primer servicio que hay que configurar (obviando ssh) es el servicio web que utilizaremos para distintos fines. Apache y nginx son dos opciones extraordinarias para montar un sitio web e ir añadiendo componentes a medida que sea necesario. En esta caso vamos a utilizar Apache, por lo que simplemente instalamos el paquete apache2 que levanta automáticamente el servicio web en el puerto 80/tcp:

ss -lntp|grep :80
LISTEN    0    128     *:80           *:*

https

Hoy en día es imprescindible configurar un servicio web cifrado, es así en general y mucho más si pretendemos usar la máquina para albergar determinados servicios de uso personal. En este caso no es posible crear nuestra propia autoridad certificadora y emitir certificados autofirmados ya que diferentes servicios tendrán que interactuar con otros equipos que no están a nuestra alcance, por lo que es necesario utilizar certificados firmados por una autoridad certificadora válida en Internet; la mejor opción en estos momentos es sin duda Let’s Encrypt.

Let’s Encrypt

Let’s Encrypt es una entidad sin ánimo de lucro, gestionada por la fundación Mozilla y la EFF entre otros y que tiene como objetivo la generalización del uso de https para mejorar la seguridad y la privacidad en la web. Let’s Encrypt es gratuito, pero no es un servicio gratuito de una empresa que quiera obtener datos tuyos a cambio de permitirte usar el servicio, es una entidad sin ánimo de lucro que se financia a través de donaciones, así que colabora en la medida que consideres adecuado y puedas si eres usuario de esta autoridad certificadora.

Gestión de los certificados X.509. Certbot

Let’s Encrypt proporciona gran cantidad de formas de gestionar los certificados X509, la mayoría de ellos buscan la facilidad de uso y la generación y renovación automática. Uno de los clientes más utilizados es certbot, que es el que vamos a configurar en nuestro equipo de la siguiente forma:

apt install certbot

Certbot a su vez permite gestionar los certificados con diferentes plugins, teniendo un servidor web gestionado por nosotros mismos, lo más cómodo es utilizar el plugin webroot, para lo que debemos crear un directorio donde certbot puede escribir temporalmente algún token que permita a let’s encrypt verificar que somos propietarios del sitio web. Creamos el directorio para estos tokens:

mkdir -p /var/www/certbot/.well-known/acme-challenge

Y definimos un alias en apache para ese directorio en el sitio por defecto:

Alias /.well-known/acme-challenge /var/www/certbot/.well-known/acme-challenge

Comprobamos que certbot puede encontrar los tokens en esa ubicación, para lo que utilizamos certbot en modo «dry-run» de la siguiente forma:

certbot certonly --webroot -w /var/www/certbot -d DOMINIO --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for 
Using the webroot path /var/www/certbot for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - The dry run was successful.

Una vez comprobado el funcionamiento, solicitamos el certificado (si no añadiésemos el resto de parámetros nos preguntaría de forma interactiva):

certbot certonly --webroot -w /var/www/certbot -d DOMINIO -m  \
--agree-tos --no-eff-email

Que generará el certificado X509 firmado por let’s Encrypt y lo ubicará en el directorio /etc/letsencrypt/archive/DOMINIO/:

cert1.pem  chain1.pem fullchain1.pem privkey1.pem

Podemos ver el certificado con openssl:

openssl x509 -in cert1.pem -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:b2:0e:7c:3a:74:2d:ba:ad:03:48:fa:78:e8:d7:7d:ec:7a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Nov 11 06:05:39 2020 GMT
            Not After : Feb  9 06:05:39 2021 GMT
        Subject: CN = DOMINIO
        Subject Public Key Info:
...

Una de las cosas que podemos ver en este certificado es que es válido durante 3 meses, por lo que certbot incluye una tarea de cron (/etc/cron.d/certbot) que comprueba la validez del certificado y lo renueva si es necesario.

Habilitamos el sitio default-ssl de apache y agregamos las líneas:

SSLCertificateFile /etc/letsencrypt/live/DOMINIO/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/DOMINIO/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

Reiniciamos apache y comprobamos que podemos acceder por https con un certificado válido firmado por Let’s Encrypt.

Redirigir el tráfico http a https

Modificamos el sitio por defecto para que todo el tráfico que llegue al puerto 80/tcp se redirija automáticamente al 443/tcp y forzar así el uso de https en todos los clientes que accedan:

 Redirect permanent / https://DOMINIO/

Tenemos que tener la precaución de incluir en el sitio default-ssl las directivas de let’s encrypt que certbot pueda seguir accediendo a los tokens temporales cuando sea necesario renovar el certificado X509.

Configuración de https

Es conveniente modificar la configuración por defecto de https que viene con Apache y una buena forma de hacerlo es seguir las recomendaciones de Mozilla SSL Configuration Generator y comprobar el estado con la herramienta Qualys SSL Labs Test.

Desgooglearse (III). ssh y https

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s