Conception et déploiement d'une infrastructure web sécurisée sur le réseau Tor

Introduction

L'objectif de ce projet est de concevoir et de déployer une infrastructure web hautement sécurisée en utilisant le réseau Tor.

Contrairement à un site internet classique, ce laboratoire met en place un "service caché" (service Onion). Cela permet d'héberger un site web qui n'est accessible qu'au travers du Navigateur Tor, garantissant ainsi un anonymat total et un chiffrement de bout en bout, tant pour l'utilisateur que pour le serveur.

Pour atteindre ce niveau de sécurité, le projet repose sur une architecture stricte séparant les rôles sur deux machines virtuelles sous Debian 12 :

• Une passerelle réseau : Elle sert de point d'entrée et gère exclusivement la communication chiffrée avec le réseau Tor public.
• Un serveur web isolé : Il héberge le contenu du site (via Nginx) sur un réseau privé virtuel, sans aucun accès direct à Internet.

Partie 1 : Contexte et Enjeux Théoriques

Cette première partie pose les fondations théoriques du projet. Avant de concevoir l'architecture technique, il est indispensable de comprendre les mécanismes de l'anonymat en ligne et les menaces spécifiques qui pèsent sur l'hébergement de services cachés.

1.1. Les principes de l'anonymat en ligne : VPN vs Routage en Oignon

Aujourd'hui, lorsqu'il est question de masquer son adresse IP ou de sécuriser sa connexion, la première solution envisagée est souvent le VPN (Réseau Privé Virtuel). Cependant, pour un projet nécessitant un anonymat fort, le VPN présente une faille conceptuelle majeure : il repose sur la confiance.

• Le VPN (Le modèle centralisé) : Un VPN crée un tunnel chiffré direct entre l'utilisateur et le serveur du fournisseur VPN. Le fournisseur connaît donc l'adresse IP réelle de l'utilisateur et sa destination finale. Si le serveur VPN est compromis, piraté, ou contraint légalement, l'anonymat de l'utilisateur est totalement détruit.
• Le Routage en Oignon / Tor (Le modèle décentralisé) : À l'inverse, le réseau Tor ne fait confiance à personne. Le trafic d'un utilisateur rebondit à travers au moins trois serveurs aléatoires (les nœuds) répartis dans le monde. Chaque nœud ne connaît que le maillon précédent et le maillon suivant. De plus, les données sont enveloppées de plusieurs couches de chiffrement (d'où l'image de l'oignon). Chaque nœud "épluche" une couche de chiffrement pour découvrir vers où envoyer le paquet ensuite. Résultat : aucun nœud ne connaît à la fois l'identité de l'utilisateur et sa destination finale.

C'est ce modèle décentralisé qui a été retenu pour ce projet, car il offre la garantie mathématique et structurelle la plus forte contre la surveillance réseau.

1.2. Le fonctionnement des Services Cachés (Onion Services v3)

Le réseau Tor ne sert pas uniquement à naviguer anonymement sur le web classique. Il permet également d'héberger des sites web directement à l'intérieur du réseau Tor : ce sont les services cachés (ou Onion Services). Leur fonctionnement diffère totalement de l'hébergement web traditionnel.

• La cryptographie comme adresse : Sur le web classique, on loue un nom de domaine (comme google.com) qui pointe vers une adresse IP. Sur le réseau Tor, l'adresse du site (qui se termine par .onion et fait 56 caractères) n'est pas achetée : elle est générée automatiquement. Cette adresse est en réalité la clé publique cryptographique du serveur. Cela garantit aux visiteurs qu'ils communiquent bien avec le propriétaire légitime du site, rendant toute usurpation mathématiquement impossible.
• Le Point de Rendez-vous (Rendezvous Point) : Lorsqu'un client souhaite visiter un site web classique, il se connecte directement à l'adresse IP du serveur, ce qui expose la localisation des deux parties. Dans le cas d'un service Onion, le client et le serveur ne se croisent jamais directement. Ils construisent chacun un circuit chiffré à travers le réseau Tor et se retrouvent au milieu, sur un nœud aléatoire appelé "Point de Rendez-vous". Ainsi, l'utilisateur ne connaît pas l'adresse IP du serveur, et le serveur ignore l'adresse IP de l'utilisateur. L'anonymat est bidirectionnel.

1.3. Les enjeux de la Sécurité Opérationnelle (OpSec) et du Zero Trust

Comprendre le routage de Tor ne suffit pas à garantir la sécurité d'un projet. Le plus grand danger pour un service caché ne vient généralement pas d'une faille dans le réseau Tor lui-même, mais d'une mauvaise configuration du serveur web qui l'héberge. C'est ce qu'on appelle une faille de Sécurité Opérationnelle (OpSec).

• La menace de la désanonymisation : Les serveurs web comme Nginx ou Apache sont conçus pour le web classique, pas pour le darknet. Si un attaquant parvient à exploiter une faille sur le site web (par exemple, en injectant un script ou en forçant le serveur à télécharger un fichier externe), le serveur web pourrait tenter de se connecter à Internet en utilisant sa véritable adresse IP publique, contournant ainsi le réseau Tor. Le serveur révélerait alors sa position exacte à l'attaquant.
• L'isolation et l'approche Zero Trust (Zéro Confiance) : Pour contrer ce risque mortel, la seule réponse viable est l'architecture Zero Trust. Dans ce projet, le principe est simple : nous ne faisons pas confiance au serveur web. Au lieu de tout installer sur une seule machine, l'infrastructure est physiquement et virtuellement scindée en deux. Le serveur web est enfermé dans un réseau privé virtuel sans aucun accès direct à Internet. Il ne peut communiquer qu'avec une passerelle réseau dédiée, qui, elle, est chargée de faire le lien avec le réseau Tor. Même en cas de piratage total du site web, l'attaquant reste piégé dans une machine aveugle, incapable de fuiter la moindre information sur la véritable localisation de l'infrastructure.

Partie 2 : Conception de l'Architecture Sécurisée

Cette deuxième partie détaille la conception technique de l'infrastructure. Elle explique les choix de ségrégation réseau, la sélection des composants logiciels et les principes de sécurisation retenus pour garantir une isolation hermétique du serveur web.

2.1. Topologie Réseau et Ségrégation sous VMware

Pour répondre aux exigences de la sécurité opérationnelle (OpSec), l'infrastructure a été conçue autour d'une séparation stricte des rôles sur deux machines virtuelles distinctes hébergées sous VMware.

1. La Passerelle Tor (VM 1) :

• Rôle : Point d'entrée unique de l'infrastructure depuis le réseau public. Elle gère la terminaison du circuit chiffré Tor et relaie le trafic légitime vers le réseau interne.
• Interfaces réseau :
  • ens33 (Mode NAT) : Connectée à Internet pour joindre les relais du réseau Tor.
  • ens3 (Mode LAN Segment) : Connectée exclusivement au réseau privé interne avec l'adresse IP statique 192.168.50.1
  • 
  • 

2. Le Serveur Web (VM 2) :

• Rôle : Hébergement de l'application et publication des pages web.
  Interface réseau :
• Interface réseau:
  • ens36 (Mode LAN Segment) : Connectée sur le même segment privé que la passerelle, avec l'adresse IP statique 192.168.50.2.
  • Aucun accès Internet : La VM 2 ne possède aucune carte réseau configurée en NAT ou en accès direct vers l'extérieur.
  • 

3. Le client TOR (VM3)

• Rôle : connexion sur le serveur web nginx via le navigateur de tor (tor browser)
• Interface réseau:
  • ens33(Mode NAT) : Connecté à internetr pour rjoindre le réseau TOR
    • 

2.2. Choix de la Stack Technologique

Le choix des composants logiciels repose sur trois critères essentiels : la stabilité, la légèreté et le contrôle fin des interfaces d'écoute.

• Distribution Linux : Debian 12 (Bookworm) Le choix de Debian 12 s'impose pour un environnement serveur en raison de sa grande stabilité, de son cycle de mise à jour rigoureux et de son empreinte mémoire réduite. Sa gestion native des services système via systemd permet un contrôle précis des processus réseau.
• Serveur Web : Nginx Contrairement à des serveurs web plus lourds ou modulaires comme Apache, Nginx a été retenu pour sa structure événementielle très performante et sa faible consommation de ressources. De plus, sa syntaxe de configuration permet de définir très simplement les interfaces et ports d'écoute (listen 192.168.50.2:80;), évitant ainsi toute exposition involontaire sur d'autres interfaces.

2.3. Sécurisation des Flux : La Justification du Protocole HTTP

L'une des particularités de cette architecture réside dans l'utilisation du protocole HTTP (port 80) entre la passerelle et le serveur web, sans ajout de certificat SSL/TLS (HTTPS). Ce choix, qui serait une erreur sur le web classique, est ici une décision d'architecture réfléchie et justifiée par le fonctionnement du protocole Onion v3 :

1. Chiffrement natif de bout en bout : Le réseau Tor chiffre l'intégralité du trafic depuis le navigateur du client jusqu'à la passerelle Tor (VM 1). Ajouter une couche HTTPS par-dessus ce tunnel chiffré créerait une surcouche de calcul inutile sans apporter de gain de sécurité mesurable.
2. Authentification par clé publique : L'adresse .onion v3 est la représentation directe de la clé publique du service. L'authenticité du serveur est donc prouvée cryptographiquement lors de l'établissement du circuit Tor, rendant l'usage d'une Autorité de Certification (CA) tierce totalement superflu.
3. Isolation du segment LAN : Les échanges HTTP en clair n'ont lieu que sur le segment réseau virtuel privé (192.168.50.0/24) à l'intérieur de l'hyperviseur VMware. Ce réseau privé n'étant relié à aucun équipement physique externe, le risque d'écoute clandestine (eavesdropping) sur ce segment est nul.

Partie 3 : Configuration et Sécurisation

Cette section détaille la mise en œuvre technique de l'architecture sur les systèmes Debian 12. L'objectif de cette phase de déploiement n'est pas seulement de rendre le service fonctionnel, mais d'appliquer concrètement les principes de durcissement et d'isolation réseau définis lors de la conception.

3.1. Configuration de la Passerelle Tor (VM 1)

La VM 1 agit comme le routeur d'entrée du service Onion. Le cœur de son fonctionnement repose sur le daemon tor et son fichier de configuration principal (/etc/tor/torrc).

• sudo apt install tor -y : Installation de tor

• sudo mkdir /var/lib/tor/site_onion : création du répertoire ou sera stocké les clés cryptographiques du service, ainsi que le fichier hostname contenant l'adresse publique .onion

• sudo nano /etc/tor/torrc : on accède au fichier de configuration puis on rajoute les lignes suivante:

  • 
  • sudo systemctl restart tor

• sudo cat /var/lib/tor/mon_service_onion/hostname: on récupère l'addresse publique .onion de notre serveur web.

  • 

• La mise en place du service caché s'effectue via deux directives critiques :

  • HiddenSericeDir : Spécifie le répertoire (/var/lib/tor/mon_service_onion/) où le daemon génère et stocke de manière sécurisée les clés cryptographiques du service, ainsi que le fichier hostname contenant l'adresse publique .onion.
  • HiddenServicePort : Définit la règle de transfert de port (Port Forwarding).

Analyse technique : La directive HiddenServicePort est le point de pivot de l'architecture. Elle ordonne au processus Tor d'écouter les requêtes entrantes sur le port 80 depuis le darknet, et de les relayer explicitement vers l'adresse IP interne du serveur web (192.168.50.2) sur le segment réseau privé. Le processus agit ici comme un reverse-proxy applicatif, sans qu'il soit nécessaire d'activer le routage IP global (IP forwarding) sur le noyau Linux de la passerelle.

3.2. Durcissement et Isolement du Serveur Web (VM 2)

Sur la seconde machine virtuelle, l'installation du serveur web Nginx requiert une configuration stricte pour s'aligner sur l'approche Zero Trust de l'infrastructure.

• sudo apt install nginx -y: Installation du serveur nginx

• sudo nano /etc/nginx/sites-available/default: On édite le fichier de configuration en ajoutant les ligne suivante:

  • 
  • Faut pas oublier de mettre l'url .onion (hostname) comme server_name pour notre site web
  • sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/: Activation de la configuration de nginx
  • sudo nginx -t: On vérifie notre configuration
    • 

• Analyse technique : Grâce à la directive listen 192.168.50.2:80;, Nginx ignore totalement les paquets qui proviendraient de la boucle locale (127.0.0.1) ou d'une éventuelle autre interface. Couplé à l'absence de passerelle par défaut configurée vers Internet sur cette machine, le serveur web se trouve dans une bulle hermétique. Toute tentative d'exfiltration de données vers l'extérieur (Reverse Shell) échouerait directement au niveau de la couche réseau.

  • sudo nano /var/www/html/index.nginx-debian.html: On modifie légèrement la page d'acceuil
    • 

• sudo systemctl restart nginx

3.3. Configuration du client et connexion

Dans cette troisème partie, nous allons installer le navigateur tor (tor browser) pour rejoindre le réseau le réseau tor.

• wget https://www.torproject.org/dist/torbrowser/13.5.2/tor-browser-linux-x86_64-13.5.2.tar.xz: Téléchargement de la dernière archive Linux depuis le site officie de TOR
• tar -xf tor-browser-linux-x86_64-*.tar.xz: On extrait l'archive
• cd tor-browser-linux-x86_64-15.0.19/tor-browser: on se déplace dans le dossier tor
• ./start-tor-browser.desktop --register-app: On enregistre l'application pour qu'elle apparaisse dans notre menus débian
• ./start-tor-browser.desktop: Puis on lance le navigateur
  • 
• Par défaut les navigateur comme firefox, chrome, ou même tor browser accepte que des requet en HTTPS et rejet les requet HTTP ou tante de faire transformer la requet http en https. Donc il faut le forcer à faire des requetes en http en modifaint les parametre car notre site web écoute sur le port 80 en http.
  • 
  • On clique sur les 3 petit bars horizon en haut à droit de l'écran > Parametre Vie privé et sécurité > On déscend jusqu'à en bas > Puis on choisis l'option Ne pas activer le mode HTTPS uniquement
  • 
  • Ensuite on colle notre URL .onionqu'on a générer sur la VM1 dans le navigateur puis on clique sur Entrer et on croise le doigt 🤞
  • 
  • Et voilà notre site accéssible uniquement via le réseau Tor 😤
  • Si on clique sur le logo en forme de circuit à gauche de l'url, on peut voir les différente noeud auquel notre requet est acheminer et on peut même le changer de noeud en cliquant sur Nouveau circuit tor pour ce site
    • 

3.3. Gestion des conflits de ports et Troubleshooting

Lors du déploiement, une problématique classique d'administration système a été rencontrée : le conflit d'occupation des sockets réseau. Lors des premiers tests de connectivité, la page par défaut du serveur web Apache s'affichait en lieu et place de celle de Nginx.

La méthodologie de diagnostic appliquée a été la suivante :

1. Audit des sockets en écoute : Utilisation de la commande d'inspection réseau ss -tulnp | grep :80 pour identifier quel processus (PID) occupait réellement le port 80 sur la machine.
2. Identification : L'analyse a confirmé que le daemon apache2 (souvent préinstallé avec certaines images Debian) s'était approprié le port avant Nginx.
3. Remédiation : Le service Apache a été immédiatement stoppé (systemctl stop apache2) puis purgé du système (apt purge apache2) afin d'éviter tout conflit futur lors des redémarrages. Le service Nginx a ensuite pu être relancé et s'approprier correctement le port réseau cible.

Cet incident valide l'importance de l'audit continu des services actifs sur un serveur en production, afin de s'assurer qu'aucun processus fantôme ou indésirable n'expose de surface d'attaque supplémentaire.

Partie 4 : Audit et Validation (La preuve par l'analyse)

Déployer une architecture sécurisée exige de vérifier que la réalité technique correspond parfaitement au modèle théorique. L'objectif de cette phase d'audit est de certifier deux éléments critiques : l'isolation totale du serveur web (OpSec) et le chiffrement de bout en bout du flux externe.

4.1. Méthodologie d'Audit

Pour valider l'étanchéité de l'infrastructure, une série de tests a été réalisée en simulant le comportement d'un client externe. Le trafic a été généré via le Navigateur Tor depuis une machine cliente, tandis que l'outil d'analyse réseau tcpdump a été placé en écoute sur les points stratégiques des deux machines virtuelles. L'analyse s'est concentrée sur la vérification des en-têtes IP (Couche 3) et des charges utiles applicatives (Couche 7) de part et d'autre de la passerelle.

4.2. Preuve de l'Isolation du Serveur (Audit du segment LAN)

La première étape de l'audit consiste à vérifier ce que le serveur web "voit" réellement lorsqu'un client accède au site. Pour ce faire, une écoute réseau a été lancée sur l'interface interne du serveur web (VM 2), couplée à une analyse des journaux d'accès (logs) de Nginx.

Observations lors de la requête client :

On lance la commande sur le serveur Web (VM2):

• sudo tcpdump -i ens33 -n -w capture.pcap:
  • tcpdump : Lance l'outil d'analyse de paquets réseau.
  • -i ens33 : Spécifie l'interface réseau à écouter (ici, la carte nommée ens33).
  • -n : Désactive la résolution de noms. Elle force l'affichage et le traitement des adresses IP sous forme numérique au lieu d'essayer de trouver leur nom de domaine (ce qui accélère la capture et évite de générer du trafic DNS inutile).
  • -w capture.pcap : Écrit (write) les paquets capturés dans un fichier nommé capture.pcap au format standard PCAP, au lieu de les afficher textuellement dans le terminal.
    • 
    • Le trafic capturé sur le réseau virtuel (192.168.50.0/24) montre bien des requêtes HTTP en clair transitant sur le port 80.
  • Analyse des journaux (/var/log/nginx/mon_site_onion.log) :
    • 
• Analyse technique :
  Ces résultats prouvent le succès de l'architecture Zero Trust. L'adresse IP source enregistrée par le serveur Nginx est strictement celle de l'interface interne de la passerelle Tor (192.168.50.1). L'adresse IP publique de la machine cliente n'est jamais transmise, pas même dans les en-têtes HTTP (comme le ferait un proxy classique avec un header X-Forwarded-For).
  Le daemon Tor de la passerelle opère une véritable rupture de protocole. Ainsi, en cas de compromission totale de la VM 2, un attaquant n'aurait accès qu'à une machine aveugle, ignorant tout de l'identité des visiteurs et de sa propre localisation sur Internet.

4.3. Preuve du Chiffrement et de l'Anonymat

La seconde étape de l'audit visait à simuler le point de vue d'un Fournisseur d'Accès à Internet (FAI) ou d'un pare-feu d'entreprise observant le trafic sortant de l'hyperviseur vers Internet. Une écoute réseau complète a été effectuée sur l'interface publique (NAT) de la Passerelle Tor (VM 1).

• 

• 

• Observations :

  • Aucun trafic n'a été détecté sur le port 80 ou le port 443 vers une destination web classique.

  • La totalité des paquets interceptés étaient dirigés vers un ensemble restreint d'adresses IP publiques, correspondant aux "Guard Nodes" (Nœuds d'entrée) du réseau Tor.

  • L'inspection approfondie des paquets n'a révélé aucune donnée lisible : l'intégralité de la charge utile était lourdement chiffrée (TLS).

• Analyse technique :
  Cette analyse côté WAN valide la résilience de l'infrastructure face à la surveillance globale. Il est impossible pour un observateur externe de déterminer que cette machine héberge un serveur web, ni de savoir à quel moment un client consulte le site. Le masquage du flux est total, confirmant que le choix de ne pas implémenter de certificat HTTPS applicatif était justifié par la robustesse du chiffrement natif de la couche transport Onion.

4.4. Scan avec Proxychains et Nmap

Dans cette section, nous adoptons la posture d'un attaquant externe afin d'auditer notre infrastructure et d'identifier d'éventuels ports exposés ou vulnérabilités. L'outil de référence pour cette phase de reconnaissance est le scanner réseau Nmap.

Toutefois, Nmap n'est pas conçu pour résoudre nativement les adresses en .onion. Pour contourner cette limitation, nous devons l'associer à un utilitaire indispensable : Proxychains. Ce dernier permet d'intercepter n'importe quelle commande réseau sous Linux et de forcer son exécution à travers le tunnel chiffré de Tor (via le proxy local SOCKS5 écoutant sur le port 9050).

• sudo apt install proxychains4 nmap: Installation Proxychains et Nmap
• sudo nano /etc/proxychains4.conf : On accède au fichier de configuration de Proxychains
• On déscend tout en bas puis on ajoute cette ligne socks5 127.0.0.1 9050
  • 
• On enregistre puis on quitte
• On lance notre scan:
  • proxychains4 nmap -Pn -sT -p 22,80,443 -A yeob57nkcqdb2olql3jem43ct4hhvtmrjwat4lmgdgc4ujebqu7674qd.onion
    • -Pn : Cette option ordonne à Nmap: "Ne cherche pas à pinger la machine, considère qu'elle est en ligne et lance directement l'analyse TCP car les paquet ICPM ne sont pas routable sur le réseau Tor
    • -sT: force Nmap à établir une connexion TCP complète (le fameux "Three-way handshake" : SYN, SYN-ACK, ACK) comme le ferait un vrai navigateur web.
    • -p 22,80,443: Ordonne à Nmap de scanner uniquement les port 80(http), 22(ssh) et le port 443(https)
    • -A: Nmap active la détection de version et les scripts avancés
    • 
    • Analyse Techique:
      • Le Scan Nmap a révélé une vulnérabilité de divulgation d'informations (Information Disclosure) : le serveur annonçait publiquement sa version exacte (Server: nginx/1.22.1). Sur un réseau hostile, cette empreinte permet à un attaquant de cibler des vulnérabilités spécifiques (CVE).
      • Pour y remédier, on active une directive de durcissement applicatif dans le fichier (/etc/nginx/nginx.conf) de configuration Nginx
        • sudo nano /etc/nginx/nginx.conf: On accède au fichier de config puis décommente (#) le ligne server_tokens off;
        • sudo systemctl restart nginx: Puis on redemarre le service nginx pour valider la modification.
    • On refait notre scan:
      • 
      • On peut voir que le serveur ne communique plus sa version du logiciel.

Partie 5 : Perspectives et Améliorations

Un ingénieur réseau et sécurité doit toujours envisager l'évolution, la maintenance et la mise à l'échelle de son architecture. Bien que fonctionnel, isolé et sécurisé, ce laboratoire de test peut être enrichi pour répondre aux standards industriels d'un environnement de production complexe.

5.1. Automatisation et Infrastructure as Code (IaC)

Le déploiement manuel de ce projet a été indispensable pour comprendre les mécanismes sous-jacents (routage, résolution de conflits de ports). Toutefois, dans un contexte d'entreprise, la reproductibilité est primordiale. La prochaine évolution logique de ce laboratoire serait d'automatiser l'intégralité du déploiement via des outils d'Infrastructure as Code (IaC) :

• Utilisation d'Ansible pour provisionner automatiquement les machines Debian, installer les paquets et pousser les configurations (torrc, nginx.conf).
• Conteneurisation du service web via Docker sur la VM 2 pour isoler encore davantage le processus Nginx du système d'exploitation hôte.

5.2. Défense en profondeur (Durcissement réseau via nftables)

L'isolation actuelle repose sur la topologie (l'absence de route vers Internet sur la VM 2). Pour appliquer le principe de "défense en profondeur", il serait pertinent d'implémenter un pare-feu strict avec nftables sur les deux machines. En appliquant une politique DROP par défaut en sortie (OUTPUT), on s'assure que même si la machine était compromise, il lui serait mathématiquement impossible d'initier une quelconque connexion non sollicitée, bloquant ainsi toute tentative de reverse-shell.

5.3. Haute Disponibilité (Load Balancing avec Onionbalance)

Actuellement, l'architecture repose sur un point individuel de défaillance (Single Point of Failure - SPOF). Pour un service en production soumis à un fort trafic, l'infrastructure pourrait évoluer vers un modèle de Haute Disponibilité en intégrant l'outil Onionbalance. Cela permettrait de conserver une adresse .onion unique tout en répartissant la charge des requêtes sur plusieurs serveurs Nginx (backend nodes), garantissant ainsi la résilience du service.

Conclusion Générale

Ce projet de laboratoire nous a permis de concevoir, déployer et auditer de bout en bout une infrastructure réseau hautement sécurisée. En dépassant la simple installation d'un service web classique, on a mis en pratique les concepts fondamentaux de la cybersécurité moderne : l'approche Zero Trust, la ségrégation des flux réseau, et la gestion stricte de la Sécurité Opérationnelle (OpSec).

Les différentes phases du projet ont validé plusieurs compétences techniques clés :

1. L'administration système : Le déploiement sous Debian 12, la configuration fine de services (Tor, Nginx), et le durcissement applicatif (masquage d'en-têtes HTTP suite à un auditProxychains et Nmap).
2. L'architecture réseau : La conception d'une topologie isolée sous VMware et la maîtrise du routage entre les VM.
3. L'analyse et le Troubleshooting : La validation des flux de données et du chiffrement via l'analyse de trames (tcpdump, Wireshark), confirmant la rupture de protocole et l'isolation totale du serveur.

6. Bibliographie et Ressources Numériques

Documentation Officielle & Architecturale :

• The Tor Project : Set up Your Onion Service. Tutoriel officiel de référence utilisé pour la configuration initiale du daemon Tor, la gestion du fichier torrc et la génération des clés du service caché v3.

  • Lien : https://community.torproject.org/onion-services/setup/

• Nginx : Documentation officielle (Core Module). Utilisée pour la configuration fine du bloc serveur (Virtual Host), la restriction des écoutes réseau sur le segment LAN et la directive de durcissement applicatif.

  • Lien : https://nginx.org/en/docs/http/ngx_http_core_module.html

Outils d'Audit et de Sécurité :

• Nmap (Network Mapper) : Official Nmap Reference Guide. Ressource consultée pour adapter les commandes de scan aux contraintes du réseau Tor (contournement de l'ICMP avec -Pn, forçage de la connexion complète avec -sT).

  • Lien : https://nmap.org/book/man.html

• Proxychains-ng : Documentation du projet pour la compréhension et la configuration de l'encapsulation des flux réseau TCP dans le proxy local SOCKS5.

  • Lien :
    • https://doc.ubuntu-fr.org/proxychains
    • https://www.youtube.com/watch?v=5sLLqbl45Nk

Assistance Technique et Rédactionnelle :

• Gemini (Intelligence Artificielle par Google) :

  • Rôle dans le projet : Outil utilisé comme assistant technique (sparring-partner) lors des phases de développement et de rédaction.

  • Apports spécifiques : Assistance à la méthodologie de diagnostic (troubleshooting réseau, analyse des trames HTTP 304, compréhension des conflits de résolution DNS avec Proxychains), aide à la vulgarisation des concepts d'architecture Zero Trust, et accompagnement dans la structuration globale de ce rapport.