maltrail
0.76
Maltrail ist ein System zur Erkennung böswilligen Datenverkehrs, das öffentlich verfügbare (schwarze) Listen mit bösartigen und/oder allgemein verdächtigen Spuren sowie statische Spuren nutzt, die aus verschiedenen AV-Berichten und benutzerdefinierten benutzerdefinierten Listen zusammengestellt wurden, wobei Spur alles sein kann, vom Domänennamen (z. B. zvpprsensinaix.com für Banjori-Malware), URL (z. B. hXXp://109.162.38.120/harsh02.exe für bekanntermaßen schädliche ausführbare Dateien), IP-Adresse (z. B 185.130.5.231 für bekannte Angreifer) oder HTTP-User-Agent-Header-Wert (z. B. sqlmap für automatische SQL-Injection und Datenbankübernahme-Tool). Außerdem verwendet es (optional) erweiterte heuristische Mechanismen, die bei der Erkennung unbekannter Bedrohungen (z. B. neuer Malware) helfen können.
Die folgenden (schwarzen) Listen (dh Feeds) werden verwendet:
360bigviktor, 360chinad, 360conficker, 360cryptolocker, 360gameover,
360locky, 360necurs, 360suppobox, 360tofsee, 360virut, abuseipdb, alienvault,
atmos, badips, bitcoinnodes, blackbook, blocklist, botscout,
bruteforceblocker, ciarmy, cobaltstrike, cruzit, cybercrimetracker,
dataplane, dshieldip, emergingthreatsbot, emergingthreatscip,
emergingthreatsdns, feodotrackerip, gpfcomics, greensnow, ipnoise,
kriskinteldns, kriskintelip, malc0de, malwaredomainlistdns, malwaredomains,
maxmind, minerchk, myip, openphish, palevotracker, policeman, pony,
proxylists, proxyrss, proxyspy, ransomwaretrackerdns, ransomwaretrackerip,
ransomwaretrackerurl, riproxies, rutgers, sblam, socksproxy, sslbl,
sslproxies, talosintelligence, torproject, trickbot, turris, urlhaus,
viriback, vxvault, zeustrackermonitor, zeustrackerurl, etc.
Bei statischen Einträgen wurden die Spuren für die folgenden bösartigen Entitäten (z. B. Malware-C&Cs oder Sinkholes) manuell eingefügt (aus verschiedenen AV-Berichten und persönlichen Recherchen):
1ms0rry, 404, 9002, aboc, absent, ab, acbackdoor, acridrain, activeagent,
adrozek, advisorbot, adwind, adylkuzz, adzok, afrodita, agaadex, agenttesla,
aldibot, alina, allakore, almalocker, almashreq, alpha, alureon, amadey,
amavaldo, amend_miner, ammyyrat, android_acecard, android_actionspy,
android_adrd, android_ahmythrat, android_alienspy, android_andichap,
android_androrat, android_anubis, android_arspam, android_asacub,
android_backflash, android_bankbot, android_bankun, android_basbanke,
android_basebridge, android_besyria, android_blackrock, android_boxer,
android_buhsam, android_busygasper, android_calibar, android_callerspy,
android_camscanner, android_cerberus, android_chuli, android_circle,
android_claco, android_clickfraud, android_cometbot, android_cookiethief,
android_coolreaper, android_copycat, android_counterclank, android_cyberwurx,
android_darkshades, android_dendoroid, android_dougalek, android_droidjack,
android_droidkungfu, android_enesoluty, android_eventbot, android_ewalls,
android_ewind, android_exodus, android_exprespam, android_fakeapp,
android_fakebanco, android_fakedown, android_fakeinst, android_fakelog,
android_fakemart, android_fakemrat, android_fakeneflic, android_fakesecsuit,
android_fanta, android_feabme, android_flexispy, android_fobus,
android_fraudbot, android_friend, android_frogonal, android_funkybot,
android_gabas, android_geinimi, android_generic, android_geost,
android_ghostpush, android_ginmaster, android_ginp, android_gmaster,
android_gnews, android_godwon, android_golddream, android_goldencup,
android_golfspy, android_gonesixty, android_goontact, android_gplayed,
android_gustuff, android_gypte, android_henbox, android_hiddad,
android_hydra, android_ibanking, android_joker, android_jsmshider,
android_kbuster, android_kemoge, android_ligarat, android_lockdroid,
android_lotoor, android_lovetrap, android_malbus, android_mandrake,
android_maxit, android_mobok, android_mobstspy, android_monokle,
android_notcompatible, android_oneclickfraud, android_opfake,
android_ozotshielder, android_parcel, android_phonespy, android_pikspam,
android_pjapps, android_qdplugin, android_raddex, android_ransomware,
android_redalert, android_regon, android_remotecode, android_repane,
android_riltok, android_roamingmantis, android_roidsec, android_rotexy,
android_samsapo, android_sandrorat, android_selfmite, android_shadowvoice,
android_shopper, android_simbad, android_simplocker, android_skullkey,
android_sndapps, android_spynote, android_spytekcell, android_stels,
android_svpeng, android_swanalitics, android_teelog, android_telerat,
android_tetus, android_thiefbot, android_tonclank, android_torec,
android_triada, android_uracto, android_usbcleaver, android_viceleaker,
android_vmvol, android_walkinwat, android_windseeker, android_wirex,
android_wolfrat, android_xavirad, android_xbot007, android_xerxes,
android_xhelper, android_xploitspy, android_z3core, android_zertsecurity,
android_ztorg, andromeda, antefrigus, antibot, anubis, anuna, apocalypse,
apt_12, apt_17, apt_18, apt_23, apt_27, apt_30, apt_33, apt_37, apt_38,
apt_aridviper, apt_babar, apt_bahamut, etc.
Maltrail basiert auf der Architektur Traffic -> Sensor <-> Server <-> Client . Sensor (en) ist eine eigenständige Komponente, die auf dem Überwachungsknoten (z. B. einer Linux-Plattform, die passiv mit dem SPAN-/Spiegelungsport verbunden ist oder transparent inline auf einer Linux-Bridge verbunden ist) oder auf dem eigenständigen Computer (z. B. Honeypot) läuft und dort den vorbeiströmenden Datenverkehr „überwacht“. für Elemente/Trails auf der schwarzen Liste (z. B. Domainnamen, URLs und/oder IPs). Im Falle einer positiven Übereinstimmung werden die Ereignisdetails an den (zentralen) Server gesendet, wo sie im entsprechenden Protokollierungsverzeichnis (z. B. LOG_DIR , beschrieben im Abschnitt „Konfiguration “) gespeichert werden. Wenn Sensor auf demselben Computer wie Server ausgeführt wird (Standardkonfiguration), werden Protokolle direkt im lokalen Protokollverzeichnis gespeichert. Andernfalls werden sie über UDP-Nachrichten an den Remote-Server gesendet (z. B. LOG_SERVER beschrieben im Abschnitt „Konfiguration“ ).
Die Hauptaufgabe des Servers besteht darin, die Ereignisdetails zu speichern und Back-End-Unterstützung für die meldende Webanwendung bereitzustellen. In der Standardkonfiguration laufen Server und Sensor auf demselben Computer. Um potenzielle Unterbrechungen der Sensoraktivitäten zu verhindern, basiert der Front-End-Berichtsteil auf der „Fat Client“-Architektur (dh die gesamte Datennachbearbeitung erfolgt innerhalb der Webbrowser-Instanz des Clients). Ereignisse (z. B. Protokolleinträge) für den gewählten Zeitraum (24 Stunden) werden an den Client übertragen, wobei die meldende Webanwendung allein für den Präsentationsteil verantwortlich ist. Die Daten werden in komprimierten Blöcken an den Client gesendet, wo sie nacheinander verarbeitet werden. Der Abschlussbericht wird in einer stark komprimierten Form erstellt, die praktisch die Darstellung einer nahezu unbegrenzten Anzahl von Ereignissen ermöglicht.
Hinweis: Die Serverkomponente kann ganz übersprungen werden und einfach den eigenständigen Sensor verwenden. In einem solchen Fall würden alle Ereignisse im lokalen Protokollierungsverzeichnis gespeichert, während die Protokolleinträge entweder manuell oder von einer CSV-Leseanwendung überprüft werden könnten.
Voll funktionsfähige Demoseiten mit gesammelten realen Bedrohungen finden Sie hier.
Um Maltrail ordnungsgemäß auszuführen, ist Python 2.6 , 2.7 oder 3.x auf einem *nix/BSD-System zusammen mit dem installierten pcapy-ng-Paket erforderlich.
HINWEIS: Die Verwendung von pcapy lib anstelle von pcapy-ng kann zu Fehlfunktionen von Maltrail führen, insbesondere in Python 3.x- Umgebungen. Beispiele.
Die Sensorkomponente erfordert mindestens 1 GB RAM, um im Einzelprozessmodus ausgeführt zu werden, oder mehr, wenn sie im Multiprozessormodus ausgeführt wird, abhängig vom Wert, der für die Option CAPTURE_BUFFER verwendet wird. Darüber hinaus erfordert die Sensorkomponente (im Allgemeinen) Administrator-/Root-Rechte.
Für die Serverkomponente gelten keine besonderen Anforderungen.
Der folgende Befehlssatz sollte Ihren Maltrail -Sensor zum Laufen bringen (standardmäßig mit Standardeinstellungen und Überwachungsschnittstelle „beliebig“):
sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.pysudo zypper install gcc gcc-c++ git libpcap-devel python3-devel python3-pip procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.pyUm den (optionalen) Server auf demselben Computer zu starten, öffnen Sie ein neues Terminal und führen Sie Folgendes aus:
[[ -d maltrail ]] || git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
python server.pyUm zu testen, ob alles funktioniert, führen Sie Folgendes aus:
ping -c 1 136.161.101.53
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logUm die Erfassung des DNS-Verkehrs zu testen, können Sie außerdem Folgendes versuchen:
nslookup morphed.ru
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logUm Sensor- und Serverinstanzen zu stoppen (sofern sie im Hintergrund ausgeführt werden), führen Sie Folgendes aus:
sudo pkill -f sensor.py
pkill -f server.py Greifen Sie auf die Berichtsschnittstelle (z. B. Client ) zu, indem Sie in Ihrem Webbrowser http://127.0.0.1:8338 (Standardanmeldeinformationen: admin:changeme! ) aufrufen:
Die Konfiguration des Sensors finden Sie im Abschnitt [Sensor] der maltrail.conf Datei:
Wenn die Option USE_MULTIPROCESSING auf true gesetzt ist, werden alle CPU-Kerne verwendet. Ein Kern wird nur für die Paketerfassung verwendet (mit entsprechender Affinität, E/A-Priorität und guten Ebeneneinstellungen), während andere Kerne für die Paketverarbeitung verwendet werden. Andernfalls wird alles auf einem einzigen Kern ausgeführt. Die Option USE_FEED_UPDATES kann verwendet werden, um die Trail-Updates von Feeds vollständig zu deaktivieren (und nur die bereitgestellten statischen zu verwenden). Die Option UPDATE_PERIOD enthält die Anzahl der Sekunden zwischen jeder automatischen Trail-Aktualisierung (Hinweis: Der Standardwert ist auf 86400 (dh einen Tag) eingestellt), indem Definitionen im trails -Verzeichnis verwendet werden (Hinweis: Sowohl Sensor als auch Server kümmern sich um die Trail-Aktualisierung). Die Option CUSTOM_TRAILS_DIR kann vom Benutzer verwendet werden, um den Speicherort des Verzeichnisses anzugeben, das die benutzerdefinierten Trails-Dateien ( *.txt ) enthält.
Die Option USE_HEURISTICS aktiviert heuristische Mechanismen (z. B. long domain name (suspicious) , excessive no such domain name (suspicious) , direct .exe download (suspicious) usw.), was möglicherweise zu Fehlalarmen führt. Die Option CAPTURE_BUFFER stellt einen Gesamtspeicher (in Bytes als Prozentsatz des gesamten physischen Speichers) dar, der im Multiprocessing-Modus zum Speichern der Paketerfassung in einem Ringpuffer zur weiteren Verarbeitung durch nicht erfassende Prozesse verwendet werden soll. Die Option MONITOR_INTERFACE sollte den Namen der erfassenden Schnittstelle enthalten. Verwenden Sie den Wert any um von allen Schnittstellen zu erfassen (sofern das Betriebssystem dies unterstützt). Die Option CAPTURE_FILTER sollte den Netzwerkerfassungsfilter ( tcpdump ) enthalten, um uninteressante Pakete zu überspringen und den Erfassungsprozess zu vereinfachen. Die Option SENSOR_NAME enthält den Namen, der im Wert sensor_name des Ereignisses erscheinen sollte, damit das Ereignis eines Sensors vom anderen unterschieden werden kann. Wenn die Option LOG_SERVER festgelegt ist, werden alle Ereignisse remote an den Server gesendet. Andernfalls werden sie direkt im Protokollierungsverzeichnis gespeichert, das mit der Option LOG_DIR festgelegt wurde und im Abschnitt [All] der Datei maltrail.conf zu finden ist. Falls die Option UPDATE_SERVER gesetzt ist, werden alle Trails vom angegebenen Speicherort abgerufen, andernfalls werden sie von Trail-Definitionen aktualisiert, die sich innerhalb der Installation selbst befinden.
Die Optionen SYSLOG_SERVER und/oder LOGSTASH_SERVER können verwendet werden, um Sensorereignisse (dh Protokolldaten) an Nicht-Maltrail-Server zu senden. Im Fall von SYSLOG_SERVER werden Ereignisdaten im CEF-Format ( Common Event Format ) an den UDP-Dienst (z. B. Syslog) gesendet, der an der angegebenen Adresse lauscht (z. B. 192.168.2.107:514 ), während im Fall von LOGSTASH_SERVER Ereignisdaten gesendet werden JSON-Format zum UDP-Dienst (z. B. Logstash), der an der angegebenen Adresse lauscht (z. B 192.168.2.107:5000 ).
Beispiel für das Senden von Ereignisdaten über UDP ist wie folgt:
SYSLOG_SERVER (Hinweis: LogSeverity Werte sind 0 (für niedrig), 1 (für mittel) und 2 (für hoch)): Dec 24 15:05:55 beast CEF:0|Maltrail|sensor|0.27.68|2020-12-24|andromeda (malware)|2|src=192.168.5.137 spt=60453 dst=8.8.8.8 dpt=53 trail=morphed.ru ref=(static)
LOGSTASH_SERVER : {"timestamp": 1608818692, "sensor": "beast", "severity": "high", "src_ip": "192.168.5.137", "src_port": 48949, "dst_ip": "8.8.8.8", "dst_port": 53, "proto": "UDP", "type": "DNS", "trail": "morphed.ru", "info": "andromeda (malware)", "reference": "(static)"}
Wenn der Sensor (z. B. sudo python sensor.py ) zum ersten Mal ausgeführt wird und/oder nachdem er längere Zeit nicht ausgeführt wurde, werden die Trails automatisch aus den Trail-Definitionen aktualisiert (Hinweis: im trails -Verzeichnis gespeichert). Nach der Initialisierung beginnt es mit der Überwachung der konfigurierten Schnittstelle (Option MONITOR_INTERFACE in maltrail.conf ) und schreibt die Ereignisse entweder in das konfigurierte Protokollverzeichnis (Option LOG_DIR im Abschnitt [All] der Datei maltrail.conf ) oder sendet sie remote an die Protokollierungs-/ Berichtsserver (Option LOG_SERVER ).
Erkannte Ereignisse werden im Protokollierungsverzeichnis des Servers (dh Option LOG_DIR im Abschnitt [All] der maltrail.conf -Datei) im leicht lesbaren CSV-Format (Hinweis: Leerzeichen „“ wird als Trennzeichen verwendet) als einzeilige Einträge gespeichert bestehend aus: time sensor src_ip src_port dst_ip proto trail_type trail trail_info reference (z. B. "2015-10-19 15:48:41.152513" beast 192.168.5.33 32985 8.8.8.8 53 UDP DNS 0000mps.webpreview.dsl.net malicious siteinspector.comodo.com dst_port "2015-10-19 15:48:41.152513" beast 192.168.5.33 32985 8.8.8.8 53 UDP DNS 0000mps.webpreview.dsl.net malicious siteinspector.comodo.com ):
Die Serverkonfiguration finden Sie im maltrail.conf -Abschnitt [Server] :
Die Option HTTP_ADDRESS enthält die Abhöradresse des Webservers (Hinweis: Verwenden Sie 0.0.0.0 , um alle Schnittstellen abzuhören). Die Option HTTP_PORT enthält den Listening-Port des Webservers. Der Standard-Abhörport ist auf 8338 eingestellt. Wenn die Option USE_SSL auf true gesetzt ist, wird SSL/TLS für den Zugriff auf den Webserver verwendet (z. B. https://192.168.6.10:8338/ ). In diesem Fall sollte die Option SSL_PEM auf die private/zertifizierte PEM-Datei des Servers verweisen.
Der Unterabschnitt USERS enthält die Konfigurationseinstellungen des Benutzers. Jeder Benutzereintrag besteht aus username:sha256(password):UID:filter_netmask(s) . Der Wert UID stellt die eindeutige Benutzerkennung dar. Es wird empfohlen, für Administratorkonten Werte unter 1000 und für nichtadministrative Konten einen höheren Wert zu verwenden. Der Teil filter_netmask(s) stellt den/die durch Kommas getrennten Hartfilter dar, mit dem/denen die angezeigten Ereignisse je nach Benutzerkonto/-konten gefiltert werden können. Der Standardeintrag lautet wie folgt:
Die Option UDP_ADDRESS enthält die Abhöradresse für die Protokollerfassung des Servers (Hinweis: Verwenden Sie 0.0.0.0 , um alle Schnittstellen abzuhören), während die Option UDP_PORT den Wert des Abhörports enthält. Wenn es aktiviert ist und in Kombination mit der Option LOG_SERVER verwendet wird, kann es für unterschiedliche (mehrere) Sensor <-> Server -Architekturen verwendet werden.
Die Option FAIL2BAN_REGEX enthält den regulären Ausdruck (z. B. attacker|reputation|potential[^"]*(web scan|directory traversal|injection|remote code|iot-malware download|spammer|mass scanner ), der in /fail2ban Webaufrufen zur Extraktion verwendet werden soll Dies ermöglicht die Verwendung von IP-Blockierungsmechanismen (z. B. fail2ban , iptables oder ipset ) durch periodisches Abrufen Eine Beispielverwendung wäre das folgende Skript (z. B. als root Cronjob auf Minutenbasis ausführen):
#! /bin/bash
ipset -q flush maltrail
ipset -q create maltrail hash:net
for ip in $( curl http://127.0.0.1:8338/fail2ban 2> /dev/null | grep -P ' ^[0-9.]+$ ' ) ; do ipset add maltrail $ip ; done
iptables -I INPUT -m set --match-set maltrail src -j DROP Mit der Option BLACKLIST können reguläre Ausdrücke erstellt werden, die auf ein Feld angewendet werden. Für jede Regel lautet die Syntax: <field> <control> <regexp> wobei:
field gibt das Feld an, das kompagiert werden soll. Es kann sein: src_ip , src_port , dst_ip , dst_port , protocol , type , trail oder filter .control kann entweder ~ für Übereinstimmungen oder !~ für „trifft nicht überein“ lautenregexp ist der reguläre Ausdruck, der auf das Feld angewendet werden soll. Verketten Sie eine weitere Regel mit dem Schlüsselwort and (das Schlüsselwort or wird nicht unterstützt, fügen Sie hierfür einfach eine Zeile hinzu). Sie können das Schlüsselwort BLACKLIST allein verwenden oder einen Namen hinzufügen: BLACKLIST_NAME . Im letzteren Fall lautet die URL: /blacklist/name
Im Folgenden wird beispielsweise eine Out-Blacklist für den gesamten Datenverkehr von einer anderen Quelle als 192.168.0.0/16 zum Zielport SSH oder einem mit dem scan übereinstimmenden oder known attacker erstellt
BLACKLIST_OUT
src_ip !~ ^192.168. and dst_port ~ ^22$
src_ip !~ ^192.168. and filter ~ scan
src_ip !~ ^192.168. and filter ~ known attacker
BLACKLIST_IN
src_ip ~ ^192.168. and filter ~ malware
Die Vorgehensweise zum Erstellen einer IPset-Blacklist ist die gleiche (siehe oben), mit der Ausnahme, dass die URLs in unserem Beispiel /blacklist/in und /blacklist/out lauten.
Das Gleiche gilt für Sensor : Wenn der Server (z. B. python server.py ) zum ersten Mal ausgeführt wird und/oder nach einem längeren Zeitraum ohne Ausführung, wenn die Option USE_SERVER_UPDATE_TRAILS auf true gesetzt ist, werden die Trails automatisch aus den Trail-Definitionen aktualisiert ( Hinweis: im trails -Verzeichnis gespeichert). Seine Grundfunktion besteht darin, die Protokolleinträge im Protokollierungsverzeichnis zu speichern (d. h. die Option LOG_DIR im Abschnitt [All] der maltrail.conf -Datei) und die Web-Berichterstellungsschnittstelle bereitzustellen, um dem Endbenutzer dieselben Einträge anzuzeigen (Hinweis: Es gibt keine Sie müssen die Webserverpakete von Drittanbietern wie Apache installieren):
Beim Betreten der Berichtsschnittstelle des Servers (dh über die durch die Optionen HTTP_ADDRESS und HTTP_PORT definierte Adresse) wird dem Benutzer der folgende Authentifizierungsdialog angezeigt. Der Benutzer muss die richtigen Anmeldeinformationen eingeben, die vom Serveradministrator in der Konfigurationsdatei maltrail.conf festgelegt wurden (Hinweis: Die Standardanmeldeinformationen sind admin:changeme! ):
Im Inneren wird dem Benutzer die folgende Berichtsoberfläche angezeigt:
Im oberen Teil befindet sich eine verschiebbare Zeitleiste (Hinweis: Wird aktiviert, nachdem Sie auf die Beschriftung des aktuellen Datums und/oder das Kalendersymbol geklickt haben), in der der Benutzer Protokolle für vergangene Ereignisse auswählen kann (Hinweis: Wenn Sie mit der Maus über das Ereignis fahren, wird eine QuickInfo mit der ungefähren Anzahl aktueller Ereignisse angezeigt Datum). Die Daten werden nach Monaten gruppiert, wobei die Daten für einen Zeitraum von 4 Monaten im Widget selbst angezeigt werden. Mithilfe des bereitgestellten Schiebereglers (z. B. ) kann der Benutzer jedoch problemlos auf Ereignisse früherer Monate zugreifen.
Sobald Sie auf das Datum klicken, sollten alle Ereignisse für dieses bestimmte Datum geladen und im Webbrowser des Kunden dargestellt werden. Abhängig von der Anzahl der Ereignisse und der Geschwindigkeit der Netzwerkverbindung kann das Laden und Anzeigen protokollierter Ereignisse einige Sekunden bis zu mehreren Minuten dauern (z. B. dauern 100.000 Ereignisse insgesamt etwa 5 Sekunden). Während der gesamten Verarbeitungszeit wird der animierte Lader auf der deaktivierten Benutzeroberfläche angezeigt:
Der mittlere Teil enthält eine Zusammenfassung der angezeigten Ereignisse. Das Feld Events stellt die Gesamtzahl der Ereignisse in einem ausgewählten 24-Stunden-Zeitraum dar, wobei die rote Linie IP-basierte Ereignisse, die blaue Linie DNS-basierte Ereignisse und die gelbe Linie URL-basierte Ereignisse darstellt. Das Feld Sources stellt die Anzahl der Ereignisse pro Top-Quelle in Form eines gestapelten Säulendiagramms dar, mit der Gesamtzahl der Quellen oben. Das Feld Threats stellt den Prozentsatz der Top-Bedrohungen in Form eines Kreisdiagramms dar (Hinweis: Der graue Bereich enthält alle Bedrohungen mit jeweils <1 % der Gesamtereignisse) mit der Gesamtzahl der Bedrohungen oben. Das Feld Trails stellt den Prozentsatz der Top-Trails in Form eines Kreisdiagramms dar (Hinweis: Der graue Bereich enthält alle Trails mit jeweils <1 % der Gesamtereignisse), mit der Gesamtzahl der Trails oben. Jedes dieser Felder ist aktiv. Wenn Sie also auf eines dieser Felder klicken, wird eine detailliertere Grafik angezeigt.
Der untere Teil enthält eine komprimierte Darstellung der protokollierten Ereignisse in Form einer paginierten Tabelle. Jeder Eintrag enthält Details zu einer einzelnen Bedrohung (Hinweis: eindeutig identifiziert durch ein Paar (src_ip, trail) oder (dst_ip, trail) , wenn src_ip mit dem trail übereinstimmt, wie bei Angriffen von außen):
Die Spalte threat enthält die eindeutige ID der Bedrohung (z. B. 85fdb08d ) und die Farbe (Hinweis: aus der ID der Bedrohung extrudiert), sensor enthält die Sensornamen, bei denen das Ereignis ausgelöst wurde (z. B. blitvenica ), events enthält die Gesamtzahl der Ereignisse für eine aktuelle Bedrohung , severity enthält den bewerteten Schweregrad der Bedrohung (Hinweis: Berechnet basierend auf Werten in info und reference , wobei der durch Malware generierte Datenverkehr priorisiert wird), first_seen speichert die Zeit des ersten Ereignisses in einem ausgewählten Zeitraum (24 Stunden) (z. B 06th 08:21:54 ), last_seen enthält die Zeit des letzten Ereignisses in einem ausgewählten Zeitraum (24 Stunden) (z. B. 06th 15:21:23 ), sparkline enthält ein kleines Sparkline-Diagramm, das die Aktivität der Bedrohung im ausgewählten Zeitraum darstellt, src_ip enthält Quell-IP(s). ) einer Bedrohung (z. B. 99.102.41.102 ), src_port enthält Quellports (z. B 44556, 44589, 44601 ), dst_ip enthält Ziel-IP(s) (z. B. 213.202.100.28 ), dst_port enthält Ziel-Port(s) (z. B. 80 (HTTP) ), proto enthält Protokoll(e) (z. B. TCP ), trail Holds Ein auf der schwarzen Liste stehender (oder heuristischer) Eintrag, der das/die Ereignis(e) ausgelöst hat. info enthält weitere Informationen über die Bedrohung/Spur (z. B. known attacker ). known attacker für bekannte IP-Adressen des Angreifers oder ipinfo für bekannten IP-Informationsdienst, der häufig von Malware während eines Startvorgangs verwendet wird), enthält reference eine Quelle des auf der schwarzen Liste stehenden Eintrags (z. B. (static) für statische Trails oder myip.ms für einen dynamischen Feed, der von diesem abgerufen wird). Quelle) und tags enthält benutzerdefinierte Tags für einen bestimmten Trail (z. B. APT28 ).
Wenn Sie mit der Maus über die Tabelleneinträge src_ip und dst_ip fahren, wird ein Informations-Tooltip mit detaillierten Reverse-DNS- und WHOIS-Informationen angezeigt (Hinweis: RIPE ist der Informationsanbieter):
Ereignisdetails (z. B. src_port , dst_port , proto usw.), die sich innerhalb desselben Bedrohungseintrags unterscheiden, werden in Form eines Blasensymbols (z. B.) zusammengefasst. Dies wird durchgeführt, um eine nutzbare Berichtsschnittstelle mit möglichst wenigen Zeilen zu erhalten. Wenn Sie mit der Maus über ein solches Symbol fahren, wird ein Informations-Tooltip mit allen gehaltenen Elementen angezeigt (z. B. alle vom attacker gescannten Portnummern):
Wenn Sie auf ein solches Symbol klicken, wird ein neues Dialogfeld geöffnet, das alle gespeicherten Elemente (Hinweis: in ihrer nicht komprimierten Form) enthält und zum Kopieren und Einfügen (d) zur weiteren Analyse bereitsteht:
Wenn Sie den Mauszeiger einige Sekunden lang über die Spur der Bedrohung bewegen, wird ein Rahmen mit Ergebnissen angezeigt, in denen die Spur als Suchbegriff verwendet wird Suche verschlüsseln searX-Suchmaschine. In vielen Fällen liefert dies grundlegende Informationen über die Bedrohung selbst, sodass der Benutzer keine manuelle Suche danach durchführen muss. In der oberen rechten Ecke des geöffneten Rahmenfensters befinden sich zwei zusätzliche Schaltflächen. Durch Klicken auf das erste (z. B. ) wird der resultierende Rahmen im Tab (oder Fenster) des neuen Browsers geöffnet, während durch Klicken auf das zweite (z. B. ) der Rahmen sofort geschlossen wird (Hinweis: Die gleiche Aktion wird durch Verschieben des erreicht Mauszeiger außerhalb der Rahmenränder):
Für jede Bedrohung gibt es ein Spalten tag , das mit beliebigen „Tags“ gefüllt werden kann, um alle Bedrohungen mit derselben Spur genau zu beschreiben. Außerdem ist es eine gute Möglichkeit, Bedrohungen einzeln zu beschreiben, sodass alle Bedrohungen mit demselben Tag (z. B. yahoo ) später gruppiert werden können:
Im folgenden Abschnitt werden einige der „üblichen Verdächtigen“-Szenarien anhand realer Fälle beschrieben.
Massenscans sind ein ziemlich häufiges Phänomen, bei dem sich Einzelpersonen und/oder Organisationen das Recht geben, täglich den gesamten 0.0.0.0/0-IP-Bereich (also das gesamte Internet) zu scannen, mit einem Haftungsausschluss, wenn sie das nicht möchten Dann sollten Sie sie privat kontaktieren, um von zukünftigen Scans ausgeschlossen zu werden.
Erschwerend kommt hinzu, dass Organisationen wie Shodan und ZoomEye alle Ergebnisse über ihre Suchmaschine frei verfügbar machen (für andere potenzielle Angreifer). In den folgenden Screenshots sehen Sie Details zu Shodan-Scans an einem einzigen Tag.
Hier ist eine Reverse-DNS- und WHOIS-Suche der Adresse des „Angreifers“:
Wenn Sie mit dem Mauszeiger über den Inhalt der trail -Spalte (IP-Adresse) fahren, werden Ihnen die Suchergebnisse von searX angezeigt, wo Sie weitere Informationen über den „Angreifer“ finden können:
Wenn Sie über eine große Organisation verfügen, wird Ihnen in der Spalte dst_ip eine große Liste gescannter IP-Adressen angezeigt:
In der Spalte dst_port sehen Sie alle Ports, die durch solche Massenscans gescannt wurden:
In anderen ähnlichen Situationen werden Sie das gleiche Verhalten beobachten, das von einzelnen Angreifern ausgeht, die auf der schwarzen Liste stehen (in diesem Fall von cinsscore.com):
Ein weiteres häufiges Verhalten ist das Scannen des gesamten IP-Bereichs 0.0.0.0/0 (dh des Internets) auf der Suche nach einem bestimmten Port (z. B. TCP-Port 443, wenn Heartbleed gefunden wurde). Im folgenden Screenshot finden Sie einen solchen Fall für zuvor auf der schwarzen Liste stehende Angreifer (in diesem Fall von alienvault.com und zwei anderen schwarzen Listen), die auf der Suche nach falsch konfigurierten VoIP-Geräten den UDP-Port 5060 (d. h. SIP) ins Visier nehmen:
Um die potenziellen Angreifer zu erkennen, die sich hinter dem Tor-Anonymitätsnetzwerk verbergen, nutzt Maltrail öffentlich verfügbare Listen von Tor-Exit-Knoten. Im folgenden Screenshot sehen Sie einen Fall, in dem ein potenzieller Angreifer das Tor-Netzwerk nutzte, um auf verdächtige Weise auf das Webziel (über HTTP) im Bereich unserer Organisation zuzugreifen (insgesamt 171 Verbindungsanfragen in 10 Minuten):
Ein ziemlich ähnlicher Fall wie der vorherige ist, wenn ein zuvor auf der schwarzen Liste stehender Angreifer auf ziemlich verdächtige Weise versucht, auf einen bestimmten (z. B. Nicht-HTTP(s)) Dienst im Bereich unserer Organisation zuzugreifen (d. h. insgesamt 1513 Verbindungsversuche in weniger als 15 Minuten):
Wenn wir den ssh attacker in das Filter eingeben, können wir alle ähnlichen Vorkommnisse für diesen Tag sehen, in diesem Fall jedoch für Port 22 (d. h. SSH):
Bei Verbindungsversuchen von infizierten Computern innerhalb unserer Organisation zu bereits bekannten C&C-Servern können Sie auf Bedrohungen wie die folgenden (in diesem Fall Beebone) stoßen:
Bei DNS-Anfragen mit bekannten DGA-Domänennamen wird die Bedrohung wie folgt angezeigt (in diesem Fall Necurs):
Im folgenden Fall kam es zu Datei-Downloads von auf der schwarzen Liste stehenden URLs (in diesem Fall von Malwarepatrol.net):
Wenn wir den bestimmten Malware-Namen (in diesem Fall Ramnit) in das Filter eingeben, werden nur Bedrohungen herausgefiltert, von denen bekannt ist, dass sie mit dieser Malware in Verbindung stehen (es werden alle betroffenen internen Computer angezeigt):
Allgemeiner gesagt: Wenn wir die malware in das Feld Filter eingeben, werden alle Bedrohungen, die durch Malware-(bezogene) Spuren (z. B. IP Adressen) gefunden wurden, gefiltert in:
Maltrail verwendet die statische Liste der TLD-Domänen, von denen bekannt ist, dass sie häufig an verdächtigen Aktivitäten beteiligt sind. Die meisten dieser TLD-Domains stammen von kostenlosen Domain-Registraren (z. B. Freenom) und sollten daher genauer unter die Lupe genommen werden. Im folgenden Screenshot sehen wir einen Fall, in dem eine solche TLD-Domäne .cm von unbekannter Malware mithilfe des DGA-Algorithmus verwendet wurde, um Kontakt zu ihren C&C-Servern aufzunehmen:
Es gibt auch Fälle, in denen vollkommen gültige TLD-Domänen (z. B. .ru ) für verdächtige Aktivitäten verwendet werden, wie in diesem Fall (z. B. long domain name (suspicious) ), bei denen es sich bei den Domänen offensichtlich um DGA handelt, die von unbekannter Malware generiert wurden:
Maltrail verwendet eine statische Liste sogenannter „dynamischer Domänen“, die häufig bei verdächtigen Aktivitäten verwendet werden (z. B. für Malware-C&C-Server, die häufig die IP-Adressen des Ziels ändern):
Außerdem verwendet Maltrail eine statische Liste von „Zwiebel“-bezogenen Domänen, die auch häufig für verdächtige Aktivitäten verwendet werden (z. B. Malware, die C&C-Server über Tor2Web-Dienste kontaktiert):
Im Falle alter und/oder veralteter Malware, die sich unentdeckt auf den infizierten internen Computern des Unternehmens befindet, kommt es häufig zu einem „Phänomen“, bei dem Malware ständig versucht, ohne DNS-Auflösung Kontakt mit der Domäne des längst nicht mehr genutzten C&C-Servers aufzunehmen. Daher werden diese Art von (potenziellen) Bedrohungen als excessive no such domain (suspicious) :
Für den Fall, dass ein Trail für zu viele Bedrohungen verantwortlich ist (z. B. im Fall gefälschter Quell-IPs wie bei DNS-Amplification-Angriffen), werden alle ähnlichen Bedrohungen unter einer einzigen flood Bedrohung zusammengefasst (Hinweis: Die Bedrohungs-ID wird mit dem Suffix F0 gekennzeichnet). wie im folgenden Beispiel:
Viele Schadprogramme nutzen eine Art ipinfo Dienst (z. B. ipinfo.io), um die Internet-IP-Adresse des Opfers herauszufinden. Bei regelmäßigen Anfragen und insbesondere außerhalb der Bürozeiten sollten solche Anfragen genau überwacht werden, wie im folgenden Beispiel:
Mithilfe des Filters ipinfo können alle potenziell infizierten Computer im Bereich unserer Organisation aufgelistet werden, die dieses verdächtige Verhalten aufweisen:
Maltrail verfolgt alle verdächtigen direkten Datei-Download-Versuche (z. B. .apk , .bin , .class , .chm , .dll , .egg , .exe , .hta , .hwp , .lnk , .ps1 , .scr , .sct , .wbk und .xpi Dateierweiterungen). Dies kann viele Fehlalarme auslösen, könnte aber letztendlich bei der Rekonstruktion der Infektionskette helfen (Hinweis: Seriöse Dienstanbieter wie Google verwenden normalerweise verschlüsseltes HTTPS, um diese Art von Downloads durchzuführen):
Bei verdächtigen Anfragen von externen Webanwendungs-Sicherheitsscannern (z. B. Suche nach Schwachstellen in SQLi, XSS, LFI usw.) und/oder bei böswilligen Versuchen interner Benutzer auf unbekannte Websites können Bedrohungen wie die folgenden gefunden werden (echter Fall von). Angreifer versuchen, die Schwachstellen CVE-2015-7297, CVE-2015-7857 und CVE-2015-7858 im Joomla! CMS auszunutzen):
Im folgenden Beispiel wurde der Schwachstellenscan für Webanwendungen als „verdächtig“ markiert:
Wenn wir für Details auf das Blasensymbol (z. B. ) klicken und den gesamten Inhalt kopieren und in eine Textdatei einfügen, können wir alle verdächtigen HTTP-Anfragen sehen:
Im folgenden Screenshot ist eine Ausführung des beliebten SQLi-Schwachstellentools sqlmap in unseren Protokollen zu finden:
Im Falle zu vieler Verbindungsversuche zu einer beträchtlichen Anzahl verschiedener TCP-Ports warnt Maltrail aufgrund seiner heuristischen Mechanismuserkennung vor einem möglichen Port-Scanning. Im folgenden Screenshot sind solche Warnungen für eine Ausführung des beliebten Port-Scanning-Tools nmap zu finden:
Ein beliebter DDoS-Angriff auf die Infrastruktur des Webservers ist die Erschöpfung der Ressourcen seines (Haupt-)DNS-Servers durch gültige DNS-Rekursionsabfragen für (pseudo)zufällige Subdomänennamen (z. B. abpdrsguvjkyz.www.dedeni.com ):
Verschiedene Programme (insbesondere auf Mobilgeräten) zeigen ein Malware-ähnliches Verhalten, bei dem sie potenziell sensible Daten an entfernte Beacon-Posts senden. Maltrail wird versuchen, ein solches Verhalten wie im folgenden Beispiel zu erfassen:
Wie alle anderen Sicherheitslösungen ist Maltrail anfällig für „falsch positive Ergebnisse“. In solchen Fällen zeichnet Maltrail (insbesondere bei suspicious Bedrohungen) das Verhalten eines normalen Benutzers auf und markiert es als böswillig und/oder verdächtig. Im folgenden Beispiel ist zu sehen, dass ein Blacklist-Feed-Anbieter blocklist.de reguläre Google-Server als attacker markiert hat, was zu folgender Bedrohung führte:
Wenn Sie mit der Maus über den Pfad fahren, zeigt der Rahmen mit den Ergebnissen der SearX-Suche, dass es sich (höchstwahrscheinlich) um einen regulären Google-Server handelt:
Ein weiteres Beispiel: Der Zugriff auf reguläre .work Domains (beliebte TLD für böswillige Zwecke) führte zu der folgenden Bedrohung:
Dennoch sollten Administratoren etwas mehr Zeit investieren und (mit anderen Mitteln) prüfen, ob „verdächtig“ bösartig bedeutet oder nicht, wie im folgenden Beispiel:
Auf Ubuntu/Debian
sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
cd /tmp
git clone --depth 1 https://github.com/stamparm/maltrail.git
sudo mv /tmp/maltrail /opt
sudo chown -R $USER : $USER /opt/maltrailAuf SUSE/openSUSE
sudo zypper install gcc gcc-c++ git libpcap-devel python3-devel python3-pip procps schedtool
sudo pip3 install pcapy-ng
cd /tmp
git clone --depth 1 https://github.com/stamparm/maltrail.git
sudo mv /tmp/maltrail /opt
sudo chown -R $USER : $USER /opt/maltrailArbeitsumgebung einstellen:
sudo mkdir -p /var/log/maltrail
sudo mkdir -p /etc/maltrail
sudo cp /opt/maltrail/maltrail.conf /etc/maltrail
sudo nano /etc/maltrail/maltrail.confLaufumgebung festlegen:
crontab -e # autostart server & periodic update */5 * * * * if [ -n "$(ps -ef | grep -v grep | grep 'server.py')" ]; then : ; else python3 /opt/maltrail/server.py -c /etc/maltrail/maltrail.conf; fi
0 1 * * * cd /opt/maltrail && git pull
sudo crontab -e # autostart sensor & periodic restart */1 * * * * if [ -n "$(ps -ef | grep -v grep | grep 'sensor.py')" ]; then : ; else python3 /opt/maltrail/sensor.py -c /etc/maltrail/maltrail.conf; fi
2 1 * * * /usr/bin/pkill -f maltrail
Als systemd-Dienste aktivieren (nur Linux):
sudo cp /opt/maltrail/maltrail-sensor.service /etc/systemd/system/maltrail-sensor.service
sudo cp /opt/maltrail/maltrail-server.service /etc/systemd/system/maltrail-server.service
sudo systemctl daemon-reload
sudo systemctl start maltrail-server.service
sudo systemctl start maltrail-sensor.service
sudo systemctl enable maltrail-server.service
sudo systemctl enable maltrail-sensor.service
systemctl status maltrail-server.service && systemctl status maltrail-sensor.service
Hinweis : /maltrail-sensor.service kann als dedizierter Dienst ohne vorab gestarteten /maltrail-server.service gestartet werden. Dies ist nützlich, wenn /maltrail-server.service auf einem anderen Computer in Ihrer Netzwerkumgebung installiert ist und funktioniert.
Diese Software wird unter einer MIT-Lizenz bereitgestellt. Weitere Informationen finden Sie in der beiliegenden LICENSE-Datei.
1 (Nur) Trails nutzen
2 Verbindung zu Wanderwegen (nur)
