Són dos quarts de nou del matí i el servidor de nòmines d'una empresa petita
mostra activitat que ningú reconeix. No hi ha cap SIEM ni cap equip de
guàrdia: hi ha una responsable de sistemes, una càmera a la sala
d'administració, un auth.log i la reunió amb direcció d'aquí a unes hores.
Així comencen de debò la majoria d'incidents en una pime, i no amb una
alerta vermella en un tauler.
El difícil, en aquesta situació, no és teclejar grep. És saber quina
pregunta cal fer a cada evidència, no refiar-se de la primera hora que
surt a la pantalla, no esborrar la prova en netejar el sistema i no fer fora
del servidor qui hi està treballant. El cas Montseny és això, en quatre
capítols: vídeo, deducció i un terminal forense amb registres que es
llegeixen com els d'un servidor real.
A qui va adreçat
| Formació | Curs d'especialització en Ciberseguretat en entorns de les TI |
| Mòdul | 5021 · Incidents de ciberseguretat |
| RA principal | RA3 · Investiga incidents de ciberseguretat analitzant els riscos implicats i definint les possibles mesures a adoptar |
| CA que treballa | 3.2 anàlisi d'evidències · 3.3 investigació de l'incident · 3.5 primeres mesures de contenció |
| CA que toca de passada | 3.1 (les evidències arriben com a còpia de només lectura i el cas insisteix a conservar-les, però no es practica l'adquisició) · RA2 2.3 (detecció amb elements de seguretat física: la càmera i el lloc de treball) i 2.5 (documentació i seguiment) · RA4 4.5 (lliçons apreses a l'informe) |
| Durada | unes 4 hores, en una o dues sessions |
| Format | en equip, per capítols, amb informe final puntuat |
| Idiomes | ES · CA · EN (la veu dels vídeos és en castellà; els subtítols, en tots tres) |
La teoria
El cicle de vida d'un incident
La referència que gairebé tothom fa servir per ordenar una resposta és la guia NIST SP 800-61 (Computer Security Incident Handling Guide). A la revisió 2 (2012) descriu quatre fases que es recorren en bucle:
| Fase | Pregunta que respon | Al cas |
|---|---|---|
| Preparació | Què tenim a punt abans que passi? | el que faltava: rellotges sincronitzats, MFA, taules netes |
| Detecció i anàlisi | Què ha passat, quan, des d'on i amb quin abast? | capítols 1 i 2 |
| Contenció, eradicació i recuperació | Com aturo el dany, trec el que hi ha deixat l'atacant i torno a la normalitat? | capítols 2, 3 i 4 |
| Activitat posterior | Què n'aprenem perquè no es repeteixi? | l'informe final |
La revisió 3, publicada el 2024, reorganitza el mateix contingut sobre les funcions del NIST Cybersecurity Framework 2.0 (governar, identificar, protegir, detectar, respondre, recuperar). El fons no canvia: la resposta no comença amb l'incident ni s'acaba quan es tanca.
Una idea d'aquest cicle que el cas fa notar: contenir no és eradicar. Bloquejar la sortida de dades atura l'hemorràgia, però si l'atacant ha deixat una porta del darrere, tornarà. I si ningú canvia la credencial compromesa, també.
Evidència i cadena de custòdia
Una evidència digital només serveix si es pot demostrar que no ha canviat des que es va recollir. Per això:
- Es treballa sobre còpies, mai sobre l'original. Al cas, el terminal del primer capítol és una còpia de només lectura, i al tercer es recorda que abans d'esborrar res se'n desa una còpia com a evidència.
- Es calcula un resum criptogràfic (
sha256sum) en el moment de l'adquisició i es torna a calcular a cada traspàs. Si coincideix, el fitxer és el mateix. - Es documenta la cadena de custòdia: què s'ha recollit, de quin equip, qui, quan, amb quina eina, on es guarda i per quines mans ha passat. Un forat en aquesta llista és un argument per a l'altra part.
- Es respecta l'ordre de volatilitat. L'RFC 3227 (Guidelines for Evidence Collection and Archiving) demana recollir primer el que desapareix abans: registres de la CPU, memòria, connexions i processos en curs, i després el disc i les còpies de seguretat. Apagar el servidor «perquè no continuï entrant» esborra justament el més volàtil.
Les normes de referència són la ISO/IEC 27037 (identificació, recollida, adquisició i preservació d'evidència digital) i, a l'Estat, la UNE 71506 sobre metodologia d'anàlisi forense d'evidències electròniques.
I una regla que al cas es nota: un compte compromès es bloqueja, no s'esborra. Esborrar-lo n'elimina el directori, les claus i l'historial, que formen part de la prova.
Llegir els registres d'un Linux
Un servidor Debian o Ubuntu guarda la història d'un accés en diversos llocs que no diuen el mateix:
| Font | Què conté | Com es llegeix | Compte amb |
|---|---|---|---|
/var/log/auth.log | autenticació: sshd, sudo, PAM, systemd-logind | grep, awk, less | a RHEL i derivades es diu /var/log/secure |
/var/log/wtmp | sessions obertes i tancades, reinicis | last | és binari: cat no serveix |
/var/log/btmp | intents fallits | lastb (amb sudo) | pot no existir o haver-se rotat |
/run/utmp | qui hi ha dins ara | who, w | es buida en reiniciar |
~/.bash_history | ordres escrites a Bash | cat | s'escriu en tancar la sessió, sense hora tret que hi hagi HISTTIMEFORMAT, i es desactiva amb una línia |
/etc/crontab, /etc/cron.d/, /var/spool/cron/crontabs/ | tasques programades del sistema i de cada usuari | ls -l, cat, crontab -l -u | l'execució queda al syslog com a CRON[pid]: (usuari) CMD (…) |
~/.ssh/authorized_keys | claus que poden entrar sense contrasenya | cat | cada línia és una clau més |
Les línies de sshd que importen tenen formes fixes: Accepted password
for USUARI from IP port N ssh2, Accepted publickey for …, Failed
password for … i Invalid user … from …. Dues lectures que es confonen
sovint:
- Molts errors no proven que algú entrés, i un accés correcte sense errors previs no prova que fos legítim. Qualsevol SSH exposat a internet rep intents a totes hores: són soroll de fons fins que es demostri el contrari.
- L'absència de rastre no és innocència. Un historial buit pot voler dir que no s'ha fet res o que algú ha executat
unset HISTFILE.
Persistència: el que s'hi queda
Qui ha entrat vol poder tornar. Els llocs clàssics a Linux són pocs:
tasques de cron, temporitzadors i serveis de systemd, claus SSH
afegides a authorized_keys, fitxers d'arrencada del shell (.bashrc,
.profile), usuaris nous o amb UID 0, i binaris amb SUID que abans no hi
eren.
El que delata la persistència és gairebé sempre la regularitat: una
cosa que passa cada N minuts exactes, sempre al mateix segon, en un servidor
on les persones no treballen amb aquesta precisió. I el que la delata al
disc és el que no encaixa amb els veïns: una data de modificació
diferent, un nom que n'imita un altre de legítim. Compte: el mtime que
mostra ls -l es canvia amb touch, així que és un indici, no una prova.
En eradicar es falla de dues maneres: deixant la porta del darrere o enduent-se per davant una cosa legítima que s'hi assemblava.
La línia temporal, i els rellotges que menteixen
La línia temporal és l'espinada de l'informe: cada esdeveniment, amb l'hora, normalitzada a una sola referència (normalment UTC, anotant el desfasament aplicat a cada font), la font i el grau de certesa. «Sessió oberta a les HH:MM des de tal IP» és un fet; «va copiar les nòmines» pot ser una inferència, i l'informe els ha de distingir.
El format clàssic de syslog (Mar 3 12:05:09) no porta ni any ni zona
horària: l'hora és la local del servidor i cal saber quina era. Les
distribucions recents escriuen ISO 8601 amb el desfasament inclòs, i això
estalvia disgustos. A la Catalunya peninsular, com a la resta de l'Estat,
el desfasament canvia dues vegades l'any: UTC+1 a l'hivern i UTC+2 a
l'estiu, amb el canvi l'últim diumenge de març i l'últim d'octubre. Un
equip que no s'actualitza després del canvi d'hora va exactament una hora
desviat, i un equip sense NTP deriva segons o minuts cada setmana.
Quan dues fonts no coincideixen, la pregunta no és quina té raó, sinó quina està sincronitzada i quant es desvia l'altra. Es calcula el desfasament amb un esdeveniment que aparegui a totes dues i s'aplica a tota la resta. Per això l'NTP a tots els equips —servidors, però també enregistradors de càmeres, tallafocs i controladors d'accés— és una mesura de preparació, no un detall tècnic.
Correlacionar evidència física i lògica
El cas combina dos mons que a les empreses solen estar en mans diferents: el que grava una càmera o registra un control d'accés, i el que escriuen els servidors. Cap dels dos no n'hi ha prou tot sol. La càmera diu qui o què hi havia en una sala, però no què ha passat a la xarxa; el log diu quin compte i des de quina adreça, però no qui hi havia darrere el teclat.
Correlacionar és creuar-los, i les etiquetes físiques (d'un rack, d'un lloc de treball) també són evidència. La seguretat física forma part de l'incident: una dada exposada en un lloc de treball és una vulnerabilitat igual que un port obert.
Les pistes falses
Tota investigació real té soroll que s'assembla al senyal:
- Activitat legítima a la mateixa franja. Còpies de seguretat, administradors, companys que treballen a deshora.
- Coincidència temporal no és causalitat. Que dues coses passin a la mateixa hora no les uneix.
- Adreces que canvien. Un mateix domini pot resoldre a adreces diferents a hores diferents, i una IP pública pot amagar moltes persones darrere d'un NAT o d'una xarxa d'anonimat.
- El que es veu a la pantalla no sempre és de l'atacant. Abans d'atribuir una dada, cal preguntar-se qui l'ha generada.
La defensa és metodològica: hipòtesi, evidència a favor, evidència que la contradiria i comprovació. Si l'equip s'encalla, que torni a l'evidència.
Contenir sense fer mal
La contenció ha de ser proporcionada i precisa:
- Bloquejar l'adreça concreta, no una xarxa sencera que pot incloure serveis legítims. En un servidor amb UFW, una regla de sortida (
ufw deny out to …) talla l'exfiltració sense tocar la resta. - Tallar la sessió de l'intrús, no totes les de l'usuari.
whoiwdiuen qui hi ha i des d'on;psdona el procés de cada terminal.pkill -u usuariels fa fora a tots, també qui treballa. - Bloquejar el compte (
passwd -lousermod -L) i, després, rotar la credencial. Bloquejar sense rotar només ajorna el problema.
L'informe
El llegeix direcció, no l'equip tècnic. Una estructura que funciona:
| Apartat | Contingut |
|---|---|
| Resum executiu | què ha passat, impacte i estat actual, en un paràgraf |
| Línia temporal | esdeveniments en UTC (o en hora local declarada), amb la font |
| Vector d'entrada | com va entrar, amb l'evidència que ho prova |
| Abast | quins sistemes i quines dades, i què no s'ha vist afectat |
| Indicadors de compromís | adreces, dominis, fitxers, claus |
| Accions fetes | contenció, eradicació, recuperació, amb hora |
| Lliçons i recomanacions | què va fallar a la preparació i què canvia |
Si hi ha dades personals afectades —i unes nòmines ho són—, el RGPD obliga, a l'article 33, a notificar la bretxa a l'autoritat de control en un termini de 72 hores des que se'n té constància, tret que sigui improbable que suposi un risc per a les persones. Per a una empresa privada, aquesta autoritat és l'AEPD. Això és matèria del RA5, però l'informe del cas és el primer que caldria per fer-ho.
Com funciona el laboratori
Cada capítol comença amb una gravació d'uns 55 segons que la primera
vegada no es pot avançar: el que cal és en el que es veu i en el que es diu,
però el vídeo no dona mai la resposta. Després hi ha el terminal
forense, amb ordres reals (grep, awk, cut, sort, uniq, w,
ps, ufw…) sobre fitxers de registre de debò, i un tauler de
conclusions.
- Accés nocturn. Lectura d'
auth.log, correlació de la gravació amb el registre i conciliació de rellotges. Entrena la fase de detecció i anàlisi, i a separar el soroll del senyal. - Rastre de sortida. Registres de DNS i del tallafocs perimetral, correlació per client, domini i hora, i una primera contenció amb el tallafocs local. Entrena l'exfiltració i la contenció precisa.
- Alguna cosa s'hi va quedar. Ara es pot modificar el servidor. Trobar la persistència, entendre què fa i treure-la sense trencar el que és legítim. Entrena l'eradicació.
- Contenció i tancament. Sessions actives, bloqueig de comptes i la reconstrucció ordenada de la línia temporal. Entrena la contenció sense danys col·laterals i el tancament de l'incident.
Als capítols 2 a 4, l'ordre comprobar (també accepta àlies en català i
anglès) verifica els canvis al servidor i dona un codi; restaurar deixa el
capítol com al principi. Les pistes hi són, tres per capítol, i costen
minuts.
Cada capítol val 25 punts, que baixen amb les respostes incorrectes, els
comprobar fallits i les pistes. Al final en surt un informe imprimible.
Errors habituals
- Refiar-se de la primera hora que es veu, sense saber quin rellotge hi ha al darrere.
- Confondre intent amb accés, en tots dos sentits.
- Atribuir per proximitat: una IP o una sessió propera a l'incident no és de l'atacant per estar a prop.
- Contenir a la brava: xarxes senceres, totes les sessions, apagar.
- Eradicar sense conservar còpia ni resum del que s'ha esborrat.
- Tancar sense rotar la credencial.
- Escriure l'informe per a tècnics, quan qui decideix és direcció.
Notes per al professorat
- Equips de tres o quatre, un navegador per equip. Funciona millor si una persona porta el terminal, una altra les notes i una altra la línia temporal, i van rotant a cada capítol.
- Auriculars per equip: cada equip revisa els vídeos al seu ritme; el projector queda per a la posada en comú.
- Ritme: unes quatre hores. Si es parteix en dues sessions, el tall natural és després del capítol 2. El progrés es desa al navegador, així que l'equip ha de tornar al mateix ordinador i al mateix navegador.
- Seguiment: cada capítol resolt dona un codi d'avanç per al docent, i l'informe final un de verificació amb equip, puntuació i temps.
- Les respostes es desen com a resum amb sal al mateix client. Això impedeix llegir-les al codi font, però no resisteix la força bruta quan l'espai de respostes és petit. Serveix per a classe, no per qualificar; en un mòdul de ciberseguretat es pot proposar, després, com a exercici.
- Sense xarxa: el laboratori és una carpeta (pàgina, guions, dades i vídeos) i no envia res enlloc. Es pot copiar sencera a un llapis USB; si en obrir-la com a fitxer el navegador no carrega els subtítols, n'hi ha prou de servir-la en local (
python3 -m http.server).
Preguntes per a la posada en comú:
- Quina font us va fer dubtar d'una hora, i com ho vau resoldre?
- Quina pista falsa us va costar més de descartar, i quina evidència la va descartar?
- Quina mesura de preparació hauria evitat l'incident? I quina l'hauria detectat abans?
- Si demà l'haguéssiu de notificar, a qui, en quin termini i amb quines dades?