Firewall ou WAF : ce que chacun voit et arrête

Ce qu'un firewall stateful décide

Un firewall de couche 3/4 suit les connexions et juge chaque nouvelle connexion sur ses adresses, son port et l'état du flux auquel elle appartient. Cisco Firepower, OPNsense et netfilter le font tous bien : un port qu'aucune règle n'ouvre est fermé, une réponse n'est autorisée que pour une connexion initiée de l'intérieur, et les ports de gestion ne répondent qu'aux plages placées en allow-list. Sa vision s'arrête à la couche transport. Avec TLS sur le chemin, il ne peut rien voir dans la charge utile à moins de terminer la session, et même en clair il n'a aucune notion d'URL, d'en-tête, de code de réponse ou de connexion.

Ce qu'un WAF ajoute

Un web application firewall lit la transaction HTTP après la terminaison TLS, ce qui en pratique veut dire qu'il vit dans le reverse proxy ou à côté de lui. Il ajoute trois types de contrôle que le firewall ne peut pas exprimer. Les règles de signature, comme ModSecurity avec l'OWASP Core Rule Set, repèrent dans la requête les injections, les traversées de répertoires et les charges d'exploitation connues. Les règles comportementales comptent par client et par chemin : requêtes par minute sur la route de connexion, réponses d'échec de connexion par adresse, signes de bot dans les en-têtes et le rythme. Les règles positives déclarent ce qu'un chemin accepte, par exemple quelles méthodes, quels types de contenu et quelle taille de corps, et refusent le reste.

Un WAF ne remplace pas le firewall. Il ne voit que le trafic qui l'atteint, et il ne sait rien de SSH, des ports de bases de données ou du plan de gestion.

Où l'abus de connexion devient visible

Une connexion échouée est un fait dans la réponse. L'application répond à un POST vers le chemin de connexion par un code ou une redirection qui distingue l'échec du succès, et le proxy l'écrit dans son access log à chaque tentative. Compter les échecs par client et par minute tient en une ligne d'awk sur ce log, et c'est le signal qu'un filtre de paquets n'a aucun moyen de voir.

Le contrôle doit être indexé sur le client, pas sur le compte. Le verrouillage de compte, à lui seul, arrête les tentatives contre un nom d'utilisateur et met son propriétaire à la porte, pendant que le bot passe au nom suivant de sa liste. Une limite de débit par client sur la route de connexion fait ce que le verrouillage ne peut pas faire :

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

HAProxy exprime la même idée avec une stick table indexée sur l'adresse source, et un jeu de règles WAF peut compter directement le code de réponse d'échec de connexion.

Comment les deux s'emboîtent

L'ordre est : le firewall, puis la terminaison TLS et le proxy avec ses règles WAF, puis l'application. La détection appartient à la couche 7, parce que c'est là que se trouvent les preuves. L'application de la mesure peut se faire à l'une ou l'autre couche. Le proxy peut répondre au client fautif par un 429 ou un 403 à sa requête suivante, ce qui suffit pour la plupart des abus. Pour un client qui insiste, le proxy peut pousser l'adresse dans la table dynamique du filtre de paquets pour une durée déterminée, ce qui coupe aussi les autres connexions de ce client et ne coûte rien au firewall par paquet.

Deux points de conception précèdent l'armement de cette boucle de rétroaction. Les plages de gestion et de supervision de l'opérateur vont d'abord dans l'allow-list, pour qu'un test ou une faute de frappe ne puisse pas mettre à la porte les personnes qui exploitent la plateforme. Et les adresses partagées existent bel et bien : un NAT de bureau ou un NAT d'opérateur place beaucoup de monde derrière une seule adresse, donc les blocages portent une expiration courte et une procédure documentée pour les lever. Toute la chaîne est ensuite testée depuis un hôte extérieur au réseau, tel qu'un attaquant la rencontrerait, avant que quiconque ne s'y fie.

Ce qu'aucun des deux ne voit

Un mot de passe correct. Le credential stuffing avec un mot de passe valide ayant fuité ressemble à une connexion réussie pour chaque couche. Cette faille se ferme par l'authentification multifacteur sur le compte et par l'allow-list des chemins d'administration au firewall, pour qu'un identifiant valide soit inutile depuis une adresse qui n'est pas la vôtre.