Il y a en fait 2 problèmes (enfin, je shématise un peu....):
D'abord, la facon "logique" de faire, a savoir passer par des proxies (ce que font la plupart des solutions, ca permet parfois de reprendre des proxies existants, donc on y gagne en dev, mais c'est lent....) ou faire de l'inspection "a la volée" (souvent en inspectant les paquets sans vraiment les "décapsuler", coté perfs, c'est nettement meilleur, mais c'est plus lourd a développer...).
Ensuite vient la grande problématique des ASICs. Les commerciaux des solutions basées sur des ASICs diront qu'un ASIC, c'est top, ca va super vite (et faut reconnaitre que c'est vrai), ils oublient juste de préciser qu'un ASIC va super vite, mais uniquement pour faire ce pourquoi il a été prévu, et que comme c'est un composant matériel cablé, pas question de le mettre à jour quand la technologie évolue.
Et actuellement, (a peu pres ?) toutes les boites qui font des solutions basées sur ASIC mettent en avant leurs perfs "filtrage pur", et recommandent meme de désactiver l'IPS sur des "coeurs de réseaux", parceque les perfs s'effondrent quand on l'active. Peut etre qu'ils "résoudront" le problème avec une future version de leur ASIC qui inclue une partie des routines d'IPS....
Maintenant, les solutions basées sur du processeur "générique" mais avec une techno a base de proxies ont le meme genre de problèmes.....
Et pour l'instant, les seuls qui tirent leur épingle du jeu dans ce domaine, c'est ceux qui sont sur un processeur "générique" ET qui ont une implémentation "kernel" de l'IPS (en clair, c'est de l'inspection, pas du proxy). Et y'en a pas beaucoup....
[^] # Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vanhu . En réponse à la dépêche Article sur la haute-disponibilité de firewalls sur OpenBSD. Évalué à 2.
D'abord, la facon "logique" de faire, a savoir passer par des proxies (ce que font la plupart des solutions, ca permet parfois de reprendre des proxies existants, donc on y gagne en dev, mais c'est lent....) ou faire de l'inspection "a la volée" (souvent en inspectant les paquets sans vraiment les "décapsuler", coté perfs, c'est nettement meilleur, mais c'est plus lourd a développer...).
Ensuite vient la grande problématique des ASICs. Les commerciaux des solutions basées sur des ASICs diront qu'un ASIC, c'est top, ca va super vite (et faut reconnaitre que c'est vrai), ils oublient juste de préciser qu'un ASIC va super vite, mais uniquement pour faire ce pourquoi il a été prévu, et que comme c'est un composant matériel cablé, pas question de le mettre à jour quand la technologie évolue.
Et actuellement, (a peu pres ?) toutes les boites qui font des solutions basées sur ASIC mettent en avant leurs perfs "filtrage pur", et recommandent meme de désactiver l'IPS sur des "coeurs de réseaux", parceque les perfs s'effondrent quand on l'active. Peut etre qu'ils "résoudront" le problème avec une future version de leur ASIC qui inclue une partie des routines d'IPS....
Maintenant, les solutions basées sur du processeur "générique" mais avec une techno a base de proxies ont le meme genre de problèmes.....
Et pour l'instant, les seuls qui tirent leur épingle du jeu dans ce domaine, c'est ceux qui sont sur un processeur "générique" ET qui ont une implémentation "kernel" de l'IPS (en clair, c'est de l'inspection, pas du proxy). Et y'en a pas beaucoup....