En la siguiente entrega veremos como configurar **Traefik** como proxy inverso.
{{</admonition>}}
Describimos la instalación de un VPS en el proveedor Contabo, pero quitando los detalles particulares de ese proveedor el resto de los pasos se pueden aplicar a cualquier VPS con **Debian 12 Server**
## Opciones en Contabo
Escogemos un servidor sencillo sin opciones extra.
| | |
|:------------------|:-----------------|
| Sistema Operativo | Debian 12 Server |
| Tipo de servidor | Cloud VPS 1 |
| Cores | 4 vCPU |
| Memoria | 6 Gb RAM |
| HD | 400 Gb |
- En el proceso de instalación especificamos que queremos Debian 12
- Es importante recordar la password de ***root*** aunque ahora hay una opción para resetearla desde la web de contabo
- **ATENCIÓN: Evita usar caracteres especiales y las letras 'y' y 'z' al establecer la password de *root***. Hay un problema con los `LOCALES` y con el mapa de teclado que solucionaremos más tarde
- **Los snapshots de los servidores se borran a los 30 dias**
- En el panel de control web, sección *Your Services* debajo del botón *Manage* tenemos la opción para asignarle un nombre al servidor, yo lo hago con todos por que me es más sencillo recordarlos e interpretar las facturas
- Si hay problemas tendrás que recurrir al acceso via VNC. En la web de control de servidores en Contabo tienes la info para conectarte al VNC. Tienes que poner una contraseña para acceder al servidor VNC **que contenga mayúsculas, minúsculas, números y tenga EXACTAMENTE ocho caracteres**. Puedes dejar el acceso VNC desactivado y activarlo solo cuando lo necesitas.
## Instalación
### Actualización de paquetes
Con nuestro S.O. escogido (Debian 12) recién instalado en el VPS nos conectamos desde nuestro PC.
En mi estación de trabajo (desde donde me conecto a mis servidores) tengo configurado el acceso ssh via claves GPG. Si haces como yo y usas distintas claves por cada servidor remoto es posible se acumulen tantas claves que la conexión falle con el error *Too many authentication failures*. Esto ocurre por que `ssh` irá probando todas las claves disponibles para la conexión. Como el servidor aun no está configurado para aceptar claves fallarán todos los intentos de conexión, aparecerá el error y el servidor remoto rechazará la conexión. Para evitar eso usamos la opción:
`Preferredauthentications=password`
Otra forma de conectarse sería:
`ssh -o IdentitiesOnly=yes root@<vps_ip_address>`
{{</admonition>}}
Y hacemos la típica actualización de todos los paquetes:
Lo más seguro es que nos de un fallo de `locale settings` de este estilo
```log
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB:en",
LC_ALL = (unset),
LC_TIME = "es_ES.UTF-8",
LC_MONETARY = "es_ES.UTF-8",
LC_ADDRESS = "es_ES.UTF-8",
LC_TELEPHONE = "es_ES.UTF-8",
LC_NAME = "es_ES.UTF-8",
LC_MEASUREMENT = "es_ES.UTF-8",
LC_IDENTIFICATION = "es_ES.UTF-8",
LC_NUMERIC = "es_ES.UTF-8",
LC_PAPER = "es_ES.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
```
Lo arreglamos en la siguiente sección.
### Reconfigurar *locales* y mapa de teclado
Reconfiguramos los *locales*:
```bash
dpkg-reconfigure locales
```
Dejamos el `en_US.UTF-8` como *locale* por defecto.
Aparentemente Debian 12 ha pasado a controlar los locales bajo **systemd**. Parece que hay conflictos por que el antiguo comando `locale` nos dice una cosa y el nuevo comando `localectl status` nos dice otra:
```bash
locale -a # Lista de los locales que he generado con dpkg-reconfigure locales
C
C.utf8
en_GB.utf8
en_US.utf8
es_ES.utf8
eu_ES.utf8
gl_ES.utf8
POSIX
locale # Antiguo comando para ver la configuración de locales
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=es_ES.UTF-8
LC_TIME=es_ES.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=es_ES.UTF-8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=es_ES.UTF-8
LC_NAME=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_MEASUREMENT=es_ES.UTF-8
LC_IDENTIFICATION=es_ES.UTF-8
LC_ALL=
localectl status # Nuevo comando para ver la configuración de locales
System Locale: LANG=en_US.UTF-8
LANGUAGE=en_GB:en
VC Keymap: (unset)
X11 Layout: de
X11 Model: pc105
```
En cualquier caso ya no nos aparecerán más errores de locales, pero tenemos que solucionar también el problema del mapa de teclado que nos interfiere al conectarnos via VNC desde la página web de administración de Contabo. Para ello ejecutamos `dpkg-reconfigure keyboard-configuration`, escogiendo las opciones:
- **Keyboard model**: *Generic 105-key PC*
- **Country of origin**: *Spanish*
- **Keyboard Layout**: *Spanish*
- **Altgrn key**: *Default*
- **Compose key**: *No compose key*
Después de reconfigurar ya tendremos el mapa correcto :
```bash
localectl status
System Locale: LANG=en_US.UTF-8
LANGUAGE=en_GB:en
VC Keymap: (unset)
X11 Layout: es
X11 Model: pc105
```
Con esto no deberíamos tener ya problemas para hacer login con el VNC sea cual sea la contraseña de nuestro usuario `root`.
Una vez que compruebes que el teclado funciona bien via VNC y que la configuración de *locales* ya no te da problema puedes cambiar las contraseñas y poner la que quieras. Pero en los siguientes pasos vamos a prohibir el acceso de `root` y vamos a exigir que el acceso por ssh se haga con claves GPG.
Eso si, por VNC desde la página de administración de Contabo, siempre podrás entrar como `root`.
{{</admonition>}}
### Instalación de **git** y **etckeeper**
**git** lo uso continuamente, **etckeeper** se encarga de mantener todos los cambios que haya en el directorio `/etc/` de nuestro servidor controladas con **git**. A mi ya me ha resultado muy útil para resolver un par de problemas causados por cambios de configuración o instalación de paquetes. Uso el **etckeeper** estrictamente en local, nunca he definido un *remote* para este repo de **git**.
**git-crypt** y **gnupg** son una manera de almacenar información confidencial en un repo de git. Aunque **gnupg** vale para muchas más cosas y merece la pena tenerlo instalado.
Instalamos `git` y `etckeeper` (los siguientes comandos hay que ejecutarlos como `root` para tener el git configurado para **etckeeper**):
En nuestra estación de trabajo preparamos las claves de acceso al server remoto y las trasferimos al mismo. Lo dos primeros comandos son de ejemplo, con una sola clave del tipo que sea te vale.
```bash
ssh-keygen -b 4096 -t rsa # Especificamos ~/.ssh/<serverName>_rsa como salida
ssh-keygen -t ed25519 -a 100 # <--Opciónmasrobusta(especificamoscomosalida~/.ssh/<serverName>_ed25519)
Para dejar correctamente configurado el acceso ssh al VPS desde nuestra estación de trabajo, tenemos que configurar nuestro cliente ssh editando el fichero `~/.ssh/config`. Hay también un fichero global con opciones para el cliente ssh que sería `/etc/ssh/ssh_config`. Los dos ficheros tienen el mismo formato.
Con esta configuración y **una vez configurado el ssh en el servidor** (ver siguiente apartado) el comando de conexión será simplemente:
`ssh <serverName>`
Puedes conectarte a distintos usuarios en el lado VPS siempre y cuando hayas copiado la clave pública correspondiente al fichero `~/.ssh/authorized_keys` de ese usuario remoto.
### Configuración del servidor ssh en el VPS
En nuestro servidor VPS cambiamos la configuración para que:
- **No** se admitan login via ssh con password (**¡OJO! Esta es la opción que tendrás que habilitar de nuevo si te lias con tus claves gpg para ssh**)
- **No** se admita login via ssh con el usuario `root`
Tenemos que editar el fichero de configuración `/etc/ssh/sshd_config`. A continuación los cambios introducidos
```config
.
.
.
# 20240619-salvari uncomment
PubkeyAuthentication yes
.
.
.
# To disable tunneled clear text passwords, change to no here!
# 20240619-salvari changed to no
PasswordAuthentication no
#PermitEmptyPasswords no
.
.
.
# 20240619-salvari changed to no
UsePAM no
.
.
.
# 20240619-salvari changed to no
PermitRootLogin no
```
Después de cambiar la configuración reiniciamos el servicio con `sudo systemctl restart ssh`
Ahora tenemos que comprobar que podemos conectarnos desde nuestra estación de trabajo via clave gpg, por ejemplo con el comando que ya describimos: `ssh <serverName>`
## Configuración del cortafuegos
Ya hace tiempo que en Linux se ha pasado de implementar los _firewall_ con **iptables** a usar **nftables**. Para mantener la compatibilidad con el antiguo **iptables** hay utilidades que se encargan de traducir los comandos **iptables** a configuraciones con **nftables**
Yo solía usar *Uncomplicated Firewall* (UFW) para configurar mis cortafuegos por que mi configuración era muy simple. El problema es que **UFW** sigue usando comandos **iptables** y no se si la traducción a **nftables** queda muy elegante así que aunque de momento lo dejemos con **UFW** voy a echar un ojo a la configuración directa con **nftables** y también a usar **Firewalld** en lugar de **UFW**.
Las ventajas de usar directamente **nftables** son configuraciones más simples y que aprendes como usuar **nftables** y como funciona un cortafuegos.
La principal ventaja de usar **UFW** o **Firewalld** es que los escenarios y aplicaciones típicos son muy fáciles de configurar.
### UFW
Habíamos instalado **ufw** al instalar las utilidades al principio. Ahora vamos a poner la configuración básica del cortafuegos, es decir, vamos a permitir exclusivamente conexiones via ssh:
```bash
sudo ufw status verbose # Comprobamos que está deshabilitado
sudo ufw app list # comprobamos que apps soporta
sudo ufw default deny incoming # le decimos que por defecto no acepta nada entrante
**Según vayamos añadiendo servicios tendremos que ir añadiendo reglas al *firewall*.**
Si queremos ver como queda esto configurado en **nftables** podemos ejecutar el comando `sudo nft list ruleset`. Antes de activar el cortafuegos el comando no devuelve nada puesto que no hay definida ninguna regla. Pero tras activarlo obtenemos la configuración de reglas que figura a continuación. Son muchísimas reglas para lo que queremos (permitir sólo el acceso via **ssh**) Es de suponer que el **UFW** deja todo preparado para añadir nuevas reglas en el futuro. Aun así si configuramos lo mismo directamente con comandos **nftables** dudo mucho que necesitemos más de 30 lineas para dejar todo programado y bien comentado en el fichero de configuración.
```nftables
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
chain ufw-before-logging-input {
}
chain ufw-before-logging-output {
}
chain ufw-before-logging-forward {
}
chain ufw-before-input {
iifname "lo" counter packets 0 bytes 0 accept
ct state related,established counter packets 35 bytes 3502 accept
ct state invalid counter packets 0 bytes 0 jump ufw-logging-deny
ct state invalid counter packets 0 bytes 0 drop
meta l4proto icmp icmp type destination-unreachable counter packets 0 bytes 0 accept
meta l4proto icmp icmp type time-exceeded counter packets 0 bytes 0 accept
meta l4proto icmp icmp type parameter-problem counter packets 0 bytes 0 accept
meta l4proto icmp icmp type echo-request counter packets 0 bytes 0 accept
Si queremos ver el cortafuegos en acción podemos ejecutar el comando `sudo journalctl -S today |grep UFW`, la cantidad de intentos de acceso bloqueados nunca deja de asombrarme.
## Instalación y configuración de **fail2ban**
### Instalación de **fail2ban**
Primero necesitamos instalar **fail2ban** en nuestro VPS. Podemos usar simplemente:
```bash
sudo apt install fail2ban
```
Si por lo que sea queremos instalar la última versión, podemos hacerlo descargándola desde [aquí](https://github.com/fail2ban/fail2ban/releases) con los siguientes comandos:
```bash
# Echa un ojo al repo de releases y apunta la versión actual de fail2ban
# En nuestro caso es: https://github.com/fail2ban/fail2ban/releases/download/1.1.0/fail2ban_1.1.0-1.upstream1_all.deb
# 4) to ensure the upgrade run gentler (protocol of previous version may be incompatible), stop fail2ban before install:
# using service:
sudo service fail2ban stop
# using client:
sudo fail2ban-client stop
# 5a) either install package using dpkg (standalone package, don't regard dependencies):
sudo dpkg -i fail2ban_1.1.0-1.upstream1_all.deb
# if the package introduces some "broken" dependencies (I don't think so in case of fail2ban which has few dependencies),
# to fix the unmet dependency issue, run this:
sudo apt -f install
# 5b) alternatively install package using gdebi (that will take care of installation of dependencies):
sudo gdebi fail2ban_1.1.0-1.upstream1_all.deb
# if you want to check anyway whether there are some broken packages and fix them automatically, you can run:
sudo apt -f install
```
Una vez instalado **fail2ban** podemos comprobar el estado del servicio:
```bash
systemctl list-units -a --state=active --type=service
systemctl status fail2ban.service
```
### Configuración de **fail2ban**
Hay dos ficheros principales de configuración en **fail2ban**: `/etc/fail2ban/fail2ban.conf` y `/etc/fail2ban/jail.conf` (ver [aquí](https://github.com/fail2ban/fail2ban/wiki/Proper-fail2ban-configuration))
/etc/fail2ban/fail2ban.conf
: Es el fichero de configuración de las opciones de operación del demonio **fail2ban**. Aquí se especifican cosas como el *loglevel*, el fichero de log, el socket o el fichero del pid.
/etc/fail2ban/jail.conf
: Este es el fichero interesante, aquí es donde configuramos las reglas de baneado. Así aquí se configura, por ejemplo, el intervalo de baneo, el número de intentos de login antes de banear una ip, la lista blanca de IPs, la info que se envia por correo cuando se detecta un ataque, etc. etc.
: En **fail2ban** definimos un `jail` por cada servicio que nos interesa proteger.
En casi todos los sitios que he leido nos aconsejan es hacer copias de los dos ficheros con extensión `.local` y hacer la configuración en estas copias.
```bash
cd /etc/fail2ban/
cp fail2ban.conf fail2ban.local
cp jail.conf jail.local
```
Pero la verdad es que en el man de fail2ban nos dicen que en los ficheros `.local` pongamos **exclusivamente** lo que no coincida con los valores por defecto. Y así lo voy a configurar.
{{<admonitiontype=dangertitle="Cambio de ficheros de logs en Debian 12"open=true>}}
Debian 12 ha cambiado la forma de gestionar los logs del sistema, ahora se usa **journald** bajo el paragüas de **systemd**. Si echais un ojo al directorio `/var/log` comprobareis que ya no existen la mayoria de los ficheros de log tradicionales.
Esto impacta directamente en la configuración de **fail2ban**. Hay que tenerlo en cuenta por que con las configuraciones típicas de ejemplo en internet (o mi antigua configuración) **ya no funciona**.
{{</admonition>}}
Otro detalle de la configuración de **fail2ban** es que la mayoría de los linux actuales han cambiado del antiguo **iptables** a **nftables** para implementar las políticas de cortafuegos. Este cambio no es reciente pero yo no era muy consciente por que hay programas de "traducción" de reglas **iptables** a reglas **nftables** . Si investigas un poco en tu linux seguramente verás que cuando invocas `iptables` casi seguro que en realidad estás invocando a `xtables-nft-multi`.
Este no es un problema que impida el funcionamiento de **fail2ban**. Por ejemplo, ya comentamos que el cortafuegos que hemos instalado en nuestro server (*Uncomplicated Firewall* o **ufw**) sigue usando **iptables** y lo mismo hacen muchas otras aplicaciones como **Docker** sin ir más lejos. Asi que si no cambiamos la configuración por defecto **fail2ban** también usaría comandos de **iptables** que serían traducidos por **xtables-nft-multi**. Pero creo que lo conveniente es usar ya **nftables** puesto que **fail2ban** lo soporta. [^1]
[^1]: Queda pediente buscar una alternativa a **ufw** que use directamente **nftables**, como **firewalld** por ejemplo.
Si desplegamos **fail2ban** por primera vez hay que ir con cuidado de que no nos bloquee a nosotros mismos fuera del sistema. Puede que quieras activar el acceso con password via ssh antes de hacer el despliegue de **fail2ban** y seguramente es mejor no desplegar políticas de *baneo* muy agresivas hasta comprobar que todo funciona bien.
Si antes de activar **fail2ban** quereis ver la cantidad de intentos de acceso ilegales[^2] que tiene vuestro VPS podéis ejecutar:
[^2]: Si también quereis ver los intentos de acceso que esta bloqueando **UFW** podeis ejecutar `sudo journalctl -S today |grep UFW`
```bash
journalctl -u ssh.service -S today
journalctl -u ssh -S "1 hour ago"q # Limitado a la última hora, el parámetro u (unit) acepta regexp
```
Con todas estas consideraciones nuestro fichero `jail.local` inicial quedaría:
```toml
[DEFAULT]
# Add my others VPS as trusted servers
ignoreip = xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
banaction=nftables[type=multiport]
# banaction=nftables[type=allports] # optional, more aggresive
#
# JAILS
#
[sshd]
enabled = true
backend = systemd # backend is systemd in Debian 12
```
En este fichero de configuración:
- Añado mis otros VPS a la lista `ignoreip` para que **fail2ban** nunca los banee. (Evidentemente para acceder tendre que configurar correctamente las claves ssh en esos otros VPS)
- Cambio el `banaction` para que **fail2ban** use **nftables** en lugar de **iptables**
- Activo un *jail* para el servicio `sshd` y, muy importante, especifico que el `backend` es `systemd`
Una vez configurado reiniciamos el servicio **fail2ban* con:
```bash
sudo systemctl restart fail2ban
```
Con esta parametrización estas son las ip baneadas a los pocos minutos de arrancar el servicio.
Evidentemente a medida que vayamos instalando servicios en nuestro VPS deberemos añadir las jail necesarias para que **fail2ban** monitorice intentos de acceso ilegal a esos servicios.
{{</admonition>}}
## Instalación de zsh
Me gusta usar zsh para trabajar en la terminal así que lo vamos a instalar en nuestro VPS.
Antes de empezar vamos a instalar:
- **python3-all-dev** aunque sólo lo necesitas si vas a usar **pyenv** para gestionar entornos virtuales de Python3
- **antigen** para gestionar todos los plugins de **zsh**
- **zsh-git-prompt** para tener información de git en el prompt del sistema
En el home de cada usuario (cada usario con el que queramos usar **zsh**) tendremos que crear un fichero `~/.zshrc` con las opciones de **zsh** que queramos para ese usuario y un fichero `~/.zalias.zsh` con los alias que queramos definir.
{{<admonitiontype=warningtitle="Error con el bundle docker"open=true>}}
Con esto tendríamos el **Docker** instalado en nuestro VPS. Para comprobarlo deberíamos ejecutar con nuestro usuario `dockadmin` el contenedor de pruebas con:
