Vai al contenuto

Détection — voir, et prouver qu'on voit encore

Traduzione automatica dell'originale francese.

La prévention répond à « peut-on entrer ? ». La détection répond à la question Successivamente, si tratta del giorno in cui il primo tentativo è fallito: qualcuno è entrato e cosa ha fatto?

Questa pagina descrive i sistemi di rilevamento del parco, la domanda a cui tutti rispondono, e soprattutto come ci si assicura che continuino a funzionare — perché un Il dispositivo difettoso non produce errori: produce silenzio, e il silenzio è esattamente equivalente a "nessun problema rilevato".

I termini tecnici si riferiscono al glossario.

Una domanda, un motore

Un pericolo delle molteplici soluzioni di sicurezza è quello di considerarle come una copertura. Dieci strumenti che rispondono alla stessa domanda lasciano inespresse le altre nove. Pertanto, il sistema parte dalle domande e assegna a ciascuna un motore – uno solo.

La domanda Il motore Oltre alla domanda
Questa immagine contiene un CVE noto? Trivy Cosa fa il container una volta avviato
Questo codice presenta un errore, una dipendenza vulnerabile o un segreto? Semgrep, Trivy (dipendenze), trufflehog Il comportamento del programma durante l'esecuzione
Questo host è sicuro, affidabile e aggiornato? Wazuh — SCA, FIM, rootcheck, vulnerabilità Un comportamento anomalo, in tempo reale
Cosa si avvia autonomamente su questa macchina? osquery (in Wazuh), KnockKnock su macOS —
Questo processo fa qualcosa di anomalo? Falco (eBPF) Il traffico di rete
Cosa transita sulla rete? Suricata (IDS) Il contenuto di un flusso crittografato end-to-end
Questo file è un malware noto? ClamAV Un malware sconosciuto
Cosa contiene questo file, a tutti i livelli? Strelka + YARA Cosa farebbe il file se lo eseguissimo
Chi attacca la rete? CrowdSec + blocco della comunità Cosa non è HTTP
Cosa è successo su questa macchina? Velociraptor — vedere Risposta —

La colonna a destra non è una confessione: definisce ogni strumento. Indica dove termina la sua analisi, quindi dove inizia quella di un altro.

La regola di autorità

Trivy stabilisce le regole per ciò che viene costruito e versionato. Wazuh stabilisce le regole per lo stato di un host in esecuzione. Falco, Suricata e Velociraptor stabiliscono le regole per il comportamento e il traffico. Nessuno ripete il lavoro di un altro; quando due motori rilevano la stessa cosa, la filtrano tramite l'identificatore della regola, senza però disattivare nessuno dei due.

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef det fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef hub fill:#0f766e,stroke:#0f766e,color:#fff

    subgraph sources["Ce qu'on observe"]
        img["Images et dépôts"]:::src
        host["Hôtes<br/>fichiers · configuration · paquets"]:::src
        proc["Processus et conteneurs"]:::src
        net["Trafic réseau"]:::src
        file["Fichiers déposés"]:::src
        logs["Journaux du proxy"]:::src
    end

    subgraph moteurs["Les moteurs"]
        trivy["Trivy · Semgrep · trufflehog<br/>scanner de vulnérabilités"]:::det
        wazuh["Wazuh<br/>SIEM · osquery · listes d'IOC"]:::det
        falco["Falco<br/>appels système"]:::det
        suri["Suricata<br/>signatures réseau"]:::det
        av["ClamAV + Strelka<br/>verdict · analyse profonde"]:::det
        cs["CrowdSec<br/>comportement HTTP"]:::det
    end

    tri["Tableau de triage<br/>score · exposition · journal"]:::hub
    hub["Répartiteur d'alertes"]:::hub

    img --> trivy --> tri
    host --> wazuh
    proc --> falco
    net --> suri
    file --> av --> wazuh
    logs --> cs
    wazuh -->|"identifiant de règle"| hub
    falco -.->|"après mesure du bruit"| hub
    suri -.->|"après mesure du bruit"| hub
    cs -->|"403"| logs

Le puntellino non è un semplice dettaglio di disegno: indica motori che raccolgono informazioni prima di inviarle. La ragione è più profonda, e si trova nei principi.

Wazuh (SIEM)

Un SIEM raccoglie i log di tutta la rete, li correla e invia avvisi. In questo caso, si tratta di Wazuh: un gestore e un agente su ogni macchina – hypervisor, macchine virtuali, server GPU, NAS, server remoti e postazioni di lavoro. Un server al di fuori della rete locale comunica con il gestore tramite una rete privata, mai tramite un indirizzo locale che non esiste per lui.

Cosa offrono gli agenti:

  • integrità dei file su percorsi sensibili;
  • valutazione della configurazione rispetto agli standard CIS [glossaire.md#cis];
  • ricerca di rootkit e file o porte nascoste;
  • vulnerabilità attraverso la correlazione tra pacchetti installati e database CVE;
  • inventario di hardware, pacchetti e processi.

Osquery, nel SIEM e non a parte

Osquery interroga lo stato di una macchina tramite SQL: servizi, attività pianificate, chiavi SSH autorizzate, tutto ciò che serve per persistenza. È integrato come modulo di Wazuh, non come un servizio separato: due inventari dello stesso parco finiscono sempre per divergere, e nel momento in cui divergono, nessuno sa quale credere. I risultati arrivano nello stesso indice del resto, e un controllo verifica che arrivino effettivamente — un modulo attivo che non invia nulla assomiglia a un modulo attivo.

Il rilevamento delle minacce, consumato

Tre liste di IOC – indirizzi, domini, impronte dei file – sono estratte da fonti pubbliche e aggiornate da un task pianificato. Wazuh le consulta nel momento in cui si verifica l'evento (liste CDB). La lista delle impronte si nutre anche di ciò che i motori di file del parco hanno rilevato: un file rilevato una volta viene riconosciuto ovunque.

È stata esclusa una piattaforma di condivisione di informazioni (del tipo MISP): questa è utile quando si produce informazioni, non quando si consumano tre liste. Un agente monitora la freschezza delle liste: una lista di IOC che ha smesso di aggiornarsi non produce errori, ma solo rilevamenti mancati.

Due livelli di allarme

  • Regole specifiche, una per ogni rilevamento che si desidera ricevere (un malware trovato, un canarino che non risponde più, un container terminato per mancanza di memoria), ognuna collegata al proprio identificativo.
  • Un limite generale, per tutto ciò che le regole specifiche non prevedono. Questo limite viene attivato solo dopo un periodo di misurazione del volume che produrrebbe su un parco sano.

L'esecuzione – Falco

Il SIEM visualizza lo stato di un host; non visualizza ciò che un programma sta facendo. Senza telemetria delle chiamate di sistema, un attaccante già presente in un container è visibile solo per ciò che distrugge.

Falco colma questa lacuna sugli host che eseguono container. Le scelte di deployment, ognuna con la propria ragione:

Scelta Motivo
Utilizzo di una moderna tecnologia eBPF, senza moduli del kernel Nessuna compilazione necessaria, nessun rischio di incompatibilità con gli aggiornamenti del kernel
Pacchetto di sistema, avviato prima del motore di container Il primo container avviato è già monitorato
Disabilitata l'aggiornamento automatico delle regole da Internet Le regole vengono modificate tramite repository, e vengono lette e aggiornate, mai in modo nascosto
Limiti per l'utilizzo della CPU e della memoria Uno strumento di sicurezza non dovrebbe essere in grado di compromettere il sistema che protegge
Buffer dimensionato per evitare perdite durante i picchi Un evento perso durante un picco è proprio quello che si cerca di evitare

Oltre alle regole standard del progetto, sono state definite anche regole interne, scritte per gestire specifici scenari. di un attaccante su questo parco: una scrittura in un task pianificato o nelle chiavi SSH autorizzate, un contenitore che monta il socket del motore di contenitori senza comparire nella lista nominata di coloro che ne hanno il diritto, un aumento dei privilegi all'interno di un contenitore.

I falsi positivi — le sonde di controllo dei database, che generano decine di migliaia di eventi al giorno — sono gestiti tramite eccezioni specifiche, una per caso, mai disabilitando una regola.

Una regola può caricarsi senza errori e non corrispondere più

Un aggiornamento può modificare il significato di un campo che una regola utilizza. La regola si carica, non compaiono errori all'avvio, e non si attiverà più. Rileggere la configurazione non rileva nulla: è corretta, per la versione precedente.

Da cui l'indicatore: un sensore lancia un contenitore usa e getta, apre un'interfaccia interattiva e legge un file sensibile, quindi verifica che entrambe le azioni siano state osservate, su ogni host. La sua verifica inversa ha consistito nel disattivare una regola e nel vedere il sensore cambiare colore.

La rete — Suricata

Suricata applica firme di attacchi noti al traffico che passa davanti a esso. La sua uscita, in formato JSON, viene inviata al motore di ricerca dei log.

Un IDS vede solo ciò che passa davanti a esso: quindi la sua posizione è la decisione più importante. Una rete mesh domestica non offre un port mirroring su cui ascoltare; il punto cruciale è quello in cui il traffico converge — un ponte di rete virtuale può vedere sia gli scambi tra macchine che le loro uscite verso Internet, senza bisogno di ulteriore hardware.

Come Falco, raccoglie prima di notificare, e il suo indicatore è una firma di test attivata intenzionalmente da una macchina, che poi viene trovata nelle allerte.

I file — due motori, due domande

L'architettura della catena antivirus — un motore centrale, un mirror di firme, il client che registra — è descritta nella nota di architettura. Qui, la domanda riguarda gli indicatori.

  • ClamAV risponde a "è un malware conosciuto?". Il servizio di condivisione di file rifiuta l'upload di un file rilevato.
  • Strelka risponde a "cosa c'è dentro, a tutti i livelli?": espande ricorsivamente archivi, documenti e oggetti incorporati, e applica decine di scanner a ogni elemento, tra cui migliaia di regole YARA pubbliche. Analizza ogni notte una selezione di percorsi scelti.

Il peggior guasto del parco — e perché un contatore non lo rileva

YARA compila il suo repertorio di regole in un unico blocco. Un singolo file di regole non valido fa fallire tutto il sistema: il contenitore rimane in buono stato, le analisi continuano, e non viene rilevato nulla.

Un contatore di regole caricate sembra sufficiente. Ma non lo è: indica quante regole sono in memoria, ma non se stanno ancora riconoscendo qualcosa. Il test utilizzato è una "regola canaria": una regola personalizzata, inserita nello stesso repertorio delle altre, riprodotta ad ogni aggiornamento, e un file progettato per attivarla. Un sensore invia questo file e richiede una rilevazione. Se il sistema ne compile plus, le canari tombe avec lui — c'est exactement ce qu'on veut.

Vérification inverse : un fichier de règles volontairement cassé a fait partir une alerte critique, puis le retour à la normale.

Pour ClamAV, le témoin est le fichier EICAR, soumis chaque jour.

Une vérification inverse doit casser ce qu'elle prétend tester

Per testare il meccanismo EICAR, l'idea iniziale è quella di ignorare la firma. Questo non causa alcun problema: il motore riconosce lo stesso file con un altro nome di firma, che prende il posto, e l'indicatore rimane verde. Un controllo inverso che non fa fallire l'indicatore non dimostra che l'indicatore funziona, ma dimostra semplicemente che non è stato possibile farlo fallire.

Ciò che è stato escluso, e perché.

  • Un sistema dinamico: il volume dei file non lo giustifica, e aggiungerebbe una macchina pesante, esposta a potenziali attacchi. La questione si riaprirà quando un campione reale supererà entrambi i motori.
  • Un terzo motore basato su regole YARA: leggerebbe lo stesso insieme di regole pubbliche. Un secondo strumento che legge le stesse regole non rappresenta una seconda opinione.

Il perimetro — CrowdSec

CrowdSec legge i log del proxy interno, identifica comportamenti dannosi (scansione, attacchi di forza bruta, sfruttamento noto) e li applica tramite un modulo integrato nel proxy, che risponde con un codice 403. Utilizza anche una lista di blocco comunitaria, alimentata da tutte le installazioni che la utilizzano.

Perché in uno strato applicativo piuttosto che nel firewall: vedere la nota sull'architettura. Il suo meccanismo verifica che il modulo applichi effettivamente una decisione, e non solo che sia caricato.

Le vulnerabilità — lo scanner e i suoi assi

Uno scanner di vulnerabilità domestico aggrega diversi strumenti e, soprattutto, classifica:

Asse Strumento Cosa offre
Immagini in esecuzione, su ogni host di container Trivy CVE note, quotidianamente
Repository di codice Trivy (dipendenze, IaC) + Semgrep (SAST) Vulnerabilità e dipendenze problematiche prima del deployment
Segreti rimasti sugli host trufflehog Gravità determinata dalle autorizzazioni del file: un segreto accessibile a tutti è più grave dello stesso segreto riservato al suo servizio
Azionabilità Confronto con l'immagine di riferimento Esiste già una correzione?
Esposizione Configurazione del proxy Pubblica, dietro al provider di identità, o interna
Sfruttamento EPSS + KEV Probabile, o già riscontrato altrove

Il punteggio combina gravità, sfruttamento e esposizione: una CVE critica su un servizio interno segue una CVE di livello medio, già sfruttata, su un servizio pubblico. Ogni decisione di triaggio viene registrata con l'autore.

OpenCVE completa il quadro per ciò che non è un'immagine di container: il sistema dell'hypervisor, quello del NAS: confronta le CVE pubblicate con l'inventario versionato dei componenti del parco.

Due integrazioni:

  • Un SBOM per ogni immagine in esecuzione, aggiornato settimanalmente. Quando viene pubblicata una nuova vulnerabilità, la domanda "siamo interessati?" viene risolta consultando l'inventario, senza dover riavviare uno scan.
  • Anche il tempo di correzione è un controllo. Scansionare senza misurare il tempo di correzione, significa produrre una lista che cresce. Consultare Conformità.

Il rafforzamento, e il secondo parere

La valutazione della configurazione del SIEM viene eseguita continuamente. È stato utilizzato un secondo strumento (Lynis) per effettuare un confronto. Dove i due strumenti si contraddicevano – un modulo dichiarato inattivo da uno, attivo dall'altro – la questione è stata risolta da un test funzionale: tentare di eseguire l'azione che il modulo dovrebbe impedire, e constatare il rifiuto. Il controllo automatico si sbagliava.

Non sono stati aggiunti strumenti dedicati alla rilevazione di rootkit: essi ripetono ciò che fa già il modulo del SIEM, e su sistemi container producono un rumore che sovraccaricherebbe il resto.

Cosa hanno in comune queste scelte

1. Test funzionali, non semplici contatori. "Il servizio è attivo", "5.000 regole caricate", "l'agente è connesso": questi sono contatori, e un rilevatore può soddisfarli tutti senza rilevare nulla. Un test funzionale introduce un caso noto e richiede che venga rilevato. Ogni motore di questa pagina ne ha uno.

2. Misurare il rumore prima di attivare un allarme. Un nuovo rilevatore esegue inizialmente solo la raccolta dati, con una data di attivazione predefinita. Un allarme attivato senza una misurazione preventiva misura la frequenza dell'apparecchio, non lo stato del parco – e un allarme che si attiva ogni ora fin dal primo giorno viene filtrato dall'occhio prima della fine della settimana.

3. Filtrare per identificatore di regola, non per gruppo. Un gruppo include regole vicine che non sono state lette. Un filtro per gruppo produce duplicati; una risposta automatica per gruppo agirebbe su rilevamenti che non sono mai stati scelti.

4. Ogni eccezione ha un nome. Un falso positivo viene gestito tramite un'eccezione specifica, legata al caso. Disabilitare una regola in blocco elimina anche tutte le rilevazioni vere che avrebbe effettuato.

5. Un motore per ogni domanda. L'aggiunta di uno strumento è giustificata da una domanda senza risposta, non dalla reputazione dello strumento stesso.

Da leggere successivamente

Dernière vérification de cette page : 2026-09-11