
Set di regole Linux Auditd basato sulle best practice con 14.956 regole mappate su MITRE ATT&CK, ruolo di deployment Ansible e strumenti di lint/test per il monitoraggio della sicurezza e l'audit di conformità.
Questo repository fornisce best practice complete per la configurazione e il deployment del Linux Audit Daemon (Auditd), inclusi un ampio set di regole di audit orientate alla sicurezza, un ruolo Ansible per il deployment automatizzato e gli strumenti che verificano le regole su kernel reali.
Le modifiche al set di regole, al ruolo e ai test sono elencate in CHANGELOG.md.
Auditd è un potente sistema di auditing Linux che fornisce capacità complete di monitoraggio e logging del sistema. È progettato per tracciare eventi rilevanti per la sicurezza ed è essenziale per:
Le nostre regole di audit complete (/ndaal/audit_best_practices.rules o /dataset/audit_best_practices.rules) sono progettate per soddisfare vari standard di sicurezza e best practice, tra cui:
| File | Contenuto |
|---|---|
dataset/audit_best_practices.rules | Il set di regole principale: 14.956 regole attive con 903 chiavi, scritte come coppie arch=b32/arch=b64. Questo è il file che il ruolo Ansible scarica. |
dataset/audit_best_practices_high_volume.rules | File complementare con la raccolta non filtrata: ogni execve di un utente non di sistema, kill/tkill/tgkill e connect in uscita. Ogni regola al suo interno è commentata, quindi il file è disattivato per impostazione predefinita. La sua intestazione spiega come abilitare un blocco alla volta. |
ndaal/ | Copie identiche byte per byte di entrambi i file. |
*.rules.sha-256 | Sidecar SHA-256 in formato sha256sum. Il ruolo Ansible verifica ogni download rispetto ad essi. Dopo aver modificato un file di regole, eseguire tools/update_rules_checksums.sh per rigenerarli. |
tools/key-decisions.tsv | Una decisione per ogni coppia di collisione di chiavi, applicata da tools/resolve_key_collisions.py. |
Una regola che una misurazione ha dimostrato errata viene commentata con una nota datata che ne indica il motivo. Nulla viene eliminato, quindi il file conserva la storia di ogni decisione.
Una chiave che inizia con un ID di tecnica segue MITRE ATT&CK Enterprise 19.2. ATT&CK v19 ha revocato sei ID utilizzati dal file. Il 2026-09-27 le loro chiavi sono state rinominate con i successori che MITRE indica per esse. Modificare ogni query SIEM e ogni alert che utilizza una vecchia chiave:
| Vecchia chiave | Nuova chiave |
|---|---|
T1562.001_Impair_Defenses_Disable_or_Modify_Tools | T1685_Disable_or_Modify_Tools |
T1562.004_Impair_Defenses_Disable_or_Modify_System_Firewall | T1686_Disable_or_Modify_System_Firewall |
T1070.002_Indicator_Removal_Clear_Linux_or_Mac_System_Logs | T1685.006_Disable_or_Modify_Tools_Clear_Linux_or_Mac_System_Logs |
T1107_File_Deletion | T1070.004_Indicator_Removal_File_Deletion |
T1169_Sudo | T1548.003_Abuse_Elevation_Control_Mechanism_Sudo_and_Sudo_Caching |
T1079_Multilayer_Encryption | T1573_Encrypted_Channel |
Il watch su /var/log/audit/ porta T1685.004_Disable_or_Modify_Tools_Disable_or_Modify_Linux_Audit_System_Log, la sotto-tecnica v19 per il log di audit stesso, invece di T1685.006. Le note datate scritte prima della rinomina, e le regole commentate che esse spiegano, mantengono i vecchi nomi.
Sempre il 2026-09-27, le chiavi che nominavano la tecnica sbagliata sono state corrette. Modificare anche le query SIEM e gli alert per queste regole:
| Regola | Vecchia chiave | Nuova chiave |
|---|---|---|
Scritture e modifiche di attributi su /etc/passwd (una nuova coppia; le letture mantengono T1087) | T1087_Account_Discovery | T1098_Account_Manipulation |
Scritture e modifiche di attributi su /etc/shadow | T1087_Account_Discovery | T1098_Account_Manipulation |
Una persona che legge /etc/shadow | T1087_Account_Discovery | T1003.008_OS_Credential_Dumping_etc_passwd_and_etc_shadow |
/etc/ssh/sshd_config | T1021_Remote_Services | T1021.004_Remote_Services_SSH |
/root/.ssh/authorized_keys | T1021_Remote_Services | T1098.004_Account_Manipulation_SSH_Authorized_Keys |
/etc/systemd/system/ | T1053.006_Scheduled_Task_Systemd_Timers | T1543.002_Create_or_Modify_System_Process_Systemd_Service |
date | T1083_File_and_Directory_Discovery | T1124_System_Time_Discovery |
| Gli interpreti Python (pip, pipx, conda e npm mantengono T1072) | T1072_Software_Deployment_Tools | T1059.006_Command_and_Scripting_Interpreter_Python |
| mysql e psql eseguiti da una persona | T1213_002_database_access | T1213.006_Data_from_Information_Repositories_Databases |
Scritture e modifiche di attributi su /etc/group | T1087_Account_Discovery | T1098_Account_Manipulation |
Scritture e modifiche di attributi su /etc/gshadow (una nuova coppia; le letture mantengono T1087) | T1087_Account_Discovery | T1098_Account_Manipulation |
/usr/lib/systemd/system/ (/run/systemd/transient/ mantiene T1053.006) | T1053.006_Scheduled_Task_Systemd_Timers | T1543.002_Create_or_Modify_System_Process_Systemd_Service |
/home/vagrant/.ssh/authorized_keys | T1021_Remote_Services | T1098.004_Account_Manipulation_SSH_Authorized_Keys |
Scritture in /var/log/tomcat10/, 64-bit (un refuso) | tomcattomcat | tomcat |
Scritture in /etc/mandiant/, 32-bit (un refuso) | mmandiant_config | mandiant_config |
unix_chkpwd, il controllo della password di sudo e dei blocchi schermo, legge /etc/shadow con l'audit ID della persona, quindi ogni controllo della password ora arriva come T1003.008. Filtrare exe=/usr/sbin/unix_chkpwd nella regola SIEM per il credential dumping. Le altre 34 regole con una chiave nella grafia T1234_567 non hanno mai etichettato un record, perché una regola precedente intercetta gli stessi eventi. Sono commentate con una nota che nomina quella regola.
Le chiamate a 32-bit di kexec_load, capset, perf_event_open e semtimedop_time64 ora portano KEXEC, capability_change_ebpf, perf_event_ebpf e T1559_Inter-Process_Communication invece di 32bit_abi. Il watch elasticsearch-data sull'intera directory dei dati è disattivato su entrambe le ABI: il suo warning lo rende opt-in. Su host a 64-bit le chiavi elasticsearch-nodes e elasticsearch-data-deletion, che fino ad allora venivano assegnate, ricompaiono.
Il kernel associa la chiave della regola caricata per prima che corrisponde a un evento. Questo vale sia per le regole sulle system call sia per i watch sui path (kernel/auditfilter.c, kernel/auditsc.c). Una regola ampia posizionata presto sottrae quindi la chiave a ogni regola specifica successiva. Fino al 2026-09-20 la regola execve procmon non filtrata si trovava alla riga 1.575, e 368 chiavi non sono mai apparse su un record.
Le regole catch-all ora chiudono il file, in questo ordine: