© Andriy Popov / 123RF.com

Die leichtgewichtige Analysesoftware Maltrail begutachtet den Netzverkehr und schlägt bei verdächtigen Webzugriffen oder dubiosen Namensauflösungen Alarm.

Im Internet buhlen Hunderte von Sicherheitsprodukten um die Gunst der Anwender und versprechen Schutz auf höchstem Niveau. Neben zahlreichen kommerziellen Angeboten mit monatlichem Grundpreis finden sich auch kostenfreie Open-Source-Produkte, die den bestehenden Basisschutz erweitern wollen.

Maltrail [1] gehört zur Kategorie Open-Source-Tools. Es legt sich im Netz auf die Lauer und schlägt Alarm, wenn ein gesichtetes Paket verdächtig erscheint. Es berichtet seinen Fund, greift jedoch nicht ein. Mit seiner Arbeitsweise bewegt sich Maltrail zwischen einem Intrusion-Detection-System und einem Malware-Scanner. Für die Untersuchung der Pakete bedient sich Maltrail bei öffentlichen Blacklists. Im Maltrail-Jargon bezeichnet man die Beschreibung einer verdächtigen IP-Adresse, Web-URL oder Domäne als Trail. Bei Feeds handelt es sich um Listen aus bekannten Trails, die die Maltrail-Community aktuell hält.

Aufbau

Maltrail besteht aus zwei Komponenten: Der Sensor beschnüffelt die Pakete, die Server-Komponente sammelt die Alarme des Sensors. Der optimale Aufbau platziert die Sensorsoftware auf einem Router oder auf einer Firewall, weil die den Datenstrom aller Netzteilnehmer mitbekommen. In Abbildung 1 verbirgt sich der Sensor in einer Firewall und hat damit Zugriff auf alle durchlaufenden Pakete. Die Position des Servers spielt keine große Rolle, solange der Sensor und der Admin ihn erreichen können.

Abbildung 1: Der Maltrail-Sensor sitzt im Datenstrom und berichtet an seinen Server.

Installation

Der Programmcode von Maltrail ist vollständig in Python verfasst. Hinsichtlich der Python-Version gibt sich Maltrail nicht wählerisch. Grundsätzlich funktionieren alle Interpreter mit einer höheren Versionsnummer als 2.6, sodass selbst ältere Linux-Server als Sensor infrage kommen. Der Sensor benötigt zusätzlich das Python-Paket pcapy, um die IP-Pakete vom Netzadapter abzufangen. Die Software selbst liegt auf Github und steht unter einer freien Lizenz.

Für die Installation bemühen Sie den Paketmanager der verwendeten Distribution und installieren die benötigten Pakete (Listing 1, erste Zeile). Anschließend holen Sie den Programmcode von Github und legen ihn lokal ab (Zeile 2). In der Voreinstellung lauscht der Sensor auf allen verfügbaren Netzadaptern und legt seine Warnungen in einer lokalen Datei ab. Für einen ersten Probelauf passt das.

Beim ersten Start (Zeile 3) holt sich der Sensor alle verfügbaren Blacklists aus dem Netz und legt sie im Unterordner »~/.maltrail/« ab. Anschließend nimmt Maltrail seine Arbeit auf. Damit der Sensor an den Server Bericht erstatten kann, ergänzen Sie in der Maltrail-Konfigurationsdatei »~/.maltrail/maltrail.conf« seine IP-Adresse samt Port (Listing 2, Zeile 2 und 3). Anschließend starten Sie den Server (Listing 1, Zeile 4). Der Sensor verschickt seine Ergebnisse an den DNS-Namen beziehungsweise an die bereits aufgelöste IP-Adresse des Servers (Listing 2, letzte Zeile).

Ob die Kommunikation zwischen Sensor und Server steht, lässt sich einfach testen. Dazu lösen Sie auf dem System, auf dem der Sensor läuft, eine Domäne auf, die in der Blacklist von Maltrail steht (Listing 1, Zeile 5). Der Sensor erkennt die Aktion und petzt den Vorfall an den Server.

$ sudo apt install python-pcapy git
$ git clone --depth 1 https://github.com/stamparm/maltrail.git cd maltrail
$ sudo python sensor.py
$ sudo python server.py
$ nslookup kshield.net

# Adresse und Port des Servers
UDP_ADDRESS 0.0.0.0
UDP_PORT 8337
# Log-Server
LOG_SERVER server.example.net:8337

Auswertung

Der Server liefert die Ergebnisse über eine hübsche Webseite aus. Unter http://server.example.net:8338 erwartet Sie eine grafische Aufarbeitung aller gemeldeten Alarme, gruppiert nach Meldungstyp, Sensor und IP-Adresse des verursachenden Clients. Ob es sich bei der Meldung tatsächlich um eine reale Bedrohung handelt, müssen Sie selbst beurteilen. Wenn beispielsweise die Windows-Rechner im lokalen Netz die Remote-Management-API verwenden, meldet Maltrail zwar verdächtige Aktionen, das stellt für Sie aber keinen Grund zur Sorge dar.

Datenschützer aufgepasst: Die Genauigkeit von Maltrail passt gar nicht gut zum Schutz von personenbezogenen Daten. So finden sich in der Auswertung die IP-Adressen der Clients und in den HTTP-Zugriffen auch gelegentlich Benutzernamen. Wollen Sie nicht in Teufels Küche kommen, schwärzen Sie die Client-Adresse in der Log-Datei nachträglich mit den Kommandos aus Listing 3.

$ cat $(date +"%Y-%m-%d").log | awk '{ $4 = "-"; print }' > temp
mv temp $(date +"%Y-%m-%d").log

Die Weboberfläche des Servers präsentiert einen Tagesbericht mit allen erhaltenen Alarmmeldungen (Abbildung 2). Zusätzlich dazu fasst sie Bedrohungen, Events, die verdächtigsten IP-Adressen und die häufigsten Trails in bunten Diagrammen zusammen. Details zu den aufgezeichneten Adressen erhalten Sie, indem Sie den Mauszeiger über dem jeweiligen Text positionieren.

Abbildung 2: Der Maltrail-Server informiert über alle Alarme.

Viele Programme und Betriebssysteme funken im Hintergrund nach Hause, und Maltrail zeigt in seiner Übersicht, welche der Nachrichten verdächtig erscheinen. Darüber hinaus erfahren Sie durch Maltrail, welche Maschinen im lokalen Netz miteinander kommunizieren, ohne dass Sie davon wissen oder das erwünscht ist.

Eine Sammlung mit Beispielen realer Angriffe präsentiert das Projekt auf seiner Webseite im Bereich Real-life cases. Finden sich in den Reports Ihres Maltrail-Servers ähnliche Einträge, dann war Ihr Netz möglicherweise das Opfer eines Massen-Scans, eines Port-Scans, von Malware oder einem Datenleck. Freilich muss nicht jede Meldung automatisch einen Klasse-1-Alarm auslösen. Ein sinnvoller Einsatz von Maltrail setzt voraus, dass Sie die neue Alarmanlage an die eigene Umgebung anpassen und damit Falschmeldungen minimieren.

Einsatzort

Lässt sich Maltrail im eigenen Netz nicht auf einem Router, Switch oder einer Firewall installieren, setzen Sie die Software im passiven Modus ein. Dazu starten Sie den Sensor auf einem beliebigen Rechner und erhalten über einen Spiegel-Port des Core-Switches eine Kopie jedes Pakets. Damit sitzt der Sensor zwar nicht im Datenpfad, erhält aber genug Information, um wirksam zu arbeiten.

In kleinen Netzen mit einer Fritzbox oder einem Speedport als zentraler Komponente fällt dagegen ein höherer Aufwand an: Die populären DSL-Router erlauben nur über eine Hintertür Einblick in die empfangenen Pakete. Hier endet der Hersteller-Support und beginnt die Bastelei. Glücklicherweise teilen verschiedene Skriptkünstler ihre Erfolge beim Zugriff auf die versteckten Bereiche der Weboberfläche von Fritzbox [2] und Konsorten [3]. Rückt Ihr Router tatsächlich den Paketstrom im PCAP-Format heraus, kann der Maltrail-Sensor die resultierende Datei mit dem Schalter »-i« einlesen und analysieren.

Falls solche Workarounds Ihre Geduld zu sehr strapazieren, bleibt nur noch, Maltrail als Host-IDS zu nutzen. Dabei läuft der Sensor lokal auf allen Servern, die er überwachen soll. Damit beschützt Maltrail allerdings nicht mehr das ganze Netz, sondern nur noch ausgesuchte Rechner.

Ausnahmen

Nicht alle Trails im eigenen Netz stellen automatisch eine Bedrohung dar. Maltrail sieht auch Dienste wie DynDNS und verschiedene HTTP-User-Agents als potenzielles Risiko. Damit die harmlosen Meldungen nicht das gesamte Log füllen, klammern Sie Gruppen von Trails oder sogar ganze Feeds von der Untersuchung aus.

Sollen einzelne Trails aus dem Blickfeld der Webseite verschwinden, machen Sie diese per Rechtsklick und Hide Threat unsichtbar. Umgekehrt akzeptiert Maltrail auch eigene Quellen mit Trails, die Sie in der Konfigurationsdatei per »CUSTOM_TRAILS_DIR« angeben.

Sonderfall: Windows

Offiziell läuft Maltrail nur auf Linux und Unix, aber mit ein paar Klimmzügen lassen sich auch Windows-Rechner als Sensoren einsetzen. Hier hakt es nicht bei Maltrail selbst, sondern beim Pcapy-Paket, das einen wahren Rattenschwanz an Abhängigkeiten aufweist. Scheuen Sie die Mühe nicht, dann holen Sie sich den Quellcode von Pcapy, Winpcap und Python sowie den Microsoft Visual C++ Compiler for Python und kompilieren das begehrte Paket selbst [4]. Ist dieser Schritt vollbracht, startet der Sensor unter Windows und lässt sich auf die gewohnte Art und Weise bedienen (Abbildung 3).

Abbildung 3: Über Umwege läuft Maltrail auch unter Windows.

Hinsehen und raten

Passt der untersuchte Datenstrom zu keiner Blockierliste, muss Maltrail tiefer in die Trickkiste greifen und die Heuristik bemühen. In dieser Disziplin sucht Maltrail nach Indizien für böswilliges Verhalten wie ungewöhnlichen User-Agents in Webanfragen, Port-Scans, langen Domänennamen und Webzugriffen mit Code-Injections.

Auch die Ergebnisse dieser Checks fallen nicht immer präzise aus und können zu Fehlalarmen führen. Ob es eine Meldung aufgrund der Heuristik in die Webseite geschafft hat, zeigt die Spalte reference. Falls sich hier die Ursache heuristic häuft, unterbinden Sie über die Konfigurationsanweisung »USE_HEURISTICS« diese Methode.

Gegenmaßnahmen einleiten

Maltrail kann nur berichten, aber nicht kontern. Um IP-Pakete zu blockieren, gibt es unter Linux Iptables/Nftables, unter FreeBSD Pf, und Windows setzt auf die Microsoft-Defender-Firewall. Immerhin stellt der Maltrail-Server seine Entdeckungen als Liste mit verdächtigen IP-Adressen via HTTP bereit. Die Projektseite beschreibt, wie Sie damit per Skript die lokale Iptables-Richtlinie füttern. Grundsätzlich lässt sich mit der IP-Liste jede per API oder Skript zugängliche Firewall erweitern, zum Beispiel OPNsense und sogar die Windows-Firewall.

Einschränkung

Maltrail ist kein vollwertiges IDS, sondern lediglich ein Paketscanner, der sich bei öffentlichen Blacklists bedient. Komplexe, auf der Anwendungsebene erfolgende Angriffe kann Maltrail nicht erkennen. Damit kommt es auch nicht an die Erkennungsrate eines echten IDS heran.

Ein weiteres Manko stellt die Kommunikation zwischen Sensor und Server dar, die über das unverschlüsselte UDP-Protokoll läuft. Der berüchtigte Man-in-the-Middle kann Alarmmeldungen mitlesen, manipulieren oder löschen, um seine Aktionen zu verbergen. Für den ungestörten Transport über das Internet muss der Admin die Alarmpakete mit IPsec oder SSH absichern. Der Zugriff auf die Weboberfläche des Maltrail-Servers benutzt TLS und ein Server-Zertifikat, was ausreichende Sicherheit bietet.

Ausblick

Maltrail fühlt sich auch in virtuellen Umgebungen zu Hause und analysiert den Netzverkehr der Gastsysteme einer VMware-Infrastruktur. Der ESXi-Host hat zwar einen Python-Interpreter an Bord, aber besser läuft Maltrail als eigenständige virtuelle Maschine. Dazu benötigt die VM jeweils einen Netzadapter pro Port-Gruppe. Da Maltrail über PCAP an die IP-Pakete gelangt, benötigt die Port-Gruppe oder der virtuelle Switch die Erlaubnis, den Promiscuous Mode zu verwenden. In diesem Setup arbeitet Maltrail nur mit Kopien der Pakete. Damit bleiben die virtuellen Server auch dann erreichbar, wenn der Sensorprozess Fehler produziert oder die Maltrail-VM nicht läuft.

Der Maltrail-Sensor kann nicht nur seinem eigenen Server-Dienst Bericht erstatten, sondern auch Syslog und Logstash beliefern. Dazu formatiert er seine Botschaften als standardisierte Syslog-Nachricht oder als strukturierte JSON-Meldung, die ein Log Shipper sinnvoll auswerten kann. Damit lässt sich Maltrail in eine größere Log-Infrastruktur einbinden oder in einem Logging-as-a-Service-Konzept unterbringen.

Fazit

Der leichtgewichtige Netzwerkscanner Maltrail analysiert den Netzverkehr auf verdächtige Aktivitäten hin. Sein Wissen bezieht er aus frei verfügbaren Blacklists und Reputationsdatenbanken. Dabei arbeitet Maltrail wie ein Intrusion-Detection-System: Es lädt Signaturen und vergleicht sie mit den gesichteten IP-Paketen. Bei Übereinstimmung gibt es einen Alarm im Dashboard, der den Admin warnt. Maltrail ist zwar kein Rundum-sorglos-Paket, aber ein sinnvoller Baustein in einem Sicherheitskonzept. (jcb/jlu)