🌐 Séance 1 : Apache 2.4, Nginx et TLS — C2.2.4

Introduction (10 min)

Accroche : En décembre 2021 l'exploit Log4Shell (CVE-2021-44228) a permis à des attaquants d'injecter une chaîne malveillante via des en-têtes HTTP (User-Agent, Referer) envoyés à des serveurs frontaux (Nginx/Apache) qui reverse-proxyaient des applications Java utilisant Log4j. Dans plusieurs architectures DMZ, le proxy web a servi de vecteur et a relayé des requêtes malicieuses vers l'application vulnérable, entraînant compromission et exfiltration. Cette séance montre comment configurer correctement les serveurs web (Apache/Nginx) et TLS pour limiter la surface d'attaque, inspecter et durcir les échanges, et déployer des en-têtes de sécurité côté frontal.

À l'issue de cette séance, vous serez capable de :

• configurer Apache 2.4 et ses VirtualHosts (ServerName, DocumentRoot, Directory, logs) et gérer les modules utiles (mod_rewrite, mod_ssl, mod_headers, mod_security2),
• déployer Nginx en frontal comme reverse proxy vers Apache (proxy_pass, upstream, load balancing) et optimiser sa configuration (worker_processes, logs),
• obtenir et vérifier des certificats TLS avec Certbot/Let's Encrypt, activer HSTS et ajouter des en-têtes de sécurité (X-Frame-Options, X-Content-Type-Options, Content-Security-Policy).

1. Apache 2.4 — fondamentaux et bonnes pratiques (70 min)

Apache 2.4 est un serveur web mature qui supporte plusieurs modèles de traitement des requêtes — les MPM (Multi-Processing Modules). Les MPM décrivent si Apache utilise des processus, des threads, ou un mixte pour servir les requêtes ; le choix impacte la consommation mémoire, la concurrence et la compatibilité avec des modules comme mod_php.

Le MPM prefork crée plusieurs processus indépendants, chacun traitant une requête, ce qui évite les problèmes de thread-safety pour des modules non-thread-safe (ex : mod_php historique). En contrepartie, la consommation mémoire est plus élevée. Les MPM worker et event utilisent des threads pour augmenter la concurrence et réduire la mémoire utilisée ; event gère mieux les connexions keep-alive et les workloads asynchrones.

Sur Debian 12, les fichiers de configuration des MPM se trouvent dans /etc/apache2/mods-available/ (mpm_prefork.conf, mpm_worker.conf, …). Seul un MPM est activé à la fois ; on bascule avec a2dismod/a2enmod :

# Exemple : basculer vers mpm_event (plus performant pour reverse proxy + PHP-FPM)
sudo a2dismod mpm_prefork && sudo a2enmod mpm_event
sudo systemctl restart apache2

VirtualHosts

Depuis Apache 2.4 la directive NameVirtualHost est obsolète ; il suffit de déclarer des blocs <VirtualHost *:port> et de définir ServerName/ServerAlias. Voici un VirtualHost minimal adapté à notre PME InnovatTech (Apache configuré pour écouter sur le port 8080, derrière Nginx frontal) :

<VirtualHost *:8080>
    ServerName www.innovattech.fr
    ServerAlias innovattech.fr
    DocumentRoot /var/www/www.innovattech.fr/public_html

    <Directory /var/www/www.innovattech.fr/public_html>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/www.innovattech_fr-error.log
    CustomLog ${APACHE_LOG_DIR}/www.innovattech_fr-access.log combined
</VirtualHost>

Commentaires :

• DocumentRoot définit l'emplacement des fichiers web ; le Directory avec AllowOverride All autorise .htaccess dans ce répertoire (voir remarque performance ci-dessous).
• ErrorLog/CustomLog utilisent la variable ${APACHE_LOG_DIR} (typiquement /var/log/apache2).

Modules importants et commandes

# Activer modules courants sur Debian
sudo a2enmod rewrite ssl headers
# mod_security2 est un WAF (installation supplémentaire)
sudo apt install -y libapache2-mod-security2
sudo a2enmod security2

# Vérifier la configuration Apache (syntax check)
sudo apachectl configtest   # ou sudo apache2ctl configtest
# Redémarrer/relancer
sudo systemctl reload apache2
# Vérifier l'état
sudo systemctl status apache2 --no-pager

Sortie attendue :

$ sudo apachectl configtest
Syntax OK

Performance et .htaccess

Le fichier .htaccess est évalué à chaque requête pour déterminer si des directives locales s'appliquent ; dans des environnements à fort trafic, cela induit une pénalité de performance. La recommandation opérationnelle est de placer les directives dans la configuration principale d'Apache (/etc/apache2/sites-available/*.conf) et de définir AllowOverride None pour désactiver la lecture des .htaccess sauf si nécessaire.

Mod_security2 (notion)

mod_security2 agit comme un WAF (Web Application Firewall) côté Apache ; il inspecte les requêtes et peut bloquer des patterns connus (ex : tentatives d'injection). Il est conseillé d'installer les règles Core Rule Set (OWASP CRS) et d'opérer en mode DetectionOnly au début pour analyser les faux positifs.

2. Nginx — reverse proxy, upstream et tuning (70 min)

Nginx est conçu comme serveur d'entrées (reverse proxy), équilibreur et serveur statique efficace en mémoire. Dans une architecture typique InnovatTech, Nginx écoute sur les ports 80/443 exposés en DMZ et reverse-proxy les requêtes vers Apache (ou vers des pools d'applications) situés en backend.

Configuration principale : worker_processes et tuning des connexions

# /etc/nginx/nginx.conf (extrait)
worker_processes auto;
events { worker_connections 1024; }

http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent"';

    upstream apache_backend {
        server 127.0.0.1:8080;
        # server 192.168.30.6:8080;  # autre serveur Apache pour load balancing
    }

    server {
        listen 80;
        server_name www.innovattech.fr;

        access_log /var/log/nginx/www.innovattech_fr-access.log main;
        error_log /var/log/nginx/www.innovattech_fr-error.log warn;

        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://apache_backend;
            proxy_read_timeout 90;
        }
    }
}

Notes :

• Le bloc upstream définit un pool de backends. Le comportement par défaut est round-robin ; on peut utiliser least_conn ou ip_hash selon les besoins.
• proxy_set_header Host $host; conserve le Host original pour que l'application en backend puisse distinguer le VirtualHost.
• Logs : access_log et error_log sont essentiels pour diagnostiquer le proxy.

Commandes utiles

# Tester la configuration nginx
sudo nginx -t
# Recharger sans couper les connexions
sudo systemctl reload nginx

Sortie attendue :

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

3. TLS/SSL — Certbot, vérification et en-têtes de sécurité (20–30 min)

Let's Encrypt fournit des certificats gratuits et automatisables avec Certbot. Sur un proxy Nginx frontal, la méthode la plus simple est certbot --nginx qui obtient et installe le certificat directement dans la config Nginx.

Commandes Certbot

# Installer certbot et le plugin nginx
sudo apt update
sudo apt install -y certbot python3-certbot-nginx
# Obtenir un certificat (exécution interactive possible)
sudo certbot --nginx -d www.innovattech.fr -m admin@innovattech.fr --agree-tos --no-eff-email
# Test de renouvellement
sudo certbot renew --dry-run

Vérifier le certificat côté client

openssl s_client -connect www.innovattech.fr:443 -servername www.innovattech.fr

Extrait attendu (sélection) :

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Verify return code: 0 (ok)

HSTS et en-têtes de sécurité

Ajouter HSTS protège contre les attaques de downgrade ; X-Frame-Options et Content-Security-Policy réduisent l'exposition au clickjacking et au XSS. Exemple Nginx à ajouter dans le bloc server qui écoute 443 :

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'" always;

Dans Apache, l'équivalent se configure via mod_headers :

# Exemple dans la configuration principale ou VirtualHost
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'"

Travaux Pratiques (70 min)

Contexte du TP

Vous êtes technicien chez InnovatTech SARL. Le responsable réseau vous demande de publier un site public www.innovattech.fr depuis la DMZ (debian-srv02) en utilisant Nginx en frontal (port 80/443) et Apache en backend (écoute 8080). Le nom DNS www.innovattech.fr pointe déjà vers l'IP publique 91.208.45.12. Vous devez obtenir un certificat Let's Encrypt, ajouter des en-têtes de sécurité, et vérifier la qualité de la configuration TLS.

Objectif

Déployer un reverse proxy Nginx qui sert www.innovattech.fr via TLS avec certificat Let's Encrypt, proxifier vers Apache, et activer les en-têtes de sécurité. Livrable : les fichiers de configuration (Apache + Nginx), la preuve d'obtention du certificat, et la sortie de vérification OpenSSL.

Prérequis techniques

• Accès SSH root sur debian-srv02 (DMZ), Debian 12.
• Entrée DNS A pour www.innovattech.fr → 91.208.45.12 (déjà en place).
• Ports 80 et 443 ouverts sur le firewall DMZ vers debian-srv02.

Étape 1 — Préparer le serveur et installer les paquets

sudo apt update && sudo apt install -y apache2 nginx certbot python3-certbot-nginx

Étape 2 — Configurer Apache pour écouter sur le port 8080

Éditer /etc/apache2/ports.conf et remplacer/ajouter :

Listen 8080

Créer le VirtualHost Apache /etc/apache2/sites-available/www.innovattech.fr.conf (voir bloc VirtualHost section 1) et créer l'arborescence :

sudo mkdir -p /var/www/www.innovattech.fr/public_html
echo "<html><body><h1>Site InnovatTech - Apache backend</h1></body></html>" | sudo tee /var/www/www.innovattech.fr/public_html/index.html
sudo a2ensite www.innovattech.fr.conf
sudo apache2ctl configtest && sudo systemctl reload apache2

Résultat attendu : apachectl configtest → Syntax OK et page accessible localement :

curl -sS http://127.0.0.1:8080
# Doit retourner le HTML contenant "Site InnovatTech - Apache backend"

Étape 3 — Configurer Nginx en reverse proxy

Créer /etc/nginx/sites-available/www.innovattech.fr :

server {
    listen 80;
    server_name www.innovattech.fr;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:8080;
    }
}

Activer le site et tester la configuration :

sudo ln -s /etc/nginx/sites-available/www.innovattech.fr /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Vérification :

curl -I http://www.innovattech.fr  # doit répondre via Nginx et retourner 200 ou 301

Étape 4 — Obtenir le certificat Let's Encrypt avec Certbot

sudo certbot --nginx -d www.innovattech.fr -m admin@innovattech.fr --agree-tos --no-eff-email

Sortie attendue : message "Congratulations" et chemins /etc/letsencrypt/live/www.innovattech.fr/

Étape 5 — Ajouter les en-têtes de sécurité

Dans le bloc server qui écoute 443 (modifié par certbot) :

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'" always;

Recharger Nginx :

sudo nginx -t && sudo systemctl reload nginx

Étape 6 — Vérifications finales

# Vérifier en-têtes
curl -I https://www.innovattech.fr
# Vérifier la chaîne TLS
openssl s_client -connect www.innovattech.fr:443 -servername www.innovattech.fr
# Vérifier renouvellement (dry-run)
sudo certbot renew --dry-run

Synthèse de séance (10 min)

Cette séance a couvert la mise en place d'une architecture web moderne où Nginx fait office de frontal performant et d'équilibreur tandis qu'Apache héberge le contenu ou les applications en backend. Nous avons explicité les MPM d'Apache, la structure des VirtualHosts, l'impact des .htaccess sur la performance, l'usage des modules essentiels (mod_rewrite, mod_ssl, mod_headers, mod_security2) et la manière d'obtenir et vérifier un certificat TLS automatisé avec Certbot. La solidité de la chaîne TLS et l'ajout d'en-têtes HTTP de protection réduisent significativement la surface d'attaque exposée aux applications proxyées.

🎮 Quiz — Valide tes connaissances

5 questions · Combo x3 disponible · Scores envoyés au leaderboard SISR