maltrail v3.2
Système de détection de trafic malveillant en temps réel utilisant des listes noires publiques, des traces statiques de logiciels malveillants et une analyse heuristique pour identifier les menaces sur le trafic DNS, HTTP et IP.
Maltrail
Maltrail est un système de détection de trafic réseau qui identifie les communications avec une infrastructure malveillante connue et signale certaines anomalies de trafic sélectionnées. Il met en correspondance les domaines, les URL, les adresses IP, les paires IP:port et les valeurs User-Agent observés sur le réseau avec un ensemble d'indicateurs appelés trails.
Une détection est enregistrée sous la forme d'un événement unique contenant la source, la destination, le protocole, le trail correspondant, la classification et la source du trail :```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 est conçu pour la surveillance réseau basée sur les indicateurs. Ses détections heuristiques complètent
la correspondance de pistes, mais elles ne remplacent pas la télémétrie des terminaux ni un système de prévention
des intrusions à usage général.
## Fonctionnalités
- Une construction complète de pistes combinant plus de 3 000 fichiers statiques intégrés, 42 intégrations de flux publics,
et des pistes optionnelles fournies par l'opérateur.
- Un capteur Rust multithread utilisant libpcap, avec des workers de capture Linux `PACKET_FANOUT` optionnels.
- Un serveur Python fournissant l'interface de reporting, la réception d'événements et l'API HTTP.
- Des pistes personnalisées et des listes blanches en texte brut pouvant être examinées et versionnées.
- Des heuristiques pour le scan, l'épuisement DNS, les recherches de type DGA, les téléchargements suspects, les sondes proxy,
les valeurs User-Agent suspectes et l'activité réseau associée.
- La journalisation locale des événements, la journalisation Maltrail distante, CEF sur syslog et la sortie JSON Logstash.
- La validation du déploiement avec `maltrail-sensor -T` et des métriques Prometheus optionnelles.
## Contenu
- [Architecture](#architecture)
- [Interface de reporting](#interface-de-reporting)
- [Performance](#performance)
- [Installation](#installation)
- [Installateur](#installateur)
- [Compilation depuis les sources](#compilation-depuis-les-sources)
- [Systemd](#systemd)
- [Docker](#docker)
- [Configuration](#configuration)
- [Pistes](#pistes)
- [Événements et API](#evenements-et-api)
- [Opérations](#operations)
- [Surveillance](#surveillance)
- [Rétention des événements](#retention-des-evenements)
- [Documentation](#documentation)
- [Contribution](#contribution)
- [Projet](#projet)
- [Licence](#licence)
- [Mainteneurs](#mainteneurs)
- [Sponsors](#sponsors)
- [Présentations et publications](#presentations-et-publications)
- [Liste noire dérivée](#liste-noire-derivee)
- [Intégrations tierces](#integrations-tierces)
- [Remerciements](#remerciements)
## Architecture
Maltrail se compose de deux processus indépendants qui peuvent s'exécuter sur le même hôte ou sur des hôtes séparés :```text
┌──────────┐ events (UDP or file) ┌──────────┐
│ sensor │ ───────────────────────► │ server │ ◄── browser
└──────────┘ └──────────┘
Rust Python
libpcap + PACKET_FANOUT reporting UI + API
trail matching + heuristics
Le capteur capture le trafic, effectue la correspondance de pistes et l'analyse heuristique, et produit des événements.
Il peut écrire les événements localement (LOG_DIR), les envoyer à un serveur Maltrail distant (LOG_SERVER), ou faire
les deux. Il peut également émettre du CEF via syslog (SYSLOG_SERVER) et du JSON vers Logstash
(LOGSTASH_SERVER).
Le serveur reçoit et stocke les événements distants, sert les journaux d'événements disponibles localement, et fournit l'interface web et l'API.
Interface de reporting
Maltrail inclut une interface de reporting basée sur navigateur pour explorer le trafic détecté, avec mises à jour en direct, recherche par champ, chasse rétrospective, vues géographiques, triage, vues sauvegardées et export.
L'interface est servie par server.py à l'adresse HTTP_ADDRESS:HTTP_PORT. C'est du JavaScript pur avec une
seule dépendance d'exécution tierce (PapaParse, pour l'analyse CSV) et aucune étape de build. Une journée est
consultée à la fois, sélectionnée avec un sélecteur de date qui fait aussi office de grille de densité d'événements sur les
journaux quotidiens disponibles. Les événements sont diffusés depuis /events et agrégés dans le navigateur en
menaces — une ligne par (source, trail) distinct — affichées dans une grille triable avec un panneau de détail.
| Fonctionnalité | Notes |
|---|---|
| Mode direct | Les événements ajoutés sont poussés via Server-Sent Events (/live) et fusionnés dans la vue courante. Bascule vers l'interrogation par plages d'octets du journal quotidien lorsque SSE est indisponible, ou pour les sessions que le flux ne peut pas servir. Les nouvelles menaces de haute sévérité peuvent déclencher une notification de bureau et une alerte sonore ; les deux peuvent être désactivées |
| Recherche | Jetons à portée de champ (src: dst: port: proto: type: trail: info: family: tag: uid: sev: dir: status: ; family:interlock inclut interlock-1/-2, les fragments en lesquels un dump de flux arrive) combinés avec l'espace comme AND, - pour exclure, * jokers, CIDR (src:10.0.0.0/8), et plages numériques et comparaisons (port:>1024, count:>=100). Les filtres actifs apparaissent sous forme de puces supprimables |
| Chasse rétrospective | Recherche dans tous les journaux quotidiens conservés pour un indicateur (/hunt), pas seulement le jour affiché. Limitée par une limite de jours, un budget en temps réel et un plafond d'échantillons ; un jour tronqué par le budget est signalé séparément des jours complétés plutôt que compté comme un total terminé. Un index sidecar par jour (LOG_DIR/index/, USE_EVENT_INDEX) permet au balayage de sauter chaque ligne non correspondante et rend /counts exact |
| Carte mondiale | Densité d'événements par pays pour le jour sélectionné (/geo), plaçant le point de terminaison externe de chaque événement. Les événements qui ne peuvent pas être attribués à une adresse externe sont signalés comme non mappés plutôt que devinés. Définissez HOME_LAT / HOME_LON pour tracer les arcs d'origine |
| Triage | Statut par menace (nouveau / en cours d'investigation / résolu / faux positif), notes en texte libre, tags, et masquage. Les règles de liste blanche et les pivots OSINT sont disponibles depuis le menu contextuel de la ligne |
| Vues sauvegardées | Préréglages de filtres nommés |
| Export | La vue filtrée courante en CSV, JSON, ou indicateurs défangés |
| Apparence | Thèmes sombre et clair, et étapes discrètes de taille de texte |
L'état de triage, les vues sauvegardées, les tags et les paramètres d'apparence sont stockés dans le navigateur
(localStorage), pas sur le serveur : ils sont par navigateur et par origine, et ne sont pas partagés
entre analystes.
Les sessions restreintes par un filtre réseau ne voient que les événements de leurs propres réseaux, et cette restriction s'applique aux points de terminaison de comptage, de carte et de liste noire ainsi qu'à la liste d'événements.
L'enrichissement par pays et ASN pour des adresses individuelles est recherché sur stat.ripe.net par le
serveur, qui met en cache les résultats et les sert à l'interface depuis son propre point de terminaison /ripe
; le navigateur ne communique qu'avec Maltrail. Définissez DISABLE_RIPE_LOOKUPS pour désactiver entièrement
les recherches sortantes. Sans elles — ou sur un hôte sans accès internet — les drapeaux proviennent
de la table RIR locale à la place et tout le reste dans l'interface fonctionne hors ligne.
Performance
Les performances dépendent du processeur, de la composition du trafic, de la taille de l'ensemble de pistes, du pilote de capture et de l'interface réseau. Les chiffres ci-dessous mesurent le chemin de traitement des paquets du capteur isolément ; ce ne sont pas des mesures de capture en direct de bout en bout.
Mesures représentatives sur un AMD Ryzen 7 PRO 4750U avec heuristiques activées et un ensemble de pistes de 1,5 million de lignes :
| Trafic | Temps par paquet |
|---|---|
| ICMP echo, 58 octets | 101 ns |
| TCP SYN, 70 octets | 302 ns |
| TLS en masse, 1 473 octets | 402 ns |
| Requête DNS avec cache chaud, 93 octets | 452 ns |
| Trafic mixte, moyenne de 866 octets | 552 ns |
| Requête HTTP, 169 octets | 602 ns |
| Requête DNS avec un nom unique, 93 octets | 1 102 ns |
Des exécutions de comparaison hors ligne utilisant la même capture générée, la même configuration et le même ensemble de pistes ont mesuré un
coût par paquet en régime permanent 14 à 37× inférieur à celui du capteur Python retiré sur les systèmes testés.
Ces chiffres séparent le temps de traitement complet du régime permanent, car le chargement des pistes domine une
courte relecture. La détection elle-même est vérifiée séparément, par le corpus de 42 cas dans
sensor/tests/replay.rs.
Mesurez-le sur le système cible avec :```bash cargo bench --manifest-path sensor/Cargo.toml --bench hotpath
Un worker de capture est utilisé par défaut. Des workers supplémentaires peuvent augmenter la capacité de capture, mais le hachage de flux Linux divise l'état par source entre les workers et réduit donc la sensibilité de certaines heuristiques d'analyse. Dans le test documenté, 91 % des alertes heuristiques avec un seul worker subsistaient avec deux workers, 86 % avec quatre, et 65 % avec huit. La correspondance exacte des pistes est restée inchangée. N'augmentez `CAPTURE_FANOUT` que lorsque les métriques de perte de capture montrent que c'est nécessaire.
La méthodologie de benchmark, les résultats matériels, la sortie du profileur, les mesures de mémoire et les vérifications de fanout en direct sont documentés dans [`sensor/docs/REPORT.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/REPORT.md).
## Installation
### Installateur
L'installateur est vérifié sur douze distributions Linux — Debian, Ubuntu, Fedora, Rocky, AlmaLinux, Arch, openSUSE Leap et Tumbleweed, et Alpine — ainsi que FreeBSD et macOS, à chaque version, avec le résultat complet enregistré dans [`docs/compat`](https://github.com/stamparm/maltrail/blob/master/docs/compat). Raspberry Pi OS et les autres systèmes ARM 64 bits utilisent la build `aarch64` ; l'ARM 32 bits n'a pas de capteur précompilé et doit le compiler depuis les sources.```bash
curl -fsSL https://raw.githubusercontent.com/stamparm/maltrail/master/install.sh | sudo sh
Il installe les dépendances, crée une copie de travail gérée sous /opt/maltrail, vérifie la somme de contrôle
du capteur précompilé, crée un compte maltrail non privilégié, installe les unités systemd, prépare
les répertoires de journaux et d'état, et démarre le capteur et le serveur. Réexécuter l'installateur met à niveau
la copie de travail gérée.
Examinez le script avant de l'exécuter avec des privilèges élevés. À partir d'une copie de travail existante, l'exécution à blanc affiche les commandes sans modifier le système :```bash sh install.sh --dry-run
Options d'installation courantes :```bash
sh install.sh --role sensor # Install only the sensor
sh install.sh --ref 3.1.2 # Install a release tag instead of master
sh install.sh --no-service # Install without changing systemd
sh install.sh --dry-run # Print commands without applying them
sh install.sh --uninstall # Remove the managed installation; keep logs and state
Le tableau de bord est disponible à l'adresse http://127.0.0.1:8338 après l'installation. Notez que la valeur HTTP_ADDRESS fournie par défaut est 0.0.0.0, il est donc accessible sur toutes les interfaces, pas seulement sur la boucle locale — et les identifiants par défaut sont admin / changeme!. Modifiez USERS, et définissez HTTP_ADDRESS sur 127.0.0.1 (ou placez le serveur derrière un reverse proxy avec TLS), avant que l'hôte ne soit sur un réseau non fiable.
La construction initiale de la piste peut prendre plusieurs minutes. Le capteur ne détecte pas les correspondances de piste tant qu'un ensemble de pistes valide n'est pas disponible. L'unité systemd exécute la validation -T du capteur avant le démarrage, de sorte qu'une absence de privilèges, un répertoire de journaux non inscriptible ou un ensemble de pistes invalide provoque un échec de démarrage visible.
Le banc de test de l'installateur couvre douze distributions, et « il s'est installé » n'est pas l'assertion : dans chacune d'elles, le serveur est démarré et interrogé sur /ping, le capteur est invité à se valider avec -T, les unités sont vérifiées pour les chemins qui se résolvent, l'installateur est réexécuté pour prouver qu'une mise à niveau conserve la configuration de l'opérateur, et --uninstall est exécuté. Chaque résultat est enregistré par plateforme dans docs/compat, et la page qui s'y trouve est générée à partir de ces lignes plutôt qu'écrite à la main.
Alpine et les autres systèmes musl reçoivent une compilation du capteur -musl. On leur disait auparavant que le binaire précompilé était lié à glibc et qu'ils devaient compiler le leur ; le capteur se compile et s'exécute nativement sur musl, il s'agissait donc d'un artefact manquant plutôt que d'une limite de plateforme.
Compilation à partir des sources
Le capteur nécessite Rust 1.74 ou une version plus récente, les en-têtes de développement libpcap et les outils de capacités du système. Le serveur et le programme de mise à jour des pistes nécessitent Python 3.6 ou une version plus récente.
Installez les paquets de la distribution :```bash
Debian / Ubuntu / Raspberry Pi OS
sudo apt-get install cargo libpcap-dev libcap2-bin python3
RHEL / Fedora
sudo dnf install cargo libpcap-devel libcap python3
openSUSE / SLES
sudo zypper install cargo rust libpcap-devel libcap-progs python311
Ensuite, compilez et validez le capteur :```bash
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
cargo build --release --manifest-path sensor/Cargo.toml
sudo setcap cap_net_raw,cap_net_admin=eip \
sensor/target/release/maltrail-sensor
sudo install -d -o "$USER" -g "$(id -gn)" -m 750 /var/log/maltrail
sensor/target/release/maltrail-sensor -T
sensor/target/release/maltrail-sensor
Démarrez le serveur dans un autre terminal ou sur un autre hôte :```bash python3 server.py
Des binaires de capteur précompilés sont joints aux versions actuelles avec des sommes de contrôle SHA-256 : Linux `x86_64`
et `aarch64` pour glibc et musl, macOS sur Apple silicon et Intel, FreeBSD `amd64`, et
Windows `x86_64`.
Les builds glibc lient libpcap statiquement et ciblent glibc 2.28, donc la bibliothèque C est la seule chose
dont ils ont besoin — rien à installer, sur RHEL 8+, Debian 10+, Ubuntu 18.04+ et Leap 15.x de la même manière. Les builds musl
sont entièrement statiques, donc Alpine n'a besoin de rien du tout. Le build Windows est en 64 bits et nécessite Windows 10 ou ultérieur plus
[Npcap](https://npcap.com) installé avant de démarrer — `wpcap.dll` est une dépendance au chargement,
donc sans lui le chargeur refuse l'exécutable plutôt que d'échouer à la capture. L'archive le dit
aussi.
Les binaires de **3.1.1 et antérieurs** ne le faisaient pas : ils liaient libpcap dynamiquement, et le demandaient par
le nom qu'utilise leur hôte de build AlmaLinux. Debian et Ubuntu fournissent la bibliothèque identique sous le
nom plus ancien `libpcap.so.0.8`, donc ces binaires s'arrêtent avant de démarrer —```
./maltrail-sensor: error while loading shared libraries: libpcap.so.1: cannot open shared object file
— sur une machine où libpcap est installé. install.sh crée le lien manquant pour vous. Manuellement :```bash
adjust the directory for your architecture: aarch64-linux-gnu, or /usr/lib64 on RPM distributions
sudo ln -sf /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 /usr/lib/x86_64-linux-gnu/libpcap.so.1 sudo ldconfig
### Systemd
Les unités fournies dans `packaging/systemd/` exécutent les deux processus sous
l'utilisateur non privilégié `maltrail`. Systemd crée `/var/log/maltrail` et `/var/lib/maltrail`, restreint
l'accès au système de fichiers et accorde au capteur `CAP_NET_RAW` et `CAP_NET_ADMIN`.
L'installateur configure ces unités automatiquement. Pour une installation existante depuis les sources, suivez
la procédure de service manuelle dans [`sensor/docs/INSTALL.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/INSTALL.md).
Vérifiez l'état du service et les journaux avec :```bash
systemctl status maltrail-sensor maltrail-server
journalctl -u maltrail-sensor -f
Docker
Démarrez le déploiement Compose fourni avec :```bash docker compose -f docker/docker-compose.yml up -d
La configuration du conteneur, le stockage, les privilèges et les contrôles de santé sont documentés dans
[`docker/README.md`](https://github.com/stamparm/maltrail/blob/master/docker/README.md).
## Configuration
Maltrail lit `maltrail.conf`, qui contient des paramètres distincts `[Sensor]` et `[Server]`. L'installateur place la configuration gérée à `/etc/maltrail.conf`.
Les options de capteur fréquemment utilisées incluent :
| Option | Objectif |
| --- | --- |
| `MONITOR_INTERFACE` | Interface ou interfaces de capture ; `any` sélectionne toutes les interfaces prises en charge |
| `CAPTURE_FILTER` | Filtre de capture BPF |
| `CAPTURE_FANOUT` | Nombre de sockets de capture Linux ; par défaut un |
| `CAPTURE_WORKERS` | Workers de capture, un socket chacun ; par défaut `CAPTURE_FANOUT`, donc un sauf si l'un ou l'autre est défini |
| `LOG_DIR` | Répertoire local des journaux d'événements |
| `TRAILS_FILE` | Base de données de trails générée |
| `LOG_SERVER` | Serveur d'événements Maltrail distant |
| `SYSLOG_SERVER` | Destination ou destinations syslog CEF |
| `LOGSTASH_SERVER` | Destination ou destinations Logstash JSON |
| `STATS_ADDRESS` | Écouteur de métriques Prometheus ; désactivé sauf si configuré |
| `UPDATE_PERIOD` | Intervalle de rafraîchissement des trails |
| `STATIC_TRAILS_URL` | Source de récupération de l'ensemble statique de trails assemblé ; épinglez-la à une version datée pour contrôler l'arrivée de nouveaux contenus |
| `USER_WHITELIST` | Indicateurs gérés par l'opérateur qui ne doivent pas déclencher d'alerte |
| `CUSTOM_TRAILS_DIR` | Répertoire de trails géré par l'opérateur |
| `STATIC_TRAILS_DIR` | Checkout optionnel du dépôt de trails ; utilisé uniquement pour afficher la citation de source d'un trail dans l'interface |
`PROCESS_COUNT` s'applique au capteur Python retiré et au limiteur de journal d'événements hérité ; il ne définit **pas** le nombre de workers du capteur Rust. Configurez les workers de capture avec `CAPTURE_FANOUT` ou `CAPTURE_WORKERS` à la place.
Exécutez la vérification de déploiement après avoir modifié la configuration :```bash
sensor/target/release/maltrail-sensor -T
Le contrôle valide la configuration, les trails, les entrées de liste blanche, le filtre de capture, les privilèges, le stockage des journaux, la prise en charge des mises à jour et les paramètres des workers. Un contrôle réussi inclut des comptages positifs de trails et de liste blanche plutôt que de simplement confirmer que les fichiers existent.
Trails
Un trail est un indicateur — un domaine, une URL, une adresse IP, une paire IP:port, un User-Agent, une empreinte JA3/JA4 ou un hash de certificat — accompagné de sa signification et de sa provenance. Le programme de mise à jour fusionne quatre sources dans TRAILS_FILE, dans cet ordre :
| source | provenance |
|---|---|
| Feeds | feeds/*.py, récupérés directement par votre déploiement depuis chaque éditeur |
| Custom | CUSTOM_TRAILS_DIR et CUSTOM_TRAILS_URL, vos propres indicateurs |
| Static | l'ensemble assemblé depuis stamparm/trails, récupéré depuis STATIC_TRAILS_URL ; sous licence séparée |
| Engine lists | data/mass_scanner*.txt, fournis ici car ils changent rarement |
Les trails statiques résident dans leur propre dépôt. Le contenu de détection change des dizaines de fois par jour ; le moteur, non, et les garder ensemble signifiait que la mise à jour de la détection nécessitait de récupérer du code et rendait l'historique de ce dépôt inutilisable. STATIC_TRAILS_URL pointe vers l'ensemble publié le plus récent :```text
STATIC_TRAILS_URL https://github.com/stamparm/trails/releases/latest/download/trails.csv.gz
Pointez-le vers une version spécifique `content-YYYYMMDD-HHMM` pour épingler une version, afin qu'une mauvaise publication ne soit pas immédiatement globale. L'ensemble est mis en cache à côté de `TRAILS_FILE`, ce qui permet une reconstruction hors ligne ou en environnement isolé ; le `sha256` publié est vérifié avant le téléchargement, de sorte qu'un déploiement qui se met à jour plus souvent que le contenu ne change transfère 65 octets plutôt que 11 Mo, et une charge utile qui ne correspond pas à son empreinte est refusée au profit du cache.
`update_trails()` publie un nouveau `TRAILS_FILE` de manière atomique et uniquement après une compilation réussie. Les flux qui ne renvoient rien sont signalés par leur nom, afin qu'un déploiement ne dépende pas silencieusement d'une source qui a discrètement cessé d'exister.
Ajoutez vos propres indicateurs sous `CUSTOM_TRAILS_DIR`, et tout ce qui ne doit jamais déclencher d'événement dans `USER_WHITELIST`. Gardez les deux en dehors du répertoire d'installation afin qu'une mise à niveau ne puisse pas les écraser.
Les contributions de trails statiques vont sur [stamparm/trails](https://github.com/stamparm/trails) ; les nouveaux flux vont ici. Dans les deux cas, un indicateur nécessite une classification et une source vérifiable — voir [Contributing](#contributing).
## Événements et API
Maltrail enregistre un événement séparé par des espaces par détection, en utilisant le guillemet CSV lorsqu'une valeur contient des espaces :```text
"<time>" <sensor> <src_ip> <src_port> <dst_ip> <dst_port> <proto> <type> <trail> "<info>" <reference>
Le champ type identifie ce qui a correspondu, notamment DNS, IP, IPORT, URL, PATH, HTTP,
UA, PORT, CERT, JA3 et JA4. Le champ info contient la classification de la piste, et
reference identifie la liste statique, le flux, la source personnalisée ou l'heuristique qui l'a produite. Les
types JA3/JA4 se déclenchent sur les empreintes TLS client : la pile TLS d'un implant survit à chaque
rotation d'adresse et de domaine, de sorte que son hash hello continue de correspondre après que tout le reste a été brûlé
(publié par le flux SSLBL JA3 d'abuse.ch).
Recherche d'indicateur
Utilisez /check pour interroger un domaine, une adresse IP ou une URL :```bash
curl 'http://127.0.0.1:8338/check?q=www.sub.evil.example'
- **`--no-verify`** : Ignore la vérification du certificat SSL lors de la connexion à la cible. À utiliser uniquement pour les tests sur des hôtes avec des certificats auto-signés.
- **`--timeout`** : Définit un délai d'attente pour les requêtes réseau (par défaut : 10 secondes).
- **`--user-agent`** : Spécifie une chaîne User-Agent personnalisée pour les requêtes HTTP.
- **`--proxy`** : Achemine le trafic via un proxy (par exemple, `http://127.0.0.1:8080`).
- **`--output`** : Enregistre les résultats dans un fichier au format JSON ou texte brut.
- **`--verbose`** : Active la journalisation détaillée pour le débogage.
### Exemples
```bash
# Analyse de base d'une cible unique
python3 cve_2025_55182.py -u https://example.com
# Analyse de plusieurs cibles à partir d'un fichier
python3 cve_2025_55182.py -f targets.txt --threads 20
# Analyse avec un proxy et un User-Agent personnalisé
python3 cve_2025_55182.py -u https://example.com --proxy http://127.0.0.1:8080 --user-agent "Mozilla/5.0"
# Enregistrer les résultats dans un fichier JSON
python3 cve_2025_55182.py -u https://example.com --output results.json
Sortie
L'outil génère un rapport de synthèse indiquant si chaque cible est vulnérable, non vulnérable ou inaccessible. Les résultats détaillés incluent le code de statut HTTP, les en-têtes de réponse et les preuves de vulnérabilité extraites de la réponse du serveur.
Avertissement
Cet outil est destiné à des fins éducatives et à des tests de sécurité autorisés uniquement. L'utilisation de cet outil contre des systèmes sans autorisation écrite préalable est illégale et contraire à l'éthique. Les auteurs ne sont pas responsables de tout dommage ou utilisation abusive.
Références
- Avis de sécurité officiel
- Analyse de la CVE-2025-55182
- Directives de test éthique```json { "query": "www.sub.evil.example", "found": true, "trail": "evil.example", "info": "asyncrat (malware)", "reference": "(static)", "confidence": 100 }
Le champ `confidence` (0-100, ou `null` lorsqu'il n'est pas disponible) indique dans quelle mesure les sources soutiennent l'entrée : 40 pour un seul flux, +15 par flux supplémentaire concordant indépendamment jusqu'à 100, et la note maximale pour les entrées personnalisées et statiques de l'opérateur. Il est calculé au moment de la mise à jour des trails à partir de la concordance des flux dans un sidecar `trails.confidence` à côté de `trails.csv` ; un serveur qui récupère les trails depuis un `UPDATE_SERVER` n'a pas de provenance à évaluer et renvoie `null`. Utilisez-le pour prioriser le triage - une entrée issue d'un seul flux à 40 mérite un second examen avant de mériter une règle de pare-feu.
Une recherche de sous-domaine peut correspondre à son parent listé. Les recherches d'URL vérifient `host/path` avant de vérifier l'hôte seul. Le serveur lit la base de données de trails mappée en mémoire et observe les mises à jour des trails sans redémarrage.
Les trails statiques publics et les trails de flux sont disponibles sans authentification, conformément au point de terminaison `/trails` utilisé par les capteurs distants. Les trails personnalisés nécessitent une session autorisée ; une recherche personnalisée seule non autorisée est signalée comme un échec. Les données d'événements restent authentifiées.
## Opérations
### Surveillance
Utilisez `maltrail-sensor -T` comme porte de déploiement et de configuration. L'unité systemd fournie l'exécute en tant que `ExecStartPre`.
Pour confirmer que la détection elle-même fonctionne — et pas seulement que les processus démarrent — exécutez :```bash
python3 server.py --detect-test
Il rejoue un pcap fabriqué de trafic malveillant émulé (déclenchements sur une requête DNS, une IP, un
IP:port, un chemin d'URL et un en-tête Host, plus les heuristiques d'injection SQL, de traversée, de RCE, de XSS, de sonde de proxy,
de sinkhole, d'absence de Host et de scan de port/web/infection) à travers le capteur installé
et vérifie que chaque détection attendue se déclenche. Il n'a besoin ni de root, ni d'interface, ni de son propre ensemble de pistes. Une installation saine affiche 20/20 detection(s) fired.
Lorsque STATS_ADDRESS est configuré, surveillez au moins ces métriques Prometheus :
| Métrique | Signification opérationnelle |
|---|---|
maltrail_up == 0 | Aucun worker de capture ne fonctionne |
maltrail_capture_dropped_total en augmentation | L'anneau de capture perd des paquets |
maltrail_local_log_errors_total en augmentation | Des événements ont été produits mais n'ont pas pu être écrits localement |
maltrail_remote_log_errors_total en augmentation | Les événements n'ont pas pu être livrés à un récepteur distant ; avec DISABLE_LOCAL_LOG_STORAGE, ils sont perdus |
maltrail_trail_generation qui ne progresse pas | L'ensemble de pistes actif n'est pas actualisé |
maltrail_log_dir_free_bytes | Capacité restante pour le stockage local des événements |
maltrail_state_saturations_total en augmentation | Une limite d'état heuristique a été atteinte |
maltrail_throttle_evictions_total en augmentation | La table de limitation d'événements est à son maximum, donc les événements sont agrégés plus tôt que configuré |
La saturation d'état affecte l'heuristique correspondante ; la correspondance exacte des pistes reste active.
Envoyez SIGHUP ou utilisez systemctl reload maltrail-sensor pour demander un rechargement des pistes. Les fichiers de pistes
mis à jour par un autre processus sont détectés automatiquement et publiés aux workers sans redémarrer
le capteur.
Le magasin observable condensé (USE_CONDENSED_STORAGE, meta.sqlite) prend en charge les vues de nouveauté et de rétro-chasse du
serveur. L'index sidecar du journal d'événements par jour (USE_EVENT_INDEX,
LOG_DIR/index/*.sqlite, environ le double de la taille des journaux sur disque) est ce qui rend /counts exact et
/hunt rapide ; il est maintenu de manière incrémentale à partir des journaux eux-mêmes et peut être reconstruit avec
server.py --rebuild-index. La compatibilité avec le capteur retiré est documentée dans
sensor/docs/COMPATIBILITY.md.
Rétention des événements
Maltrail ne fait pas tourner ni ne supprime les journaux d'événements. Les opérateurs sont responsables de définir la rétention, l'archivage et la suppression selon les exigences de stockage et la politique organisationnelle.
Pratiques recommandées :
- Envoyez la copie durable des événements à un serveur Maltrail distant ou à un SIEM avec
LOG_SERVER,SYSLOG_SERVERouLOGSTASH_SERVER. - Alertez sur
maltrail_log_dir_free_bytesavec une marge suffisante pour le taux d'événements attendu. - Faites tourner, archivez ou supprimez les journaux quotidiens locaux à l'aide d'outils externes.
- Conservez les fichiers nécessaires à l'interface de reporting non compressés dans
LOG_DIR; archivez les fichiers compressés ailleurs.
Lorsque le système de fichiers des journaux est plein, le capteur ne peut pas ajouter d'événements. Les journaux d'événements peuvent également contenir des adresses IP et des domaines qui sont réglementés comme données personnelles dans certaines juridictions ; la politique de rétention doit tenir compte des exigences applicables.
Trafic synthétique
Pour vérifier que la détection et le tableau de bord fonctionnent toujours, sans attendre du trafic réel :```bash python3 server.py --detect-test # assert every detection fires, then exit python3 server.py --detect-test --keep DIR --serve # ...and keep the events, serving them on :8338
`--keep` rejoue également `sensor/tests/corpus/` dans le même journal et affiche lesquelles des formes que le tableau de bord rend différemment ont un événement derrière elles, afin qu'une icône, une couleur ou un glyphe manquant soit visible plutôt que supposé. Les horodatages sont décalés pour que le jour le plus récent soit aujourd'hui. Un binaire de capteur est requis (`cargo build --release --manifest-path sensor/Cargo.toml`).
Les données de la démo publique sont régénérées à partir d'une telle exécution :```bash
python3 sensor/tools/gen_demo_js.py --from DIR/logs # tops up html/js/demo.js
Documentation
| Document | Contenu |
|---|---|
sensor/docs/INSTALL.md | Installation, privilèges, configuration et dépannage |
sensor/docs/ARCHITECTURE.md | Fonctionnement interne du capteur et flux de données |
sensor/docs/COMPATIBILITY.md | Différences délibérées par rapport au capteur Python retiré |
sensor/docs/REPORT.md | Mesures, profils et résultats de tests |
sensor/docs/ROADMAP.md | Travaux ouverts sur le capteur |
SekuriPy Labs | Notes d'ingénierie, benchmarks et articles |
Contributing
Les ajouts de trails, la maintenance des feeds, les rapports de bugs, la documentation et les améliorations du capteur sont les bienvenus. Les soumissions de trails doivent inclure une source fiable et utiliser la classification appropriée la plus étroite.
Exécutez les vérifications pertinentes avant de soumettre du code. La porte de validation complète du capteur est :```bash bash sensor/tools/check.sh
Il exécute le formatage, Clippy avec les avertissements refusés, ainsi que les suites de tests en mode debug et release. Exécutez la suite de tests du serveur Python avec :```bash
bash tests/run.sh python3
La version Windows peut être testée depuis Linux, c'est là que ses bugs ont été trouvés :```bash sh sensor/tools/check_windows.sh
Il effectue une compilation croisée du capteur avec mingw-w64, extrait la bibliothèque en espace utilisateur de Npcap depuis son installateur
(une archive NSIS, donc rien n'est installé), et exécute le résultat sous Wine — toute la suite de tests,
`-T` contre la configuration fournie, le corpus pcap comparé octet par octet au binaire natif,
et le serveur répondant à `/ping` sous un Python Windows. La capture en direct est la seule chose qu'il
ne peut pas couvrir ; cela nécessite le pilote noyau de Npcap et une véritable machine Windows. Les prérequis sont
`gcc-mingw-w64-x86-64`, `wine`, et `p7zip-full`.
## Projet
### Licence
**TL;DR :** Maltrail est sous licence MIT, mais le jeu de données Maltrail Trails a des conditions distinctes. La consultation/référence indépendante d'IOC est autorisée ; l'utilisation systématique de Trails comme source de renseignement dans un produit ou service commercial nécessite une autorisation/licence.
Maltrail est distribué sous la licence MIT. Voir [`LICENSE`](https://github.com/stamparm/maltrail/blob/master/LICENSE).
C'est le moteur. L'ensemble de trails statique est un travail distinct sous des conditions distinctes : gratuit pour un usage défensif interne, la recherche et l'enseignement, mais un produit commercial, un service, une offre MSSP ou MDR, ou un flux redistribué nécessite une licence. Un moteur sous MIT ne rend pas le contenu libre à la vente — voir
[`LICENSE.md`](https://github.com/stamparm/trails/blob/main/LICENSE.md) dans
[stamparm/trails](https://github.com/stamparm/trails) avant de l'intégrer dans quelque chose que vous facturez.
### Mainteneurs
- Miroslav Stampar ([@stamparm](https://github.com/stamparm))
- Mikhail Kasimov ([@MikhailKasimov](https://github.com/MikhailKasimov))
### Sponsors
- [Sansec](https://sansec.io/) (2024–2025)
- [Sansec](https://sansec.io/) (2020–2021)
### Présentations et publications
- 47th TF-CSIRT Meeting, Prague, 2016
([slides](https://web.archive.org/web/20161109135211/https://www.terena.org/activities/tf-csirt/meeting47/M.Stampar-Maltrail.pdf))
- _Detect attacks on your network with Maltrail_, Linux Magazine, 2022
([article](https://www.linux-magazine.com/Issues/2022/258/Maltrail))
- _Best Cyber Threat Intelligence Feeds_, Silent Push, 2022
([review](https://www.silentpush.com/blog/best-cyber-threat-intelligence-feeds))
- _Research on Network Malicious Traffic Detection System Based on Maltrail_, Nanotechnology
Perceptions, 2024
([paper](https://nano-ntp.com/index.php/nano/article/view/1915/1497))
### Intégrations tierces
- [FreeBSD Port](https://www.freshports.org/security/maltrail)
- [OPNsense Gateway Plugin](https://github.com/opnsense/plugins/pull/1257)
- [D4 Project](https://www.d4-project.org/2019/09/25/maltrail-integration.html)
- [BlackArch Linux](https://github.com/BlackArch/blackarch/blob/master/packages/maltrail/PKGBUILD)
- [Validin](https://x.com/ValidinLLC/status/1719666086390517762)
- [Maltrail Add-on for Splunk](https://splunkbase.splunk.com/app/7211)
- [Maltrail decoder and rules for Wazuh](https://github.com/MikhailKasimov/maltrail-wazuh-decoder-and-rules)
- [GScan](https://github.com/grayddq/GScan) (trails uniquement)
- [MalwareWorld](https://www.malwareworld.com/) (trails uniquement)
- [oisd domain blocklist](https://oisd.nl/?p=inc) (trails uniquement)
- [NextDNS](https://github.com/nextdns/metadata/blob/e0c9c7e908f5d10823b517ad230df214a7251b13/security/threat-intelligence-feeds.json) (trails uniquement)
- [NoTracking](https://github.com/notracking/hosts-blocklists/blob/master/SOURCES.md) (trails uniquement)
- [OWASP Mobile Audit](https://github.com/mpast/mobileAudit#environment-variables) (trails uniquement)
- [Mobile Security Framework MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/12b07370674238fa4281fc7989b34decc2e08876) (trails uniquement)
- [pfBlockerNG-devel](https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/www/pfblockerng/pfblockerng_feeds.json) (trails uniquement)
- [Sansec eComscan](https://sansec.io/kb/about-ecomscan/ecomscan-license) (trails uniquement)
- [Palo Alto Networks Cortex XSOAR](https://xsoar.pan.dev/docs/reference/integrations/github-maltrail-feed) (connecteur de trails)
### Remerciements
- Thomas Kristner
- Eduardo Arcusa Les
- James Lay
- Ladislav Baco (@laciKE)
- John Kristoff (@jtkdpu)
- Michael Münz (@mimugmail)
- David Brush
- @Godwottery
- Chris Wild (@briskets)
- Keith Irwin (@ki9us)
- Simon Szustkowski (@simonszu)