Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
ndaal_public_auditd — 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à. | Kitploit
Strumenti/GitLabGitLab/ndaal_open_source/ndaal_public_auditd
Strumenti DifensiviAudit di ConfigurazioneDigital ForensicsDevSecOpsThreat IntelligenceRilevamento IntrusioniRisposta agli IncidentiAnalisi dei Log

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
GitLab
ndaal_open_source/ndaal_public_auditd

ndaal_public_auditd

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à.

Vedi Repository
445 giorni faNon ancora revisionato
Condividi

Linux Audit Daemon (Auditd) Best Practices and Deployment

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.

Panoramica

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:

  • Monitoraggio della sicurezza e rilevamento delle minacce
  • Audit di conformità (PCI-DSS, NISPOM, FISMA, STIG)
  • Indagine sugli incidenti e analisi forense
  • Analisi del comportamento del sistema

Caratteristiche principali

  • Tracciamento degli accessi ai file e delle modifiche
  • Monitoraggio dell'esecuzione dei processi
  • Logging dell'autenticazione utente
  • Rilevamento delle modifiche alla configurazione di sistema
  • Registrazione degli eventi rilevanti per la sicurezza
  • Auditing delle system call

Best practice per le regole di audit

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:

  • Requisiti di conformità PCI DSS
  • Linee guida di conformità NISPOM
  • Linee guida di sicurezza STIG
  • Best practice del settore provenienti da più fonti

I file delle regole

FileContenuto
dataset/audit_best_practices.rulesIl 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.rulesFile 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-256Sidecar 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.tsvUna 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.

Chiavi e MITRE ATT&CK

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 chiaveNuova chiave
T1562.001_Impair_Defenses_Disable_or_Modify_ToolsT1685_Disable_or_Modify_Tools
T1562.004_Impair_Defenses_Disable_or_Modify_System_FirewallT1686_Disable_or_Modify_System_Firewall
T1070.002_Indicator_Removal_Clear_Linux_or_Mac_System_LogsT1685.006_Disable_or_Modify_Tools_Clear_Linux_or_Mac_System_Logs
T1107_File_DeletionT1070.004_Indicator_Removal_File_Deletion
T1169_SudoT1548.003_Abuse_Elevation_Control_Mechanism_Sudo_and_Sudo_Caching
T1079_Multilayer_EncryptionT1573_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:

RegolaVecchia chiaveNuova chiave
Scritture e modifiche di attributi su /etc/passwd (una nuova coppia; le letture mantengono T1087)T1087_Account_DiscoveryT1098_Account_Manipulation
Scritture e modifiche di attributi su /etc/shadowT1087_Account_DiscoveryT1098_Account_Manipulation
Una persona che legge /etc/shadowT1087_Account_DiscoveryT1003.008_OS_Credential_Dumping_etc_passwd_and_etc_shadow
/etc/ssh/sshd_configT1021_Remote_ServicesT1021.004_Remote_Services_SSH
/root/.ssh/authorized_keysT1021_Remote_ServicesT1098.004_Account_Manipulation_SSH_Authorized_Keys
/etc/systemd/system/T1053.006_Scheduled_Task_Systemd_TimersT1543.002_Create_or_Modify_System_Process_Systemd_Service
dateT1083_File_and_Directory_DiscoveryT1124_System_Time_Discovery
Gli interpreti Python (pip, pipx, conda e npm mantengono T1072)T1072_Software_Deployment_ToolsT1059.006_Command_and_Scripting_Interpreter_Python
mysql e psql eseguiti da una personaT1213_002_database_accessT1213.006_Data_from_Information_Repositories_Databases
Scritture e modifiche di attributi su /etc/groupT1087_Account_DiscoveryT1098_Account_Manipulation
Scritture e modifiche di attributi su /etc/gshadow (una nuova coppia; le letture mantengono T1087)T1087_Account_DiscoveryT1098_Account_Manipulation
/usr/lib/systemd/system/ (/run/systemd/transient/ mantiene T1053.006)T1053.006_Scheduled_Task_Systemd_TimersT1543.002_Create_or_Modify_System_Process_Systemd_Service
/home/vagrant/.ssh/authorized_keysT1021_Remote_ServicesT1098.004_Account_Manipulation_SSH_Authorized_Keys
Scritture in /var/log/tomcat10/, 64-bit (un refuso)tomcattomcattomcat
Scritture in /etc/mandiant/, 32-bit (un refuso)mmandiant_configmandiant_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.

Ordine delle regole: la prima regola corrispondente fornisce la chiave

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:

Scarica lo strumento