Configurar auditd per a monitoritzar accés a arxius crítics

Posar auditd a vigilar arxius crítics sona fàcil quan ho llegeixes en la documentació o quan t’ho expliquen en una presentació sobre compliment normatiu. Una altra cosa és quan ho necessites en producció, en sistemes amb càrrega real, on el rendiment importa, els logs creixen sense control i les regles es barregen amb el soroll.

Hi ha eines que tothom instal·la però pocs afinen. Auditd és una d’elles. De vegades s’activa perquè ho demana una auditoria, d’altres perquè algú vol “veure qui va tocar X arxiu”. Però si no ho configures amb cura, acabes amb centenars d’esdeveniments irrellevants per segon, o pitjor, sense registrar res útil just quan ho necessites.

No tot el que es pot auditar s’ ha d’ auditar

L’error més comú en començar amb auditd és l’ambició. Es pretén auditar tot el que sembli important: accessos a /etc, /var/log, /bin/su, /etc/shadow, /home, fins i tot /var/www. Això dura fins que el disc s’omple o algú es queixa d’I/O.

Una regla senzilla: si no tens un cas d’ús concret per a un arxiu o ruta, no l’auditis. El que sembla “crític” genèricament no sempre ho és en el context operatiu. Auditar /etc complet sembla lògic, però genera esdeveniments inútils cada vegada que algun servei llegeix les seves configuracions, fins i tot en accessos de només lectura completament legítims.

Centrem-nos en el que fa mal quan es veu alterat o accedit de forma inesperada: sudoers, shadow, passwd, claus privades, credencials hardcodejades, alguns scripts d’automatització, certificats TLS si estan en text pla. La resta es revisa cas a cas.

Regla clara: diferència entre lectura i modificació

No és el mateix voler saber qui va canviar alguna cosa que qui el va llegir. Això condiciona el tipus d’ esdeveniments que configures. En molts entorns, l’accés en lectura no és sensible (per exemple, /etc/hosts), però els canvis sí. El problema és que si fas servir -a always,exit -F path=/etc/passwd -F perm=r, vas a registrar esdeveniments cada vegada que qualsevol binari llegeixi aquest arxiu, cosa que inclou comandaments com id, who, getent, login, etc.

La regla pràctica és fer servir perm=w per a canvis, i només afegir r si hi ha una raó clara per a auditar la lectura (per exemple, si estàs en un entorn on l’exfiltració de secrets és una preocupació seriosa). Fem servir perm=r només en arxius com .env o /etc/ssl/private/* si contenen claus en text pla i el sistema no té mecanismes de control més fins.

UID real, no efectiu: el filtre que evita malentesos

Un error comú és configurar regles sense tenir en compte l’UID real (auid) i quedar-se amb l’UID efectiu (uid). Això porta a confusions quan els esdeveniments mostren que va ser el procés sshd el que va tocar alguna cosa, quan en realitat va ser un usuari connectat per SSH.

Filtrem sempre per auid en lloc de uid. L’ auid s’ assigna quan s’ inicia una sessió i es conserva fins i tot si es canvia d’ usuari amb sudo o su. Així, pots rastrejar qui va iniciar la sessió original. Si fas servir només uid, et perdràs en processos que canvien d’usuari tot el temps.

Una regla típica:

-a always,exit -F path=/etc/shadow -F perm=w -F auid>=1000 -F auid!=4294967295 -k shadow-write

La condició auid>=1000 filtra a usuaris reals (en la majoria de distres modernes), i auid!=4294967295 descarta processos del sistema (auid=-1 en unsigned).

El control del soroll: si no pots llegir-lo, no serveix

Un cop configurades les regles, comença el veritable treball: gestionar els logs. Si no tens rotació de logs, disc dedicat per a /var/log/audit, o una política de retenció clara, els esdeveniments t’ofeguen. El dimoni s’atura si no pot escriure, i quan això passa, és pitjor que si no tinguéssim auditoria.

Un truc simple: muntar /var/log/audit en un volum separat o almenys com un bind mount limitat, i configurar num_logs i max_log_file amb marges estrictes:

max_log_file = 100
num_logs = 5

Això limita a 500 MB rotant. Si s’omple, perdem esdeveniments vells, però no aturem el sistema. En entorns crítics, pots activar disk_full_action = SYSLOG o SUSPEND, però necessites saber molt bé el que fas. Hi ha sistemes on perdre logs és millor que col·lapsar el node. Decideix segons el tipus de càrrega.

Un altre costum útil: fer ausearch -ts recent -k <clau> part del troubleshooting habitual. Si els logs hi són, però ningú sap consultar-los, estàs igual que sense tenir-los.

Distingir esdeveniments reals d’ activitat legítima

Quan habilites auditoria en arxius que es modifiquen per processos automàtics (ex: logrotate, cron, puppet), acabes veient esdeveniments esperables però sorollosos. Si no filtres aquests casos, acabes ignorant tots els logs, fins i tot els importants.

Un patró que podem seguir és etiquetar cada regla amb una clau (-k) específica, com passwd-write, cert-read, etc., i després establir un cron que filtri esdeveniments nous sense UID a la whitelist (scrips coneguts, serveis específics). No tot s’automatitza, però almenys tens un punt de partida quan busques alguna cosa anòmala.

També es poden aplicar regles inverses: si determinat arxiu només hauria de ser accedit per un binari específic, i apareix un altre PID, això sí que és senyal d’alerta. Per això, combinem ausearch amb pid, exe, i uid. No és trivial, però amb un script de parsing bàsic (ausearch + jq o ausearch -i | grep) es poden generar alertes per patró desconegut.

Evita regles genèriques tipus watch

Evita fer servir -w /ruta amb auditctl. És fàcil caure en això perquè és més directe que les regles completes amb -a always,exit -F. Però aquestes regles watch només controlen operacions a nivell d’inode, i no et donen el mateix control sobre permisos, UID, ni permeten combinacions amb dir, key, etc. És millor definir regles completes, encara que siguin més verboses.

En comptes de:

-w /etc/shadow -p w -k shadow-watch

Fes servir:

-a always,exit -F path=/etc/shadow -F perm=w -F auid>=1000 -F auid!=4294967295 -k shadow-write

El segon enfocament és més precís i escalable.

Com mantenir les regles a producció

No editis directament audit.rules a mà a cada màquina. Fes servir un arxiu separat amb comentaris, versionat a Git, i aplica amb la teva eina d’automatització habitual. En molts casos, es pot gestionar amb Ansible i una plantilla simple que defineix només les regles necessàries per a cada tipus de host (bastió, base de dades, node d’aplicació). Així evitem regles redundants.

I compte amb auditctl vs augenrules. Moltes vegades apliques regles amb auditctl per provar-les, però després reinícies i desapareixen. En sistemes amb augenrules, el que es carrega és el que estigui en /etc/audit/rules.d/. Més d’una vegada he vist incidents perquè algú pensava que les regles estaven “configurades” i no ho estaven després d’un reboot.

Última recomanació: monitoritza al propi auditd

En entorns amb risc real o amb compliment estricte, monitoritzo també el propi auditd. Algú podria intentar parar-lo o modificar la seva configuració. Pots afegir regles com aquestes:

-w /etc/audit/ -p wa -k audit-config
-a always,exit -F arch=b64 -S kill -F auid>=1000 -F auid!=4294967295 -F obj_uid=0 -F obj_gid=0 -F exe=/bin/kill -k audit-kill

Això no és infal·lible, però almenys et dona visibilitat si algú amb privilegis intenta silenciar-ho.

Configurar auditd per a vigilar accessos crítics no és qüestió de marcar tot com a important, sinó de saber què esperes veure i què t’ha de destorbar. La diferència entre tenir logs útils o soroll que ningú mira està en els detalls. I com sempre, si no automatitzes la revisió, acabes sense assabentar-te de res. Millor menys regles, ben triades, que un bosc d’esdeveniments que ningú ha d’analitzar.