OPNsense - Maltrail Erkennung von Schadverkehr
Auf einen Blick
| Gilt für | OPNsense 26.1/26.7 mit Plugin os-maltrail 1.10 |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 20 Minuten (Einrichtung), danach regelmäßige Auswertung |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 |
Maltrail ist ein Open-Source-System zur Erkennung von Schadverkehr (Malicious Traffic Detection). Es gleicht den Netzwerkverkehr mit öffentlichen Blocklisten, Antiviren-Berichten und eigenen Listen ab – sogenannten Trails: Domainnamen, URLs, IP-Adressen oder HTTP-User-Agents, die mit Malware, Botnetzen, Phishing, Krypto-Minern, Tor oder Scannern in Verbindung stehen. Zusätzlich erkennen Heuristiken auch bisher unbekannte Auffälligkeiten. Mit dem Plugin os-maltrail läuft Maltrail direkt auf der OPNsense und zeigt, welches Gerät im Netz mit welchem verdächtigen Ziel kommuniziert – ein wertvoller Frühindikator für infizierte Systeme.
Maltrail im Vergleich zu IDS/IPS
| Kriterium | Maltrail | Suricata (OPNsense Intrusion Detection) |
|---|---|---|
| Ansatz | Abgleich mit Reputationslisten (Domains, IPs, URLs) + Heuristik | Signaturen auf Paket- und Protokollebene |
| Stärke | Erkennung kompromittierter Clients (C2, Malware-Domains, Miner) | Erkennung von Exploits und Angriffsmustern, Blockieren im Inline-Modus |
| Blockieren | Indirekt über Firewall-Alias | Direkt (IPS-Modus) |
| Ressourcen | gering bis mittel | mittel bis hoch |
Beide ergänzen sich: Maltrail liefert eine übersichtliche Liste verdächtiger Kommunikation, Suricata erkennt Angriffe auf Protokollebene.
Aufbau: Sensor und Server
- Sensor: Liest den Netzwerkverkehr auf den gewählten Schnittstellen mit und meldet Treffer.
- Server: Speichert die Ereignisse, stellt die Weboberfläche bereit und kann Ereignisse mehrerer Sensoren (z. B. mehrerer Standorte) sammeln.
Auf einer einzelnen OPNsense laufen Sensor und Server gemeinsam.
Schritt 1: Plugin installieren
System → Firmware → Plugins: os-maltrail installieren und die Seite neu laden. Das Menü befindet sich unter Services → Maltrail mit General, Sensor und Server.
Schritt 2: Admin-Passwort setzen (Pflicht!)
changeme!, und die Weboberfläche lauscht standardmäßig auf allen Adressen. Vor dem Aktivieren des Servers unbedingt ein eigenes Passwort setzen und die Listen-Adresse einschränken.Maltrail erwartet das Passwort als SHA256-Hash. Erzeugen lässt er sich z. B. so:
# Linux / macOS
echo -n 'MeinSicheresPasswort' | sha256sum
# OPNsense / FreeBSD (Shell)
sha256 -s 'MeinSicheresPasswort'
# Windows PowerShell
$b=[Text.Encoding]::UTF8.GetBytes('MeinSicheresPasswort'); -join ([Security.Cryptography.SHA256]::Create().ComputeHash($b) | % { $_.ToString('x2') })
Den Hash unter Services → Maltrail → General im Feld SHA256 Admin Password eintragen.
Schritt 3: Allgemeine Einstellungen (General)
| Feld | Standard | Empfehlung |
|---|---|---|
| Use Heuristics | an | an lassen – erkennt z. B. verdächtige Domainnamen (DGA), lange DNS-Anfragen oder ungewöhnliche Dateidownloads |
| Check Hostheaders | aus | optional; prüft zusätzlich HTTP-Host-Header gegen Domain-Trails. Hinweis: In der aktuellen Plugin-Vorlage (1.10) folgt später ein fester Eintrag CHECK_HOST_DOMAINS false, sodass die Option derzeit vermutlich keine Wirkung hat.
|
| Update Period | 86400 (1 Tag) |
Standard oder kürzer (z. B. 21600 = 6 Stunden) |
| Monitor Interface | leer (alle) | die internen Schnittstellen (LAN, VLANs, DMZ) – so bleibt die Quell-IP des betroffenen Geräts sichtbar; WAN nur zusätzlich, wenn eingehende Scans interessieren |
| Whitelist | leer | bekannte Fehlalarme (IPs oder Domains), z. B. eigene Scanner oder Update-Server |
Schritt 4: Sensor aktivieren
Services → Maltrail → Sensor:
- Enable Maltrail Sensor aktivieren.
- Capture All: aus (Standard) prüft UDP, ICMP, TCP-Verbindungsaufbauten und typische HTTP-/Proxy-Ports – das spart Ressourcen. Aktiviert wird sämtlicher IPv4/IPv6-Verkehr untersucht.
- Capture Buffer Size: leer = 10 % des Arbeitsspeichers; auf kleinen Systemen gezielt begrenzen (z. B. 100 MB).
- Remote Server leer lassen (lokaler Server) bzw. bei zentralem Maltrail-Server dessen Adresse und Port (Standard 8337/UDP) eintragen.
- Syslog Server / Syslog Port: Ereignisse zusätzlich per Syslog weiterleiten – z. B. an ein SIEM.
Schritt 5: Server aktivieren
Services → Maltrail → Server:
| Feld | Standard | Empfehlung |
|---|---|---|
| Enable Maltrail Server | aus | aktivieren |
| UI Listen Address | 0.0.0.0 (alle Adressen) |
auf die LAN-/Management-Adresse der Firewall ändern, z. B. 192.168.10.1
|
| UI Listen Port | 8338 |
Standard |
| Add Blocklist Alias | aus | aktivieren, um erkannte Angreifer-IPs automatisch als Firewall-Alias BlocklistMaltrail bereitzustellen |
| Log Listen Address/Port | leer | nur bei zentralem Server für entfernte Sensoren (UDP 8337) |
Anschließend Firewall → Rules auf dem LAN-/Management-Interface: Zugriff auf TCP 8338 der Firewall nur von Admin-Systemen erlauben. Die Weboberfläche ist unter http://192.168.10.1:8338 erreichbar (Benutzer admin, Passwort aus Schritt 2). Sie verwendet kein HTTPS – bei Zugriff über unsichere Netze per SSH-Tunnel oder Reverse Proxy (z. B. Caddy mit Access List) absichern.
Schritt 6: Ereignisse auswerten
Die Weboberfläche zeigt pro Tag eine Zeitleiste und eine Ereignistabelle mit:
- Quelle und Ziel (IP, Port) – die Quelle ist bei überwachten LAN-Schnittstellen das betroffene interne Gerät,
- Trail (z. B. eine Domain oder IP), Info (z. B. malware, suspicious, known attacker, crypto mining, tor exit) und Referenz (Quelle der Liste),
- Severity und Anzahl der Treffer.
Vorgehen bei einem Treffer:
- Plausibilisieren: Ist der Trail glaubwürdig (Referenz prüfen) oder ein Fehlalarm (z. B. Werbe-/Tracking-Domain)?
- Gerät identifizieren: Über DHCP-Leases bzw. ARP-Tabelle der OPNsense herausfinden, welches Gerät hinter der Quell-IP steht.
- Untersuchen: Virenscan, EDR-Auswertung, ggf. Gerät isolieren.
- Fehlalarme unter General → Whitelist eintragen.
Schritt 7: Erkannte Angreifer blockieren (Alias)
Mit Add Blocklist Alias legt das Plugin den Alias BlocklistMaltrail an. Er enthält IPs, die Maltrail als Angreifer, Massen-Scanner, Spammer oder bei Web-Angriffen (Directory Traversal, Injection, Remote Code Execution) erkannt hat. Verwendung:
- Firewall → Rules, Interface WAN: Block-Regel mit Quelle BlocklistMaltrail ganz oben – blockiert eingehende Verbindungen dieser IPs.
- Optional auf internen Interfaces eine Block-Regel mit Ziel BlocklistMaltrail.
Die Sperrliste reagiert auf beobachtetes Verhalten; sie ersetzt keine kuratierten Blocklisten, ergänzt sie aber sinnvoll.
Zentraler Betrieb mit mehreren Standorten
Bei mehreren Firewalls kann eine OPNsense (oder ein separater Linux-Server) als zentraler Maltrail-Server dienen: Dort Log Listen Address/Port setzen (UDP 8337) und auf den Außenstellen im Sensor unter Remote Server diese Adresse eintragen – über ein VPN, da die Übertragung unverschlüsselt ist. Die lokale Speicherung entfällt dann auf den Sensoren.
Ressourcen, Grenzen und Datenschutz
- Verschlüsselter Verkehr: Bei HTTPS sieht Maltrail Ziel-IP und (über DNS) den Domainnamen, nicht aber URLs oder Inhalte. Da DNS-Anfragen der Clients meist über die Firewall laufen, sind Domain-Trails dennoch sehr wirksam. DNS over HTTPS in Browsern kann die Erkennung umgehen – ggf. per Richtlinie unterbinden.
- Ressourcen: Sensor und Paketmitschnitt benötigen CPU und RAM, besonders mit Capture All bei hohem Durchsatz.
- Datenschutz: Maltrail protokolliert Verbindungsdaten von Beschäftigten (IP, Ziel, Zeit). Einsatz mit Datenschutzbeauftragten bzw. Betriebsrat abstimmen und Aufbewahrungsfristen festlegen.
- Weiterverarbeitung: Ereignisse per Syslog an ein SIEM übergeben, z. B. ein Open-Source-SIEM auf Wazuh-Basis, und dort mit Endpoint-Daten korrelieren.
Typische Probleme
| Symptom | Lösung |
|---|---|
| Weboberfläche nicht erreichbar | Server aktiviert? UI Listen Address/Port und Firewall-Regel prüfen. |
| Anmeldung schlägt fehl | Hash statt Klartext eintragen; beim Erzeugen keinen Zeilenumbruch mitrechnen (echo -n).
|
| Keine Ereignisse | Sensor aktiviert? Monitor Interface korrekt? Trails nach dem ersten Start erst nach dem Update vorhanden. |
| Viele Fehlalarme | Whitelist pflegen; Werbe-/Tracking-Domains bewerten; Heuristik-Treffer kritisch prüfen. |
| Hohe Last | Capture All deaktivieren, Capture Buffer begrenzen, weniger Schnittstellen überwachen. |
Fazit
Maltrail ist ein schlanker, sehr nützlicher Baustein für die Netzwerksicherheit: Es zeigt auf einen Blick, welche Geräte mit bekannten Schad-Infrastrukturen sprechen, und liefert mit dem Firewall-Alias eine einfache Möglichkeit, auffällige Angreifer zu sperren. Wichtig sind ein eigenes Admin-Passwort, eine auf das Management-Netz beschränkte Oberfläche und eine regelmäßige Auswertung der Ereignisse.
Unterstützung von m.a.x. it
Sie möchten Schadverkehr in Ihrem Netz erkennen, Maltrail, Suricata und Ihr SIEM zusammenführen oder auffällige Ereignisse professionell bewerten lassen? m.a.x. it unterstützt Sie mit Cybersecurity-Leistungen von m.a.x. it und einem Open-Source-SIEM von m.a.x. it.
Siehe auch
- OPNsense - Netdata Echtzeit-Monitoring
- OPNsense - Net-SNMP Monitoring per SNMP
- Suricata
- IDS
- IOC
- Botnet
- Threat Intelligence
Links und Quellen
- Maltrail auf GitHub (Dokumentation und Trails)
- Quellcode des Plugins os-maltrail
- m.a.x. it – Cybersecurity-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
