Les tres lliçons anteriors han aixecat un perímetre: xarxa controlada, SSH amb claus i sense root, tallafocs amb política de llista blanca i fail2ban bloquejant qui insisteix. Tot això és prevenció, i la prevenció té una propietat incòmoda: quan falla, no avisa. Un atacant que entra amb una credencial legítima no dispara cap regla; la seva connexió apareix com a established, igual que la teva. Aquesta lliçó canvia la pregunta de «com impedeixo que hi entrin?» a «com m'assabento que ja hi han entrat?», i respon amb eines concretes: integritat de fitxers amb AIDE, auditoria del nucli amb auditd, lectura sistemàtica dels registres, auditoria de configuració amb Lynis i un procediment de resposta a incidents que puguis seguir a les tres de la matinada sense improvisar.

Advertiment legal previ. Tot el que hi ha aquí és defensiu i s'aplica sobre srv-tramontana, que és la teva pròpia màquina de laboratori. Escanejar, sondejar o intentar accedir a sistemes aliens sense autorització escrita és un delicte, amb independència de la intenció. I en el terreny del compliment: detectar intrusions en un sistema que tracta dades personals d'hostes activa obligacions legals concretes —notificació de bretxes en 72 hores sota el RGPD— i monitorar l'activitat de persones treballadores té límits que no decideix l'administrador. Totes dues coses es tracten al final de la lliçó.

1. Per què la detecció és un control diferent de la prevenció
2. Taxonomia: NIDS, HIDS, firmes, anomalies, IDS i IPS
3. Integritat de fitxers amb AIDE
4. Automatitzar AIDE amb un temporitzador de systemd
5. Detecció de rootkits: rkhunter i chkrootkit
6. auditd: l'auditoria del nucli
7. Anàlisi de registres per a la detecció
8. NIDS: panoràmica honesta de Suricata
9. Auditoria de configuració amb Lynis
10. Resposta a incidents i obligacions legals

Un control preventiu intenta que una cosa no passi. Un control detectiu assumeix que pot passar i s'ocupa que no passi desapercebuda. No són alternatives: són capes diferents, i una organització que només té la primera s'assabentaria d'un compromís per una trucada d'un tercer, setmanes després.

Els quatre camins pels quals la prevenció de srv-tramontana pot fallar, avui mateix:

La mentalitat que cal adoptar es diu presumpció de compromís: no «estic segur?», sinó «si estigués compromès, com ho sabria?». I aquella pregunta es descompon en tres, que són les que estructuren tota la lliçó:

1. Què ha canviat? Un atacant que vol persistir ha de modificar alguna cosa: un binari, un fitxer de configuració, una clau autoritzada, una unitat de systemd. → integritat de fitxers.
2. Qui hi ha entrat? Tota sessió deixa rastre als registres d'autenticació. → anàlisi de registres.
3. Què ha fet? Quins fitxers s'han llegit o escrit, quins processos s'han llançat. → auditoria del nucli.

El vocabulari de l'àrea és confús perquè barreja tres eixos independents. Convé separar-los:

Les conseqüències pràctiques de cada elecció:

• Firmes: precisió alta, pocs falsos positius, i ceguesa total davant del que no és al catàleg. Necessiten actualització constant.
• Anomalies: poden detectar el desconegut, a canvi de falsos positius i de necessitar un període d'aprenentatge del que és «normal». I «normal» canvia: la línia base que vas establir a 05-07 caduca.
• IPS: quan s'equivoca, provoca una interrupció del servei. fail2ban, que ja tens funcionant, és exactament un IPS de propòsit estret — i ja vas veure a 06-03 el risc que et bloquegi a tu.

Per a un servidor únic com srv-tramontana, la inversió que més rendeix és un HIDS d'integritat més auditoria del nucli. El NIDS guanya valor quan hi ha una xarxa amb diversos equips i un punt pel qual passa tot el trànsit; hi tornarem.

La integritat de fitxers és el senyal més fiable que té un servidor, per una raó estructural: un atacant que vol persistir ha d'escriure al disc. Pot esborrar entrades de registre, pot falsejar la sortida de ps amb un rootkit, però el binari modificat o la clau afegida hi continuen sent, i la seva empremta criptogràfica no coincideix amb la que tenies.

AIDE (Advanced Intrusion Detection Environment) construeix una base de dades amb els atributs i les sumes de comprovació dels fitxers que li indiquis, i després compara l'estat actual contra ella.

La configuració viu a /etc/aide/aide.conf i als fragments de /etc/aide/aide.conf.d/. L'essencial són els grups d'atributs, que defineixen què es comprova de cada fitxer:

Es combinen amb + en definicions reutilitzables, i després s'apliquen a rutes amb ruta grup per vigilar i !ruta per excloure:

Fixa't en el criteri: el nivell de vigilància s'ajusta al que s'espera que canviï. Vigilar el contingut d'acces.log amb sha256 produiria una alerta cada minut i en dos dies hauries deixat de llegir els informes — que és la manera més comuna que un sistema de detecció deixi de servir per a res.

I ara el punt que decideix si tot això serveix d'alguna cosa o és teatre:

Una base de dades d'integritat que viu al servidor vigilat no val res. Un atacant amb privilegis de root modifica el binari, regenera la base de dades, i aide --check et dirà que tot està en ordre. La base de dades —i, si t'ho pots permetre, el mateix binari d'aide— ha d'estar fora d'abast: en un mitjà de només lectura, o en una altra màquina.

Com el manual d'operació (runbook) de recuperació que ja guardes fora del servidor (05-08), la còpia de referència surt de la màquina:

Guardant almenys la suma de la base de dades fora del servidor pots detectar que la mateixa base de dades ha estat manipulada, que és l'atac contra el qual cal protegir-se.

La notació és densa però mecànica: la primera lletra és el tipus (f fitxer, d directori, l enllaç), i les posicions següents indiquen quin atribut ha canviat (C contingut, p permisos, u propietari, s mida, m mtime). Un + a la columna significa que s'ha afegit.

I aquí hi ha l'habilitat de debò, que no és llegir l'informe sinó classificar-lo:

• Els dos fitxers canviats són openssl i libssl. Tens una explicació documentada: el 18/08 a les 06:12 unattended-upgrades va aplicar la correcció d'un CVE de TLS. És un canvi legítim, i es comprova de manera independent:

  $ grep -E 'openssl|libssl' /var/log/apt/history.log | tail -2
  Upgrade: libssl3t64:amd64 (3.0.13-0ubuntu3.4, 3.0.13-0ubuntu3.5), openssl:amd64 (3.0.13-0ubuntu3.4, 3.0.13-0ubuntu3.5)
  $ sudo debsums -c openssl
  # sense sortida: tots els fitxers del paquet coincideixen amb el manifest de Debian
  

  debsums és la segona opinió: verifica els fitxers instal·lats contra les sumes del mateix paquet. Coincideixen, així que el binari és el que Ubuntu va publicar.

• El fitxer afegit és una altra cosa. authorized_keys2 és un nom obsolet que OpenSSH ja no llegeix per defecte, però que en configuracions antigues sí, i ningú no tenia motiu per crear-lo. Això no té explicació documentada, i és exactament la forma d'un mecanisme de persistència. Aquí no s'esborra el fitxer: s'activa el procediment de resposta a incidents del final de la lliçó.

Després de validar els canvis legítims, la base de dades s'actualitza perquè el proper informe torni a estar net:

Existeixen alternatives: Tripwire és l'avantpassat d'AIDE i té un model de signatura criptogràfica de la seva pròpia base de dades una mica més robust, a canvi de bastant més complexitat. debsums ja l'has vist i cobreix només fitxers de paquets. Per a un servidor únic, AIDE és l'equilibri correcte.

Una comprovació que cal recordar de fer no es fa. Amb el que has après a 05-05, el patró és directe, i respecta el principi de silenci si tot va bé:

Les 05:40 no són arbitràries: la còpia de seguretat acaba abans d'aquella hora i la purga s'executa els dilluns a les 05:10, així que la comprovació d'integritat veu un sistema en repòs i no competeix per l'E/S — el mateix raonament que vas aplicar a 05-07 quan vas moure la còpia a les 02:30. Nice=19 i IOSchedulingClass=idle són la garantia addicional.

Un rootkit és programari que s'instal·la després del compromís per mantenir l'accés i ocultar-ne la presència, típicament substituint binaris del sistema (ps, ls, netstat) o carregant un mòdul del nucli que menteix a l'espai d'usuari. És la raó per la qual la regla d'or del final d'aquesta lliçó existeix: si el sistema menteix sobre el seu propi estat, cap eina que corri dins d'ell no és de fiar.

I aquí arriba l'aprenentatge real d'aquestes eines: els dos avisos són falsos positius, i saber per què ho són és la feina.

• El primer és una limitació de l'anàlisi sintàctica de rkhunter: tu sí que vas configurar PermitRootLogin no a 06-02, però ho vas fer en un fitxer de /etc/ssh/sshd_config.d/, que l'eina no llegeix. Es verifica amb la font autoritzada, sshd -T, que mostra la configuració efectiva:

  $ sudo sshd -T | grep -i permitrootlogin
  permitrootlogin no
  

• El segon s'explica per l'actualització d'openssl: els binaris van canviar després que executessis --propupd. Després de validar-ho amb debsums, es regenera la base de propietats.

chkrootkit cobreix un terreny semblant amb altres heurístiques i és habitual que marqui interfícies en mode promiscu o processos ocults que en realitat són artefactes de la virtualització. La conclusió operativa és que aquestes eines són complement, no nucli: s'executen periòdicament, els seus avisos s'investiguen un a un, i mai no s'automatitza una acció a partir d'ells.

AIDE respon a «què ha canviat?», però no a «qui ho va canviar, quan i amb quin procés?». Això és auditd, el subsistema d'auditoria del nucli de Linux: registra crides al sistema i accessos a fitxers en el moment en què passen, amb l'usuari real, l'usuari efectiu, el PID i l'ordre.

Les regles persistents van a /etc/audit/rules.d/, i augenrules les compila en arrencar:

Recorda que a 05-02 vas posar chattr +i a app.conf. Mira què va aparèixer:

Llegeix-ho a poc a poc, perquè conté un incident complet: l'usuari luis va intentar obrir app.conf en escriptura amb vim, i la crida openat va fallar amb EPERM. L'atribut immutable va fer la seva feina. I —això és el que aporta auditd sobre qualsevol altre control— l'intent va quedar registrat amb nom, hora, PID i ordre, encara que no arribés a produir cap canvi que AIDE pogués veure.

No és necessàriament maliciós: el més probable és que el Luis volgués apujar max_connexions per resoldre els db_timeout i no sabés res del chattr. Però és una dada que abans no tenies, i la conversa que provoca —canalitzar els canvis de configuració per desplegar-segur en comptes d'editar a mà en producció— és exactament el valor d'un control detectiu.

Els informes agregats surten amb aureport:

I aquella segona línia torna a apuntar al mateix que AIDE va detectar. Dos controls independents assenyalant el mateix lloc és un senyal fort.

auditd no és gratis. Cada regla afegeix feina al camí de les crides al sistema, i una regla àmplia sobre una ruta amb molta activitat pot degradar el rendiment de manera perceptible i omplir el disc.

Vigila el que importa, mesura el volum (du -sh /var/log/audit/) i controla la retenció a /etc/audit/auditd.conf amb max_log_file, num_logs i max_log_file_action. I quan la configuració estigui tancada, -e 2 al final de les regles les fa immutables fins al proper reinici: ni root no les pot modificar, cosa que impedeix que un atacant desactivi l'auditoria abans d'actuar. El preu és que un canvi legítim exigeix reiniciar.

Tens journald persistent des de 05-06 i saps manejar journalctl. El que falta és saber què buscar. Aquests són els senyals que un administrador revisa, amb la consulta que els obté:

Dues observacions sobre aquests resultats, que són les que converteixen una consulta en una decisió:

• La línia 2 mostra que luis va entrar amb password. Però a 06-02 vas configurar PasswordAuthentication no. Que aquella autenticació tingués èxit significa que hi ha una excepció en algun Match de sshd_config.d/, o que es va aplicar a una interfície que no vas revisar. És l'assumpte pendent que va deixar obert 06-03, i ara té evidència: cal resoldre'l, no només demanar al Luis que faci servir la seva clau.
• Els 47 intents des de 203.0.113.44 ja estan bloquejats per fail2ban, però el recompte continua sent útil com a línia base: si demà en són 4.700, o si n'apareixen des d'un rang nou, el canvi de forma és el senyal.

La tècnica que estàs aplicant és la mateixa del Mòdul 3 —grep, awk, sort | uniq -c | sort -rn— sobre una font diferent. I la raó per la qual a 05-06 vas insistir en el journal persistent és aquesta: sense ell, la consulta número 3 no tindria 30 dies d'història per consultar.

Un avís important: els registres de la mateixa màquina són evidència manipulable. Un atacant amb root pot esborrar entrades del journal. Per això la centralització de registres que es va esmentar a 05-06 no és un luxe organitzatiu: enviar els registres a una altra màquina en el moment en què es generen és el que impedeix que s'esborrin a posteriori.

Suricata és el NIDS de referència en programari lliure: inspecciona el trànsit de xarxa, el compara amb un catàleg de firmes (el conjunt gratuït ET Open d'Emerging Threats és el punt de partida habitual) i registra o bloqueja les coincidències.

On es col·loca determina el que veu:

En mode IDS rep una còpia del trànsit i només avisa. En mode IPS se situa al camí del trànsit i pot descartar paquets, amb el risc associat: si s'equivoca o cau, talla el servei.

I ara la part honesta, perquè muntar Suricata a srv-tramontana seria un error de criteri en aquest moment:

En una infraestructura d'una sola màquina, l'esforç invertit en AIDE i auditd rendeix bastant més. Quan Tramontana creixi a diversos servidors —i a 07-07 veuràs com—, el NIDS passarà a la llista.

Un eix diferent: en comptes de detectar activitat, Lynis avalua la configuració del sistema contra un catàleg de bones pràctiques i retorna una puntuació amb suggeriments.

Com llegir-ho, que és menys evident del que sembla:

• L'índex d'enfortiment no és una nota acadèmica ni té un valor «aprovat». És una mètrica de seguiment: el que importa és la seva tendència i que no baixi sense que sàpigues per què. Un 68 en un servidor amb propòsit definit pot ser correcte; un 95 aconseguit aplicant suggeriments sense entendre'ls és pitjor.
• Els suggeriments no s'apliquen a cegues. Lynis avalua contra un perfil genèric i no coneix el propòsit de la teva màquina. Algunes de les seves recomanacions aquí serien activament contraproduents.

Un exemple real de cada categoria:

El resultat de l'exercici no és una puntuació alta, sinó un informe amb decisions documentades. Això és el que s'entrega a la Marta i el que resisteix una auditoria, mentre que «hem aplicat tot el que deia l'eina» no en resisteix cap.

Lynis s'executa de manera recurrent —mensualment, amb el seu propi temporitzador— i el seu índex s'anota al costat de la línia base de rendiment de 05-07.

Tens una detecció real: un authorized_keys2 que ningú no va crear. El que facis en els propers vint minuts determina si conserves la informació necessària per entendre què va passar. Aquest és el procediment, i l'ordre importa:

1. No apaguis la màquina. Apagar destrueix tota l'evidència que viu a memòria: processos, connexions obertes, fitxers esborrats però encara oberts, claus en clar. Aïlla en el seu lloc: talla el trànsit amb el tallafocs o desconnecta la interfície de xarxa virtual des de l'hipervisor, conservant l'accés per consola.

2. Anota l'hora i la troballa per escrit, fora del servidor. A partir d'aquí, cada acció es registra amb la seva hora. Aquest quadern de bitàcola és el que després permet distingir les teves pròpies petjades de les de l'atacant.

3. Preserva l'evidència volàtil abans de tocar res, guardant la sortida fora de la màquina:

   $ ss -tunap            # connexions i a quin proces pertanyen
   $ ps auxf              # arbre de processos complet
   $ sudo lsof -n         # fitxers i sockets oberts
   $ sudo ls -l /proc/*/exe 2>/dev/null | grep deleted   # binaris esborrats en execucio
   $ w; last -F | head -20
   $ sudo cp -a /var/log /media/evidencia/    # i el journal: journalctl -o export
   

   L'última consulta és especialment valuosa: un procés el binari del qual ja no existeix al disc però continua executant-se és un senyal molt fort.

4. Pren una instantània del disc amb la màquina encara encesa. A la teva VM és una operació de l'hipervisor; a LVM, una instantània com la de 05-04. Aquella imatge és la còpia sobre la qual s'investiga, per no alterar l'original.

5. Determina l'abast: què s'ha accedit, des de quan, i si hi ha dades personals implicades. auditd i el journal són les fonts. La pregunta que cal poder respondre és si reserves.csv —amb noms d'hostes— va ser llegit o exfiltrat.

6. Comunica. La Marta primer, i tan bon punt hi hagi sospita d'accés a dades personals, el responsable de seguretat i el de protecció de dades. Això no és una decisió tècnica.

7. Recupera reinstal·lant.

La cadena de custòdia és el concepte que sosté els passos 2 a 4: un registre de qui va tenir accés a cada evidència, quan i què en va fer, juntament amb les sumes de comprovació que demostren que no s'ha alterat. Sense ella, l'evidència serveix per entendre el que ha passat però no per sustentar una reclamació o una denúncia.

Un servidor compromès es reinstal·la, no es neteja.

No és pessimisme professional, és aritmètica. Per «netejar» hauries de demostrar que has trobat tots els mecanismes de persistència: cada binari substituït, cada unitat de systemd afegida, cada línia de crontab, cada clau autoritzada, cada mòdul del nucli, cada biblioteca precarregada per LD_PRELOAD. Un atacant competent en deixa uns quants i alguns difícils de trobar. I les eines amb què buscaries corren sobre el sistema que potser t'està mentint.

Per això tota la feina del Mòdul 5 té un valor que aleshores no era evident:

• La còpia amb restic (05-08) permet restaurar les dades, no el sistema compromès.
• El manual d'operació guardat fora del servidor conté el procediment de reconstrucció.
• La configuració documentada —netplan, sshd_config, regles d'ufw, unitats de systemd, app.conf— permet reconstruir la màquina.
• L'RTO de 8 hores que va aprovar la Marta és exactament el pressupost de temps d'aquesta operació.

Reinstal·lar és l'opció ràpida i segura, no la dràstica. I la reconstrucció per codi que veuràs a 07-06 amb Ansible converteix aquestes 8 hores en bastant menys.

• Notificació de bretxes (RGPD, art. 33). Si hi ha una violació de seguretat que afecta dades personals, l'organització l'ha de notificar a l'autoritat de control en un màxim de 72 hores des que en té coneixement, i en alguns casos també a les persones afectades. srv-tramontana guarda noms d'hostes a reserves.csv: el supòsit és plenament aplicable. El termini comença a comptar des del coneixement, no des que acabes la investigació, així que la comunicació del pas 6 no pot esperar.
• Límits a la monitorització de persones. Les regles d'auditd que vigilen què fa el luis registren activitat d'una persona treballadora identificable. Això està subjecte a la normativa laboral i de protecció de dades: exigeix finalitat legítima, proporcionalitat, i —de manera determinant— informació prèvia a les persones afectades. Auditar en secret l'activitat del personal no és una decisió que correspongui a l'administrador.
• En un entorn real, tant el disseny de la detecció com qualsevol decisió sobre una bretxa els han de revisar el responsable de seguretat i el de protecció de dades. Aquest curs et dona les eines tècniques; no substitueix aquell criteri ni una auditoria formal.

Seguint la convenció del curs —dir què protegeix i què no protegeix cada mesura—, el lliurable d'aquesta lliçó:

Es corregeix:

1. L'authorized_keys2 no explicat: s'activa el procediment de resposta a incidents; fins a tancar-lo, s'assumeix compromís.
2. L'autenticació per contrasenya del luis, que funciona tot i estar deshabilitada: hi ha una excepció a la configuració d'SSH que cal localitzar i eliminar.
3. Els canvis de configuració fets editant en producció: es canalitzen per desplegar-segur, i auditd verifica que es compleix.

S'assumeix, amb motiu:

1. Sense NIDS, no hi ha visibilitat del trànsit de xarxa. S'accepta mentre hi hagi un únic servidor; es revisa quan n'hi hagi diversos.
2. Sense registres centralitzats, un atacant amb root pot esborrar el journal. S'accepta amb el cost actual; és la primera inversió quan el pressupost ho permeti.

Què protegeix això i què no. AIDE i auditd detecten canvis i accessos, i per tant escurcen el temps fins a detectar un compromís, que és la variable que determina el dany. No l'impedeixen. I cap dels dos no protegeix contra un atacant que arribi amb credencials vàlides i no modifiqui res — per a això cal que els secrets deixin d'estar on són.

• Guardar la base de dades d'AIDE només al servidor vigilat. És l'error que anul·la tota la mesura. La base de dades, o almenys la seva suma de comprovació, ha d'estar fora.
• Vigilar fitxers que canvien legítimament amb sha256. Produeix un informe amb canvis cada dia, i en una setmana ningú no els llegeix. La saturació d'alertes és la principal causa de mort d'un sistema de detecció: si sona sempre, no sona mai.
• Actualitzar la base de dades d'AIDE sense investigar el canvi. aide --update després de cada informe converteix l'eina en un registre d'història sense capacitat d'alertar. Primer es classifica cada canvi, després s'actualitza.
• Auditar massa amb auditd. Una regla àmplia sobre /var/log o /proc degrada el rendiment i omple el disc. Comença estret i amplia amb criteri, mesurant du -sh /var/log/audit/.
• Confiar en un únic control. AIDE va detectar el fitxer afegit i aureport ho va confirmar de manera independent. Dues fonts que coincideixen donen una confiança que cap no dona per separat.
• Apagar la màquina en detectar un compromís. És el reflex natural i destrueix l'evidència de memòria. Aïlla la xarxa, conserva la màquina encesa.
• Tractar els falsos positius com a soroll a silenciar. Cada avís de rkhunter o Lynis que descartes ha de quedar documentat amb el seu motiu. Silenciar sense registrar és com es perd l'únic avís que era real.
• Consell de mètode. Guarda les consultes de detecció en un script (revisio_seguretat.sh) que faci servir lib/comuns.sh i s'executi per temporitzador. Una comprovació que depèn de la teva memòria no és un control.

Dissenya la configuració d'AIDE per vigilar /home/operador/bin/, el directori que conté l'embolcall desplegar-segur amb permisos 0755 de root. Justifica el grup d'atributs que tries i explica quin atac concret detectaria la teva regla que no detectaria vigilar només la suma de comprovació del contingut.

Escriu la regla d'auditd que registri qualsevol execució del binari /home/operador/bin/desplegar-segur, i la consulta d'ausearch que mostri qui l'ha executat avui. Explica quina informació aporta això que no aporti ja el desplegament.log que escriu desplegar.sh.

aide --check informa d'un canvi a /etc/tramontana/app.conf: l'atribut de contingut i el mtime han canviat, i els permisos han passat de 640 a 644. Descriu el procediment complet d'investigació, indicant quines fonts consultaries i en quin ordre, i quina decisió prendries en cadascun dels dos desenllaços possibles.

Solució 1

El grup complet, i no només sha256, per tres raons concretes, cadascuna associada a un atac diferent:

• p (permisos). desplegar-segur és a la regla de sudoers com a ordre permesa a operador. Si un atacant aconsegueix canviar-li els permisos a 0777, qualsevol usuari del sistema pot reescriure'n el contingut i, a través de la regla de sudo, executar codi arbitrari amb privilegis. El contingut encara no hauria canviat, així que una regla que només comprovi sha256 no veuria res. Aquest és l'atac que la resposta ha d'identificar.
• u i g (propietari i grup). El fitxer ha de ser root:root. Si passa a ser propietat del luis o del grup tramontana, el seu amo el pot modificar sense necessitat de privilegis, i de nou el contingut encara coincideix.
• i (inode) i n (enllaços). Un canvi d'inode amb el mateix contingut significa que el fitxer va ser substituït, no editat —per exemple, reemplaçat per un enllaç simbòlic a un altre binari—. Un comptador d'enllaços que puja d'1 a 2 indica que algú va crear un enllaç dur al fitxer, cosa que permet conservar accés al binari original encara que es reemplaci el que és a /home/operador/bin/.

En resum: la suma de comprovació detecta la modificació del binari, però els atributs detecten la preparació per modificar-lo, que passa abans i és el moment en què la detecció encara serveix per prevenir el dany.

Solució 2

Lectura de la regla: -a always,exit registra sempre, en sortir de la crida; -F arch=b64 la limita a binaris de 64 bits (necessari perquè el filtre per path amb perm opera sobre l'arquitectura); -F path= és el fitxer concret; -F perm=x restringeix el registre a les execucions i no a les lectures o escriptures; -k etiqueta l'esdeveniment.

Què aporta davant de desplegament.log, que és la part de fons de l'exercici. desplegar.sh escriu al seu registre el que ell mateix decideix escriure, i només si arriba a executar-se:

La diferència essencial és de confiança: desplegament.log és el testimoni de l'aplicació sobre si mateixa; el registre d'auditd el genera el nucli, per sota del procés, i no depèn de la bona fe ni del correcte funcionament del que s'audita. A més auditd conserva l'auid —l'usuari que va iniciar la sessió original—, que sobreviu als canvis d'identitat per sudo i respon a «qui va ser realment?» quan uid ja és root.

Solució 3

El canvi de permisos de 640 a 644 és el que és rellevant: significa que qualsevol usuari del sistema pot ara llegir el fitxer, i aquell fitxer conté db_password en clar. Es tracta igual que una credencial exposada, exactament com l'incident de la còpia amb permisos 644.

Procediment, en aquest ordre i per aquest motiu:

1. auditd primer, perquè respon a qui i quan, i és la font que un atacant tindria més difícil de manipular:

   $ sudo ausearch -k tramontana_conf -ts today -i
   

   Busca l'esdeveniment chmod/fchmodat amb èxit i anota auid, uid, comm, exe i l'hora exacta.

2. Correlaciona amb les sessions, per saber des d'on va arribar aquell usuari:

   $ sudo journalctl -u ssh --since today | grep -E 'Accepted|Disconnected'
   $ sudo journalctl --since today | grep -E 'sudo:.*COMMAND'
   

3. Comprova si hi ha una explicació legítima: hi va haver un desplegament en aquella finestra? Coincideix amb apt?

   $ tail -20 /var/log/tramontana/desplegament.log
   $ grep -E "$(date +%Y-%m-%d)" /var/log/apt/history.log
   

4. Avalua l'exposició, que és la pregunta que determina la gravetat: durant quant de temps el fitxer va estar llegible, i si algú el va llegir. El mtime canviat indica a més que el contingut també es va modificar, així que cal veure què es va canviar comparant amb l'última còpia:

   $ sudo restic dump latest /etc/tramontana/app.conf | diff -u - /etc/tramontana/app.conf
   

   I buscar lectures del fitxer en l'interval:

   $ sudo ausearch -k tramontana_conf -ts recent -i | grep -E 'syscall=openat.*success=yes'
   

Desenllaç A — canvi legítim: l'auid és operador, l'hora coincideix amb un desplegament registrat, i el diff mostra només max_connexions ajustat. Tot i així hi ha dues accions obligatòries, perquè el resultat és incorrecte encara que la intenció fos bona: restaurar chmod 640 i chown root:tramontana, i corregir la causa arrel —el procediment o l'script que deixa el fitxer en 644— perquè no es repeteixi. Es documenta i s'actualitza la base de dades d'AIDE. La lliçó de fons: un canvi autoritzat amb un resultat insegur continua sent una troballa.

Desenllaç B — sense explicació, o auid inesperat, o diff amb canvis que ningú no reconeix: es tracta com a compromís confirmat. S'aplica el procediment de resposta a incidents complet (aïllar, no apagar, preservar evidència volàtil, instantània del disc, determinar abast, comunicar). I amb independència de com acabi la investigació, la db_password es considera compromesa i es rota immediatament, perquè va estar llegible per a tot el sistema durant un temps que no pots acotar amb certesa. Com que hi ha dades personals implicades, la comunicació al responsable de protecció de dades entra dins del termini de 72 hores.

En tots dos desenllaços s'arriba a la mateixa conclusió estructural: mentre la contrasenya estigui en clar en un fitxer de configuració, qualsevol fallada de permisos és una fuita. Aquell problema no es resol vigilant millor el fitxer.

Has passat d'un servidor que es defensa a un servidor que a més s'observa. AIDE vigila la integritat de la configuració, els binaris i els scripts, amb la seva base de dades protegida fora de la màquina i una comprovació diària per temporitzador que només parla quan hi ha alguna cosa a dir. auditd registra al nucli qui toca app.conf, qui modifica identitats i privilegis, i qui intenta carregar un mòdul — i ja t'ha donat una troballa real que cap altre control no veia: l'intent fallit del Luis contra un fitxer immutable. Saps llegir els registres buscant senyals concrets en lloc de mirar-los per sobre, saps que rkhunter i Lynis s'interpreten i no s'obeeixen, i tens un procediment de resposta a incidents que no depèn de la improvisació, amb la seva regla incòmoda inclosa: un servidor compromès es reinstal·la, no es neteja.

I la detecció ha fet justament el que se li demana: t'ha dit on és el problema de fons. Les tres troballes d'aquesta lliçó apunten al mateix lloc. L'authorized_keys2 sense explicar, la sessió del luis autenticada per contrasenya, i sobretot la conclusió de l'últim exercici: mentre la db_password visqui en clar dins d'app.conf, qualsevol fallada de permisos —teva, d'un script, d'un atacant— és una fuita de credencials, i cap quantitat de vigilància sobre aquell fitxer no ho canvia. A això s'hi afegeix una segona peça que arrossegues des del Mòdul 5: el trànsit de reserves, amb els noms dels hostes que tanta cura has posat a protegir a les còpies, continua viatjant sense xifrar pel port 8080. A la lliçó 06-05: Gestió de Secrets i Certificats TLS es resolen totes dues: trauràs la contrasenya del fitxer de configuració a un secret xifrat que systemd lliura al servei i ningú més no pot llegir, aprendràs a gestionar claus amb GPG i pass i a xifrar en repòs amb LUKS, i muntaràs el material criptogràfic de reserves.tramontana.example —clau, CSR, certificat de Let's Encrypt i vigilància de la seva caducitat— perquè el dia que el servidor intermediari invers entri en joc al Mòdul 8 el xifratge en trànsit ja estigui resolt i verificat.