Audit de sécurité d'un réseau local : Utiliser un smartphone Android et Termux

On entend souvent dire qu'il faut un ordinateur portable surpuissant et des équipements coûteux pour effectuer des tests d'intrusion ou des audits de sécurité. C'est un mythe.

Dans le contexte technologique actuel, notamment ici au Cameroun où l'agilité est primordiale, la compétence prévaut sur le matériel.

Récemment, lors d'une mission de vérification rapide, j'ai démontré qu'un simple smartphone Android équipé de Termux suffisait pour cartographier un réseau d'entreprise et identifier une faille critique sur un poste de développement. Voici le récit de cet audit et, surtout, comment sécuriser vos infrastructures.

📱 Le mythe du "Hacker au Hoodie" vs la Réalité

Le scénario est classique : un réseau Wi-Fi d'entreprise apparemment sécurisé. Un développeur travaille sur une application critique (probablement une stack Laravel/Vue.js) en utilisant Laragon ou XAMPP.

Il se sent en sécurité. Après tout, il est sur son réseau local (LAN).

Mon outil pour cet audit ? Pas de Kali Linux sur un Thinkpad. Juste mon téléphone Android personnel, connecté au Wi-Fi invité, et Termux, un émulateur de terminal Linux puissant.

🚀 La Démonstration Technique (Step-by-Step)

Voici comment l'audit s'est déroulé, étape par étape.

1. L'Arsenal de Poche

Sur Android, Termux permet d'installer les mêmes outils que sur un serveur Linux. J'ai commencé par installer Nmap, le standard de l'industrie pour le scan réseau

pkg update && pkg upgrade

pkg install nmap

2. La Cartographie

Une fois connecté au Wi-Fi, j'ai identifié ma propre adresse IP et le masque de sous-réseau pour déterminer la plage à scanner. J'ai lancé un scan ping discret pour voir qui était "vivant" sur le réseau.

nmap -sn 192.168.1.0/24

3. La Découverte de la Faille

Une IP a attiré mon attention. J'ai lancé un scan de ports spécifique pour voir quels services tournaient sur cette machine.

nmap -p 80,443,3306 192.168.1.X

Le résultat ?

• Port 80 (HTTP) : OPEN

• Port 3306 (MySQL) : OPEN

4. La Preuve de Concept (PoC)

C'est ici que ça devient critique. Le poste utilisait Laragon. Par défaut, ou par mauvaise configuration, les services n'étaient pas limités à la machine locale (localhost).

En tapant simplement l'IP 192.168.1.X dans le navigateur Chrome de mon smartphone, j'ai accédé à la racine du projet web. Pire encore, le port 3306 ouvert signifiait que je pouvais potentiellement me connecter à la base de données de l'entreprise depuis mon téléphone, en utilisant des identifiants par défaut souvent négligés (root / vide).

⚠️ La Zone Expert : Pourquoi le Pare-feu ne suffit pas

C'est ici que je fais la différence entre un "script kiddie" et un véritable analyste en sécurité.

La réaction naturelle d'un administrateur junior serait de dire : "Activez le Pare-feu Windows !". C'est vrai, mais ce n'est pas l'analyse complète. Le problème fondamental ici est le Binding des Interfaces.

Dans les environnements de dev (Laragon, WAMP, Docker), les services sont souvent configurés par défaut pour écouter sur 0.0.0.0 (toutes les interfaces). Cela signifie que le service répond aux requêtes venant de :

1. 127.0.0.1 (La machine elle-même)

2. 192.168.x.x (N'importe qui sur le réseau Wi-Fi)

🛡️ La vraie solution pour les développeurs

Si vous êtes développeur Full Stack, vous devez configurer vos services (Apache/Nginx/MySQL) pour écouter uniquement sur l'interface de bouclage (Loopback).

Dans votre configuration MySQL (my.ini) : Changez bind-address = 0.0.0.0 par : bind-address = 127.0.0.1

Cela rend le service mathématiquement inaccessible depuis l'extérieur, même si le pare-feu est désactivé. C'est ce qu'on appelle la Défense en Profondeur.

Conclusion

Cet audit prouve deux choses essentielles pour toute entreprise moderne :

1. La sécurité ne dépend pas du budget matériel, mais de la compétence de l'auditeur. Un smartphone peut être aussi dangereux qu'un ordinateur portable.

2. Les environnements de développement sont des portes dérobées. Ils contiennent souvent du code source, des clés API et des données clients, mais sont rarement aussi sécurisés que les serveurs de production.

En tant que développeur et analyste, mon rôle est de combler ce fossé entre le code et l'infrastructure.

Vous craignez que vos postes de travail ou votre réseau interne ne soient vulnérables ? Discutons-en. Je peux réaliser cet audit pour vous et sécuriser vos actifs avant qu'il ne soit trop tard.