Vulnérabilité réseau

Web, 80 (HTTP) et 442 (SSL/TLS).
Cette protection n’est-elle pas suffisante ? Et,
d’ailleurs, qu’est-ce qu’un pare-feu d’application ?

R : Les pare-feu jouent un rôle important – et essentiel – dans la
sécurité d’un réseau. Mais ils ne suffisent pas à  eux seuls. Les
réseaux les mieux protégés appliquent une philosophie appelée
« défense en profondeur », qui utilise des couches de
sécurité qui supposent que les autres lignes de défense ont pu
céder. Des outils tels que les systèmes de détection d’intrusion,
la protection basée sur serveur, les scanners de vulnérabilité
automatiques et les pare-feu d’application font tous partie
d’un système de sécurité « défense en profondeur ».
Il est vrai qu’un pare-feu d’entreprise peut fournir la protection
de base à  votre serveur Web, en n’admettant que des
ports nécessaires et en bloquant les attaques par déni de service
(DoS, Denial of Service) de base. Mais les serveurs Web
sont des systèmes compliqués, affligés de vulnérabilités que
des pare-feu ne peuvent pas pallier. Par exemple, de nombreux
serveurs Web sont vulnérables par débordement de
buffer. Un pirate peut en profiter pour prendre le contrôle
de la machine ou pour l’arrêter. L’expérience passée de quelques centaines de tels défauts nous assure que des centaines
d’autres nous attendent. Autre vulnérabilité: un XML invalide
destiné à  mettre le serveur à  genoux ou à  contourner la
sécurité. Les serveurs d’application Web non XML, comme
PHP, Perl et Python, sont tous, par nature, exposés à  divers
genres de mauvaise entrée. Même un serveur Web bien écrit,
comme Apache, souffre de défauts de coding inconnus.
Un examen de vulnérabilité de réseau ne peut détecter
que les défauts de serveur Web connus. Un scanner est incapable
de générer toutes les formes possibles de mauvaises
données pouvant faire trébucher un serveur. La seule solution
est de vérifier la validité de chaque requête au moment
où elle arrive, afin que les serveurs ne reçoivent pas de mauvaises
données.
Un pare-feu d’application améliore la sécurité en effectuant
une vérification précoce sur l’entrée et la sortie du serveur
Web, vérifiant que les longueurs du buffer correspondent
aux données fournies, que XML et autres langages
interprétés respectent les règles de syntaxe publiées et que
les règles d’utilisation de l’application sont en vigueur.
Pour ces fonctions, un pare-feu d’application est bien
meilleur qu’un serveur Web parce que c’est sa seule mission.
En effet, il n’a pas à  interagir avec des bases de données, à 
effectuer des calculs de gestion ou à  suivre les sessions utilisateur.
Si le pare-feu d’application est développé par un
fournisseur différent de celui qui fournit le serveur Web, il y
a très peu de risque que les deux fournisseurs commettent la
même erreur. (Ce qui, soit dit en passant, signifie que personne
ne devrait acheter un pare-feu d’application construit
par Microsoft !)
Un avantage indirect utile des pare-feu d’application est
qu’ils peuvent contribuer à  protéger les pare-feu traditionnels,
qui doivent suivre l’information bidirectionnelle sur
l’état des sessions. En plaçant le pare-feu d’application du
côté exposé de votre pare-feu traditionnel, vous permettez
au pare-feu d’application de bloquer les attaques DoS, les
sondes de virus et les vers Internet avant qu’ils ne consomment
les ressources du pare-feu.