🧱🔥 De l'utilité des pare-feu
Depuis longtemps l’usage des pare-feu est considéré comme un point important de la sécurité en informatique
Ayant réfléchi à la configuration de mes pare-feu que ce soit directement sur mon serveur ou sur mon routeur, je suis aujourd’hui bien moins enthousiaste sur leur utilité, configurer un pare-feu prend du temps pour une sécurité limité.
Avant d’aller plus loin, il faut distinguer 2 grand cas d’usages de pare-feu :
- le pare-feu d’appareils finaux comme votre ordinateur personnel ou un serveur.
- le pare-feu réseau, en général de routeur, qui va traiter des paquets en transit.
Note : J’omets volontairement dans ce sujet de parler de NAT qui n’est pas un pare-feu, mais peut se configurer via des règles de pare-feu. Pensez donc plutôt à un réseau IPv6 classique quand je parle de pare-feu au niveau du routeur.
Les pare-feu
Qu’est ce qu’un pare-feu concrètement
On imagine souvent que le pare-feu protège des attaques extérieures qui pourrait sans cet instrument entrer comme ils veulent dans votre réseau et vos appareils… la réalité est bien moins épique et bien plus décevante.
En général un pare-feu, ça ressemblera métaphoriquement à ça :
🧱🧱
Oui un mur placé devant un autre mur…
Oui, car en réalité, il ne suffit pas que le port soit ouvert pour que la machine traite l’information :
- si vous n’utilisez pas l’information, elle arrive à la machine et est jeté… pas de nécessité de mettre un second mur.
- De même si vous avec besoin de l’information… Vous ne devez pas la bloquer.
Le pare-feu est donc réellement pertinent dans des cas où à un certain niveau, le système dit “je veux l’information” mais qu’on veut lui imposer par-dessus “il ne faut pas que l’information transite”… il s’agit de situation très particulière, parce que si on a la main sur le système autant ne pas demander l’information directement, non ?
Bref, le pare-feu ne protège pas vraiment des attaques extérieures, mais éventuellement :
- d’éventuelles failles de sécurités de votre installation.
- d’erreurs de configuration.
L’autre intérêt, c’est dans le cas où les responsabilités sont à différents niveaux, par exemple un administrateur réseau va pouvoir avoir envie de mettre des règles très stricte, car il ne fait pas confiance au matériel que les utilisateurs utiliseront.
Néanmoins, on voit que tout cela est bien fragile si on décide explicitement d’utiliser du matériel dont on n’a pas pleinement confiance.
Pour le dire autrement : Mettre a jour ses appareils et ne pas installer des choses auquels, on n’a pas confiance sont des solutions de sécurité infiniment plus pertinente que de bloquer tel ou tel port.
Un pare-feu ne sert donc qu’à réduire les risques, réduire les conséquences d’un “si éventuellement” souvent improbable.
On pourrait se dire, il n’y a qu’à filtrer que le contenu malicieux… sauf qu’entre le coût de traitement, les problèmes de vie-privée, la difficulté technique de comprendre le contenu chiffré, etc. c’est peine perdue.
À noter de que filtrer le contenu malicieux est à la base de la logique des “antivirus” qui sont une technique qui détecte du mauvais contenu par empreinte, ce qui est à la fois malin et une solution très insatisfaisante, car on ne s’attaque pas à la vulnérabilité du système là où elle est vraiment.
Les raisons historiques des pare-feu
Pour bien comprendre pourquoi les pare-feu existent, il faut revenir bien en arrière, historiquement les ordinateurs et les réseaux n’avaient que peu de sécurité et était très permissif, des hackers pouvaient ainsi se balader à volonté dans les réseaux télécom dans les années 70. L’idée de restreinte l’usage de l’ordinateur et qu’une personne mal intentionnée puisse l’utiliser étrangère à beaucoup d’utilisateurs, souvent universitaire de l’époque, hormis peut-être sur quelques appareils militaires spécifiques, ce n’est qu’avec la massification de l’utilisateur que ces questions se sont vraiment posé et que les systèmes et les développeurs ont commencé à ne plus faire n’importe quoi en matière de sécurité.
Dans le même ordre d’idée, plus récemment, la permissivité des systèmes PC dans les années 90 a abouti à une avalanche de catastrophes avec les virus, les intrusions, etc. les systèmes et le personnel n’étaient pas réfléchis dans cette optique et donc des solutions que j’appellerais “mieux que rien” sont apparus : antivirus et aussi pare-feu.
Bref, autrefois, le système était “ouvert au quatre-vent” car les développeurs n’avait juste pas réfléchi à la question, aujourd’hui les systèmes actuels sont bien plus étudié sur ces aspects et donc on peut avoir une confiance relative dans ces logiciels utilisés par des millions voir milliard d’utilisateurs, pour ne pas faire n’importe quoi.
Un pare-feu en 2026, pourquoi faire alors ?
Pour un système Gnu/Linux récent. Je ne conseille personnellement pas spécialement la configuration d’un pare-feu sur vos serveurs ou machine personnelle sauf si vous étes parano ou avez envie d’apprendre : Cela ajoute juste de la complexité pour des cas d’usage ou de toute façon, si vous n’avez pas confiance en votre machine, pourquoi faire confiance dans le fait que le pare-feu lui vous protégera ?
Une solution plus pertinente dans ce cas présent est éventuellement un mécanisme de pare-feu “réactif” comme des logiciels fail2ban ou reaction.
Le cas du pare-feu réseau (en milieu de réseau) est un peu différent à mon sens, car on peut imaginer des choses plus pertinentes :
- vous utilisez volontairement des appareils auquel vous ne faites pas pleinement confiance (exemple : IOT).
- vous ne faites pas confiance en les utilisateurs de votre réseau donc vous voulez limiter la casse.
- vous voulez autoriser le traffic que depuis des appareils spécifiques.
- probablement d’autres cas auquel je n’ai pas pensé…
Quelles règles établir pour son routeur chez soi ?
Si vous êtes dans le cas d’un réseau domestique, il y a forte a parié que vous ne pas chercher spécialement à surprotéger votre réseau, vous voulez avant tout profiter de l’internet avec peu de friction…
Il est donc compliqué de décider de règles d’autant que vous n’êtes souvent pas seul à utiliser le réseau.
Faut-il du coup mettre un pare-feu et si oui quelles règles ?
Le comportement le plus classique des pare-feu réseau est le suivant :
- traffic sortant : on autorise tout.
- traffic entrant : on autorise uniquement le traffic déjà établi.
L’idée est astucieuse, car cela interdit d’un coup tout potentiel serveur ou faille de sécurité en contact direct des machines du réseau. Des intrusions sont toujours en théorie possible, mais bien moins évidente.
Limite de ces règles ?
Mais du coup, quel type de services légitime cette règle par défault peuvent-elles bien bloquer ?
- Les serveurs.
- les systèmes P2P : Torrents, Syncthings, appel audio et vidéo.
Pour le 1er point, le problème est relatif, en effet si vous hébergez un serveur, pourquoi ne pas l’autoriser dans les règles de votre routeur une bonne fois pour toutes.
Pour le second point… c’est plus embêtant. Si vous devez ouvrir systématiquement des ports manuellement pour tel ou tel usage P2P ça risque d’etre compliqué.
Faut-il donc tout autoriser au nom du P2P ?
La réponse est compliquée, car cela dépend réellement de comment les systèmes que vous utilisez fonctionne.
Le fait est que l’état actuel des réseaux est d’interdire certain usage par défault, de façon explicite (pare-feu) mais aussi implicite du fait du NAT en IPv4. Donc les services qui se basent sur du P2P ont dû trouver des solutions pour fonctionner. Ces solutions sont multiples :
- mécanisme côté routeur pour autoriser les logiciels clients à ouvrir des ports (protocole uPnP et PCPv2 notamment).
- mécanisme de relai (protocole TURN).
- mécanisme pour créer une “session” UDP via un relai (protocole STUN).
La 1ére solution n’a pas une super bonne réputation notamment à cause d’uPnP, elle implique aussi que le routeur soit compatible, néanmoins, il existe un certain nombre d’applications qui tente si uPnP est disponible d’ouvrir le port.
La seconde solution consiste à tirer parti du comportement de la plupart des pare-feu pour ouvrir une session entre les deux machines mal gré le pare-feu qui l’empêche, elle ne fonctionne donc pas pour tous les pare-feu, mais une bonne majorité.
La dernière solution est la solution de dernier recours, elle implique de la perte de performances et l’obligation de faire tout transiter par une machine tierce.
Comme on peut le constater aucune de ces méthodes n’est pleinement satisfaisante, pour autant, c’est la situation actuelle de la majorité des utilisateurs aujourd’hui et ça fonctionne visiblement assez bien.
La règle d’interdire les connections entrantes peut donc bel et bien être gardé sans poser tellement de problèmes, car les développeurs ont déjà fait le travail de contournement.
TLDR : Quelle règle je mets du coup sur mon réseau domestique ?
Il n’est pas nécessaire de chercher à être original, interdisez les connections entrantes non établies comme tout le monde et tout ira bien.
Si vous voulez vous distinguer un peu, vous pouvez envisager d’autoriser la plage haute de l’UDP (>1024) qui sont utilisé pour les applications P2P.
Si la paranoia est votre passion et que vous connaissez bien votre réseau, vous pouvez aussi vous amuser à autoriser que les traffics existant, mais je suis assez perplexe sur l’utilité, cela dit, c’est une très bonne façon d’apprendre à connaître les pare-feu et votre réseau.
Quant au mécanisme tel qu’uPnP et PCPv2 (la version moderne du système), ils ne me semblent pas assez utiliser largement que ce soit niveau client ou serveur (seul MiniUPnP semble implémenter le protocole serveur en opensource) pour que cela en vaille vraiment la peine.
Bref tout cas pour au final revenir au point de départ : Un pare-feu des plus classiques. Cela en est un peu frustrant.
Voilà c’est tout pour aujourd’hui .