Enterprise-Grade Webfilterung mit AdGuard Home und Wazuh SIEM aufbauen

Einleitung

In der heutigen Bedrohungslandschaft ist DNS sowohl eine kritische Infrastrukturkomponente als auch ein Hauptangriffsvektor. Malware nutzt DNS für Command-and-Control-(C2)-Kommunikation, Kryptominer verbinden sich über DNS mit Mining-Pools, und Phishing-Angriffe basieren auf Lookalike-Domains. Traditionelle Firewalls übersehen diese Bedrohungen oft, da sie auf Ebenen über DNS operieren.

Organisationen können eine umfassende Webfilterlösung bauen, indem sie AdGuard Home (eine DNS-basierte Werbeblocker- und Filterlösung) mit Wazuh (einer Open-Source-SIEM-Plattform) integrieren. Diese Kombination bietet:

• DNS-Sichtbarkeit über alle Endpunkte hinweg

• Echtzeit-Bedrohungserkennung für Kryptomining, Phishing und C2-Verkehr

• Zentralisierte Alarmierung mit automatisierter Einsatzreaktion

• Plattformübergreifende Abdeckung für Windows, Linux und macOS

Dieser Beitrag erklärt die Architektur, Implementierung und die Erkennungsregeln, die es funktionieren lassen.

Überblick über die Architektur

Die Endpunktschicht (Windows mit Sysmon, Linux mit systemd, macOS mit mDNSRespond, Container mit CoreDNS und IoT-Geräte) sendet DNS-Abfragen an AdGuard Home DNS, das DNS-Filterung, Abfrageprotokollierung, Blocklisten, DNS-over-HTTPS, Statistiken und benutzerdefinierte Regeln durchführt. JSON-Logs werden an den Wazuh Manager weitergeleitet, der einen JSON-Decoder, 110000+ Regeln und Bedrohungslisten verwendet, um Warnungen zu generieren. Diese Warnungen werden von OpenSearch Indexer Alerting Monitors verarbeitet (Cryptomining DNS alle 1 Minute, Phishing-Erkennung alle 5 Minuten, Anonymizer/Tor alle 5 Minuten, DNS-Exfiltration alle 1 Minute) und Benachrichtigungen werden über Slack, E-Mail oder GitHub Issues gesendet.

Warum AdGuard Home + Wazuh?

AdGuard Home bietet:

• Netzwerkweite DNS-Filterung ohne Client-Software

• JSON-formatierte Abfrageprotokolle sind perfekt für die SIEM-Aufnahme geeignet

• Blockierungsfunktionen zur Abwehr von Bedrohungen auf DNS-Ebene

• Verschlüsselter DNS (DoH/DoT) zur Verhinderung von DNS-Entführungen.

Wazuh bietet:

• Log-Parsing und Normalisierung über benutzerdefinierte Decoder

• Korrelationsregeln zur Erkennung von Mustern über mehrere Abfragen hinweg

• Echtzeit-Benachrichtigung mit mehreren Benachrichtigungskanälen

• MITRE ATT&CK-Kartierung zur Bedrohungsklassifizierung

• Integration mit bestehenden Sicherheitsworkflows.

Gemeinsam schaffen sie einen defensiven Ansatz, bei dem AdGuard bekannte Bedrohungen blockiert und Wazuh verdächtige Muster erkennt und warnt.

Implementierung im Detail

1. AdGuard-Log-Decoder

AdGuard Home gibt DNS-Abfrageprotokolle im JSON-Format aus. Ein benutzerdefinierter Wazuh-Decoder kann diese Protokolle wie folgt parsen:

<!-- AdGuard Home DNS Query Log Decoder -->
<decoder name="adguard">
  <prematch>^{"T":"</prematch>
</decoder>
<decoder name="adguard-fields">
  <parent>adguard</parent>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

Dieser Decoder extrahiert unter anderem folgende Felder:

• QH: Query Hostname (die angefragte Domain)

• QT: Query Type (A, AAAA, TXT, MX usw.)

• IP: IP-Adresse des Clients

• Result.IsFiltered: Gibt an, ob AdGuard die Abfrage blockiert hat

Schritte zum Erstellen benutzerdefinierter Decoder in Wazuh:

• Navigieren Sie im Wazuh-Dashboard zu Server Management → Decoders.

• Klicken Sie auf Add new decoders file, um Ihre Konfigurationsdatei hinzuzufügen.

• Fügen Sie den XML-Inhalt ein (z. B. 0004-custom-decoder.xml).

• Vergeben Sie einen Dateinamen und speichern Sie die Konfiguration.

• Alternativer Weg: Erstellen Sie direkt eine neue XML-Datei im Verzeichnis /var/ossec/etc/decoders/ auf dem Wazuh-Server.

Empfehlung: Definieren Sie den Basis-Decoder mit einem eindeutigen Namen und einem prematch-Muster, das die Protokollquelle verlässlich identifiziert (z. B. ^{"T":" für JSON-Logs von AdGuard). Erstellen Sie Child-Decoder mit dem Tag <parent>, um auf den Basis-Decoder zu verweisen, und verwenden Sie Plugins wie JSON_Decoder zur automatischen Extraktion strukturierter Felder. Starten Sie anschließend den Dienst neu (sudo systemctl restart wazuh-manager) und prüfen Sie die Funktionalität mit dem Dashboard-Tool Ruleset Test.

2. Erkennungsregeln (Detection Rules)

Die folgenden Regeln decken verschiedene Bedrohungskategorien ab. AdGuard-spezifische Regeln nutzen Rule-IDs im Bereich 110000, während endpoint-basierte DNS-Überwachungsregeln den Bereich 760000 verwenden.

Cryptomining-Erkennung (Regel 110021)

<rule id="110021" level="8">
  <if_sid>110001</if_sid>
  <field name="QH" type="pcre2">
    (coinhive|cryptoloot|coin-hive|minero|cryptonight|minergate)
  </field>
  <description>AdGuard: Cryptomining domain detected - $(QH)</description>
  <group>adguard_cryptominer,malware,</group>
</rule>

Phishing-Erkennung (Regel 110022)

<rule id="110022" level="10">
  <if_sid>110001</if_sid>
  <field name="QH" type="pcre2">
    (login|signin|account|secure|update|verify).*
    (paypal|apple|microsoft|google|amazon)
  </field>
  <description>AdGuard: Potential phishing domain - $(QH)</description>
  <group>adguard_phishing,threat_intel,</group>
</rule>

DNS-Tunneling-Erkennung (Regeln 110011–110012)

<!-- Single TXT query - informational -->
<rule id="110011" level="8">
  <if_sid>110000</if_sid>
  <field name="QT">TXT</field>
  <description>AdGuard: TXT record query - potential DNS tunneling</description>
  <group>adguard_tunnel_suspect,</group>
</rule>
<!-- High frequency TXT queries - DNS exfiltration -->
<rule id="110012" level="14" frequency="20" timeframe="60">
  <if_matched_sid>110011</if_matched_sid>
  <same_field>IP</same_field>
  <description>AdGuard: DNS exfiltration suspected from $(IP)</description>
  <group>adguard_exfiltration,data_exfiltration,</group>
</rule>

C2-Domain-Erkennung (Regel 110010)

<rule id="110010" level="12">
  <if_sid>110001</if_sid>
  <field name="QH" type="pcre2">^[a-z0-9]{20,}\.</field>
  <description>AdGuard: Suspicious long random domain - possible C2</description>
  <group>adguard_c2_suspect,threat_intel,</group>
</rule>

Diese Regel erfasst Algorithmen zur Domänengenerierung (DGAs), die Malware zur Erzeugung pseudozufälliger Domainnamen verwendet.

3. Plattformübergreifendes DNS-Monitoring

Neben AdGuard können DNS-Abfragen auch direkt auf den Endpunkten überwacht werden.

Windows (Sysmon Event ID 22)

<rule id="760010" level="14">
  <if_sid>760001</if_sid>
  <field name="win.eventdata.queryName" type="pcre2">
    (?i)minergate|xmrpool|supportxmr|moneropool|nicehash|ethermine
  </field>
  <description>CRITICAL: Cryptomining pool DNS query</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>cryptomining,dns_query,threat_detected,</group>
</rule>

Linux (systemd-resolved / dnsmasq)

<rule id="760032" level="14">
  <if_sid>760030,760031</if_sid>
  <match>minergate|xmrpool|nicehash|ethermine</match>
  <description>CRITICAL: Linux - Cryptomining pool DNS query</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>cryptomining,dns_query,threat_detected,</group>
</rule>

macOS (mDNSResponder)

<rule id="760042" level="14">
  <if_sid>760040</if_sid>
  <match>minergate|xmrpool|nicehash|ethermine</match>
  <description>CRITICAL: macOS - Cryptomining pool DNS query</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>cryptomining,dns_query,threat_detected,</group>
</rule>

4. Integration von Threat Intelligence

Schritte zum Erstellen benutzerdefinierter Erkennungsregeln in Wazuh:

• Navigieren Sie im Dashboard zu Server Management → Rules.

• Klicken Sie auf Add new rules file (z. B. 7011-dns-monitoring.xml).

• Definieren Sie den Regelinhalt und speichern Sie die Datei.

• Alternativ: Erstellen Sie die Datei unter /var/ossec/etc/rules/ auf dem Server.

Empfehlung: Kapseln Sie Regeln immer innerhalb eines <group>-Tags. Jede Regel benötigt eine eindeutige ID, eine Schweregradstufe (1–15) und eine präzise Beschreibung (<description>). Verknüpfen Sie Regeln über <if_sid> mit übergeordneten Decodern oder Basisregeln. Fügen Sie RegEx-Prüfungen mittels <match> oder <pcre2> hinzu. Mappen Sie Angriffsvektoren über <mitre> auf Techniken des MITRE-Frameworks (z. B. T1496 für Cryptomining, T1566 für Phishing). Starten Sie den Wazuh-Manager neu (sudo systemctl restart wazuh-manager) und testen Sie die Regeln im Dashboard Threat Hunting.

Pflegen Sie bei Bedarf eine kategorisierte Blockliste verdächtiger Domains:

# Cryptomining Pools
pool.minergate.com:cryptomining
xmrpool.eu:cryptomining
pool.supportxmr.com:cryptomining
nicehash.com:cryptomining
ethermine.org:cryptomining
# Command & Control
cobaltstrike.com:c2
metasploit.com:c2
# Anonymizers
torproject.org:anonymizer
onion.to:anonymizer
# Dynamic DNS (often abused)
duckdns.org:dyndns
no-ip.com:dyndns

Real-Time Alerting

OpenSearch Alerting Monitors können in flexiblen Intervallen (1–5 Minuten) ausgeführt werden:

Benachrichtigungskanäle

Bei Auslösung eines Alarms werden Benachrichtigungen weitergeleitet an:

• Slack: Für sofortige Alarmierung des Security Operations Center (SOC)

• E-Mail: Zur Dokumentation und Archivierung

• GitHub Issues: Zur Aufgabenverfolgung und Remediation

Erkennungsbeispiele

Beispiel 1: Cryptominer-Erkennung

Szenario: Der Arbeitsplatz eines Mitarbeiters wurde mit einem Krypto-Miner infiziert.

Erfasste DNS-Abfrage:

{
  "T": "2026-02-15T10:30:15Z",
  "QH": "pool.supportxmr.com",
  "QT": "A",
  "IP": "192.168.1.105",
  "Result": {"IsFiltered": false}
}

Generierter Alarm:

CRITICAL: Cryptomining Pool DNS Detected
Agent: adguard-dns
Domain: pool.supportxmr.com
Client IP: 192.168.1.105
Time: 2026-02-15T10:30:15Z

Sofortmaßnahmen:

1. Betroffenes System netzwerkseitig isolieren

2. Verdächtige Prozesse beenden

3. Malware-Scan durchführen

4. Laterale Bewegungen im Netzwerk analysieren

Wazuh-Dashboard-Ansicht: Der Alarm wird mit Rule-ID 110021 auf Schweregrad 14 (Critical) angezeigt, inklusive Timestamp, Agentenname und vollständigem AdGuard-Log. Analysten können im Reiter Threat Hunting Events direkt nach rule.groups: "cryptomining" filtern.

Figure: Wazuh Threat Hunting dashboard showing cryptomining alerts filtered by rule.mitre.technique

Figure: Wazuh Threat Hunting dashboard showing cryptomining alerts filtered by rule.mitre.technique

Figure: Wazuh extended log fields for the cryptomining pool detection alerts filtered by rule.id

Beispiel 2: Datenexfiltration über DNS

Szenario: Malware nutzt DNS-TXT-Einträge, um Unternehmensdaten unbemerkt auszuschleusen. TXT-Records werden häufig missbraucht, da kodierte Daten sowohl in Subdomains als auch in der Response Payload übertragen werden können – vorbei an HTTP/S-Inspektionen.

Erkennungslogik: Regel 110011 markiert jede TXT-Abfrage; Regel 110012 schlägt an, wenn innerhalb von 60 Sekunden 20 oder mehr TXT-Abfragen von derselben IP registriert werden (Level 14).

Generierter Alarm:

CRITICAL: DNS Exfiltration Suspected
Source IP: 192.168.x.xx
TXT Queries: 47 in last 60 seconds
Sample Domains:
  - d2f8a9b3c4e5.exfil.malware.com
  - a1b2c3d4e5f6.exfil.malware.com
MITRE ATT&CK: T1048.003 (Exfiltration Over Unencrypted Protocol)

Sofortmaßnahmen:

1. DNS-Auflösung zu verdächtigen Domains sperren

2. Netzwerkverkehr für eine forensische PCAP-Analyse mitschneiden

3. Endpunkt isolieren

4. Kompromittierte Datenbestände ermitteln

Wazuh-Dashboard-Ansicht: Der Vorfall erscheint unter Rule-ID 110012 (bzw. 110046). Analysten können gezielt nach rule.groups: "adguard_exfiltration" oder rule.groups: "data_exfiltration" filtern.

Figure:  Wazuh Threat Hunting dashboard filtered by rule.mitre.technique

Figure: Wazuh Threat Hunting dashboard filtered by rule.mitre.technique

Figure: Wazuh extended log fields for the data exfiltration filter by rule.id 110046 (DNS exfiltration)

Beispiel 3: Zugriff auf Phishing-Domains

Szenario: Ein Benutzer klickt auf einen Phishing-Link in einer gefälschten E-Mail.

Erfasste DNS-Abfrage:

{
  "QH": "login-verify-paypal.suspicious-tld.tk",
  "QT": "A",
  "IP": "192.168.x.xx"
}

Generierter Alarm:

HIGH: Phishing Domain Detected
Agent: laptop-sales-087
Domain: login-verify-paypal.suspicious-tld.tk
Pattern Match: Brand impersonation (PayPal) + suspicious TLD (.tk)
MITRE ATT&CK: T1566.002 (Spearphishing Link)

Sofortmaßnahmen:

1. Betroffenen Mitarbeiter umgehend kontaktieren

2. Prüfen, ob Anmeldedaten eingegeben wurden

3. Potenziell kompromittierte Passwörter sofort zurücksetzen

4. Domain unternehmensweit auf DNS- und Proxy-Ebene blockieren

Wazuh-Dashboard-Ansicht: Der Vorfall löst Regel 110022 (AdGuard: Potential phishing domain detected, Level 10) sowie Endpunkt-Regel 760020 (Level 12) aus. Die Ereignisse lassen sich effizient über die Gruppe adguard_phishing nachverfolgen.

Figure: Wazuh Threat Hunting dashboard showing phishing domain alerts filtered by rule.mitre.technique

Figure: Wazuh Threat Hunting dashboard showing phishing domain alerts filtered by rule.mitre.technique

Figure: Wazuh extended log fields for the phishing alert (rule.id 760020, MITRE T1566.002)

Ergebnisse und Kennzahlen

In einem realen Test-Deployment lieferte diese Architektur folgende Ergebnisse: Über 40 erkannte Cryptominer im ersten Betriebsmonat, 847 blockierte Phishing-Versuche durch markierte verdächtige Domains, 3 erkannte und gestoppte DNS-Exfiltrationsvorfälle, MTTD (Mean Time to Detect) von unter 2 Minuten bei kritischen Bedrohungen, False-Positive-Rate von unter 5 % nach gezieltem Tuning

Best Practices & Lessons Learned

1. Mit Regeln hoher Zuverlässigkeit beginnen: Starten Sie mit konkreten Indicators of Compromise (z. B. bekannten Mining-Pools), bevor Sie breitere, musterbasierte Erkennungen einführen.

2. Auf die eigene Umgebung abstimmen: Einige Teams nutzen legitimerweise dynamisches DNS oder VPNs. Passen Sie Schwellenwerte an interne Richtlinien an.

3. Quellen korrelieren: AdGuard-DNS-Logs bieten zusammen mit Endpunkt-Ereignissen eine lückenlose Sichtbarkeit.

4. MITRE ATT&CK nutzen: Die Zuordnung erleichtert die Priorisierung bei der Triage und die Berichterstattung an Führungsebenen.

5. Reaktionen automatisieren: Nutzen Sie Wazuh Active Response, um Endgeräte bei kritischen Ereignissen (z. B. Exfiltration) automatisch vom Netz zu trennen.

6. False Positives minimieren: CDNs, DynDNS-Dienste oder Cloud-Tools können DGA-ähnliche Muster erzeugen. Führen Sie eine Whitelist genehmigter Dienste und überprüfen Sie Regeln regelmäßig.

Ausblick

Die vorgestellte DNS-Sicherheitsarchitektur lässt sich künftig um folgende Module erweitern:

• Falco-Integration: Zur Überwachung von Container-Laufzeiten und frühzeitigen Erkennung von Exfiltrationsversuchen.

• IP-Reputation-Blocking: Automatisierte Sperrung bekannter bösartiger Infrastrukturen.

• ML-gestützte Anomalieerkennung: Machine-Learning-Modelle zur Erkennung bisher unbekannter DNS-Abweichungen.

• Threat-Intel-Feeds: Direkte Anbindung externer Feeds (MISP, AlienVault OTX, Abuse.ch).

Fazit

Die Kombination aus DNS-basierter Filterung mit AdGuard Home und kontinuierlicher SIEM-Erkennung via Wazuh schafft eine hochwirksame und kostengünstige Verteidigungsschicht. Durch die zentrale Überwachung von DNS-Queries und deren Korrelation mit Threat Intelligence lassen sich Cryptominer, Phishing und Exfiltrationsversuche in Echtzeit stoppen. AdGuards Blocking-Kapazitäten und Wazuhs Erkennungsstärke bilden zusammen eine robuste Lösung, die sich nahtlos in Enterprise-SOC-Abläufe integrieren lässt.