Arithmétique de la table d'états : dimensionner un firewall pour les floods, pas pour les moyennes

Demandez à la plupart des gens quelle taille un firewall doit avoir et ils répondent en bande passante. Sous attaque, la bande passante est rarement ce qui s'épuise en premier. C'est la table d'états : la liste des connexions que le firewall suit, qui a une taille fixe, se remplit au rythme d'arrivée des nouvelles connexions, et ne se vide qu'aussi vite que les timeouts le permettent. Comprenez cette arithmétique et vous pourrez dimensionner un firewall pour le jour où cela compte plutôt que pour le jour moyen.

Pourquoi les états s'épuisent avant la bande passante

Quand la table est pleine, les nouvelles connexions sont rejetées, légitimes ou non, même si les liens sont presque inactifs.

Deux sortes de trafic remplissent vite une table :

• Les SYN floods. Chaque SYN usurpé crée une entrée semi-ouverte qui ne se terminera jamais.
• L'UDP vers des services publics. DNS, NTP, serveurs de jeu, VoIP et services similaires voient d'énormes quantités d'échanges courts depuis de nombreuses sources, et chacun peut créer sa propre entrée.

L'arithmétique

Le nombre d'entrées en régime permanent dans une table est, en bonne approximation :

entries  =  new flows per second  x  seconds each entry lives

C'est la loi de Little, et tout le jeu est là. Supposez qu'un flood arrive à 50 000 nouveaux SYN par seconde, et que les entrées TCP semi-ouvertes vivent 30 secondes. La table a besoin de 1 500 000 entrées rien que pour l'attaque, avant qu'un seul vrai utilisateur n'arrive. Réduisez ce timeout à 5 secondes pendant le flood et la même attaque n'a besoin que de 250 000. Même firewall, même mémoire, une différence d'un facteur six due à un seul timer.

Il n'y a donc que trois leviers : une table plus grande (mémoire), des durées de vie plus courtes (timeouts), et moins d'entrées par flux (ne pas suivre d'état du tout là où vous n'en avez pas besoin). Utilisez les trois.

Levier un : dimensionnez la table à dessein

Déterminez la mémoire que la plateforme alloue par entrée d'état, décidez quelle part de la RAM du firewall vous êtes prêt à consacrer aux états, et fixez le maximum à partir de là, plutôt que de vivre avec une valeur par défaut choisie pour un petit bureau. Puis alertez bien avant que la table ne soit pleine.

Sur OPNsense et les firewalls basés sur pf, les chiffres en direct sont à une commande de distance :

pfctl -si | grep -A4 "State Table"
pfctl -sm | grep states

Levier deux : timeouts adaptatifs et SYN cookies

Les timeouts statiques sont un compromis entre la bienveillance envers les clients lents et la survie à un flood. Les timeouts adaptatifs suppriment le compromis : à mesure que la table se remplit au-delà d'un seuil de départ, tous les timeouts diminuent linéairement, pour atteindre zéro à un seuil de fin. Les jours normaux gardent des timers généreux ; sous pression, les entrées expirent vite. En termes pf :

set limit states 2000000
set timeout { adaptive.start 1200000, adaptive.end 2200000 }

Ajoutez les SYN cookies, idéalement dans un mode adaptatif qui ne s'active que lorsque la table franchit un seuil. Avec les cookies, le firewall répond à un SYN sans créer d'état et ne construit une entrée qu'une fois que le client termine la poignée de main, ce qu'une source usurpée ne fait jamais. Cela transforme l'attaque la plus efficace contre un firewall stateful en un trafic que le firewall remarque à peine.

Levier trois : ne suivez pas ce qui n'a pas besoin de l'être

Pour les services UDP à fort volume, suivre chaque échange n'achète presque rien : le service répond depuis un port connu, et les règles sont simples. Une paire de règles stateless (autoriser l'entrant vers le port du service, autoriser le sortant depuis celui-ci) ne crée aucune entrée, donc un flood UDP ne peut pas épuiser la table pour le compte d'un serveur DNS ou NTP. Gardez le traitement stateful pour TCP et pour tout ce dont le trafic de retour doit être strictement lié à une requête sortante.

Gardez les états à travers une panne

Le dimensionnement est la moitié du travail ; l'autre moitié est de ne pas tout perdre quand un nœud tombe. Dans une paire actif et passif, CARP déplace les adresses virtuelles vers le passif, et pfsync réplique la table d'états entre les nœuds en continu, sur un lien dédié lorsque c'est possible. Quand le nœud actif meurt, le passif connaît déjà chaque connexion établie, donc les sessions continuent au lieu que chaque utilisateur se reconnecte. Testez-le : lancez un long téléchargement ou une session SSH à travers la paire, éteignez le nœud actif, et regardez-la continuer.

Deux habitudes pratiques aident. Appliquez les changements de réglage d'abord au passif, vérifiez, puis basculez et changez l'autre nœud ; et répartissez le traitement des paquets sur les cœurs CPU avec des nombres de threads adaptés à chaque appliance, pour qu'un cœur occupé ne devienne pas la vraie limite.

Ordonnez le jeu de règles pour des décisions bon marché

Un flood est moins cher à rejeter tôt. Mettez d'abord les décisions grossières et bon marché : une liste de blocage combinée de renseignement sur les menaces, puis les blocages par pays, puis les plages d'hébergement connues comme abusives, et seulement ensuite les règles d'autorisation par hôte. Nommez chaque alias et chaque règle d'après l'hôte qu'il protège, pour que le jeu de règles se documente lui-même et que les vieilles règles puissent être retirées en confiance.

Vérifiez votre propre firewall

• Quelle est la limite de la table d'états, et quel est le pic du jour en pourcentage de celle-ci ?
• Y a-t-il une alarme bien en dessous de la limite ?
• Les timeouts adaptatifs sont-ils configurés, et les SYN cookies disponibles sous charge ?
• Les services UDP à fort volume sont-ils traités en stateless ?
• Dans une paire HA, les états sont-ils synchronisés, et avez-vous testé un basculement avec des sessions en cours ?
• Savez-vous ce qu'une attaque à dix fois votre taux de connexions normal ferait à la table ? Faites la multiplication.

Nos firewalls de périmètre à Athènes fonctionnent en paires stateful construites et réglées de cette façon, modifiées uniquement par leur API. Si vous voulez de l'aide pour faire l'arithmétique des vôtres, nous nous asseyons volontiers avec vous.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Firewalls de périmètre infogérés · Comment nous changeons les choses : la discipline de changement réseau · Supervision du réseau et preuves