maltrail
0.76
Maltrail est un système de détection de trafic malveillant, utilisant des listes (noires) accessibles au public contenant des traces malveillantes et/ou généralement suspectes, ainsi que des traces statiques compilées à partir de divers rapports AV et de listes personnalisées définies par l'utilisateur, où la trace peut être n'importe quoi depuis un nom de domaine (par exemple zvpprsensinaix.com pour les logiciels malveillants Banjori), URL (par exemple hXXp://109.162.38.120/harsh02.exe pour un exécutable malveillant connu), adresse IP (par exemple 185.130.5.231 pour un attaquant connu) ou la valeur d'en-tête HTTP User-Agent (par exemple sqlmap pour l'outil d'injection SQL automatique et de prise de contrôle de base de données). En outre, il utilise (facultatif) des mécanismes heuristiques avancés qui peuvent aider à découvrir des menaces inconnues (par exemple de nouveaux logiciels malveillants).
Les listes (noires) (c'est-à-dire les flux) suivantes sont utilisées :
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.
À partir des entrées statiques, les traces des entités malveillantes suivantes (par exemple, les C&C de logiciels malveillants ou les gouffres) ont été incluses manuellement (à partir de divers rapports antivirus et recherches personnelles) :
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 est basé sur l'architecture Traffic -> Sensor <-> Server <-> Client . Le ou les capteurs sont un composant autonome exécuté sur le nœud de surveillance (par exemple, une plate-forme Linux connectée passivement au port SPAN/miroir ou en ligne de manière transparente sur un pont Linux) ou sur la machine autonome (par exemple Honeypot) où il « surveille » le trafic qui passe. pour les éléments/pistes sur liste noire (c'est-à-dire les noms de domaine, les URL et/ou les IP). En cas de correspondance positive, il envoie les détails de l'événement au serveur (central) où ils sont stockés dans le répertoire de journalisation approprié (c'est-à-dire LOG_DIR décrit dans la section Configuration ). Si Sensor est exécuté sur la même machine que le serveur (configuration par défaut), les journaux sont stockés directement dans le répertoire de journalisation local. Sinon, ils sont envoyés via des messages UDP au serveur distant (c'est-à-dire LOG_SERVER décrit dans la section Configuration ).
Le rôle principal du serveur est de stocker les détails de l'événement et de fournir un support back-end pour l'application Web de reporting. Dans la configuration par défaut, le serveur et le capteur fonctionneront sur la même machine. Ainsi, pour éviter d'éventuelles perturbations dans les activités des capteurs, la partie reporting frontal est basée sur l'architecture « Fat Client » (c'est-à-dire que tout le post-traitement des données est effectué dans l'instance de navigateur Web du client). Les événements (c'est-à-dire les entrées de journal) pour la période choisie (24h) sont transférés au Client , où l'application Web de reporting est seule responsable de la partie présentation. Les données sont envoyées au client sous forme de blocs compressés, où elles sont traitées séquentiellement. Le rapport final est créé sous une forme très condensée, permettant pratiquement la présentation d'un nombre pratiquement illimité d'événements.
Remarque : le composant serveur peut être complètement ignoré et utiliser simplement le Sensor autonome. Dans ce cas, tous les événements seraient stockés dans le répertoire de journalisation local, tandis que les entrées du journal pourraient être examinées manuellement ou par une application de lecture CSV.
Des pages de démonstration entièrement fonctionnelles avec des menaces réelles collectées peuvent être trouvées ici.
Pour exécuter Maltrail correctement, Python 2.6 , 2.7 ou 3.x est requis sur le système *nix/BSD, ainsi que le package pcapy-ng installé.
REMARQUE : L'utilisation de pcapy lib au lieu de pcapy-ng peut entraîner un fonctionnement incorrect de Maltrail, en particulier sur les environnements Python 3.x. Exemples.
Le composant capteur nécessite au moins 1 Go de RAM pour s'exécuter en mode mono-processus ou plus s'il est exécuté en mode multitraitement, en fonction de la valeur utilisée pour l'option CAPTURE_BUFFER . De plus, le composant Sensor (dans le cas général) nécessite des privilèges administratifs/root.
Le composant serveur n'a pas d'exigences particulières.
L'ensemble de commandes suivant devrait permettre à votre capteur Maltrail d'être opérationnel (prêt à l'emploi avec les paramètres par défaut et l'interface de surveillance "n'importe laquelle") :
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.pyPour démarrer le serveur (facultatif) sur la même machine, ouvrez un nouveau terminal et exécutez ce qui suit :
[[ -d maltrail ]] || git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
python server.pyPour tester que tout est opérationnel, exécutez ce qui suit :
ping -c 1 136.161.101.53
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logDe plus, pour tester la capture du trafic DNS, vous pouvez essayer ce qui suit :
nslookup morphed.ru
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logPour arrêter les instances de capteur et de serveur (si elles sont exécutées en arrière-plan), exécutez ce qui suit :
sudo pkill -f sensor.py
pkill -f server.py Accédez à l'interface de reporting (c'est-à-dire Client ) en visitant le http://127.0.0.1:8338 (informations d'identification par défaut : admin:changeme! ) depuis votre navigateur Web :
La configuration du capteur se trouve dans la section [Sensor] du fichier maltrail.conf :
Si l'option USE_MULTIPROCESSING est définie sur true , alors tous les cœurs de processeur seront utilisés. Un cœur sera utilisé uniquement pour la capture de paquets (avec une affinité appropriée, une priorité d'E/S et des paramètres de niveau agréables), tandis que les autres cœurs seront utilisés pour le traitement des paquets. Sinon, tout fonctionnera sur un seul cœur. L'option USE_FEED_UPDATES peut être utilisée pour désactiver complètement les mises à jour de suivi des flux (et utiliser simplement celles statiques fournies). L'option UPDATE_PERIOD contient le nombre de secondes entre chaque mise à jour automatique des sentiers (Remarque : la valeur par défaut est définie sur 86400 (c'est-à-dire un jour)) en utilisant les définitions du répertoire trails (Remarque : le capteur et le serveur s'occupent tous deux de la mise à jour des sentiers). L'option CUSTOM_TRAILS_DIR peut être utilisée par l'utilisateur pour fournir l'emplacement du répertoire contenant les fichiers de sentiers personnalisés ( *.txt ).
L'option USE_HEURISTICS active des mécanismes heuristiques (par exemple long domain name (suspicious) , excessive no such domain name (suspicious) , direct .exe download (suspicious) , etc.), introduisant potentiellement des faux positifs. L'option CAPTURE_BUFFER présente une mémoire totale (en octets de pourcentage de la mémoire physique totale) à utiliser en cas de mode multitraitement pour stocker la capture de paquets dans un tampon en anneau pour un traitement ultérieur par des processus sans capture. L'option MONITOR_INTERFACE doit contenir le nom de l'interface de capture. Utilisez la valeur any pour capturer à partir de toutes les interfaces (si le système d'exploitation le prend en charge). L'option CAPTURE_FILTER doit contenir le filtre de capture réseau ( tcpdump ) pour ignorer les paquets inintéressants et faciliter le processus de capture. L'option SENSOR_NAME contient le nom qui doit apparaître dans la valeur sensor_name des événements, afin que l'événement d'un capteur puisse être distingué de l'autre. Si l'option LOG_SERVER est définie, alors tous les événements sont envoyés à distance au Server , sinon ils sont stockés directement dans le répertoire de journalisation défini avec l'option LOG_DIR , qui se trouve dans la section [All] du fichier maltrail.conf . Dans le cas où l'option UPDATE_SERVER est définie, alors tous les sentiers sont extraits de l'emplacement donné, sinon ils sont mis à jour à partir des définitions de sentiers situées à l'intérieur de l'installation elle-même.
Les options SYSLOG_SERVER et/ou LOGSTASH_SERVER peuvent être utilisées pour envoyer des événements de capteur (c'est-à-dire des données de journal) à des serveurs non Maltrail. Dans le cas de SYSLOG_SERVER , les données d'événement seront envoyées au format CEF ( Common Event Format ) au service UDP (par exemple Syslog) qui écoute à l'adresse indiquée (par exemple 192.168.2.107:514 ), tandis que dans le cas de LOGSTASH_SERVER les données d'événement seront envoyées Format JSON vers le service UDP (par exemple Logstash) écoutant à l'adresse donnée (par exemple 192.168.2.107:5000 ).
Voici un exemple de données d'événement envoyées via UDP :
SYSLOG_SERVER (Remarque : les valeurs LogSeverity sont 0 (pour faible), 1 (pour moyen) et 2 (pour élevé)) : 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)"}
Lors de l'exécution du capteur (par exemple sudo python sensor.py ) pour la première fois et/ou après une longue période d'inexécution, il mettra automatiquement à jour les sentiers à partir des définitions de sentiers (Remarque : stockés dans le répertoire trails ). Après l'initialisation, il commencera à surveiller l'interface configurée (option MONITOR_INTERFACE dans maltrail.conf ) et écrira les événements soit dans le répertoire de journaux configuré (option LOG_DIR dans la section [All] du fichier maltrail.conf ), soit les enverra à distance au serveur de journalisation/reporting (option LOG_SERVER ).
Les événements détectés sont stockés dans le répertoire de journalisation du serveur (c'est-à-dire l'option LOG_DIR dans la section [All] du fichier maltrail.conf ) au format CSV facile à lire (Remarque : l'espace « » est utilisé comme délimiteur) sous forme d'entrées sur une seule ligne. composé de : sensor time src_ip src_port dst_ip dst_port proto trail_type trail reference trail_info (par exemple "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 ) :
La configuration du serveur se trouve dans la section maltrail.conf [Server] :
L'option HTTP_ADDRESS contient l'adresse d'écoute du serveur web (Remarque : utilisez 0.0.0.0 pour écouter sur toutes les interfaces). L'option HTTP_PORT contient le port d'écoute du serveur Web. Le port d'écoute par défaut est défini sur 8338 . Si l'option USE_SSL est définie sur true alors SSL/TLS sera utilisé pour accéder au serveur Web (par exemple https://192.168.6.10:8338/ ). Dans ce cas, l'option SSL_PEM doit pointer vers le fichier PEM privé/certifié du serveur.
La sous-section USERS contient les paramètres de configuration de l'utilisateur. Chaque entrée utilisateur se compose du username:sha256(password):UID:filter_netmask(s) . La valeur UID représente l'identifiant unique de l'utilisateur, où il est recommandé d'utiliser des valeurs inférieures à 1 000 pour les comptes administratifs, tandis qu'une valeur plus élevée pour les comptes non administratifs. La partie filter_netmask(s) représente le(s) filtre(s) dur(s) délimité(s) par des virgules qui peuvent être utilisés pour filtrer les événements affichés en fonction du(des) compte(s) utilisateur. L'entrée par défaut est la suivante :
L'option UDP_ADDRESS contient l'adresse d'écoute de collecte des journaux du serveur (Remarque : utilisez 0.0.0.0 pour écouter sur toutes les interfaces), tandis que l'option UDP_PORT contient la valeur du port d'écoute. S'il est activé, lorsqu'il est utilisé en combinaison avec l'option LOG_SERVER , il peut être utilisé pour une architecture Sensor <-> Server distincte (plusieurs).
L'option FAIL2BAN_REGEX contient l'expression régulière (par exemple attacker|reputation|potential[^"]*(web scan|directory traversal|injection|remote code|iot-malware download|spammer|mass scanner ) à utiliser dans les appels Web /fail2ban pour l'extraction des adresses IP sources des attaquants actuels. Cela permet d'utiliser des mécanismes de blocage d'adresses IP (par exemple fail2ban , iptables ou ipset ) en extrayant périodiquement les adresses IP sur liste noire. adresses à partir d'un emplacement distant. Un exemple d'utilisation serait le script suivant (par exemple, exécuté en tant que tâche cron root toutes les minutes) :
#! /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 L'option BLACKLIST permet de construire des expressions régulières à appliquer sur un champ. Pour chaque règle, la syntaxe est : <field> <control> <regexp> où :
field indique le champ à compiler, il peut être : src_ip , src_port , dst_ip , dst_port , protocol , type , trail ou filter .control peut être soit ~ pour les correspondances , soit !~ pour les correspondancesregexp est l'expression régulière à appliquer au champ. Enchaînez une autre règle avec le mot-clé and (le mot-clé or n'est pas pris en charge, ajoutez simplement une ligne pour cela). Vous pouvez utiliser le mot clé BLACKLIST seul ou ajouter un nom : BLACKLIST_NAME . Dans ce dernier cas, l'url sera : /blacklist/name
Par exemple, ce qui suit créera une liste noire pour tout le trafic provenant d'une autre source que 192.168.0.0/16 vers le port de destination SSH ou correspondant à l' scan des filtres ou known attacker
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
La manière de créer une liste noire ipset est la même (voir ci-dessus), sauf que les URL seront /blacklist/in et /blacklist/out dans notre exemple.
Comme pour Sensor , lors de l'exécution du serveur (par exemple python server.py ) pour la première fois et/ou après une période d'inexécution plus longue, si l'option USE_SERVER_UPDATE_TRAILS est définie sur true , elle mettra automatiquement à jour les pistes à partir des définitions de piste ( Remarque : stocké dans le répertoire trails ). Sa fonction de base est de stocker les entrées du journal dans le répertoire de journalisation (c'est-à-dire l'option LOG_DIR dans la section [All] du fichier maltrail.conf ) et de fournir l'interface de reporting Web pour présenter ces mêmes entrées à l'utilisateur final (Remarque : il n'y a pas vous devez installer les packages de serveur Web tiers comme Apache) :
En entrant dans l'interface de reporting du serveur (c'est-à-dire via l'adresse définie par les options HTTP_ADDRESS et HTTP_PORT ), l'utilisateur se verra présenter la boîte de dialogue d'authentification suivante. L'utilisateur doit saisir les informations d'identification appropriées qui ont été définies par l'administrateur du serveur dans le fichier de configuration maltrail.conf (Remarque : les informations d'identification par défaut sont admin:changeme! ) :
Une fois à l'intérieur, l'utilisateur se verra présenter l'interface de rapport suivante :
La partie supérieure contient une chronologie coulissante (Remarque : activée après avoir cliqué sur l'étiquette de la date actuelle et/ou l'icône du calendrier) où l'utilisateur peut sélectionner les journaux des événements passés (Remarque : le survol de l'événement déclenchera l'affichage d'une info-bulle avec le nombre approximatif d'événements pour l'événement actuel. date). Les dates sont regroupées par mois, où des données sur une période de 4 mois sont affichées dans le widget lui-même. Cependant, en utilisant le curseur fourni (c'est-à-dire), l'utilisateur peut facilement accéder aux événements des mois précédents.
Une fois que vous avez cliqué sur la date, tous les événements de cette date particulière doivent être chargés et représentés par le navigateur Web du client. En fonction du nombre d'événements et de la vitesse de connexion réseau, le chargement et l'affichage des événements enregistrés peuvent prendre de quelques secondes à plusieurs minutes (par exemple, 100 000 événements prennent environ 5 secondes au total). Pendant tout le temps de traitement, un chargeur animé sera affiché sur l'interface utilisateur désactivée :
La partie centrale contient un résumé des événements affichés. La zone Events représente le nombre total d'événements sur une période de 24 heures sélectionnée, où la ligne rouge représente les événements basés sur IP, la ligne bleue représente les événements basés sur DNS et la ligne jaune représente les événements basés sur URL. La zone Sources représente le nombre d’événements par principales sources sous la forme d’un histogramme empilé, avec le nombre total de sources en haut. La zone Threats représente le pourcentage des principales menaces sous la forme d'un diagramme circulaire (Remarque : la zone grise contient toutes les menaces ayant chacune <1 % du total des événements), avec le nombre total de menaces en haut. La zone Trails représente le pourcentage des meilleurs sentiers sous la forme d'un diagramme circulaire (Remarque : la zone grise contient tous les sentiers ayant chacun <1 % du total des événements), avec le nombre total de sentiers en haut. Chacune de ces cases est active, donc le clic sur l'une d'entre elles entraînera un graphique plus détaillé.
La partie inférieure contient une représentation condensée des événements enregistrés sous la forme d'un tableau paginé. Chaque entrée contient les détails d'une seule menace (Remarque : identifiée de manière unique par une paire (src_ip, trail) ou (dst_ip, trail) si le src_ip est le même que le trail comme en cas d'attaques venant de l'extérieur) :
La colonne threat contient l'ID unique de la menace (par exemple 85fdb08d ) et sa couleur (Remarque : extrudée à partir de l'ID de la menace), sensor contient le(s) nom(s) du capteur où l'événement a été déclenché (par exemple blitvenica ), events contiennent le nombre total d'événements pour une menace actuelle. , severity contient la gravité évaluée de la menace (Remarque : calculée sur la base des valeurs des colonnes info et reference , en donnant la priorité au trafic généré par les logiciels malveillants), first_seen contient l'heure du premier événement au cours d'une période sélectionnée (24 h) (par exemple 06th 08:21:54 ), last_seen contient l'heure du dernier événement dans une période sélectionnée (24h) (par exemple 06th 15:21:23 ), sparkline contient un petit graphique sparkline représentant l'activité de la menace au cours de la période sélectionnée, src_ip contient les IP sources ) d'une menace (par exemple 99.102.41.102 ), src_port contient le(s) port(s) source (par exemple 44556, 44589, 44601 ), dst_ip contient les IP de destination (par exemple 213.202.100.28 ), dst_port contient le(s) port(s) de destination (par exemple 80 (HTTP) ), proto contient le(s) protocole(s), (par exemple TCP ), trail contient une entrée sur liste noire (ou heuristique) qui a déclenché le ou les événements, info contiennent plus d'informations sur la menace/la piste (par exemple known attacker pour les adresses IP connues de l'attaquant ou ipinfo pour le service d'informations IP connu couramment utilisé par les logiciels malveillants lors d'un démarrage), reference contient une source de l'entrée sur liste noire (par exemple (static) pour les pistes statiques ou myip.ms pour un flux dynamique récupéré à partir de cette même source) et tags contient les balises définies par l'utilisateur pour un sentier donné (par exemple APT28 ).
Lorsque vous déplacez la souris sur les entrées des tables src_ip et dst_ip , une info-bulle d'informations s'affiche avec des informations DNS inversées et WHOIS détaillées (Remarque : RIPE est le fournisseur d'informations) :
Les détails de l'événement (par exemple src_port , dst_port , proto , etc.) qui diffèrent au sein d'une même entrée de menace sont condensés sous la forme d'une icône en forme de bulle (c'est-à-dire ). Ceci est effectué pour obtenir une interface de reporting utilisable avec le moins de lignes possible. Déplacer la souris sur cette icône entraînera l'affichage d'une info-bulle d'information avec tous les éléments détenus (par exemple, tous les numéros de port analysés par attacker ) :
Cliquer sur l'une de ces icônes ouvrira une nouvelle boîte de dialogue contenant tous les éléments stockés (Remarque : sous leur forme non condensée) prêts à être copiés-collés (d) pour une analyse plus approfondie :
Lorsque vous passez le pointeur de la souris sur la trace de la menace pendant quelques secondes, un cadre composé de résultats utilisant la trace comme terme de recherche apparaîtra. Rechercher Chiffrer Moteur de recherche SearchX. Dans de nombreux cas, cela fournit des informations de base sur la menace elle-même, éliminant ainsi le besoin pour l'utilisateur d'effectuer une recherche manuelle. Dans le coin supérieur droit de la fenêtre frame ouverte se trouvent deux boutons supplémentaires. En cliquant sur le premier (c'est-à-dire ), le cadre résultant sera ouvert dans le nouvel onglet (ou fenêtre) du navigateur, tandis qu'en cliquant sur le second (c'est-à-dire ), le cadre sera immédiatement fermé (Remarque : la même action est obtenue en déplaçant le pointeur de la souris en dehors des bordures du cadre) :
Pour chaque menace, il existe une tag de colonne qui peut être remplie de « balises » arbitraires pour décrire précisément toutes les menaces partageant la même piste. C'est également un excellent moyen de décrire les menaces individuellement, de sorte que toutes les menaces partageant la même balise (par exemple yahoo ) puissent être regroupées ultérieurement :
Dans la section suivante, certains des scénarios des « suspects habituels » seront décrits à travers des cas réels.
Les analyses de masse sont un phénomène assez courant dans lequel des individus et/ou des organisations s'accordent le droit d'analyser quotidiennement l'ensemble de la plage IP 0.0.0.0/0 (c'est-à-dire l'intégralité d'Internet), avec une clause de non-responsabilité indiquant que si vous n'aimez pas alors vous devez les contacter en privé pour être ignoré des futures analyses.
Pour aggraver les choses, des organisations comme Shodan et ZoomEye mettent tous les résultats gratuitement à la disposition (à d'autres attaquants potentiels) via leur moteur de recherche. Dans les captures d'écran suivantes, vous verrez les détails des analyses Shodan en une seule journée.
Voici une recherche DNS et WHOIS inversée de l'adresse de « l'attaquant » :
Lorsque vous passez le pointeur de la souris sur le contenu de la colonne trail (adresse IP), les résultats de recherche de searX vous seront présentés où vous pourrez trouver plus d'informations sur « l'attaquant » :
Dans la colonne dst_ip , si vous avez une grande organisation, une grande liste d'adresses IP analysées vous sera présentée :
Dans la colonne dst_port vous pourrez voir tous les ports qui ont été analysés par de telles analyses de masse :
Dans d'autres situations similaires, vous constaterez le même comportement, provenant d'un ou plusieurs attaquants individuels figurant sur la liste noire (dans ce cas, par cinsscore.com) :
Un comportement plus courant consiste à analyser toute la plage IP 0.0.0.0/0 (c'est-à-dire Internet) à la recherche d'un port particulier (par exemple le port TCP 443 lorsque Heartbleed a été trouvé). Dans la capture d'écran suivante, vous trouverez un cas similaire pour des attaquants précédemment inscrits sur la liste noire (dans ce cas par alienvault.com et deux autres listes noires) ciblant le port UDP 5060 (c'est-à-dire SIP) à la recherche d'appareils VoIP mal configurés :
Pour repérer les attaquants potentiels cachés derrière le réseau d'anonymat Tor, Maltrail utilise des listes accessibles au public de nœuds de sortie Tor. Dans la capture d'écran suivante, vous verrez un cas où un attaquant potentiel a utilisé le réseau Tor pour accéder de manière suspecte à la cible Web (via HTTP) dans la zone de notre organisation (total 171 demandes de connexion en 10 minutes) :
Un cas assez similaire au précédent se produit lorsqu'un attaquant précédemment mis sur liste noire tente d'accéder à un service particulier (par exemple non HTTP(s)) dans la portée de notre organisation de manière plutôt suspecte (c'est-à-dire un total de 1 513 tentatives de connexion en moins de 15 minutes) :
Si nous entrons l' ssh attacker dans le champ Filter , nous pourrons voir toutes les occurrences similaires pour cette journée, mais dans ce cas pour le port 22 (c'est-à-dire SSH) :
En cas de tentatives de connexion provenant d'ordinateurs infectés au sein de notre organisation vers des serveurs C&C déjà connus, vous pourrez trouver des menaces similaires aux suivantes (dans ce cas Beebone) :
Dans le cas de requêtes DNS contenant des noms de domaine DGA connus, la menace sera affichée comme (dans ce cas Necurs) :
Dans le cas suivant, des téléchargements de fichiers à partir d'URL sur liste noire (dans ce cas par malwarepatrol.net) ont eu lieu :
Si nous saisissons le nom du malware particulier (dans ce cas Ramnit) dans le champ Filter , seules les menaces connues pour être liées à ce malware seront filtrées (vous montrant tous les ordinateurs internes concernés) :
Plus généralement, si nous saisissons le malware dans le champ Filter , toutes les menaces trouvées par les traces de malware (liées) (par exemple les adresses IP ) seront filtrées dans :
Maltrail utilise la liste statique des domaines TLD connus pour être couramment impliqués dans des activités suspectes. La plupart de ces domaines TLD proviennent de bureaux d'enregistrement de domaines gratuits (par exemple Freenom), ils devraient donc faire l'objet d'un examen plus approfondi. Dans la capture d'écran suivante, nous pouvons trouver un cas où l'un de ces domaines TLD .cm a été utilisé par un logiciel malveillant inconnu utilisant l'algorithme DGA pour contacter son(ses) serveur(s) C&C :
Il existe également des cas où des domaines TLD parfaitement valides (par exemple .ru ) sont utilisés pour des activités suspectes, comme dans ce cas (par exemple long domain name (suspicious) ) où les domaines sont évidemment des DGA générés par des logiciels malveillants inconnus :
Maltrail utilise une liste statique de « domaines dynamiques » qui sont souvent utilisés dans des activités suspectes (par exemple pour les serveurs C&C de logiciels malveillants qui modifient souvent les adresses IP de destination) :
En outre, Maltrail utilise une liste statique de domaines liés à « l'oignon » qui sont également souvent utilisés dans des activités suspectes (par exemple, des logiciels malveillants contactant les serveurs C&C en utilisant le(s) service(s) Tor2Web) :
Dans le cas de logiciels malveillants anciens et/ou obsolètes qui ne sont pas détectés sur les ordinateurs internes infectés de l'organisation, il existe souvent un « phénomène » où le logiciel malveillant tente continuellement de contacter le domaine du serveur C&C mort depuis longtemps sans aucune résolution DNS. Par conséquent, ce type de menaces (potentielles) sera marqué comme excessive no such domain (suspicious) :
Dans le cas où une piste est responsable de trop de menaces (par exemple dans le cas de fausses adresses IP sources comme dans les attaques par amplification DNS), toutes les menaces similaires seront regroupées sous une seule menace flood (Remarque : l'ID de la menace sera marqué du suffixe F0 ), comme dans l'exemple suivant :
De nombreux logiciels malveillants utilisent une sorte de service ipinfo (par exemple ipinfo.io) pour connaître l'adresse IP Internet de la victime. En cas d'horaires réguliers et surtout en dehors des heures de bureau, ce type de demandes doit être étroitement surveillé, comme dans l'exemple suivant :
En utilisant le filtre ipinfo tous les ordinateurs potentiellement infectés de la gamme de notre organisation peuvent être répertoriés et partagent ce type de comportement suspect :
Maltrail suit toutes les tentatives suspectes de téléchargement direct de fichiers (par exemple .apk , .bin , .class , .chm , .dll , .egg , .exe , .hta , .hwp , .lnk , .ps1 , .scr , .sct , .wbk et extensions de fichiers .xpi ). Cela peut déclencher de nombreux faux positifs, mais pourrait éventuellement aider à reconstituer la chaîne d'infection (Remarque : les fournisseurs de services légitimes, comme Google, utilisent généralement HTTPS crypté pour effectuer ce type de téléchargements) :
En cas de requêtes suspectes provenant d'analyseurs de sécurité d'applications Web externes (par exemple, recherche de vulnérabilités SQLi, XSS, LFI, etc.) et/ou de tentatives malveillantes d'un utilisateur interne vers des sites Web inconnus, des menaces telles que celles-ci pourraient être trouvées (cas réel de attaquants essayant d'exploiter les vulnérabilités CVE-2015-7297, CVE-2015-7857 et CVE-2015-7858 du CMS Joomla :
Dans l'exemple suivant, l'analyse des vulnérabilités des applications Web a été marquée comme « suspecte » :
Si nous cliquons sur l'icône en forme de bulle (c'est-à-dire ) pour plus de détails et copions-collons tout le contenu dans un fichier texte, nous pourrons voir toutes les requêtes HTTP suspectes :
Dans la capture d'écran suivante, une exécution de l'outil de vulnérabilité SQLi populaire sqlmap peut être trouvée dans nos journaux :
En cas de trop nombreuses tentatives de connexion vers un nombre considérable de ports TCP différents, Maltrail avertira de l'analyse potentielle des ports, grâce à son mécanisme heuristique de détection. Dans la capture d'écran suivante, de tels avertissements peuvent être trouvés pour une exécution de l'outil d'analyse de port populaire nmap :
Une attaque DDoS populaire contre l'infrastructure du ou des serveurs Web est l'épuisement des ressources de son serveur DNS (principal) en effectuant des requêtes récursives DNS valides pour des noms de sous-domaines (pseudo) aléatoires (par exemple abpdrsguvjkyz.www.dedeni.com ) :
Divers programmes (en particulier basés sur les appareils mobiles) présentent un comportement de type malware dans lequel ils envoient des données potentiellement sensibles aux postes de balise distante. Maltrail essaiera de capturer un tel comportement comme dans l'exemple suivant :
Comme toutes les autres solutions de sécurité, Maltrail est sujet aux « faux positifs ». Dans ce genre de cas, Maltrail (surtout en cas de menaces suspicious ) enregistrera le comportement d'un utilisateur régulier et le marquera comme malveillant et/ou suspect. Dans l'exemple suivant, on peut voir qu'un fournisseur de flux de liste noire blocklist.de a marqué le serveur Google habituel comme un ou plusieurs attacker , ce qui a entraîné la menace suivante :
En passant la souris sur le sentier, le cadre contenant les résultats de la recherche searX montre qu'il s'agit (très probablement) d'un serveur Google classique :
Comme autre exemple, l'accès aux domaines .work classiques (TLD populaires à des fins malveillantes) a entraîné la menace suivante :
Néanmoins, les administrateurs doivent investir un peu plus de temps et vérifier (par d'autres moyens) si le « suspect » signifie malveillant ou non, comme dans l'exemple suivant :
Sur 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/maltrailSur 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/maltrailDéfinir l'environnement de travail :
sudo mkdir -p /var/log/maltrail
sudo mkdir -p /etc/maltrail
sudo cp /opt/maltrail/maltrail.conf /etc/maltrail
sudo nano /etc/maltrail/maltrail.confDéfinir l'environnement d'exécution :
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
Activer en tant que services systemd (Linux uniquement) :
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
Remarque : /maltrail-sensor.service peut être démarré en tant que service dédié sans /maltrail-server.service pré-démarré. Ceci est utile dans le cas où /maltrail-server.service est installé et fonctionne sur une autre machine de votre environnement réseau.
Ce logiciel est fourni sous licence MIT. Consultez le fichier LICENSE qui l’accompagne pour plus d’informations.
1 Utiliser (uniquement) les sentiers
2 Connecteur aux sentiers (seulement)
