Les cinc lliçons anteriors han afegit mesures de seguretat d'una en una: xarxa controlada, SSH amb claus, tallafocs, detecció d'intrusions, secrets xifrats i TLS. Cadascuna resolia un problema concret. Aquesta lliçó fa una cosa diferent: les converteix en una postura de seguretat, que és un conjunt coherent de decisions justificades per un model d'amenaces explícit, amb constància escrita de què està protegit, què s'ha decidit assumir i què queda fora de l'abast d'un administrador.

La diferència no és retòrica. Sense model d'amenaces, l'enfortiment degenera en cargo cult: s'apliquen receptes trobades en guies perquè «sonen segures», es trenquen coses sense entendre per què, i s'acaba amb un sistema fràgil i una falsa sensació de control. Amb model d'amenaces, cada mesura té un perquè i cada omissió és una decisió conscient.

A més tanques aquí el tercer incident pendent —els serveis que continuen fent servir la libssl vulnerable carregada a memòria— i saldes el deute que vas deixar a 05-01: PAM, el subsistema que decideix de debò com s'autentica algú en aquest sistema.

Advertiment previ. Dos dels apartats d'aquesta lliçó —PAM i els muntatges segurs— et poden deixar sense poder iniciar sessió al teu propi servidor si t'equivoques. En tots dos casos s'indica el procediment segur. No te'l saltis: el laboratori existeix precisament perquè aprenguis això on equivocar-se no costa res.

1. Els cinc principis que ordenen tot l'anterior
2. El model d'amenaces de Tramontana
3. Reducció de la superfície d'atac
4. Enfortiment de comptes i política de contrasenyes
5. PAM: com s'autentica realment aquest sistema
6. Control d'accés obligatori amb AppArmor
7. Enfortiment del nucli amb sysctl
8. Muntatges segurs
9. Gestió de vulnerabilitats i tancament de l'incident d'openssl
10. Enfortiment de systemd revisitat
11. Còpies com a últim control davant del ransomware
12. Llista de comprovació d'enfortiment i manteniment de la postura

Tot el que has fet al mòdul respon, sense que ho haguem dit, a cinc principis. Anomenar-los permet aplicar-los a situacions noves en lloc de repetir receptes:

El més difícil d'aplicar a la pràctica és el segon, perquè exigeix treure coses, i treure coses fa por. El més oblidat és el quart: molta configuració «segura» falla obrint-se, i això és pitjor que no tenir-la, perquè ningú no se n'assabentarà.

Un model d'amenaces respon a tres preguntes. Mitja pàgina és suficient, i és la mitja pàgina que fa que tota la resta tingui sentit.

Què protegim? Dues coses, en aquest ordre:

1. Les dades personals dels hostes (noms, dates d'estada, imports a reserves.csv i a la base de dades). El seu compromís és un dany a tercers, té conseqüències legals sota el RGPD i és irreversible: un cop filtrades, no es poden «recuperar».
2. La disponibilitat del servei de reserves. La seva interrupció té un cost econòmic directe i acotat en el temps.

De qui? Quatre actors realistes, ordenats per probabilitat:

Fixa't en la tercera fila. L'actor més probable ets tu, i aquella constatació explica per què mitja dotzena de convencions del curs —copiar abans d'editar, verificar amb diff -u, provar en sec, netplan try amb reversió automàtica, mount -a abans de reiniciar— són controls de seguretat de ple dret, i no manies d'estil.

Què assumim fora d'abast? Dir-ho és tan important com l'anterior, perquè delimita què no s'està protegint:

• Atacant amb recursos estatals o cadena de subministrament compromesa. Està fora de l'abast de qualsevol mesura que un administrador pugui prendre en un servidor d'una petita empresa.
• Accés físic a la màquina. El xifratge LUKS mitiga el robatori del disc, però un atacant amb accés físic prolongat i la màquina encesa té el sistema.
• Vulnerabilitat a la mateixa aplicació (injecció SQL, lògica de negoci). És responsabilitat del desenvolupament, no de l'administració, i l'enfortiment del sistema només limita el dany posterior.
• Compromís del proveïdor del núvol o de l'hipervisor.

I ara el criteri de fons: amb aquest model, invertir en un NIDS aporta poc (ja ho vas raonar a 06-04) i invertir en detecció de canvis i en control de l'autenticació aporta molt. Això és prendre decisions, no seguir una llista.

El que no existeix no es pot atacar, no necessita pedaços i no apareix en cap CVE. És el principi amb millor relació entre esforç i resultat.

Llegeix cada línia preguntant «ha de ser aquí, i en aquella adreça?»:

• systemd-resolve a 127.0.0.53 i 127.0.0.54: local, correcte.
• sshd a 0.0.0.0:22: necessari, i ja enfortit.
• tramontana a 0.0.0.0:8080: escolta a totes les interfícies. El tallafocs el bloqueja des de fora, però això és defensa en una sola capa. El correcte és que l'aplicació escolti només a 127.0.0.1, perquè quan arribi el servidor intermediari invers de 08-01 serà qui li parlarà, i així el tallafocs passa a ser la segona línia en lloc de l'única.
• postgres a 10.0.2.15:5432: ja restringit a la interfície interna. Correcte.

El primer arreglament, doncs:

Això és defensa en profunditat aplicada: ara calen dues fallades —una regla de tallafocs mal posada i una escolta massa àmplia— per exposar el 8080. Abans en bastava una.

ModemManager gestiona mòdems i banda ampla mòbil. En una màquina virtual de servidor no té cap sentit. I aquí convé entendre la diferència entre les dues maneres d'apagar una cosa, perquè no són equivalents:

mask per al que no ha d'arrencar mai; disable per al que podries voler arrencar a mà algun dia. I el pas següent, quan n'estiguis segur, és desinstal·lar el paquet: un binari que no és al disc no té vulnerabilitats.

Sobre l'escriptori, per tancar l'apartat: un entorn gràfic afegeix centenars de paquets, un servidor X o Wayland, un gestor de sessions i un navegador — cadascun amb la seva superfície i el seu calendari de pedaços. Que srv-tramontana no en tingui no és austeritat, és la reducció de superfície més gran que es pot fer en un servidor, i per això l'instal·lador d'Ubuntu Server no l'ofereix per defecte.

Tres auditories que convé tenir guardades en un script, perquè detecten errors greus i són d'una línia cadascuna:

Els tres resultats són correctes: un únic UID 0, cap compte sense contrasenya, i els dos únics comptes de sistema amb shell són root —necessari per a la recuperació— i sync, que és un cas històric inofensiu. Que svc-tramontana no aparegui a la tercera llista és la confirmació que el -s /usr/sbin/nologin de 05-01 va fer la seva feina.

La política per defecte viu a /etc/login.defs, i afecta els comptes que es creïn a partir d'ara:

PASS_MIN_DAYS 1 és menys obvi que els altres: sense ell, algú a qui s'exigeix canviar la contrasenya la pot canviar cinc vegades seguides per esgotar l'historial i tornar a l'original. És un truc vell i continua funcionant on no es posa.

I per als comptes ja existents, chage:

chage -E mereix atenció: és la manera correcta de gestionar un compte temporal. Caduca sol en la data prevista, sense dependre que algú es recordi de donar-lo de baixa — i les baixes de personal oblidades són una de les vies de compromís més comunes que existeixen.

A 05-01 vam ajornar PAM. És el moment, perquè és la peça que decideix de debò qui entra en aquest sistema i amb quins requisits.

PAM (Pluggable Authentication Modules) és una capa d'indirecció: els programes que necessiten autenticar —login, sshd, sudo, su, passwd— no implementen la lògica, sinó que pregunten a PAM. Això permet canviar la política (exigir contrasenyes fortes, bloquejar després de fallades, afegir un segon factor) sense modificar ni recompilar cap programa. És la raó per la qual existeix.

Cada servei té el seu fitxer a /etc/pam.d/, i hi ha fitxers comuns que els altres inclouen:

Cada línia té tres parts: tipus, control i mòdul.

Els quatre tipus, que són quatre preguntes diferents i responen en moments diferents:

Confondre auth amb account és el malentès més habitual: una contrasenya correcta en un compte caducat passa auth i falla account.

Els controls determinen què passa segons el resultat del mòdul:

required davant de requisite té una raó de ser que no és evident: required continua executant la pila per no revelar en quin pas va fallar. Si un atacant pogués distingir «usuari inexistent» de «contrasenya incorrecta» pel temps de resposta o pel missatge, tindria un oracle per enumerar usuaris.

La sintaxi moderna, més precisa, fa servir claudàtors: [success=ok default=die] permet especificar l'acció per a cada codi de retorn. És el que veuràs als fitxers d'Ubuntu.

Abans de tocar ni una sola línia. Un error de sintaxi a common-auth pot impedir tot inici de sessió, inclosa la consola local, i aleshores l'única sortida és el mode de recuperació:

1. Deixa una sessió de root oberta en un altre terminal, i no la tanquis fins a haver acabat:

   $ sudo -i
   # (no tancar aquesta sessio)
   

2. Copia el fitxer abans d'editar-lo, segons la convenció del curs:

   $ sudo cp -p /etc/pam.d/common-password /etc/pam.d/common-password.bak-$(date +%F)
   

3. Prova en un tercer terminal, mai en el que tens la sessió de root.
4. Tingues a mà la consola de la VM i sàpigues com entrar en mode de recuperació (es veu a fons a 07-01).

És exactament la mateixa disciplina de netplan try i de la segona sessió SSH: no tanquis mai la porta per la qual estàs entrant.

Dos comentaris de fons. El primer: minlen = 12 amb minclass = 3 és més raonable que les polítiques de «8 caràcters amb majúscula, número i símbol» que produeixen Passw0rd! — la longitud aporta molt més que la complexitat forçada, i així ho recullen les guies actuals (NIST SP 800-63B). El segon: enforce_for_root = 1 és fàcil d'oblidar, i sense ell el compte més important del sistema és l'únic exempt de la política.

Complementa fail2ban, que actua sobre la IP; faillock actua sobre el compte, així que cobreix també els intents des de la consola o des d'IP diferents.

L'ordre importa i no és intuïtiu: preauth comprova si el compte ja està bloquejat abans de demanar credencials, authfail compta la fallada, i authsucc neteja el comptador després d'un accés correcte. Que falti authsucc produeix un bloqueig lent però inevitable, perquè el comptador no es reinicia mai.

I la combinació d'even_deny_root amb root_unlock_time = 60 és deliberada: protegir root sense crear la possibilitat d'un bloqueig total del sistema.

Dues d'aquestes línies són mesures de seguretat més que de rendiment. nproc limita el dany d'un bucle que crea processos sense control —accidental o no—. I core 0 evita els abocaments de memòria, que contenen tot el que el procés tenia a la RAM en aquell moment: inclosa la contrasenya que tanta feina t'ha costat xifrar a 06-05.

Compte amb l'abast: pam_limits s'aplica a sessions que passen per PAM. Per a un servei de systemd, els límits es posen a la unitat (LimitNOFILE, LimitNPROC), com vas veure a 05-07.

libpam-google-authenticator afegeix un codi TOTP a l'autenticació SSH. És eficaç contra el robatori de credencials, i en un servidor amb accés per clau el benefici marginal és menor que en un amb contrasenyes. Si s'implanta, hi ha dues coses que no es poden oblidar: guardar els codis de recuperació fora del servidor, i decidir què passa si el dispositiu TOTP es perd. Sense això, és una manera elegant de quedar-se fora.

A 06-04 els registres van mostrar que luis va entrar amb password, tot i que a 06-02 ho vas deshabilitar. Hora de localitzar-ho, començant per la font autoritzada:

La configuració global és correcta. Però sshd -T sense arguments mostra la configuració global; els blocs Match són condicionals i no hi apareixen. Cal preguntar pel cas concret:

Aquí està. Un bloc Match User luis amb l'excepció, posada «temporalment» mentre el Luis generava la seva clau, i mai retirada. És l'actor més probable del model d'amenaces —l'error propi— en la seva forma més característica.

Fixa't en sshd -T -C: l'opció -C avalua la configuració per a un context concret d'usuari, amfitrió i adreça, resolent els blocs Match. És l'única manera fiable de saber quina configuració s'aplica a algú, i mereix un lloc a la teva memòria: la meitat dels problemes desconcertants d'SSH són un Match oblidat.

Abans de recarregar, la disciplina de sempre: sshd -t valida, la segona sessió està oberta, i es fa servir reload en lloc de restart.

Els permisos que coneixes des de 02-07 són DAC (Discretionary Access Control): discrecionals perquè el propietari d'un recurs decideix qui hi accedeix. Tenen un límit estructural: un procés pot fer tot el que el seu usuari pot fer. Si l'aplicació de Tramontana es veu compromesa, l'atacant pot llegir qualsevol cosa llegible per svc-tramontana i escriure a qualsevol lloc on aquell usuari escrigui.

MAC (Mandatory Access Control) afegeix una capa que el propietari no pot relaxar: una política, definida per l'administrador i aplicada pel nucli, que diu què pot fer aquest programa, amb independència de qui l'executi.

Els dos modes són la clau del mètode de treball:

• complain (mode de queixa): no bloqueja, només registra el que hauria bloquejat. És el mode d'aprenentatge.
• enforce (mode d'aplicació): bloqueja. És el mode de producció.

I el procediment professional és sempre el mateix: escriure el perfil, posar-lo en complain, exercitar l'aplicació de debò, recollir les denegacions i ampliar el perfil, i només aleshores passar a enforce. Començar en enforce significa trencar el servei i descobrir els accessos que falten de la pitjor manera.

Aquell últim comentari és el que fa valuós el perfil. Un atacant que executi codi en el context de l'aplicació no pot llançar una shell, no pot llegir les còpies, no pot tocar els directoris personals i no pot modificar la seva pròpia configuració — coses que el DAC sí que li permetria fer en part, i que són precisament els primers passos de qualsevol postexplotació.

En mode complain la marca és ALLOWED amb un denied_mask: significa «això ho hauria bloquejat». Aquí ha aparegut un accés legítim que el perfil no contemplava —les plantilles—, així que s'afegeix i es repeteix el cicle:

A partir d'aquí, una denegació real apareix com a apparmor="DENIED", i és el primer que cal mirar quan el servei comença a fallar després d'un desplegament que canvia rutes:

SELinux, per a qui vagi a RHEL:

La diferència per ruta davant d'etiqueta té una conseqüència pràctica: a SELinux, moure un fitxer pot canviar-ne el context i trencar l'accés (d'aquí restorecon); a AppArmor, un enllaç simbòlic o un bind mount pot saltar-se una regla basada en ruta. Cada model té el seu punt feble.

A 06-03 vas aplicar els sysctl de xarxa. Aquests són els del mateix nucli, i són només de seguretat: els de rendiment es veuen a 07-03.

Dos avisos que has d'anotar, perquè són les dues maneres que això et mossegui més endavant:

• kernel.yama.ptrace_scope = 1 pot trencar depuradors. strace o gdb sobre un procés que ja està en marxa i no és fill teu deixarà de funcionar sense sudo. A 07-02 faràs servir exactament aquelles eines; recorda que aquest paràmetre és l'explicació si et dona Operation not permitted.
• kernel.unprivileged_userns_clone = 0 trenca contenidors sense privilegis, i a 07-05 muntaràs Docker. Per això queda comentat amb la raó escrita al costat. Un paràmetre d'enfortiment amb una nota explicant per què no està activat és documentació de qualitat; esborrar-lo i oblidar el motiu no ho és.

I el criteri general: cada línia d'aquest fitxer porta el seu comentari. Un sysctl.d amb quinze valors sense explicació és impossible de mantenir, perquè ningú —tu inclòs, d'aquí a sis mesos— no sabrà si se'n pot treure algun.

Tres opcions de muntatge que limiten el dany als directoris on qualsevol pot escriure:

El cas d'ús és directe: un atacant que aconsegueix escriure un fitxer sol necessitar executar-lo, i /tmp és el lloc on gairebé sempre pot escriure. Amb noexec, aquell pas falla.

I aquí és on la lliçó insisteix en una cosa que les guies d'enfortiment solen ometre: noexec a /tmp trenca coses reals. Diversos instal·ladors extreuen a /tmp i executen des d'allà; alguns gestors de paquets de llenguatges també. Cal comprovar-ho abans:

Aquell últim bloc és la verificació positiva: no n'hi ha prou que res no s'hagi trencat, cal comprovar que la mesura fa alguna cosa. Amb les dues comprovacions fetes, es fa persistent:

mount -a abans de reiniciar continua sent obligatori, pel que ja saps des de 05-04: un fstab mal escrit impedeix arrencar el servidor.

Un CVE és l'identificador únic d'una vulnerabilitat concreta. El seu CVSS és una puntuació de 0 a 10 acompanyada d'un vector que descriu com s'explota:

I el punt que cal interioritzar: la puntuació base no és el risc real per a tu. Un 9.8 en un component que no tens instal·lat, o que no està exposat, o que ja està mitigat per una altra capa, és menys urgent que un 6.5 al servei que dona la cara a Internet. El vector és més informatiu que el número: AV:N (explotable per xarxa) sense privilegis ni interacció de l'usuari és el que obliga a actuar avui.

El 18 d'agost a les 06:12, unattended-upgrades va actualitzar openssl i libssl3t64. El paquet està actualitzat al disc, però els processos que van arrencar abans continuen amb la biblioteca antiga carregada a memòria. És una vulnerabilitat amb paperassa: l'informe diu que està apedaçada i el servei continua exposat.

Dos serveis. L'ordre importa, i per dues raons diferents:

Un matís important sobre ssh: reload recarrega la configuració, però no substitueix la biblioteca carregada al procés mestre. Per a això cal reiniciar el dimoni — que no talla les sessions ja establertes, perquè cadascuna viu en un procés fill propi. Amb la segona sessió oberta com a xarxa de seguretat:

I la verificació de tancament:

Aquell 0 és el tancament. El segon incident queda tancat, i amb ell els tres.

Perquè no torni a passar, needrestart es configura en mode llista i s'integra a la revisió:

La decisió de no reiniciar automàticament és deliberada i coherent amb l'unattended-upgrades de 05-03: un reinici no supervisat de la base de dades a les 6 del matí és una interrupció de servei que la Marta ha de conèixer, no un efecte secundari.

A 05-05 vas enfortir tramontana.service. Ara es mesura i es millora:

3.4 MEDIUM per a un servei de xarxa no està malament, i hi ha marge. Les directives que falten, cadascuna amb la seva raó:

SystemCallFilter mereix explicació perquè és la directiva de més valor: instal·la un filtre seccomp al nucli que rebutja les crides al sistema fora del conjunt permès. Un exploit que aconsegueixi execució de codi dins del procés es troba que mount, ptrace, init_module o setuid fallen amb EPERM — no perquè faltin permisos d'usuari, sinó perquè el nucli no les accepta d'aquest procés. És contenció real, no configuració cosmètica.

I l'avís de MemoryDenyWriteExecute és el tipus de detall que separa una guia útil d'una llista copiada: impedeix que una pàgina de memòria sigui escrivible i executable alhora, cosa que bloqueja moltes tècniques d'explotació, i trenca qualsevol motor amb compilació en temps d'execució. Si l'aplicació de Tramontana fos Java o Node, aquesta línia la deixaria sense arrencar.

De 3.4 MEDIUM a 1.6 OK, amb el servei funcionant i verificat. L'ordre —aplicar, verificar, mesurar— és el mateix que a la rotació de credencials i al diagnòstic de rendiment. Aplicar sense verificar és com es descobreix a les 3 de la matinada que l'enfortiment va tombar el servei.

Quan tot l'anterior falla, queden les còpies. I davant del ransomware hi ha un detall que sol passar desapercebut: una còpia muntada permanentment és abastable pel ransomware, perquè el procés que xifra els fitxers del sistema xifra també els del volum muntat. Una còpia xifrada per l'atacant no és una còpia.

Les tres propietats que fan que una còpia resisteixi:

La millora concreta que se'n dedueix: restic admet el mode append-only a la destinació remota, en què el client pot escriure còpies noves però no esborrar les existents. Amb això, un atacant amb accés al servidor no pot destruir l'històric. És la mesura que cal demanar al proveïdor de l'emmagatzematge extern, i queda anotada a la llista de comprovació.

Aquesta és la taula que s'entrega, alineada amb l'estructura dels CIS Benchmarks i amb el que has fet realment al curs. Les tres columnes són deliberades: sense la d'evidència, una llista de comprovació és una declaració d'intencions.

Les files 25 a 27 són les importants de debò, perquè són les que un informe honest no amaga. I les files 32 a 34 delimiten el que un administrador no pot resoldre, que és informació que la direcció necessita tenir.

Un sistema enfortit es degrada sol: cada canvi, cada paquet nou, cada regla «temporal» l'allunya de l'estat que vas documentar. Quatre pràctiques el sostenen:

1. Revisió periòdica amb mètriques comparables. Lynis mensual, amb el seu índex d'enfortiment com a sèrie temporal al costat de la línia base de rendiment de 05-07:

   $ sudo lynis audit system --quiet | grep 'Hardening index'
     Hardening index : 82 [################    ]
   

   Del 68 de 06-04 al 82 actual. El rellevant no és el número: és que si baixa, hi ha una explicació per buscar.
2. Gestió del canvi. Tota modificació de configuració amb la seva còpia prèvia, el seu diff -u, la seva verificació i la seva anotació. És la convenció del curs, i és el control contra l'actor més probable del model d'amenaces.
3. Documentació viva al manual d'operació, fora del servidor: el model d'amenaces, aquesta llista de comprovació amb dates, l'inventari de secrets amb la seva última rotació, i el procediment de resposta a incidents.
4. Revisió del mateix model d'amenaces quan canviï la realitat: un servidor més, un servei nou, una dada nova que es comença a tractar. Un model d'amenaces de fa dos anys descriu un sistema que ja no existeix.

srv-tramontana tracta dades personals d'hostes. El RGPD exigeix mesures tècniques i organitzatives apropiades al risc (art. 32), i diverses de les decisions d'aquesta lliçó —la retenció de registres, l'abast de l'auditoria sobre l'activitat de persones treballadores, el termini de desplegament del xifratge en trànsit de la fila 25— tenen implicacions legals que no correspon decidir a un administrador. En un entorn real:

• El responsable de seguretat ha de revisar el model d'amenaces i la llista de comprovació, i validar els controls assumits.
• El responsable de protecció de dades ha de validar el tractament, els terminis de retenció i l'avaluació del risc residual.
• I aquesta llista de comprovació no substitueix una auditoria formal. És una autoavaluació honesta, feta per qui administra el sistema, i per definició té el punt cec de qui l'ha construït.

• Enfortir sense model d'amenaces. És la causa de la meitat dels sistemes fràgils: mesures copiades que trenquen coses i no protegeixen contra res que fos probable. Mitja pàgina de model canvia totes les decisions que vénen després.
• Tocar PAM sense una sessió de root oberta. Un error de sintaxi a common-auth pot impedir tot inici de sessió, inclosa la consola. Sessió de root en un altre terminal, còpia prèvia, i prova en un tercer.
• Oblidar pam_faillock.so authsucc. Sense aquella línia el comptador de fallades no es reinicia mai, i el bloqueig arriba dies després sense causa aparent.
• Oblidar enforce_for_root = 1 a pwquality.conf: el compte més important queda exempt de la política de contrasenyes.
• Posar un perfil d'AppArmor directament en enforce. Trenca el servei i t'obliga a descobrir els accessos que falten sota pressió. Sempre complain primer, exercitar de debò, i després enforce.
• Aplicar noexec a /tmp sense comprovar-ho. Hi ha instal·ladors que extreuen i executen allà. Prova amb mount -o remount i exercita apt i els teus scripts abans de tocar fstab.
• Editar fstab sense mount -a. Un fstab trencat impedeix arrencar el servidor. És la xarxa de seguretat de 05-04 i continua sent obligatòria.
• Confondre «paquet actualitzat» amb «vulnerabilitat corregida». Mentre el procés tingui la biblioteca vella a memòria, continua exposat. needrestart -r l després de cada actualització, i lsof | grep DEL com a confirmació.
• Enfortir i no verificar. systemd-analyze security millora la puntuació encara que hagis deixat el servei sense arrencar. Aplicar, verificar amb revisio_salut.sh, i després mesurar.
• MemoryDenyWriteExecute en una aplicació amb JIT. Java, Node i .NET no arrenquen. Llegeix què fa cada directiva abans de copiar-la.
• Una llista de comprovació sense columna d'evidència. «Tallafocs configurat» no diu res; ufw status verbose sí. Sense evidència, la llista de comprovació és una declaració d'intencions.
• Consell de mètode. Converteix les auditories d'aquesta lliçó en auditar_enfortiment.sh fent servir lib/comuns.sh, amb un temporitzador mensual i el principi de silenci si tot va bé. El que depèn de la teva memòria no és un control.

Després d'aplicar el drop-in d'enfortiment, tramontana.service deixa d'arrencar:

Descriu el procediment de diagnòstic, identifica la causa més probable a partir de la informació del missatge, i explica com acotaries quina directiva concreta el provoca sense treure-les totes de cop.

Escriu el perfil d'AppArmor per a l'embolcall /home/operador/bin/desplegar-segur, que s'executa via sudo i crida desplegar.sh. Raona què ha de permetre i —més important— què ha de denegar, i explica quin atac concret conté aquell perfil que ni el DAC ni la regla de sudoers no contenen.

La Marta et demana un informe d'una pàgina per a la direcció: «estem segurs?». Redacta'l recolzant-te en el model d'amenaces i en la llista de comprovació, sense tecnicismes innecessaris, dient amb honestedat què està protegit, què no i quines decisions necessiten pressupost o autorització.

Solució 1

La pista és al mateix missatge: code=killed, signal=SYS. SIGSYS és el senyal que envia el nucli quan un filtre seccomp rebutja una crida al sistema. Això apunta directament a SystemCallFilter, i no a les altres directives (que produirien típicament EACCES, EPERM o una fallada de ruta).

Procediment, del més informatiu al més costós:

getrandom és la crida per obtenir aleatorietat del nucli — l'aplicació la fa servir per a TLS i per a identificadors de sessió. És a @system-service, però la vaig excloure en afegir SystemCallFilter=~@privileged @resources @obsolete, i getrandom pertany al conjunt @resources en algunes versions de systemd. La segona línia, que semblava una millora, és la que trenca el servei.

Com acotar sense treure-ho tot, que és la part de mètode de l'exercici. La clau és que els drop-ins es poden apilar i anul·lar per separat:

Arrenca. Amb això queda confirmat que el problema era l'exclusió, no el conjunt base. Ara s'afina en lloc de renunciar al filtre:

Es manté ~@privileged @obsolete —que és on hi ha gairebé tot el valor defensiu—, s'abandona @resources, i s'afegeix getrandom explícitament. Exposició 1.7 en lloc d'1.6, amb el servei funcionant: un enfortiment pitjor sobre el paper i infinitament millor a la pràctica, perquè el d'1.6 no arrencava.

Mètode general aplicable a qualsevol fallada d'enfortiment:

1. Llegir el senyal o el codi d'error: SIGSYS → seccomp; EPERM en un fitxer → ProtectSystem/ReadWritePaths; EACCES amb apparmor="DENIED" → AppArmor; fallada en mapejar memòria → MemoryDenyWriteExecute.
2. Buscar l'evidència concreta al journal (syscall=, denied_mask=, la ruta).
3. Neutralitzar una directiva amb un drop-in de prefix numèric més gran, mai editant l'original.
4. Verificar que arrenca, afinar cap al mínim necessari, i tornar a mesurar.
5. Consolidar el drop-in amb un nom definitiu i deixar escrit el motiu de l'excepció — igual que l'unprivileged_userns_clone comentat del sysctl.

Solució 2

Què permet: llegir el paquet de release, escriure a releases/, canviar l'enllaç app, escriure el seu registre i el seu bloqueig, i parlar amb systemd per reiniciar el servei. Res més.

Què denega, i quin atac conté cada denegació:

I ara el fons de l'exercici: què conté aquest perfil que el DAC i sudoers no contenen.

La regla de sudoers permet a operador executar desplegar-segur com a root. A partir d'aquell moment, el DAC no ofereix cap protecció: root pot llegir /etc/shadow, pot llegir la credencial de la base de dades, pot esborrar les còpies, es pot afegir una clau SSH i pot llançar nc per obrir una shell cap a l'exterior. L'embolcall es va escriure precisament per evitar donar root complet, però la contenció depèn per complet que el contingut de l'script sigui correcte i continuï sent-ho.

Aquí hi ha el forat. Si desplegar.sh té una fallada —una variable sense cometes que permeti injectar una ordre, un tar que extregui un fitxer amb ../ a la seva ruta— l'atacant executa codi com a root a través d'una via autoritzada. Ni sudo ni els permisos Unix no l'aturen: l'execució és legítima des del seu punt de vista.

El perfil d'AppArmor és la capa que sí que l'atura, perquè el control no depèn de l'usuari sinó del programa: sigui quin sigui el codi que s'acabi executant dins d'aquest perfil, no podrà llegir els secrets, no podrà tocar les còpies, no podrà escriure a authorized_keys i no podrà llançar un intèrpret per sortir-ne. El dany queda acotat al desplegament, que és exactament el que es pretenia quan es va escriure l'embolcall i el que fins ara era només una intenció.

Això és defensa en profunditat en la seva forma més concreta: el sudoers limita qui i quina ordre; AppArmor limita què pot fer aquella ordre, fins i tot quan l'ordre es comporta malament.

Solució 3

Informe de seguretat — srv-tramontana / Tramontana Reserves Per a: Direcció · De: Operacions de sistemes · 18 d'agost de 2026

En una frase. El servidor està raonablement protegit davant de les amenaces que de debò l'afecten, amb tres qüestions pendents que detallo al final, una de les quals requereix una decisió de direcció.

Què protegim, per ordre d'importància. Primer, les dades personals dels nostres hostes: noms, dates d'estada i imports. La seva filtració seria irreversible, danyaria tercers i té conseqüències legals. Segon, la disponibilitat del servei de reserves, el cost del qual és econòmic i acotat en el temps.

De qui ens protegim, i què hem fet.

• Atacs automatitzats des d'Internet, que són constants. El servidor només accepta connexions per dues portes: la d'administració —que ja no admet contrasenyes, només claus criptogràfiques— i la del lloc web. Tota la resta està tancada per defecte, i qui insisteix a provar contrasenyes queda bloquejat automàticament. En l'últim mes s'han bloquejat 47 intents des d'una mateixa procedència.
• Robatori o filtració d'una contrasenya. Les credencials del sistema ja no estan escrites en cap fitxer llegible: estan xifrades i només el programa que les necessita les pot fer servir. Tenim a més un procediment escrit per canviar-les sense interrompre el servei.
• Els nostres propis errors, que estadísticament són el risc més probable. Tota modificació es fa amb còpia prèvia, es comprova abans d'aplicar-se i queda registrada. Un sistema independent vigila cada dia que cap fitxer crític no hagi canviat sense explicació.
• Ús indegut d'accessos legítims. Cada persona té només els permisos que la seva feina requereix, i els accessos a la configuració queden registrats.

Què fem si alguna cosa falla. Tenim còpies de seguretat xifrades, amb la restauració provada —no només configurada—, capaces de recuperar el servei en 8 hores perdent com a màxim 4 hores de reserves, terminis que es van acordar amb Operacions. I un procediment escrit de resposta a incidents, guardat fora del servidor.

Les tres qüestions pendents.

1. El trànsit web encara no viatja xifrat. El certificat està emès i verificat, però falta desplegar el component que el presentarà, previst a la fase següent. Mentrestant el servei no és accessible des d'Internet, així que l'exposició es limita a la nostra xarxa interna. No requereix decisió: està planificat.
2. Una troballa sense explicar. La nostra vigilància va detectar un fitxer de configuració d'accés que ningú no va crear. Està en investigació amb el procediment previst. N'informaré del resultat; si es confirmés accés a dades personals, hi ha obligació legal de notificar-ho en 72 hores.
3. Còpia externa protegida contra esborrat. Avui, qui tingués control del servidor podria destruir les còpies. Existeix una modalitat d'emmagatzematge que no permet esborrar el que ja està guardat, i és la millor defensa disponible davant d'un atac de segrest de dades. Requereix decisió de direcció: implica contractar emmagatzematge extern.

Què no està a les nostres mans. Tres coses queden fora del que l'administració de sistemes pot resoldre, i convé que hi constin: la seguretat interna de la mateixa aplicació, que correspon a desenvolupament; la seguretat física i del proveïdor d'infraestructura; i un atacant amb recursos molt superiors als d'una empresa de la nostra mida.

I un advertiment necessari. Aquest informe és una autoavaluació feta per qui administra el sistema, i per tant té el punt cec de qui l'ha construït. No substitueix una auditoria independent. Recomano, a més, que el tractament de dades d'hostes i els terminis de conservació de registres els revisi el responsable de protecció de dades.

En resum: la feina està feta, mesurada i documentada. L'única decisió que necessito de la direcció és la del punt 3.

srv-tramontana té ara una postura de seguretat, i això és qualitativament diferent de tenir mesures de seguretat. Hi ha un model d'amenaces escrit que diu què protegim, de qui i què assumim fora d'abast, i cada decisió d'aquesta lliçó s'hi justifica. La superfície d'atac s'ha reduït: l'aplicació escolta només en local, el que no es fa servir està emmascarat i purgat. L'autenticació passa per PAM amb política de contrasenyes, bloqueig per compte i límits de recursos —i vas localitzar el Match User luis que portava setmanes contradient la teva pròpia configuració—. AppArmor conté l'aplicació en enforce, amb un perfil que impedeix llançar una shell o llegir les còpies encara que el procés es vegi compromès. Els sysctl d'enfortiment estan aplicats i comentats, inclosa la línia que vas deixar desactivada amb la raó escrita al costat. /tmp està sense permís d'execució, comprovat abans de fer-ho persistent. I systemd-analyze security ha passat de 3.4 a 1.6 amb el servei verificat i funcionant, que és l'única millora que compta.

Els tres incidents estan tancats: els 47 intents des de 203.0.113.44 amb fail2ban, la db_password en clar amb systemd-creds i pass, i avui la libssl vulnerable que continuava carregada a memòria — perquè un paquet actualitzat no és una vulnerabilitat corregida fins que els processos ho saben. Queda una llista de comprovació de 34 files amb la seva columna d'evidència, tres qüestions obertes dites sense adorns i un informe per a la direcció que no promet el que no pot complir. L'índex de Lynis ha pujat de 68 a 82, i l'important d'aquell número no és el seu valor sinó que ara és una sèrie temporal que algú vigila.

I amb això es tanca el Mòdul 6: vas configurar la xarxa de manera persistent amb la reversió automàtica de netplan try; vas enfortir SSH amb claus ed25519, sense root i sense contrasenyes, i vas aprendre a llegir sshd -T -C per saber quina configuració s'aplica realment a algú; vas aixecar un tallafocs de llista blanca sobre nftables i vas saber l'ordre en què s'aplica per no quedar-te fora; vas muntar detecció d'intrusions amb AIDE i auditd, amb la base de dades protegida fora del servidor, i un procediment de resposta a incidents amb la seva regla incòmoda; vas treure els secrets dels fitxers de configuració i vas preparar el material criptogràfic de TLS amb renovació provada i vigilància de la caducitat; i avui has reunit tot això en una postura coherent i documentada.

Fins aquí has operat un servidor, i l'has operat a mà. Saps fer-lo servir, administrar-lo i defensar-lo, però hi ha dues coses que encara no saps fer: mirar-hi dins i multiplicar-lo. Al Mòdul 7: Temes Avançats fas totes dues. Veuràs el procés d'arrencada complet —de la UEFI a GRUB, a l'initramfs i a systemd— i aprendràs a recuperar un sistema que no arrenca, que és l'habilitat que separa qui reinstal·la de qui arregla. Aprendràs diagnòstic avançat amb strace, perf i eBPF per respondre a «què està fent exactament aquest procés?» quan els comptadors no basten (i descobriràs que el ptrace_scope que acabes de posar és part de l'enunciat del problema). Ajustaràs el nucli amb sysctl, ara sí per rendiment. I després comença la multiplicació: virtualització amb KVM i libvirt, contenidors amb Docker i per què són processos aïllats i no màquines petites, automatització amb Ansible —que convertirà tota la feina manual dels mòduls 5 i 6 en codi versionat i reproduïble, i les 8 hores d'RTO en bastant menys—, i per fi alta disponibilitat i balanceig de càrrega, on srv-tramontana deixa de ser un únic punt de fallada. Actualitza la instantània de la teva VM, guarda el manual d'operació fora de la màquina, i ens veiem al Mòdul 7.