imported>TechCorner-Redaktion: Neuer Artikel: Maltrail-Plugin (os-maltrail 1.10), Stand OPNsense 26.7

2026-10-06T00:00:00Z

Neuer Artikel: Maltrail-Plugin (os-maltrail 1.10), Stand OPNsense 26.7

Neue Seite

{{Steckbrief
| gilt_fuer = 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 ==
{| class="wikitable"
! 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.

[[Datei:OPNsense-Maltrail.png|thumb|center|750px|Maltrail auf der OPNsense: Der Sensor prüft den Verkehr gegen Trails und Heuristiken, der Server zeigt die Ereignisse in einer Weboberfläche, leitet sie an ein SIEM weiter und stellt eine Sperrliste als Firewall-Alias bereit.]]

== 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!) ==
{{Hinweis|Das Plugin hinterlegt als Standard den SHA256-Hash des Passworts '''<code>changeme!</code>''', 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:
<syntaxhighlight lang="bash">
# Linux / macOS
echo -n 'MeinSicheresPasswort' | sha256sum
# OPNsense / FreeBSD (Shell)
sha256 -s 'MeinSicheresPasswort'
</syntaxhighlight>
<syntaxhighlight lang="powershell">
# Windows PowerShell
$b=[Text.Encoding]::UTF8.GetBytes('MeinSicheresPasswort'); -join ([Security.Cryptography.SHA256]::Create().ComputeHash($b) | % { $_.ToString('x2') })
</syntaxhighlight>
Den Hash unter '''Services → Maltrail → General''' im Feld '''SHA256 Admin Password''' eintragen.

== Schritt 3: Allgemeine Einstellungen (General) ==
{| class="wikitable"
! 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 <code>CHECK_HOST_DOMAINS false</code>, sodass die Option derzeit vermutlich keine Wirkung hat.
|-
| '''Update Period''' || <code>86400</code> (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''':
{| class="wikitable"
! Feld !! Standard !! Empfehlung
|-
| '''Enable Maltrail Server''' || aus || aktivieren
|-
| '''UI Listen Address''' || <code>0.0.0.0</code> (alle Adressen) || auf die LAN-/Management-Adresse der Firewall ändern, z. B. <code>192.168.10.1</code>
|-
| '''UI Listen Port''' || <code>8338</code> || 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 <code><nowiki>http://192.168.10.1:8338</nowiki></code> erreichbar (Benutzer ''admin'', Passwort aus Schritt 2). Sie verwendet kein HTTPS – bei Zugriff über unsichere Netze per SSH-Tunnel oder Reverse Proxy (z. B. [[OPNsense - Caddy Reverse Proxy|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 [https://www.max-it.de/it-services/siem-open-source/ Open-Source-SIEM auf Wazuh-Basis], und dort mit Endpoint-Daten korrelieren.

== Typische Probleme ==
{| class="wikitable"
! 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 (<code>echo -n</code>).
|-
| 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 [https://www.max-it.de/it-services/cybersecurity/ Cybersecurity-Leistungen von m.a.x. it] und einem [https://www.max-it.de/it-services/siem-open-source/ 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 ==
* [https://github.com/stamparm/maltrail Maltrail auf GitHub (Dokumentation und Trails)]
* [https://github.com/opnsense/plugins/tree/master/security/maltrail Quellcode des Plugins os-maltrail]
* [https://www.max-it.de/it-services/cybersecurity/ m.a.x. it – Cybersecurity-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Maltrail Erkennung von Schadverkehr - Versionsgeschichte

imported>TechCorner-Redaktion: Neuer Artikel: Maltrail-Plugin (os-maltrail 1.10), Stand OPNsense 26.7