Module 3Protéger les applications Web
Chapitre 8 sur 9
Les règles de pare-feu avec ufw et iptables, la DMZ, les dix principes du développement sécurisé, les en-têtes de sécurité et le pare-feu applicatif web (WAF).
Objectifs
Avec ce chapitre, tu sauras…
ufw et iptables ;Leçon 1
Pour un serveur web, la règle est simple : seuls les ports nécessaires sont ouverts au public. Un site web a besoin des ports 80 (HTTP, pour rediriger vers HTTPS) et 443 (HTTPS). Le port 22 (SSH, administration) n'est ouvert qu'aux adresses de l'équipe. Le port 3306 (MySQL) n'est jamais ouvert sur Internet : seule l'application, sur le même serveur ou le même réseau privé, parle à la base.
Tableau: Comment le pare-feu contrôle le trafic
| Méthode | Principe | Couche |
|---|---|---|
| filtrage de paquets (statique) | chaque paquet est comparé à des filtres (adresses, ports, protocole) : il passe ou il est supprimé ; la méthode la plus simple, disponible sur la plupart des routeurs | réseau et transport (3 et 4) |
| service proxy | le pare-feu sert d'intermédiaire : le client se connecte au proxy, qui se connecte au serveur ; aucune connexion directe entre l'extérieur et l'intérieur ; très sûr mais plus lent, et limité aux protocoles qu'il comprend | application (7) |
| inspection dynamique (avec état) | le pare-feu examine plusieurs éléments de chaque paquet (adresses, ports, état de la connexion, application) et les compare à une base d'informations de confiance ; il sait si un paquet appartient à une connexion légitime déjà ouverte | 3 à 7 |
| Action | Effet | Ce que voit l'émetteur |
|---|---|---|
| Accept | le trafic est autorisé | la connexion fonctionne |
| Reject | le trafic est bloqué et le pare-feu répond par une erreur « inaccessible » | un refus immédiat |
| Drop | le trafic est bloqué sans réponse | rien : la connexion expire au bout d'un long délai (le port semble inexistant) |
Leçon 2
| N° | Principe | Exemple concret |
|---|---|---|
| 1 | minimiser la surface d'attaque | chaque fonctionnalité est une porte possible : la recherche n'est accessible qu'aux utilisateurs connectés ; on supprime les pages de test et les API inutilisées |
| 2 | établir des valeurs par défaut sûres | un nouveau compte a les droits minimaux ; la MFA, l'expiration des sessions et les règles de mot de passe sont activées par défaut |
| 3 | moindre privilège | un « auteur » du blog publie ses articles mais ne gère pas les utilisateurs ; le compte MySQL de l'application n'a pas le droit DROP |
Leçon 3
| Type | Ce qu'il surveille |
|---|---|
| basé sur le réseau | le trafic réseau destiné à une application, avant qu'il n'atteigne le serveur (équipement ou service placé devant) |
| basé sur l'hôte | tout le trafic entrant et sortant initié par une application ou un service sur une machine donnée (un module du serveur web, ou un pare-feu qui autorise ou bloque chaque programme) |
1Une règle qui bloque sans envoyer de réponse est…
2Le port qui ne doit jamais être ouvert sur Internet pour un site PHP/MySQL est…
3La politique par défaut recommandée pour le trafic entrant est…
4Un WAF travaille sur la couche…
5iptables est…
6Cacher l'URL de l'administration au lieu de la protéger viole le principe…
7L'en-tête qui oblige le navigateur à n'utiliser que HTTPS est…
8Le WAF le moins coûteux et le plus rapide à mettre en place est souvent…
L'essentiel du chapitre
ufw et iptables ; DMZ pour les serveurs exposés.nosniff, frame-ancestors, Referrer-Policy ; Options -Indexes, fichiers sensibles interdits.| 4 | défense en profondeur | pour la connexion : mot de passe + MFA + limitation des tentatives + Captcha après 3 échecs + journalisation + alerte |
| 5 | échouer de manière sécurisée | une erreur ne donne aucun droit supplémentaire et n'affiche aucune information interne (requête SQL, chemin de fichier, trace) |
| 6 | ne pas faire confiance aux services tiers | valider les données renvoyées par une API externe comme une saisie utilisateur ; ne pas donner de droits élevés à un service tiers |
| 7 | séparation des fonctions | un client du site marchand ne peut pas être administrateur (il pourrait modifier ses propres commandes) ; celui qui crée un paiement n'est pas celui qui le valide |
| 8 | pas de sécurité par l'obscurité | si l'interface d'administration n'est protégée que parce que son URL est « secrète », elle n'est pas protégée |
| 9 | rester simple | des mécanismes de sécurité trop complexes multiplient les erreurs ; utiliser les fonctions éprouvées (password_hash, PDO) plutôt qu'un système maison |
| 10 | corriger correctement les problèmes de sécurité | trouver la cause profonde, corriger, tester, puis chercher la même erreur ailleurs dans le code (elle est souvent copiée à plusieurs endroits) |
| En-tête | Protection |
|---|---|
Strict-Transport-Security: max-age=31536000 (HSTS) | le navigateur n'utilise plus que HTTPS pour ce site pendant un an : protège contre l'homme du milieu |
Content-Security-Policy: default-src 'self' (CSP) | n'autorise que les scripts, styles et images du site lui-même : limite fortement les XSS |
X-Content-Type-Options: nosniff | le navigateur respecte le type MIME annoncé (un fichier texte ne sera pas exécuté comme un script) |
Content-Security-Policy: frame-ancestors 'none' (ou l'ancien X-Frame-Options: DENY) | interdit d'afficher le site dans une <iframe> d'un autre site : protège contre le clickjacking |
Referrer-Policy: strict-origin-when-cross-origin | n'envoie pas l'URL complète (qui peut contenir des paramètres) aux autres sites |
| Modèle de règles | Principe |
|---|---|
| modèle négatif (liste noire) | bloque ce qui ressemble à une attaque connue (signatures d'injection, de XSS) ; facile à déployer, mais une attaque nouvelle peut passer |
| modèle positif (liste blanche) | n'autorise que ce qui est attendu (id doit être un entier, email un e-mail) ; très sûr, mais demande de bien connaître l'application |
| Type de WAF | Avantages | Inconvénients | Exemples |
|---|---|---|---|
| basé sur le réseau (matériel) | installé localement, latence minimale | le plus coûteux ; équipement physique à stocker et à maintenir | appliances F5, Fortinet |
| basé sur l'hôte (logiciel intégré au serveur) | moins cher, très personnalisable | consomme les ressources du serveur ; complexe à mettre en œuvre et à maintenir | ModSecurity (module Apache, Nginx, IIS) avec les règles OWASP CRS |
| basé sur le cloud | abordable, rapide à mettre en place (changement de DNS), mis à jour par le fournisseur, absorbe aussi les DDoS | abonnement ; on confie son trafic à un tiers : vérifier les options de personnalisation | Cloudflare, AWS WAF, Azure WAF |
Pour chaque attaque, indique si elle est arrêtée par un pare-feu réseau, par un WAF, par les deux ou par aucun : (1) une connexion venant d'Internet vers le port 3306 ; (2) GET /recherche.php?q=<script>alert(1)</script> ; (3) un SYN flood massif ; (4) un employé qui tape son mot de passe sur un faux site ; (5) GET /telecharger.php?f=../../.env ; (6) un scan de tous les ports du serveur.
Les règles de pare-feu
Le trafic qui traverse le pare-feu est comparé à une liste de règles, dans l'ordre. Chaque règle contient une condition (protocole, port, adresse source, interface, état de la connexion) et une action :
Reject est plus poli pour les utilisateurs légitimes qui se trompent (ils comprennent tout de suite que c'est bloqué). Drop donne moins d'informations à un pirate qui scanne les ports et ralentit son scan. En pratique, on utilise Drop pour le trafic venant d'Internet et Reject sur le réseau interne.
Les exemples du résumé, pour un serveur qui a une interface publique et une interface privée :
Le troisième exemple du résumé dit « Drop le trafic entrant, nouveau et établi, de la plage d'adresses IP de votre bureau vers l'interface du réseau privé sur le port 22 ». Il s'agit visiblement d'une erreur de traduction du tutoriel d'origine, où cette règle autorise l'administration SSH depuis le bureau : avec Drop, plus personne ne pourrait administrer le serveur.
La politique par défaut
Un pare-feu bien configuré a une politique par défaut qui refuse tout le trafic entrant (deny by default), puis des règles qui autorisent uniquement ce qui est nécessaire (liste blanche). L'inverse (tout autoriser, puis bloquer ce qui est dangereux) oublie toujours quelque chose.
sudo ufw default deny incoming # politique par défaut : refuser tout le trafic entrant
sudo ufw default allow outgoing # le serveur peut sortir (mises à jour, API)
sudo ufw allow 80/tcp # HTTP (redirigé vers HTTPS par Apache)
sudo ufw allow 443/tcp # HTTPS
sudo ufw allow from 192.168.10.0/24 to any port 22 proto tcp # SSH : seulement l'équipe technique
sudo ufw enable
sudo ufw status numbered # afficher les règles numérotéesiptables -P INPUT DROP # politique par défaut : Drop
iptables -A INPUT -i lo -j ACCEPT # trafic local de la machine
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # réponses aux connexions ouvertes (avec état)
iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j REJECT # SSH depuis ailleurs : refus explicite
# le port 3306 (MySQL) n'est jamais autorisé : il tombe dans la politique par défaut (Drop)Les règles sont lues de haut en bas et la première qui correspond s'applique. Si la règle REJECT du port 22 était placée avant la règle qui autorise l'équipe technique, plus personne ne pourrait se connecter en SSH. Et attention : activer un pare-feu à distance sans avoir autorisé SSH coupe ta propre connexion.
Pare-feu logiciel ou matériel
Le pare-feu logiciel est disponible sur tous les systèmes modernes (pare-feu Windows Defender, ufw et nftables/iptables sous Linux) : il est peu coûteux et protège chaque machine. Le pare-feu matériel (un équipement dédié ou un routeur) protège tout le réseau, analyse le trafic en profondeur et décharge les serveurs. Les deux sont complémentaires.
La zone démilitarisée (DMZ)
┌──────────────────── DMZ ────────────────────┐
Internet ── pare-feu externe ── serveur web (ports 80, 443) │
│ serveur de messagerie │
└─────────────────────┬───────────────────────┘
pare-feu interne (seul le serveur web peut joindre MySQL sur 3306)
│
réseau interne : base de données, postes des employésLa DMZ (zone démilitarisée) est un réseau intermédiaire qui accueille les serveurs exposés à Internet. Si le serveur web est piraté, le pirate est dans la DMZ, pas dans le réseau interne : il doit encore franchir le pare-feu interne, qui n'autorise que le strict nécessaire (le port 3306, depuis le seul serveur web, vers le seul serveur de base de données).
Il est impossible d'écrire une application parfaitement sûre : des bugs se glissent toujours, et les attaquants les trouvent. Mais on peut concevoir l'application pour que ces bugs fassent le moins de dégâts possible : qu'ils ne donnent pas accès à toutes les données et ne fassent pas tomber tout le service. C'est le but des dix principes de sécurité de la conception, popularisés par l'OWASP.
Un pare-feu applicatif analyse, surveille et contrôle le trafic à destination ou en provenance d'une application ou d'un service, en comprenant son contenu (couche 7). Il complète le pare-feu réseau, qui ne voit que les adresses et les ports.
Le résumé cite iptables comme exemple de pare-feu applicatif basé sur le réseau. C'est inexact : iptables est un filtre de paquets (couches 3 et 4, avec suivi d'état) intégré au noyau Linux ; il ne lit pas le contenu des requêtes HTTP. Un exemple de pare-feu applicatif est ModSecurity, ou un WAF en cloud.
Le pare-feu d'application web (WAF)
Un WAF (Web Application Firewall) protège les applications web en filtrant et surveillant le trafic HTTP et HTTPS entre l'application et Internet. Placé entre les utilisateurs et les serveurs, il analyse chaque requête et applique des règles pour séparer le trafic légitime du trafic malveillant : injection SQL, XSS, inclusion de fichiers, traversée de répertoire, falsification de requête intersites (CSRF), robots abusifs.
navigateur ── HTTPS ──► pare-feu réseau ──► WAF ──► serveur web (Apache + PHP) ──► MySQL
(ports, adresses) (contenu des requêtes HTTP :
GET /fiche.php?id=1' OR '1'='1 → 403 bloqué)Pour l'application de gestion de stagiaires : (1) crée le fichier .htaccess avec les en-têtes de sécurité du cours (commentaires sur des lignes séparées) ; (2) vérifie dans les outils de développement (onglet Réseau, en-têtes de réponse) que les en-têtes sont bien envoyés ; (3) ajoute un try/catch qui échoue de manière sécurisée autour des accès à la base ; (4) passe display_errors à Off et log_errors à On dans php.ini ; (5) relis ton carnet de sécurité depuis le chapitre 1 : quelles failles reste-t-il ?
Un serveur Ubuntu héberge l'application de gestion de stagiaires (Apache, PHP, MySQL sur la même machine). Le réseau de l'administration de l'ISTA est 10.20.0.0/16. Écris les commandes ufw pour : politique par défaut sûre ; HTTP et HTTPS pour tous ; SSH seulement depuis le réseau de l'administration ; MySQL inaccessible de l'extérieur. Indique ensuite ce que fait la commande sudo ufw deny 21/tcp et si elle est utile.
Nomme le principe de développement sécurisé respecté ou violé : (1) en cas d'erreur, la page affiche SQLSTATE[42S02]: Table 'ista.notes2' doesn't exist ; (2) l'application supprime l'ancien module de messagerie que personne n'utilise ; (3) les données reçues de l'API d'une banque partenaire sont insérées dans la base sans validation ; (4) un développeur corrige une injection SQL dans fiche.php et vérifie toutes les autres requêtes du projet ; (5) le comptable qui saisit les virements ne peut pas les valider lui-même ; (6) les nouveaux comptes sont créés avec le rôle administrateur « pour simplifier ».
<?php
try {
$stmt = $pdo->prepare('SELECT * FROM notes WHERE stagiaire_id = ?');
$stmt->execute([$id]);
$notes = $stmt->fetchAll();
} catch (PDOException $e) {
error_log('Erreur notes : ' . $e->getMessage()); // le détail va dans le journal du serveur
http_response_code(500);
exit('Une erreur est survenue. Réessaie plus tard.'); // le visiteur ne voit rien d'interne
}Les en-têtes de sécurité HTTP
Le serveur peut demander au navigateur d'appliquer des protections supplémentaires grâce à des en-têtes de réponse. C'est une application directe de la défense en profondeur.
# pas de listage du contenu des dossiers
Options -Indexes
# en-têtes de sécurité
Header always set Strict-Transport-Security "max-age=31536000"
Header always set Content-Security-Policy "default-src 'self'; frame-ancestors 'none'"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
# fichiers sensibles (.env, .git…) inaccessibles
<FilesMatch "^\.(env|git)">
Require all denied
</FilesMatch>Dans httpd.conf, ServerTokens Prod et ServerSignature Off évitent d'afficher la version exacte d'Apache dans les en-têtes et les pages d'erreur, et expose_php = Off dans php.ini masque la version de PHP. Ce n'est pas une protection en soi (principe 8), mais cela ne donne pas d'indice gratuit aux robots qui cherchent des versions vulnérables.
Tableau: Les trois façons de déployer un WAF
SecRuleEngine On
SecRule ARGS "@detectSQLi" \
"id:100001,phase:2,deny,status:403,log,msg:'Injection SQL détectée'"En pratique, on n'écrit pas les règles soi-même : on active l'OWASP Core Rule Set (CRS), un ensemble de règles libres qui couvre l'OWASP Top 10. ModSecurity, longtemps développé par Trustwave, est maintenu par l'OWASP depuis 2024.