🛡️ Øvelse 36b – Detekter forsøg på eksekvering af ondsindede kommandoer¶
🌟 Formål¶
Denne øvelse har væsentlig flere trin end de forrige øvelser. Derudover skal konfigurationen også laves på to forskellige hosts, hvilket kan øge sværhedsgraden. Bevæg jer langsomt frem, og brug evt. fejlsøgningsguiden i bunden af øvelsen.
Formålet med denne øvelse er at få indsigt i, hvordan man med egne regler kan detektere forsøg på at køre farlige eller mistænkelige kommandoer på en overvåget server. Øvelsen introducerer samtidig grundelementer i detection engineering, hvor man definerer egne sikkerhedskriterier.
🧠 Det vi her kalder "ondsindede kommandoer" er ikke nødvendigvis skadelige i sig selv – men det er værktøjer, som angribere typisk bruger til at udføre fx netværksscanning, dataexfiltration eller omgåelse af sikkerhedsforanstaltninger. De er derfor interessante at overvåge i sikkerhedskontekst.
🔄 Øvelsen bygger videre på den viden, du opnåede i Øvelse 36a, hvor du lærte at aktivere og analysere rå loghændelser i Wazuh Archives.
🔁 Overblik: Hvordan data bevæger sig¶
Inden du går i gang, er det vigtigt at forstå, hvad der egentlig sker i denne øvelse – og hvorfor vi vælger netop disse værktøjer.
-
🧪 Netcat er et netværksværktøj, der ofte bruges af angribere til fx at etablere forbindelser, overføre data eller lave scanninger. Det er i sig selv ikke ondsindet – men mistænkeligt i visse kontekster.
-
👁️ auditd er en del af Linux Audit Framework og bruges til at overvåge systemkald, fx når en bruger forsøger at starte et program.
👇 Flowet herunder viser, hvordan en hændelse bevæger sig gennem systemet – fra den sker på hosten, til den (forhåbentlig) udløser en alarm i Wazuh:
[Bruger kører Netcat]
↓
[auditd registrerer systemkald (execve)]
↓
[audit.log opdateres]
↓
[Wazuh-agent læser loggen og sender til manager]
↓
[Manager evaluerer regel og genererer evt. alarm]
🛠️ Trin 1: Forudsætninger¶
💡 Disse forudsætninger sikrer, at både overvågningsmotoren (auditd) og logtransporten (Wazuh-agenten) fungerer korrekt, før du går videre.
auditdskal være installeret og aktiv- Du skal kunne tilgå både Wazuh-agent og Wazuh-manager
- Reglerne skal opsættes som root-bruger
🔧 Trin 2: Konfiguration af auditd (på overvåget host)¶
💡 Her konfigurerer du auditd til at fange systemkald, når brugere forsøger at starte et program via execve. Vi fokuserer kun på brugere med UID ≥ 1000 (almindelige brugere).
-
Skift til root-bruger:
👉 Nødvendigt for at tilføje audit-regler. -
Redigér audit-regelfilen:
-
Tilføj følgende to regler (64-bit og 32-bit):
🧠 Reglerne fanger alle programkørsler fra normale brugere og tagger dem med nøgleordet-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k suspicious-nc -a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k suspicious-ncsuspicious-nc. -
Indlæs reglerne:
-
Bekræft at reglerne er aktive:
✅ Du bør kunne se begge regler listet her. -
Forlad root-bruger:
⚙️ Trin 3: Konfiguration af Wazuh-agent (på overvåget host)¶
💡 Wazuh-agenten skal vide, at den skal overvåge audit.log, hvor auditd skriver sine hændelser.
-
Åbn agentens konfigurationsfil:
-
Tilføj følgende sektion under
<ossec_config>: -
Genstart agenten:
🧾 Trin 4: Konfiguration af Wazuh-manager (på manageren)¶
💡 Her definerer du hvilke kommandoer, der skal udløse en alarm – og hvordan Wazuh skal matche dem.
- Opret en CDB-liste
👉 En CDB-liste i Wazuh er en simpel nøgle-værdi-liste (key:value), der bruges til at matche bestemte tekstfelter i logs – f.eks. programnavne. Man kan bruge listerne til at definere kategorier af farlige kommandoer og reagere forskelligt afhængigt af typen.
🧠 I denne øvelse bruger vi en CDB-liste til at kategorisere forskellige netværksværktøjer. Listen bliver senere brugt i vores regel til at afgøre, hvilke kommandoer der skal udløse en alarm.
Opret filen med:
Indsæt følgende indhold:
📌 Formatet er kommando:klassifikation. I vores regel fokuserer vi kun på de kommandoer, der er markeret med red, men du kan senere bruge listen til mere granulære reaktioner.
-
Tilføj listen til
Findossec.conf:<ruleset>-blokken og tilføj: -
Tilføj en regel i
Indsæt nederst i filen:local_rules.xml:
<group name="audit">
<!-- Regel ID: 100210 - Detekterer eksekvering af kommandoer kategoriseret som 'red' i CDB-listen -->
<rule id="100210" level="12">
<!-- Matcher kun hændelser, der i forvejen er blevet dekodet af auditd-parseren (regel 80700) -->
<if_sid>80700</if_sid>
<!-- Sammenligner audit.command-feltet med CDB-listen 'suspicious-programs' -->
<!-- Den bruger key:value-par, og vi filtrerer kun efter entries med value 'red' (fx 'nc:red') -->
<list field="audit.command" lookup="match_key_value" check_value="red">etc/lists/suspicious-programs</list>
<!-- Alarmens tekst: $(audit.exe) erstattes med den konkrete kommando, fx 'nc' -->
<description>Audit: Highly Suspicious Command executed: $(audit.exe)</description>
<!-- Tilføjer reglen til en brugerdefineret gruppe – kan bruges til dashboards og filtrering -->
<group>audit_command</group>
</rule>
</group>
- Genstart manageren:
🧪 Trin 5: Test detektering¶
💡 Her tester du, om det hele virker, ved at køre en af de kommandoer, du netop har markeret som farlige.
-
Installer og kør Netcat:
-
Gå til Wazuh Dashboard → Discover og søg:
✅ Hvis alt virker, får du en alert med teksten “Highly Suspicious Command executed”.
🤔 Refleksionsspørgsmål¶
- Hvorfor er det vigtigt at inkludere både 32 og 64-bit regler?
- Hvilke programmer kunne være relevante at tilføje til CDB-listen?
- Hvorfor er det vigtigt at kende sin distro og programplacering?
- Hvad kunne en angriber gøre for at undgå denne form for detektion?
- Hvad kan du bruge Wazuh Archives til, hvis du fejler i at udløse en alert?
🔗 Relateret til CIS Controls¶
- Control 08 – Audit Log Management
- Control 13 – Network Monitoring and Defense
- Control 17 – Incident Response Management