Maltrail

Maltrail ist ein System zur Erkennung von Netzwerkverkehr, das die Kommunikation mit bekannter bösartiger Infrastruktur identifiziert und ausgewählte Verkehrsanomalien meldet. Es gleicht Domains, URLs, IP-Adressen, IP:port-Paare und User-Agent-Werte, die im Netzwerk beobachtet werden, mit einer Reihe von Indikatoren ab, die als Trails bezeichnet werden.

Eine Erkennung wird als einzelnes Ereignis aufgezeichnet, das Quelle, Ziel, Protokoll, den übereinstimmenden Trail, die Klassifizierung und die Trail-Quelle enthält:```text "2026-08-07 09:14:22.117034" gw 10.13.13.2 57809 1.1.1.1 53 UDP DNS malware.bakewithdavid.com "asyncrat (malware)" (static)

Maltrail ist für indikatorbasiertes Netzwerk-Monitoring konzipiert. Seine heuristischen Erkennungen ergänzen
das Trail-Matching, sind jedoch kein Ersatz für Endpoint-Telemetrie oder ein universelles
Intrusion-Prevention-System.

## Funktionen

- Ein vollständiger Trail-Build, der mehr als 3.000 mitgelieferte statische Dateien, 42 Integrationen öffentlicher Feeds
  und optionale, vom Betreiber bereitgestellte Trails kombiniert.
- Ein multithreaded Rust-Sensor unter Verwendung von libpcap, mit optionalen Linux-`PACKET_FANOUT`-Capture-Workern.
- Ein Python-Server, der die Reporting-Oberfläche, die Event-Aufnahme und die HTTP-API bereitstellt.
- Benutzerdefinierte Trails und Whitelists im Klartextformat, die überprüft und versioniert werden können.
- Heuristiken für Scanning, DNS-Erschöpfung, DGA-ähnliche Lookups, verdächtige Downloads, Proxy-Probes,
  verdächtige User-Agent-Werte und verwandte Netzwerkaktivitäten.
- Lokales Event-Logging, Remote-Maltrail-Logging, CEF über syslog und Logstash-JSON-Ausgabe.
- Deployment-Validierung mit `maltrail-sensor -T` und optionalen Prometheus-Metriken.

## Inhalt

- [Architektur](#architecture)
- [Reporting-Oberfläche](#reporting-interface)
- [Leistung](#performance)
- [Installation](#installation)
  - [Installer](#installer)
  - [Aus dem Quellcode bauen](#building-from-source)
  - [Systemd](#systemd)
  - [Docker](#docker)
- [Konfiguration](#configuration)
- [Trails](#trails)
- [Events und API](#events-and-api)
- [Betrieb](#operations)
  - [Monitoring](#monitoring)
  - [Event-Aufbewahrung](#event-retention)
- [Dokumentation](#documentation)
- [Mitwirken](#contributing)
- [Projekt](#project)
  - [Lizenz](#license)
  - [Maintainer](#maintainers)
  - [Sponsoren](#sponsors)
  - [Präsentationen und Veröffentlichungen](#presentations-and-publications)
  - [Abgeleitete Blacklist](#derived-blacklist)
  - [Integrationen von Drittanbietern](#third-party-integrations)
  - [Danksagungen](#acknowledgements)

## Architektur

Maltrail besteht aus zwei unabhängigen Prozessen, die auf demselben Host oder auf getrennten Hosts ausgeführt werden können:```text
   ┌──────────┐   events (UDP or file)   ┌──────────┐
   │  sensor  │ ───────────────────────► │  server  │ ◄── browser
   └──────────┘                          └──────────┘
    Rust                                  Python
    libpcap + PACKET_FANOUT               reporting UI + API
    trail matching + heuristics

Der Sensor erfasst Datenverkehr, führt Trail-Matching und heuristische Analysen durch und erzeugt Ereignisse. Er kann Ereignisse lokal schreiben (LOG_DIR), sie an einen entfernten Maltrail-Server senden (LOG_SERVER) oder beides tun. Er kann außerdem CEF über Syslog (SYSLOG_SERVER) und JSON an Logstash (LOGSTASH_SERVER) ausgeben.

Der Server empfängt und speichert entfernte Ereignisse, stellt lokal verfügbare Ereignisprotokolle bereit und bietet die Weboberfläche und API.

Berichtsoberfläche

Maltrail enthält eine browserbasierte Berichtsoberfläche zum Erkunden erkannten Datenverkehrs, mit Live-Aktualisierungen, feldbezogener Suche, Retro-Hunting, geografischen Ansichten, Triage, gespeicherten Ansichten und Export.

Die Oberfläche wird von server.py unter HTTP_ADDRESS:HTTP_PORT bereitgestellt. Sie ist reines JavaScript mit einer einzigen Laufzeitabhängigkeit von Drittanbietern (PapaParse, für CSV-Parsing) und ohne Build-Schritt. Es wird jeweils ein Tag angezeigt, ausgewählt über eine Datumsauswahl, die zugleich als Ereignisdichte-Raster über die verfügbaren Tagesprotokolle dient. Ereignisse werden von /events gestreamt und im Browser zu Bedrohungen aggregiert — eine Zeile pro unterschiedlichem (source, trail) — dargestellt in einem sortierbaren Raster mit Detailbereich.

Funktion	Hinweise
Live-Modus	Angehängte Ereignisse werden über Server-Sent Events (/live) übertragen und in die aktuelle Ansicht eingefügt. Fällt auf Polling von Byte-Bereichen des Tagesprotokolls zurück, wenn SSE nicht verfügbar ist oder für Sitzungen, die der Stream nicht bedienen kann. Neue Bedrohungen hoher Schwere können eine Desktop-Benachrichtigung und einen hörbaren Alarm auslösen; beide können stummgeschaltet werden
Suche	Feldbezogene Tokens (src: dst: port: proto: type: trail: info: family: tag: uid: sev: dir: status:; family:interlock zieht interlock-1/-2 mit ein, die Shards, in die ein Feed-Dump aufgeteilt ankommt) kombiniert mit Leerzeichen als UND, - zum Ausschließen, *-Platzhalter, CIDR (src:10.0.0.0/8) sowie numerische Bereiche und Vergleiche (port:>1024, count:>=100). Aktive Filter erscheinen als entfernbare Chips
Retro-Hunt	Durchsucht alle aufbewahrten Tagesprotokolle nach einem Indikator (/hunt), nicht nur den angezeigten Tag. Begrenzt durch ein Tageslimit, ein Wall-Clock-Budget und eine Stichprobenobergrenze; ein Tag, den das Budget vorzeitig abgeschnitten hat, wird getrennt von den abgeschlossenen Tagen gemeldet, statt als fertige Gesamtsumme gezählt zu werden. Ein tagesbezogener Sidecar-Index (LOG_DIR/index/, USE_EVENT_INDEX) ermöglicht es dem Durchlauf, jede nicht passende Zeile zu überspringen, und macht /counts exakt
Weltkarte	Ereignisdichte pro Land für den ausgewählten Tag (/geo), wobei der externe Endpunkt jedes Ereignisses platziert wird. Ereignisse, die keiner externen Adresse zugeordnet werden können, werden als nicht zugeordnet gemeldet, statt geraten zu werden. Setzen Sie HOME_LAT / HOME_LON, um Ursprungsbögen zu zeichnen
Triage	Status pro Bedrohung (neu / in Untersuchung / gelöst / falsch positiv), Freitextnotizen, Tags und Ausblenden. Whitelist-Regeln und OSINT-Pivots sind über das Kontextmenü der Zeile verfügbar
Gespeicherte Ansichten	Benannte Filter-Voreinstellungen
Export	Die aktuelle gefilterte Ansicht als CSV, JSON oder entschärfte Indikatoren
Erscheinungsbild	Dunkle und helle Themes sowie diskrete Textgrößenstufen

Triage-Status, gespeicherte Ansichten, Tags und Erscheinungsbild-Einstellungen werden im Browser (localStorage) gespeichert, nicht auf dem Server: Sie sind pro Browser und pro Origin und werden nicht zwischen Analysten geteilt.

Sitzungen, die mit einem Netzwerkfilter eingeschränkt sind, sehen nur Ereignisse aus ihren eigenen Netzwerken, und diese Einschränkung gilt auch für die Zähl-, Karten- und Blacklist-Endpunkte sowie für die Ereignisliste.