Firewalls from Scratch You May Be Asking the Wrong Question

SYNTHÈSE STRUCTURÉE

Le problème historique de l’egress

L’intervenant rappelle que dans les années 90, les firewalls n’avaient qu’un rôle : empêcher les menaces d’entrer. Le trafic sortant était considéré comme fiable car il provenait de machines internes. « Pourquoi voudriez-vous empêcher vos propres ordinateurs de parler à Internet ? » Cette question semblait absurde à l’époque, mais l’apparition de chevaux de Troie comme Back Orifice (1998) ou Sub7 a changé la donne : une fois un malware à l’intérieur, il lui suffisait d’une connexion sortante pour recevoir des commandes. La métaphore du sous-marin illustre bien le problème : « Vous pouvez avoir la porte d’entrée la plus solide sur un sous-marin, mais si vous mettez une moustiquaire quelque part, il ne flottera pas. »

L’IA change la donne en 2026

L’auteur cite les équipes de Mandiant (Google) qui documentent des attaques comme « prompt flux » ou « prompt steel » : des malwares capables d’appeler des API de grands modèles de langage pendant leur exécution pour générer du code ou s’adapter en temps réel. Check Point décrit ce passage de l’IA comme « assistant de préparation d’attaque » à « participant actif à l’attaque ». Cela rend la détection par signature ou comportement connu obsolète, car le malware peut se réécrire lui-même. La solution n’est plus de reconnaître la menace, mais de définir une politique stricte : « Si cette machine n’est pas autorisée à parler à celle-là, alors non, aucune communication ne peut avoir lieu. »

La limite des outils classiques comme PfSense, PfBlockerNG ou Pi-hole

L’intervenant mentionne la sortie de PfSense 2.6.0.7 et son contrôleur Nexus avec Threatgate, qui pousse vers une politique d’egress « zero trust » (tout bloquer par défaut, sauf autorisation explicite). Mais il note que ces outils, comme PfBlockerNG ou Pi-hole, fonctionnent sur un modèle inverse : ils autorisent tout par défaut puis bloquent ce qui est listé comme malveillant. « Si ce n’est pas sur la liste, ça sort par défaut. Ce n’est pas la même chose que le default deny egress. » Cette approche est « à 180 degrés » de ce qu’il faut construire.

Le firewall a deux missions distinctes

La première mission est l’ingress : empêcher les trafics non désirés d’entrer. La seconde est l’egress : garantir que seuls les trafics autorisés sortent. L’intervenant pose une question importante : faut-il mettre ces deux fonctions sur le même équipement ? Si l’egress est compromise, toute la sécurité est à risque. Il recommande de placer l’egress au point de sortie du réseau, juste avant Internet, mais de ne pas commencer par une politique de blocage total.

Commencer par observer avant de bloquer

L’avertissement est clair : « Si je mets une politique de drop total sur l’egress et que mes règles d’ingress échouent, j’ai fonctionnellement déconnecté mon WAN de mon réseau. » Il propose donc de commencer par activer une surveillance du trafic pour comprendre ce qui est normal : quelles destinations, quels ports, quels protocoles, quels serveurs DNS sont utilisés. « Vous ne pouvez pas écrire une politique saine si vous ne comprenez pas ce qui est normal dans votre trafic. » Il faut aussi identifier les machines à haute valeur (postes d’administration, systèmes avec clés ou identifiants) pour prioriser les règles.

Le rôle central de nftables

L’intervenant annonce que la construction du firewall se fera avec nftables, le successeur moderne d’iptables sous Linux. Il insiste sur le fait que cette approche reste sous le contrôle de l’administrateur, contrairement aux solutions propriétaires comme Threatgate qui dépendent de matériel supporté et de vérifications matérielles (SMBIOS, UUID) qui peuvent échouer sur certains systèmes comme les Protectli avec Coreboot.

CONCEPTS CLÉS

• Egress firewall : politique de filtrage du trafic sortant, visant à empêcher les communications non autorisées depuis l’intérieur du réseau vers l’extérieur.
• Ingress firewall : filtrage du trafic entrant, la fonction historique des firewalls.
• Default deny : principe de sécurité où tout est bloqué par défaut, et seules les exceptions explicitement définies sont autorisées.
• Zero trust egress : application du modèle « ne jamais faire confiance, toujours vérifier » au trafic sortant, en opposition au modèle « autoriser par défaut, bloquer sur liste ».
• nftables : framework de filtrage réseau sous Linux, remplaçant iptables, avec une syntaxe plus lisible et des performances améliorées.
• Threatgate / Nexus controller : fonctionnalités de PfSense pour l’egress policy, nécessitant un matériel spécifique et des identifiants matériels valides (SMBIOS, UUID).

CONCLUSION

Le message principal est que la sécurité réseau ne peut plus se limiter à bloquer les entrées. Avec des malwares capables de s’adapter en temps réel via l’IA, la seule défense fiable est une politique d’egress stricte : tout ce qui sort doit être explicitement autorisé. Mais cette politique ne s’improvise pas : il faut d’abord observer et comprendre son trafic normal, puis construire des règles nftables progressivement, en évitant de tout bloquer d’un coup pour ne pas se couper du monde. La vidéo pose les bases conceptuelles ; la construction pratique viendra dans une prochaine session.