Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
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.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
auditd — Configurazione Auditd secondo le migliori pratiche | Kitploit
Strumenti/GitHubGitHub/neo23x0/auditd
Strumenti DifensiviAudit di ConfigurazioneInformatica ForenseRilevamento IntrusioniRisposta agli IncidentiAnalisi dei Log
GitHubneo23x0/auditd

auditd

Configurazione Auditd secondo le migliori pratiche

Vedi Repository
1.9k3103 mesi faRevisionato da Kitploit

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 →
Condividi

Actively Maintained

root@kitploit:~
    ___             ___ __      __
   /   | __  ______/ (_) /_____/ /
  / /| |/ / / / __  / / __/ __  / 
 / ___ / /_/ / /_/ / / /_/ /_/ /  
/_/  |_\__,_/\__,_/_/\__/\__,_/   

Configurazione Auditd di Best Practice

Idea

L'idea di questa configurazione auditd è di fornire una baseline di best practice che

  • è progettata per caricarsi immediatamente sulle principali distribuzioni Linux
  • copre un ampio insieme di attività dell'host rilevanti per la sicurezza
  • preferisce telemetria riutilizzabile a lunghe liste di rilevamenti hard-coded
  • mantiene la logica di rilevamento in regole Sigma, contenuti SIEM o analisi lato host
  • rimane facile da leggere e adattare grazie a sezioni e commenti

Il set di regole semplificato mantiene intenzionalmente alcune telemetrie di alto valore ma potenzialmente ad alto volume, in particolare la creazione di processi, la creazione di socket e gli eventi di fallimento di accesso ai file. Regola queste sezioni in base al tuo ambiente se necessario.

Coverage

La configurazione attuale si concentra sulle seguenti aree di copertura:

  • auto-audit e integrità della configurazione dell'audit
  • filtri di rumore ed esclusioni orientate alla portabilità
  • modifiche al kernel, moduli, mount, swap e ora
  • attività pianificate, database degli account, PAM, sudo e stato di login
  • configurazione di rete, firewall, avvio, servizi e percorso di boot
  • percorsi delle librerie, profili shell, SSH, systemd e modifiche alle policy MAC
  • tentativi di accesso falliti, modifiche DAC, file di sessione e euristiche di abuso dei privilegi
  • primitive speciali come ptrace, memfd_create, bpf, namespace, io_uring e userfaultfd
  • percorsi di configurazione di software, container e strumenti di sicurezza
  • telemetria ad alto volume come execve, execveat, creazione di socket, cancellazione di file e uso di ABI a 32 bit

Progetti Correlati

Questo set di regole è inteso rimanere agnostico rispetto alla logica di rilevamento a valle. Si concentra sulla raccolta di telemetria di audit ampiamente utile che può poi essere analizzata in modi diversi, ad esempio con strumenti basati su Sigma o query SIEM.

Un progetto open source che può fare uso di questi dati di audit è Aurora Linux, un agente leggero e personalizzabile basato su Sigma per Linux che combina telemetria basata su eBPF con arricchimento nello spazio utente e corrispondenza di regole Sigma.

Validazione

Questo set di regole include intenzionalmente -i in modo che i percorsi opzionali specifici della distribuzione non interrompano il caricamento su sistemi in cui alcuni binari o directory sono assenti. Questo mantiene semplice la distribuzione predefinita, ma significa anche che gli errori di caricamento delle regole vengono ignorati.

Se desideri una validazione rigorosa pre-distribuzione, testa una copia temporanea con la riga -i rimossa, ad esempio:

root@kitploit:~
grep -v '^-i$' audit.rules > /tmp/audit.rules.strict
auditctl -R /tmp/audit.rules.strict

Il repository include anche controlli GitHub Actions che analizzano le regole e verificano che una copia CI portatile e una copia rigorosa possano essere caricate su Ubuntu.

UID_MIN

Diverse regole in audit.rules usano auid>=1000 -F auid!=unset per concentrarsi sull'attività degli utenti interattivi ed escludere sessioni di login non impostate.

1000 è il comune UID_MIN su molte distribuzioni Linux, ma non è universale. Se il tuo host usa un UID_MIN diverso, controlla /etc/login.defs e sostituisci 1000 in audit.rules prima della distribuzione:

root@kitploit:~
awk '$1=="UID_MIN" { print $2 }' /etc/login.defs

AF_ALG / Telemetria Copy Fail

Il 29 aprile 2026, Xint ha pubblicato Copy Fail (CVE-2026-31431), una tecnica di escalation dei privilegi locale che abusa dell'interfaccia kernel crypto nello spazio utente (AF_ALG) insieme a splice() per corrompere file supportati da page cache in memoria.

Questo set di regole include un piccolo blocco af_alg per raccogliere le parti stabili e a basso rumore di quella configurazione da sessioni utente attribuibili:

  • socket(AF_ALG, ...)
  • bind() usando il comune struct sockaddr_alg a dimensione fissa
  • setsockopt(..., SOL_ALG, ...)

Questo è intenzionalmente più generico di una firma usa-e-getta per authencesn(hmac(sha256),cbc(aes)) perché i filtri delle syscall di audit non possono corrispondere a argomenti stringa. In pratica, il nome dell'algoritmo si trova nel record SOCKADDR emesso da bind(), quindi il rilevamento a valle consigliato è:

  • filtra su key=af_alg
  • ispeziona SOCKADDR.saddr / SADDR={ saddr_fam=alg ... }
  • segnala salg_type=aead con salg_name contenente authencesn(
  • alza la severità quando lo stesso pid, exe o auid emette molti di questi bind in una breve finestra temporale

Il proof-of-concept descritto da Xint si basa anche su operazioni ripetute di splice(). Quelle syscall sono troppo rumorose per il set di regole predefinito su molti sistemi, quindi il repository fornisce solo un overlay splice_user commentato in audit.rules. Abilitalo solo se splice / vmsplice sono poco comuni nel tuo ambiente e correlalo con attività af_alg recenti dallo stesso processo o sessione utente.

Fonti

La configurazione si basa sulle seguenti fonti e anni di miglioramenti integrati nel set di regole predefinito:

Regole auditd Gov.uk https://github.com/gds-operations/puppet-auditd/pull/1

Hardening CentOS 7 https://highon.coffee/blog/security-harden-centos-7/#auditd---audit-daemon

Repo audit Linux https://github.com/linux-audit/audit-userspace/tree/master/rules

Auditing Linux ad alte prestazioni con Auditd https://linux-audit.com/tuning-auditd-high-performance-linux-auditing/

Copy Fail: 732 Byte per diventare root su ogni principale distribuzione Linux. https://xint.io/blog/copy-fail-linux-distributions

Interfaccia kernel Linux crypto nello spazio utente (AF_ALG) https://docs.kernel.org/crypto/userspace-if.html

Ulteriori regole

Non tutte queste regole sono state incluse.

Per la conformità PCI DSS vedere: https://github.com/linux-audit/audit-userspace/blob/master/rules/30-pci-dss-v31.rules

Per la conformità NISPOM vedere: https://github.com/linux-audit/audit-userspace/blob/master/rules/30-nispom.rules

Spiegazioni Video di IppSec

IppSec ha registrato un video che spiega come rilevare lo sfruttamento della vulnerabilità OMIGOD usando auditd. I concetti fondamentali di auditd in quel video sono ancora utili, ma il set di regole in questo repository è stato da allora semplificato significativamente. Considera il video come background storico e un'introduzione alle idee di rilevamento basate su auditd, non come documentazione riga per riga dell'attuale audit.rules.

https://www.youtube.com/watch?v=lc1i9h1GyMA

Contributi

Si prega di contribuire con le proprie modifiche tramite pull request

Scarica lo strumento