Revisió de seguretat per a servidors Linux acabats d’ instal·lar

Un cop aixeques una màquina Linux acabada d’instal·lar —ja sigui en un núvol públic, un servidor físic o una màquina virtual del laboratori— l’últim que vols és que algú te la comprometi abans d’haver acabat de posar-la a punt. La sensació d’ “haig d’assegurar això ja, però no em vull oblidar res bàsic” ens ha passat a tots més d’una vegada.

Això no va de muntar SELinux, AppArmor, o d’escriure polítiques complexes des del minut zero. Va de tenir clar què revisar, què ajustar i què deixar ben lligat abans de connectar aquest servidor al món real. Res de guies acadèmiques ni mantres genèrics. Això és el que reviso i ajusto cada vegada que deixo una màquina recent instal·lada mig enllestida per a producció.

1. Actualitza, abans de tocar res

Sí, el de sempre, però no per repetit deixa de ser crític. De vegades costa no donar-li a l’ apt install elquesigui directament perquè tens pressa, però el primer que faig —encara que acabi d’instal·lar des de la ISO més recent— és actualitzar els paquets. No te’n refiïs. Hi ha un buit entre la creació de la imatge i el present, i en aquest buit solen caure unes quantes CVEs.

Per costum:

apt update & apt upgrade -y

# o en sistemes RHEL

dnf update -y

Depenent de l’entorn, també deixo activades les actualitzacions automàtiques de seguretat (per exemple, amb unattended-upgrades a Debian/Ubuntu). Si el servidor ha d’estar en un entorn poc vigilat o sense automatització de configuració, tenir això actiu et pot evitar sorpreses. Tot i que és clar, això té matisos: en entorns més delicats prefereixo deixar-ho en mode només-notificació.

2. Mata l’accés root per SSH

Un d’aquests ajustos que s’obliden per costum o perquè “total, si tinc claus”. Però si algú aconsegueix pujar una clau pública al teu servidor, o hi ha alguna mala configuració en sshd_config, l’accés root directe pot ser un problema greu.

L’habitual és crear un usuari amb permisos de sudo i després ajustar:

PermitRootLogin no

en /etc/ssh/sshd_config. Després reinicies SSH i llest.

I sí, pot haver-hi qui pensi que tenir accés root directe amb clau privada és “igual de segur”, però a la pràctica, afegir un pas més sempre redueix riscos, especialment quan aquest accés root no està monitoritzat o aïllat adequadament.

3. Fes servir claus SSH, mai contrasenyes

Això ja gairebé no cal dir-ho, però encara em trobo servidors amb PasswordAuthentication yes. Poques coses obren tant la porta a atacs de força bruta com això.

A més, quan gestiones diversos servidors, les claus SSH ben organitzades són molt més fàcils de gestionar que anar recordant o guardant contrasenyes. I ja si les tens en un ssh-agent, millor encara.

Assegura’t de deixar en sshd_config alguna cosa com:

PasswordAuthentication no
PubkeyAuthentication yes

I si ets molt paranoic (o simplement curós), afegeix PermitEmptyPasswords no, tot i que ja hauria de venir així.

4. Revisa què està exposat

Un dels errors més comuns és pensar que perquè alguna cosa no està documentada, ningú ho ha de veure. Cal revisar bé quins serveis estan escoltant, i en quines interfícies. El clàssic netstat -tulnp (o ss -tuln en sistemes moderns) et diu ràpid si, per exemple, tens un mysql o un redis escoltant en 0.0.0.0.

I si tens serveis que no haurien d’estar accessibles des de fora, tanca l’aixeta. Pot ser via firewalld, ufw, o a pèl amb iptables/nftables. M’és igual l’eina; l’important és que la capa de xarxa estigui controlada.

Jo vaig seguir una política bàsica de “deny all, allow only what es necessita ara mateix”. El típic: SSH, HTTP/HTTPS si estàs muntant un webserver, i la resta sota demanda.

5. Càrrega mínima de serveis actius

Una de les coses més tontes però més eficaces que pots fer és revisar què dimonis arrenca al teu sistema per defecte. Depenent de la distro, la instal·lació base ja et fica un parell de coses que no necessites.

Fes un systemctl list-unit-files –type=service | grep enabled i mira què hi ha actiu. Serveis com cups, avahi, o bluetooth en un servidor que viu en un CPD… sobren. Cada servei és una potencial superfície d’atac, i no tindràs exploits d’alguna cosa que no està corrent.

6. Instal·la Fail2Ban o similar

Si el servidor exposa SSH (i sol fer-ho), és qüestió d’hores fins que vegis una munió d’intents de login fallits en els logs. Res personal, només bots recorrent rangs IP.

Fail2Ban no és màgic, però fa lo que toca: detecta patrons d’intents fallits (per defecte en SSH, però pots afegir més) i bloqueja la IP temporalment. El tinc gairebé com un estàndard en qualsevol màquina accessible des de fora:

apt install fail2ban

Revisa la configuració per defecte, ajusta els temps i els llindars si cal, i llest. No ho soluciona tot, però sí que et treu força soroll.

7. Avisa si alguna cosa va malament (logs i monitoratge)

Aquest punt és on de vegades ens confiem massa. Instal·lar el servidor, configurar-lo, tot bé… ¿i després què? Sense un mínim sistema de logs ben organitzats i alguna forma de revisió o alerta, no t’assabentes de res fins que ja és tard.

Almenys, assegura’t que journald no estigui rotant tan agressivament que et perdis els esdeveniments del dia anterior. Si fas servir rsyslog, mira que els logs crítics vagin a fitxers separats (auth.log, messages, etc.).

I si pots muntar alguna cosa de monitorització, encara que sigui bàsic, millor. Jo de vegades tiro de monit si és un entorn petit, o de solucions més integrades com Prometheus i Grafana si és una cosa més seriosa. Però fins i tot un correu d’alerta en cas que un servei es caigui ja és millor que res.

8. Desactiva IPv6 si no el fas servir

Aquí hi ha debat, però la meva regla personal és: si no estàs fent servir IPv6 activament i no ho tens ben gestionat, millor desactivar-lo.

Per què? Perquè moltes vegades ni el tens controlat al firewall, ni el tens monitoritzat, i continua funcionant igual. És una altra superfície que no estàs mirant.

Per desactivar-lo pots afegir al sysctl:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

I després aplicar amb sysctl -p.

No és obligatori, però és un d’aquests ajustos que he vist evitar problemes quan els scripts d’atac per defecte també busquen vectors IPv6.

9. Còpies de seguretat: pensa-hi des del començament

No esperis a tenir el servidor en producció per pensar en backups. Una còpia de seguretat mal pensada o directament inexistent és com no tenir frens al cotxe i assumir que no t’hauràs d’aturar mai.

El mínim: còpia dels fitxers de configuració personalitzats (/etc, /var/www, etc.), i si hi ha dades crítiques, un pla per guardar-los fora del servidor (S3, un altre node, el que sigui).

Jo sempre deixo algun script de backup automàtic en cron des de l’inici, encara que després es refactoritzi en una cosa més elegant. Però saber el més important es guarda fora ja et dona una mica de tranquil·litat.

10. Revisió regular: crea la teva pròpia rutina

Aquest punt és més difús, però no menys important. Un servidor que queda “segur” el dia zero pot estar exposat el dia 30 si no el vigiles. No cal tenir tot automatitzat amb Ansible, però sí tenir una petita rutina de revisió: usuaris nous, paquets instal·lats, serveis corrent, ports oberts…

Un truc que utilitzo: deixo en cada servidor un petit script que em treu un snapshot d’estat (serveis actius, ports oberts, logs dels últims dies) i me l’envia per correu. De vegades només el miro per sobre, però quan alguna cosa canvia inesperadament, ho noto asseguda.

Algunes coses que deixo fora (a propòsit)

Per si algú el troba a faltar: no hi ha res d’ escanejos amb Lynis, ni de muntar AppArmor, ni d’autenticació 2FA per a SSH, ni de segmentació de xarxa, ni de hardening kernel amb sysctl més agressiu.  No perquè no siguin importants, sinó perquè crec que tot això té sentit un cop tens el més bàsic ben cobert. Aquesta llista és aquesta capa mínima que no pots deixar passar, sense complicar-te amb marcs de compliance i sense que se’t faci bola.