Introduction
Une équipe envoie normalement ses documents vers docs.approved.test. Une petite capture enregistrée contient aussi des envois vers une autre destination. Vous êtes autorisé à créer un détecteur hors ligne pour ces échanges synthétiques.
Une capture de paquets (PCAP) conserve des paquets réseau. Suricata reconstruit leurs requêtes HTTP et teste des règles. Ici, il lit des fichiers sans contacter ces hôtes. Tous les noms et documents sont fictifs. Le HTTP en clair rend le corps visible ; cet exercice ne montre pas comment lire du HTTPS chiffré.
Saisissez les commandes dans l’onglet Analyst. Sélectionnez l’onglet Traffic Reference pour consulter les mêmes requêtes préparées que dans traffic/requests.txt ; la page de référence s’ouvre directement. Ce sont des exemples enregistrés, pas une topologie active. Seules la saisie au terminal et la navigation entre onglets sont nécessaires, sans expérience IDS préalable.
Reconnaître les requêtes d’envoi
Dans cette étape, créez une première règle repérant les requêtes POST, y compris les envois normaux. Une alerte signifie qu’une règle correspond ; elle ne prouve pas une compromission et ne bloque rien.
Sélectionnez l’onglet Analyst dans l’interface du laboratoire pour commencer cette étape.
HTTP fonctionne par requêtes et réponses. La méthode indique l’action : POST envoie du contenu et GET demande une ressource. L’en-tête Host nomme le site destinataire, l’URI sa route et le corps contient les champs du document soumis. Passez à l’onglet Traffic Reference pour voir les échanges HTTP préparés dans le navigateur. La page est une référence, pas un moniteur de paquets en direct. Revenez ensuite à l’onglet Analyst pour lire les mêmes échanges et exécuter toutes les commandes ci-dessous. cat affiche un fichier ; son chemin indique son emplacement.
Passez à l’onglet Analyst avant d’exécuter la commande suivante.
cat traffic/requests.txt
Comparez le POST légitime vers docs.approved.test, le GET du collecteur et le POST contenant classification=internal. L’organisation autorise les documents internes sur le service approuvé. La route du collecteur accepte des démonstrations publiques, mais pas les documents internes. Destination et contenu comptent ensemble ; un hôte inconnu ne suffit pas comme preuve.
Une règle Suricata comprend un en-tête et des options entre parenthèses. alert http choisit une alerte sur HTTP analysé. Les deux paires any any acceptent toutes les adresses et tous les ports source/destination ; -> indique le sens source vers destination. flow:established,to_server limite l’analyse aux requêtes d’un client connecté. Un point-virgule termine une option. msg décrit la correspondance, sid est l’identifiant numérique de signature et rev sa révision. Chaque règle utilise un sid unique.
Un tampon persistant sélectionne le champ HTTP examiné par le content suivant. http.method choisit la méthode. content:"POST" recherche ce texte ; startswith et endswith imposent le champ entier plutôt qu’une sous-chaîne. Utilisez la règle ci-dessous.
cat > method.rules écrit le fichier en remplaçant son ancien contenu. <<'RULE' commence une saisie littérale sur plusieurs lignes ; le dernier RULE doit être seul sur sa ligne. Cette méthode d’édition est simple : en cas de faute, réexécutez tout le bloc.
cat > method.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; sid:1000001; rev:1;)
RULE
Relisez la capture. mkdir -p crée le dossier de sortie et accepte un dossier existant. --runmode single emploie un seul fil de traitement ; -c choisit la configuration ; -S charge exclusivement votre fichier de règles ; -r lit le PCAP ; -l choisit la sortie. --init-errors-fatal arrête le programme si une règle ne charge pas. La configuration examine au plus 64 Ko par corps de requête ; tous les corps fournis respectent cette limite. Les limites d’un déploiement réel demandent une évaluation distincte.
mkdir -p method-output
suricata --runmode single -c suricata.yaml -S method.rules -r traffic/core.pcap -l method-output --init-errors-fatal
python3 /opt/c09/read-alerts.py method-output/eve.json
Le message d’arrêt de Suricata est normal à la fin du fichier hors ligne. eve.json contient un objet JSON par événement. JSON utilise des champs nommés : event_type: alert indique une correspondance, signature_id sa règle et les champs HTTP la requête. Le lecteur Python fourni affiche le port source, la méthode, l’hôte, l’URI et l’identifiant de signature de chaque alerte. Le port relie l’échange à la référence ; il ne définit pas la politique.
Le résultat attendu est Alerts: 10. Le POST normal de documents et les POST du collecteur apparaissent. GET et PUT restent silencieux. Ce premier détecteur volontairement large enseigne la sélection par méthode.
Le vérificateur exécute votre règle inchangée sur deux petits corpus indépendants dans des dossiers temporaires. Il ignore les journaux sauvegardés et préserve règles et captures. Vérifiez ce détecteur de méthode :
python3 /opt/c09/check.py method.rules method
Les deux lignes doivent annoncer 10 échanges attendus. En cas d’erreur de syntaxe, comparez guillemets, points-virgules et parenthèse finale, réécrivez puis réessayez. Réutiliser un dossier de sortie ajoute des événements ; choisissez-en un neuf pour comparer les nombres. Le vérificateur repart toujours de zéro.
Sélectionner la destination du collecteur
Dans cette étape, combinez méthode et hôte pour exclure les envois normaux au service documentaire. Tous les tampons d’une règle doivent correspondre à la même transaction HTTP.
Sélectionnez l’onglet Analyst dans l’interface du laboratoire pour commencer cette étape.
Le site destinataire se recherche dans http.host, pas dans le corps : un document peut mentionner le collecteur sans lui être envoyé. Suricata normalise ce tampon en minuscules. La référence contient collector.example.test.other.test, qui est un autre hôte. La correspondance du champ entier le distingue.
Créez un nouveau fichier et gardez le premier détecteur pour comparaison. Conservez l’en-tête et la méthode ; le nouveau tampon ajoute la destination.
Passez à l’onglet Analyst avant d’exécuter la commande suivante.
cat > destination.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p destination-output
suricata --runmode single -c suricata.yaml -S destination.rules -r traffic/core.pcap -l destination-output --init-errors-fatal
python3 /opt/c09/read-alerts.py destination-output/eve.json
Attendez Alerts: 6. Le service approuvé et l’hôte au nom proche disparaissent. Les POST vers /status et /collect-backup correspondent encore, car les routes ne sont pas distinguées. Ces faux positifs connus sont utiles : ils correspondent à un comportement hors de votre cible d’investigation.
python3 /opt/c09/check.py destination.rules destination
Les deux corpus doivent correspondre à six échanges méthode-hôte. Si un hôte autorisé déclenche encore une alerte, vérifiez que startswith; endswith; suivent son contenu. Modifier un événement JSON sauvegardé ne répare pas le détecteur ; modifiez la règle et relisez.
Limiter la détection à la route d’envoi
Dans cette étape, réalisez un détecteur de route fonctionnel tout en reconnaissant sa limite concernant le contenu. L’URI est la route, par exemple /collect, distincte de l’hôte.
Sélectionnez l’onglet Analyst dans l’interface du laboratoire pour commencer cette étape.
Utilisez http.uri et le champ entier pour sélectionner exactement /collect. /collect-backup est une autre route. Gardez méthode et destination pour laisser silencieux contrôles de santé et destinations légitimes.
Passez à l’onglet Analyst avant d’exécuter la commande suivante.
cat > upload.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; http.uri; content:"/collect"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p route-output
suricata --runmode single -c suricata.yaml -S upload.rules -r traffic/core.pcap -l route-output --init-errors-fatal
python3 /opt/c09/read-alerts.py route-output/eve.json
Attendez Alerts: 4, pour les ports 41002, 41003, 41007 et 41011. Comparez leurs corps dans la référence : deux documents internes et deux démonstrations publiques. Tous sont des POST vers l’hôte et la route choisis. Le détecteur surveille la route, mais surestime les envois sensibles.
python3 /opt/c09/check.py upload.rules route
Les deux corpus doivent correspondre à quatre échanges de route. Le vérificateur change aussi les noms de documents et ports source : ces valeurs accessoires ne doivent pas décider de la détection. Expliquez la portée de la règle en partageant ses alertes. Le laboratoire suivant ajoute le contexte documentaire et teste la réduction du bruit dans un environnement neuf.
Résumé
Vous avez construit des détecteurs de méthode, destination et route avec la relecture réelle de Suricata. Vous avez relié les alertes aux requêtes enregistrées et identifié les faux positifs des documents publics avant de parler de détection des envois sensibles.
