Detectie – zien en aantonen dat we nog steeds zien¶

Machinevertaling van het Franse origineel.

De preventie beantwoordt de vraag: "Kunnen we hier binnen?" De detectie beantwoordt de volgende vraag, die belangrijk is wanneer de eerste poging mislukt: "Is er iemand binnen, en wat doet hij?"

Deze pagina beschrijft de detectiemethoden van het park, de vraag waarop elke methode antwoordt, en vooral hoe we ervoor zorgen dat ze nog steeds werken – omdat een een defecte detector geeft geen foutmelding: het geeft geen geluid, en het stilte lijkt precies op "geen melding".

De technische termen verwijzen naar glossarium.

Een vraag, één motor¶

Een valkuil van een set veiligheidsinstrumenten is om ze te zien als een oplossing. Tien instrumenten die dezelfde vraag beantwoorden, laten de andere negen vragen onbeantwoord. Het systeem begint dus met vragen en wijst er één toe aan elk instrument – één en slechts één.

De vraag	Het hulpmiddel	Buiten de vraag
Bevat deze afbeelding een bekende CVE?	Trivy	Wat het container doet nadat het is gestart
Heeft deze code een fout, een kwetsbare afhankelijkheid, een geheim?	Semgrep, Trivy (afhankelijkheden), trufflehog	Het gedrag van het programma tijdens de uitvoering
Is dit systeem beveiligd, geïntegreerd en up-to-date?	Wazuh — SCA, FIM, rootcheck, kwetsbaarheden	Een abnormaal gedrag, in real-time
Wat start automatisch op deze machine?	osquery (in Wazuh), KnockKnock op macOS	—
Heeft dit proces iets abnormaals?	Falco (eBPF)	Het netwerkverkeer
Wat gaat er over het netwerk?	Suricata (IDS)	De inhoud van een end-to-end versleutelde stroom
Is dit bestand malware?	ClamAV	Nieuwe malware
Wat zit er in dit bestand, op alle niveaus?	Strelka + YARA	Wat het bestand zou doen als het wordt uitgevoerd
Wie valt het systeem aan?	CrowdSec + community-blokkering	Dingen die geen HTTP zijn
Wat is er gebeurd op deze machine?	Velociraptor — zie Antwoord	—

De rechter kolom is geen bekentenis: het definieert wat elk hulpmiddel doet. Het geeft aan waar de antwoorden van elk hulpmiddel eindigen, dus waar de antwoorden van een ander beginnen.

De autoriteit

Trivy heeft autoriteit over wat is gebouwd en versieert. Wazuh heeft autoriteit over de status van een levend systeem. Falco, Suricata en Velociraptor hebben autoriteit over het gedrag en de stromen. Geen van hen herhaalt het werk van een ander; wanneer twee motoren dezelfde observatie melden, wordt deze gefilterd door een regel-ID, zonder een van beide uit te schakelen.

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

De gestippelde pijlen zijn geen detail, maar duiden op motoren die eerst verzamelen voordat ze een melding sturen. De reden hiervoor ligt verder, in de principes.

Wazuh (SIEM)¶

Een SIEM verzamelt de logs van het hele netwerk, correlateert deze en stuurt meldingen. Hier is Wazuh: een manager en een agent op elke machine – hypervisor, container hosts, GPU host, NAS, externe server en werkstation. Een host buiten het LAN communiceert met de manager via een privénetwerk, nooit via een lokale adres dat niet bestaat voor hem.

Wat de agents bieden:

Integriteit van bestanden op gevoelige locaties;
Configuratiebeoordeling tegen CIS benchmarks;
Zoeken naar rootkits en verborgen bestanden of poorten;
Kwetsbaarheden door correlatie tussen geïnstalleerde pakketten en CVE-databases;
Inventaris van hardware, pakketten en processen.

osquery, in het SIEM en niet los¶

osquery onderzoekt de status van een machine met behulp van SQL: services, geplande taken, SSH-sleutels, alles wat als persistentie dient. Het is verbonden als een module van Wazuh, niet als een apart service: twee inventaren van hetzelfde netwerk verschillen uiteindelijk altijd, en op het moment dat ze verschillen, weet niemand meer welke te vertrouwen. De resultaten komen in dezelfde index als de rest, en een controleert of ze daadwerkelijk aankomen – een geactiveerde module die niets stuurt, lijkt op een geactiveerde module.

Threat intelligence, geconsumeerd¶

Drie lijsten van IOC – adressen, domeinen, bestandspaden – worden afgelezen uit openbare bronnen en worden periodiek bijgewerkt. Wazuh raadpleegt deze lijsten wanneer een gebeurtenis plaatsvindt (CDB-lijsten). De lijst met bestandspaden wordt ook bijgevuld met wat de bestandsscan-engines in het netwerk hebben gevonden: een bestand dat één keer is gedetecteerd, wordt daarna overal herkend.

Een platform voor het delen van informatie (zoals MISP) is niet geschikt: het is nuttig wanneer er informatie wordt gegenereerd, maar niet wanneer er drie lijsten worden gebruikt. Een monitor houdt de actualiteit van de lijsten in de gaten: een IOC-lijst die niet meer wordt bijgewerkt, genereert geen fouten, maar alleen gemiste detecties.

Twee niveaus van waarschuwing¶

Regels op naam, één per detectie die we willen ontvangen (bijvoorbeeld malware, een "canari" die niet meer reageert, een container die is gestopt vanwege een geheugenprobleem), elk gekoppeld aan zijn unieke identificatie.
Een algemeen drempelwaarde, voor alles wat de regels op naam niet dekken. Deze wordt alleen geactiveerd na een periode van meting van het aantal waarschuwingen dat deze zou genereren in een gezond netwerk.

Uitvoering – Falco¶

Het SIEM bekijkt de status van een host; het ziet niet wat een programma op dat moment doet. Zonder telemetrie van systeemoproepen, kan een aanvaller die al aanwezig is in een container, alleen worden gedetecteerd door wat hij beschadigt.

Falco vult deze lacune in op hosts die containers draaien. De keuzes voor implementatie, elk met zijn eigen reden:

Keuze	Waarom
Moderne eBPF sonde, geen kernelmodule	Geen code dat gecompileerd moet worden, geen problemen bij de volgende kernel-update
Systeempakket, gestart voor de container engine	De eerste container is al in gebruik
Automatische updates van regels vanaf het internet uitgeschakeld	Regels worden gewijzigd via een repository, en worden gelezen, nooit heimelijk
Limiet voor processor en geheugen	Een beveiligingstool mag de host die het beschermt niet compromitteren
Buffer met een capaciteit voor nul verlies tijdens piekbelasting	Een verloren gebeurtenis tijdens een piek is precies de gebeurtenis die we zoeken

Naast de stabiele regels van het project, zijn er ook regels die zelf zijn gemaakt, geschreven voor de acties van een aanvaller op dit netwerk: het schrijven naar een geplande taak of in SSH-sleutels, het opzetten van een container die de socket van de container engine gebruikt, zonder op de lijst van toegestane gebruikers te staan, het verhogen van de rechten binnen een container.

De vals-positieven – de gezondheidscontroles van de databases, die al honderdduizenden gebeurtenissen per dag registreren – worden verwerkt met specifieke uitzonderingen, één per geval, nooit door een regel uit te schakelen.

Een regel kan zonder fout worden geladen en nooit meer overeenkomen

Een update kan de betekenis van een veld veranderen dat een regel gebruikt. De regel wordt geladen, er ontstaan geen fouten tijdens het opstarten, en deze zal nooit meer worden geactiveerd. Het opnieuw lezen van de configuratie ziet niets: deze is correct, voor de vorige versie.

Daarom is er een "bewijs": een scanner lanceert een eenmalig gebruiksvoorwerp, opent er een interactieve shell en leest een gevoelige bestanden, en controleert vervolgens of beide acties zijn uitgevoerd, op elk systeem. Zijn omgekeerde controle bestond uit het uitschakelen van een regel en het zien van de scanner rood oplichten.

Het netwerk — Suricata¶

Suricata past bekende signalen van aanvallen toe op het verkeer dat er langs loopt. Zijn uitvoer, in JSON, gaat naar de logboekzoekmachine.

Een IDS ziet alleen wat er langs loopt: zijn locatie is dus de echte beslissing. Een lokaal meshnetwerk biedt geen spiegelpoort om op te luisteren; het punt van aandacht is waar het verkeer convergeert — een virtueel netwerkbrug kan tegelijkertijd de uitwisseling tussen machines en hun uitgangen naar het internet zien, zonder extra apparatuur.

Net als Falco verzamelt hij voordat hij een melding maakt, en zijn bewijs is een testsignaal dat handmatig vanaf een machine wordt geactiveerd, en vervolgens wordt gevonden in de meldingen.

De bestanden — twee motoren, twee vragen¶

De architectuur van het antivirus-systeem — een centraal motor, een signaalspiegel, en de client die logboek bijhoudt — wordt beschreven in de architectuurnotitie. Hier gaat de vraag over bewijzen.

ClamAV antwoordt op "Is dit een bekend malware?": de bestandsshare-dienst weigert het opslaan van een gedetecteerd bestand.
Strelka antwoordt op "Wat zit er hierin, op alle niveaus?": het ontvouwt recursief archieven, documenten en ingebouwde objecten, en voert duizenden YARA-regels uit op elk stuk, plus talloze openbare scanners. Elke nacht analyseert hij een selectie van paden.

De slechtste storing in het park — en waarom een teller dat niet oppikt

YARA compile zijn set regels in één enkele blok. Één ongeldig bestand kan het hele systeem laten crashen: de container blijft in goede staat, de analyses blijven doorlopen, en er wordt niets meer gedetecteerd.

Een teller die het aantal geladen regels aangeeft, lijkt voldoende. Dat is echter niet het geval: het geeft aan hoeveel regels in het geheugen staan, maar niet of ze nog iets herkennen. Een voorbeeld van zo'n "canaris" is een eigen regel, die in dezelfde set staat, en die telkens opnieuw wordt ingeladen. Er is ook een bestand dat deze regel activeert. Een sonde stuurt dit bestand en vraagt om detectie. Als het systeem niet meer compileert, valt de canaris mee — precies wat we willen.

Omgekeerde verificatie: een bestand met ongeldige regels veroorzaakt een kritische waarschuwing, waarna het systeem weer normaal werkt.

Voor ClamAV is de canaris het bestand EICAR, dat dagelijks wordt aangeleverd.

Een omgekeerde verificatie moet het testen wat het beweert te testen

Om de EICAR-canaris te testen, is de eerste aanpak om de testsignatuur te negeren. Dit werkt echter niet: de motor herkent het bestand onder een andere signatuur, die de controle overneemt, en de canaris blijft groen. Een omgekeerde verificatie die de canaris niet laat falen, bewijst niet dat de canaris werkt — het bewijst alleen dat we hem niet hebben kunnen laten falen.

Wat is afgewezen, en waarom.

Een dynamische sandbox: De hoeveelheid bestanden rechtvaardigt het niet, en het zou een zware machine introduceren, die kwetsbaar zou zijn voor kwaadaardige code. Dit punt zal opnieuw ter sprake komen wanneer een echt voorbeeld beide motoren doorstaat.
Een derde YARA-regelmotor: Deze zou dezelfde set publieke regels lezen. Een tweede hulpmiddel dat dezelfde regels leest, is geen tweede mening.

De perimeter — CrowdSec¶

CrowdSec leest de logs van de interne proxy, herkent vijandig gedrag (scan, brute-force, bekende exploits) en voert zijn beslissing uit via een module die is geïntegreerd in de proxy, die een 403-antwoord geeft. Het maakt ook gebruik van een gemeenschappelijke bloklijst, die wordt gevoed door alle installaties die deze delen.

Waarom in de applicatielaag, en niet op de firewall: zie het architectuurrapport. Het systeem controleert of de module daadwerkelijk een beslissing uitvoert, en niet alleen of deze is geladen.

Kwetsbaarheden — de scanner en zijn assen¶

Een zelfgebouwd scanner voor kwetsbaarheden aggregeert verschillende tools en, vooral, sorteert:

Aspek	Gereedschap	Wat het biedt
Beelden en services, op elke container-host	Trivy	Bekende CVE's, dagelijks
Code repositories	Trivy (afhankelijkheden, IaC) + Semgrep (SAST)	Kwetsbaarheden en afhankelijkheden vóór de implementatie
Geheimen op de hosts	trufflehog	Ernst van het bestand wordt bepaald door de rechten: een geheim dat door iedereen leesbaar is, is ernstiger dan hetzelfde geheim dat alleen voor een bepaalde service is toegestaan
Actiebaarheid	Vergelijking met de basisimage	Is er al een oplossing?
Expositie	Configuratie van de proxy	Openbaar, via de identiteitsleverancier, of intern
Exploitatie	EPSS + KEV	Waarschijnlijk, of reeds geconstateerd elders

De score combineert ernst, exploitatie en expositie: een kritische CVE op een intern service, volgt een gemiddelde CVE, die al is geëxploiteerd, op een openbaar service. Elke beslissing van prioritering wordt vastgelegd met de auteur.

OpenCVE vult het overzicht aan voor wat geen container-image is: het systeem van de hypervisor, dat van het NAS: het combineert de gepubliceerde CVE's met het versiebeheer van de componenten in het systeem.

Twee aanvullingen:

Een SBOM per service-image, die wekelijks wordt herzien. Wanneer een nieuwe kwetsbaarheid wordt gepubliceerd, kan de vraag "zijn we er mee in aanraking gekomen?" worden beantwoord door het inventaris, zonder opnieuw een scan uit te voeren.
De tijd die nodig is om een correctie uit te voeren, is zelf ook een controle. Het scannen zonder de tijd die nodig is om een correctie uit te voeren te meten, leidt tot een lijst die steeds groter wordt. Zie Conformiteit.

Hardening, en een tweede mening¶

De configuratie-evaluatie van het SIEM draait continu. Een tweede tool (Lynis) is incidenteel gebruikt, om te vergelijken. Waar de twee elkaar tegenstonden – een module die door de ene als inactief werd aangegeven, maar door de andere als actief – werd het probleem opgelost door een functionele test: de actie die de module moet voorkomen, proberen uit te voeren, en constater dat dit geweigerd wordt. De automatische controle was foutief.

Specifieke rootkit-detectoren zijn niet toegevoegd: ze doen hetzelfde als de module van het SIEM, en op containersystemen produceren ze ruis die de rest van het systeem overbelast.

Wat deze keuzes gemeenschappelijk hebben¶

1. Functionele tests, niet alleen tellers. "De service is actief", "5.000 regels zijn geladen", "de agent is verbonden": dit zijn tellers, en een detector kan ze allemaal bevredigen zonder iets te detecteren. Een test injecteert een bekende situatie en eist dat deze wordt gezien. Elke motor op deze pagina heeft er een.

2. Het meten van de ruis voordat een alarm wordt geactiveerd. Een nieuwe detector draait eerst alleen in verzamelmodus, met een vooraf bepaalde datum voor het activeren van het alarm. Een alarm dat wordt geactiveerd zonder voorafgaande meting, meet de snelheid van het instrument, niet de staat van het systeem – en een alarm dat elke uur vanaf de eerste dag wordt afgegeven, wordt gesorteerd voordat het einde van de week.

3. Filteren op regel-ID, nooit op groep. Een groep bevat regels die dicht bij elkaar staan, die niet zijn gelezen. Een filter op groep plaatst dubbele regels; een automatische reactie op groep zou werken op detecties die nooit zijn gekozen.

4. Een uitzondering heeft een naam. Een vals positief wordt behandeld door een specifieke uitzondering, gekoppeld aan het geval. Het uitschakelen van een regel in één keer, verwijdert ook alle correcte detecties die deze zou hebben gemaakt.

5. Eén motor per vraag. Het toevoegen van een tool is gerechtvaardigd door een vraag zonder antwoord, niet door de reputatie van het tool.

Lees verder¶

Antwoord — wat er gebeurt nadat de detectie is uitgevoerd.
Conformiteit en bewijzen — hoe getuigen bewijs worden.
Woordenlijst.

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