Secure Network Architecture Lab - Vagrant, Firewall, TLS and Hardening

Introduction

#

Ce projet documente la conception, le déploiement et la sécurisation d’une petite architecture réseau d’entreprise en environnement virtualisé.

L’objectif est de construire une infrastructure reproductible avec Vagrant, puis de la durcir étape par étape:

• segmentation réseau
• firewall / routeur
• serveur web HTTPS
• base de données isolée
• chiffrement des données sensibles
• Fail2ban
• tests d’attaque contrôlés
• validation défensive

Le projet est orienté blue team et infrastructure security. Il montre comment passer d’une architecture fonctionnelle à une architecture défendable.

Objectifs

#

Les objectifs du lab sont:

• automatiser le déploiement des machines virtuelles
• isoler les rôles réseau
• appliquer le principe du moindre privilège
• limiter l’exposition des services
• chiffrer les communications web
• protéger l’accès SSH
• valider les protections par des tests offensifs contrôlés

Architecture cible

#

Le lab repose sur 4 machines virtuelles:

L’architecture cible utilise trois zones logiques, en plus de l’interface NAT de sortie :

• TEST en 192.168.10.0/24 pour les validations offensives contrôlées ;
• DMZ en 192.168.20.0/24 pour le serveur web ;
• DATA en 192.168.30.0/24 pour la base de données ;
• un accès NAT distinct pour la sortie Internet contrôlée du firewall.

Cette séparation est plus qu’une convention de nommage. Si toutes les VMs restent dans le même /24, elles peuvent communiquer directement au niveau 2 sans traverser le firewall. Une segmentation réellement filtrable exige des sous-réseaux ou VLANs distincts et le contrôle de leur routage.

Pourquoi Vagrant

#

Vagrant permet de rendre le lab reproductible.

Avantages:

• déploiement rapide
• configuration déclarative
• environnement rejouable
• documentation sous forme d’infrastructure as code
• cohérence entre les VMs

Exemple conceptuel:

Vagrant.configure("2") do |config|
  config.vm.define "fw" do |fw|
    fw.vm.box = "ubuntu/jammy64"
    fw.vm.network "private_network", ip: "192.168.10.1"
    fw.vm.network "private_network", ip: "192.168.20.1"
    fw.vm.network "private_network", ip: "192.168.30.1"
  end
end

Segmentation réseau

#

Le firewall joue le rôle de passerelle entre les zones.

Objectifs:

• empêcher l’accès direct non contrôlé vers la base de données
• centraliser le routage
• filtrer les flux entrants
• autoriser uniquement les services nécessaires

Tests de connectivité:

ip a
ip route
ping 192.168.10.1
ping 192.168.20.20
ping 192.168.30.30

Mise en place du routage

#

Sur la VM firewall, l’IP forwarding est activé:

sudo sysctl -w net.ipv4.ip_forward=1

Pour le rendre persistant:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Les VMs internes utilisent le firewall comme passerelle par défaut.

Il faut aussi vérifier le chemin réel avec traceroute ou tracepath. Un ping réussi ne prouve pas que le trafic traverse bien le point de contrôle attendu.

Politique firewall

#

La stratégie appliquée est simple:

• tout bloquer par défaut
• autoriser uniquement ce qui est nécessaire
• journaliser les flux importants
• exposer le minimum de services

Exemple UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw default deny routed
sudo ufw allow 2222/tcp
sudo ufw enable

Les règles ufw allow protègent le firewall lui-même. Les flux entre zones nécessitent des règles routées, par exemple ufw route allow, ou des règles nftables équivalentes. La matrice cible est la suivante :

Une politique stateful laisse revenir les réponses d’une connexion autorisée sans créer une règle inverse trop large. Le principe central reste : autoriser un flux métier précis, puis refuser le reste.

Durcissement du serveur web

#

Le serveur web héberge une application simple exposée uniquement via HTTPS.

Installation:

sudo apt update
sudo apt install apache2 php -y
sudo systemctl enable apache2
sudo systemctl start apache2

Ports autorisés:

• SSH d’administration sur port non standard
• HTTPS

HTTP clair peut être redirigé ou désactivé selon le besoin.

TLS avec certificat auto-signé

#

Génération d’une clé privée:

sudo openssl genrsa -out /etc/ssl/private/server.key 2048

Création d’un certificat:

sudo openssl req -new -x509 \
  -key /etc/ssl/private/server.key \
  -out /etc/ssl/certs/server.crt \
  -days 365

Activation SSL Apache:

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo systemctl reload apache2

Un certificat auto-signé chiffre la session, mais il n’apporte une authentification fiable que si son autorité ou son empreinte est distribuée par un canal de confiance. Accepter aveuglément l’avertissement du navigateur protège contre l’écoute passive, pas contre un attaquant actif capable de présenter son propre certificat.

Sécurisation de la base de données

#

La base de données ne doit jamais être exposée directement depuis Internet ou depuis le réseau attaquant.

Mesures appliquées:

• écoute limitée au réseau interne
• accès autorisé uniquement depuis le serveur web
• durcissement de l’installation
• comptes DB dédiés
• privilèges minimaux

Exemple:

sudo mysql_secure_installation

Règle réseau attendue:

web -> db:3306 autorisé
autres hôtes -> db:3306 bloqué

Chiffrement des données sensibles

#

Les données sensibles et sauvegardes peuvent être chiffrées avant stockage ou transfert.

Exemple avec GPG:

gpg --symmetric backup.sql

Objectifs:

• protéger les sauvegardes
• réduire l’impact d’une fuite de fichiers
• ajouter une couche de défense hors ligne

Fail2ban

#

Fail2ban protège les services exposés contre les tentatives répétées.

Installation:

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Exemple de contrôle:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Fail2ban est une couche de ralentissement et de réaction. Il ne remplace ni les clés SSH, ni la désactivation de l’authentification par mot de passe, ni une restriction réseau de l’administration. Il faut également tester la rotation des logs et le comportement en présence d’adresses partagées pour éviter les bannissements indésirables.

Validation par attaques contrôlées

#

Scan réseau

#

Depuis la VM attaquante:

nmap -p- 192.168.10.1
nmap -p- 192.168.20.20
nmap -p- 192.168.30.30

Résultat attendu:

• le web expose uniquement les ports nécessaires
• la DB ne doit pas exposer MySQL directement
• le firewall limite l’accès administratif

Test brute force SSH

#

Test contrôlé avec Hydra:

hydra -l user -P /usr/share/wordlists/rockyou.txt ssh://192.168.10.1 -s 2222

Résultat attendu:

• aucun mot de passe valide
• bannissement automatique après plusieurs échecs
• logs Fail2ban visibles

Test applicatif OWASP light

#

Un test rapide est réalisé avec sqlmap contre une route applicative de test.

sqlmap -u "https://192.168.20.20/app.php?id=1" --batch

Le but n’est pas d’exploiter l’application à tout prix, mais de vérifier que le lab permet aussi de tester des contrôles applicatifs.

Test TLS

#

Contrôle de la configuration TLS:

nmap --script ssl-enum-ciphers -p 443 192.168.20.20

Points à vérifier:

• protocoles faibles désactivés
• ciphers faibles évités
• certificat présent
• redirection HTTP si nécessaire

Documentation et signature

#

Le projet inclut aussi une logique d’intégrité documentaire avec OpenPGP.

Exemple:

gpg --full-generate-key
gpg --armor --detach-sign rapport.pdf

Objectif:

• garantir l’intégrité d’un livrable
• prouver qu’un document n’a pas été modifié
• introduire une approche cryptographique pratique

Résultats obtenus

#

La validation peut être suivie comme une matrice de contrôles plutôt que comme une simple liste de commandes :

Les tests montrent que:

• la segmentation limite l’exposition de la base de données
• le firewall joue bien son rôle de point de contrôle
• HTTPS protège les échanges web
• Fail2ban réduit l’efficacité des attaques automatisées
• les scans révèlent uniquement les services attendus
• le lab est reproductible grâce à Vagrant

Recommandations d’amélioration

#

Améliorations possibles:

• ajouter un reverse proxy
• utiliser Let’s Encrypt dans un environnement public
• centraliser les logs avec Wazuh
• ajouter des dashboards SIEM
• automatiser la configuration avec Ansible
• intégrer des tests de conformité CIS
• ajouter des règles IDS/Suricata

Références techniques

#

• HashiCorp, principes réseau de Vagrant : https://developer.hashicorp.com/vagrant/docs/networking
• HashiCorp, réseaux privés Vagrant : https://developer.hashicorp.com/vagrant/docs/networking/private_network
• Ubuntu, manuel de référence UFW : https://manpages.ubuntu.com/manpages/noble/en/man8/ufw.8.html
• Mozilla, générateur de configuration TLS : https://ssl-config.mozilla.org/
• Fail2ban, documentation du projet : https://www.fail2ban.org/wiki/index.php/Main_Page

Ce que ce projet m’a apporté

#

Ce projet m’a permis de travailler:

• la conception réseau sécurisée
• le routage Linux
• le filtrage UFW
• la sécurisation Apache/TLS
• la protection SSH
• le cloisonnement d’une base de données
• la validation offensive d’une architecture défensive

Conclusion

#

Ce lab montre qu’une architecture sécurisée ne repose pas sur un seul outil. Elle dépend d’un ensemble de décisions cohérentes: segmentation, filtrage, chiffrement, durcissement, supervision et tests réguliers.

C’est un projet que je peux enrichir progressivement avec une couche SIEM, une automatisation Ansible et des scénarios purple team plus avancés.