Déploiement & sécurisation d'un serveur web Debian

1. Contexte & problématique

Dans le cadre de l'épreuve E4 du BTS SIO, l'objectif était de concevoir de bout en bout une infrastructure web capable d'être exposée sur Internet sans compromettre la sécurité du système. Les serveurs web mal configurés sont une cible privilégiée des scans automatisés : ports ouverts inutilement, comptes root accessibles en SSH, absence de chiffrement. Le cahier des charges imposait de repartir d'un système vierge plutôt que d'une image préconfigurée, afin de maîtriser chaque brique installée.

2. Architecture mise en place

Le serveur repose sur une machine virtuelle Debian 12 en édition Minimal, sans interface graphique, pour réduire la surface d'attaque et la consommation de ressources. Nginx sert de serveur web frontal, avec un unique reverse proxy exposé publiquement. Le pare-feu Netfilter filtre l'intégralité du trafic entrant et sortant avant même qu'il n'atteigne les services applicatifs.

3. Étapes de réalisation

• Installation du système : déploiement d'une Debian 12 Minimal sur machine virtuelle, partitionnement manuel, création d'un compte administrateur non-root dès l'installation.
• Mise à jour & durcissement de base : mise à jour complète des paquets, désactivation des services non nécessaires, configuration du fuseau horaire et de la synchronisation NTP pour des logs exploitables.
• Configuration du pare-feu Netfilter : écriture de règles iptables avec politique DROP par défaut sur les chaînes INPUT et FORWARD. Autorisation explicite des flux TCP 80 (HTTP), 443 (HTTPS) et du port SSH personnalisé, avec sauvegarde des règles au démarrage via iptables-persistent.
• Sécurisation SSH : changement du port par défaut, désactivation de la connexion directe au compte root (PermitRootLogin no), authentification exclusivement par paire de clés RSA 4096 bits, désactivation de l'authentification par mot de passe.
• Installation & configuration de Nginx : mise en place des blocs serveur, configuration des en-têtes de sécurité (X-Frame-Options, X-Content-Type-Options), désactivation de l'affichage de la version du serveur.
• Protection Fail2ban : configuration d'une jail dédiée à SSH avec bannissement automatique après 3 tentatives infructueuses sur une fenêtre de 10 minutes, durée de bannissement progressive en cas de récidive.
• Chiffrement SSL/TLS : génération d'un certificat, configuration de Nginx pour rediriger systématiquement le trafic HTTP vers HTTPS, désactivation des protocoles TLS obsolètes (TLS 1.0 et 1.1).

4. Difficultés rencontrées

La principale difficulté a été de calibrer les règles Fail2ban sans provoquer de faux positifs lors des phases de test, où de nombreuses connexions légitimes échouaient à cause d'erreurs de configuration côté client. Le second point délicat a concerné la persistance des règles Netfilter au redémarrage, qui nécessitait un service dédié plutôt qu'un simple script.

5. Tests & validation

Le serveur a été testé face à des outils d'analyse de vulnérabilités (Nmap pour le scan de ports, Nikto pour l'analyse des failles web courantes). Seuls les ports strictement nécessaires apparaissent ouverts lors d'un scan externe. Des tentatives de connexion SSH par force brute simulées ont été bloquées après le seuil configuré, confirmant le bon fonctionnement de Fail2ban.

6. Résultat & compétences acquises

Le niveau de durcissement (hardening) atteint permet de bloquer 100 % des tentatives d'intrusion de niveau 1 lors des tests. Ce projet a permis de comprendre en profondeur le fonctionnement d'un pare-feu Linux au niveau des règles, au-delà de la simple configuration d'une interface graphique, ainsi que l'articulation entre plusieurs couches de sécurité complémentaires (réseau, authentification, chiffrement, détection d'intrusion).