Une histoire pratique du pare-feu - Partie 1 : les débuts

Jody Brazil
CEO de FireMon

Ce texte n'est ni une introduction aux pare-feu, ni une présentation exhaustive de l'histoire du pare-feu. Il existe de nombreuses ressources de qualité qui retracent l'histoire du pare-feu, par exemple Wikipédia : https://en.wikipedia.org/wiki/Firewall_(computing). Un nombre important de personnes méritent également d'être créditées pour l'invention du pare-feu sans être mentionnées dans cette série (si le sujet vous intéresse, voici un bon article de Dark Reading : Qui a inventé le pare-feu). Je m'intéresse ici au pare-feu commercial et aux dynamiques de marché qui ont conduit à l'adoption de ces technologies.

En tant que praticien aux débuts relativement précoces de l'adoption massive d'Internet (milieu à fin des années 90), j'ai été témoin de l'adoption rapide et de l'évolution de la technologie pare-feu. J'avais une vision limitée de cette histoire, et ma mémoire est certainement imparfaite. C'est pourquoi, au fil des prochains articles, vos commentaires seront les bienvenus pour m'aider à compléter les pièces manquantes de ce récit.

Au milieu des années 90, Check Point Technologies a lancé le pare-feu à inspection avec état. La concurrence de l'époque reposait principalement sur les filtres de paquets intégrés aux routeurs (par exemple les ACL sur Cisco IOS) et sur les proxys (par exemple le pare-feu TIS Gauntlet et le pare-feu Secure Computing Sidewinder). L'affrontement majeur entre l'inspection avec état et les proxys s'est joué sur trois fronts : les performances, la prise en charge des protocoles et la sécurité.

Sur le plan des performances, l'inspection avec état était nettement plus rapide que les proxys. Les proxys établissaient deux connexions TCP pour chaque session, une côté client et une côté serveur, ce qui exigeait beaucoup plus de traitement. La consommation et la demande de bande passante croissaient à un rythme spectaculaire en raison de l'utilisation accrue d'Internet ; les performances sont ainsi devenues un critère d'achat primordial pour le pare-feu. Si la sécurité comptait, les goulots d'étranglement affectant l'accès à Internet étaient inacceptables. Sur ce front, l'inspection avec état l'a emporté.

Sur le plan de la prise en charge des protocoles, l'inspection avec état s'adaptait facilement, souvent sans aucune modification du code source. Les proxys, en revanche, exigeaient souvent des piles spécifiques à un protocole pour prendre en charge une nouvelle application. Et à la fin des années 90, la normalisation était très limitée. Lorsque vous développiez une nouvelle application, vous créiez souvent un nouveau service (combinaison protocole / port, par exemple tcp/3192). L'idée d'utiliser HTTP comme transport commun pour toutes les applications n'était pas acceptable pour de nombreuses raisons, notamment les implications en matière de performances et l'absence de communication synchrone dans les premières spécifications HTTP. Cela signifiait que de nouveaux protocoles étaient créés et déployés à un rythme très rapide. En conséquence, la demande des clients pour la prise en charge de ces nouveaux protocoles a dépassé la capacité des pare-feu à base de proxy à l'assurer.

Dans presque chaque validation de concept (PoC) de pare-feu, on découvrait un problème où le pare-feu ne traitait pas correctement les communications réseau du client. Pour un proxy, cela signifiait ouvrir un ticket auprès de l'éditeur du pare-feu ou mettre en œuvre une solution de contournement peu satisfaisante. Pour l'inspection avec état, il pouvait suffire de définir un nouveau service, ou de régler un simple problème de délai d'expiration TCP. Les pare-feu à inspection avec état se sont révélés plus faciles à adapter face à ces imprévus, d'où des PoC plus réussis et, au final, davantage de ventes. Si la sécurité comptait, l'interruption des communications d'applications existantes ou nouvelles constituait une limite inacceptable du proxy. Une fois encore, l'inspection avec état l'a emporté.

Enfin, la sécurité. Les débats ont été vifs quant à savoir quel pare-feu offrait la meilleure sécurité. Aujourd'hui, la plupart s'accorderaient à dire qu'un pare-feu applicatif peut offrir une meilleure sécurité, de l'application des protocoles au contrôle comportemental. Malheureusement pour les proxys, les autres limites étaient tout simplement trop lourdes pour l'entreprise, et « une bonne sécurité aux conséquences négatives pour l'activité » s'est inclinée devant « une sécurité plutôt bonne avec des impacts limités sur l'activité ».

Résultat : l'inspection avec état a remporté la bataille contre le proxy. La technologie pare-feu a connu de nombreuses avancées au fil des ans, dont je parlerai dans les prochains articles, mais il est important de reconnaître que l'inspection avec état a gagné cette première bataille et demeure aujourd'hui la norme du secteur en matière de technologie pare-feu.

Partie 2 : la valeur de la gestion