Plop !
dire que si on compromet le host on compromet le FW c'est équivalent à
dire : si on compromet l'OS du RTR/Switch, on compromet le Circuit (vswitch)
Et le FW est lui même à 90% un dérivé UX (nux, bsd,rtos etc..) qui est
donc hackable dans l'absolue.
C'est vrai mais statistiquement admis.
Et dans les fait on s'évertue à ne pas laisser de pont ou bypass entre
le L2/L3/L7 de tout ça.
Ce qui n'est pas visible, n'est pas attaquable.
C'est pour cela que en tant qu’hébergeur on propose :
- la solution jugée ultime mais inabordable pour beaucoup
- la solution à minima (discount) pour ne pas se faire éjecter des AO
- la solution que l'on pense être le bon compromis métier sans
surqualité qui grève le cout.
Le tout accompagné du mémoire technique :
- qui explique tout ça
- qui n'est que rarement lu (le client fonce en bas à droite)
- que l'on ressort quand le client râle qu'on lui a vendu de la M...
Là (râle) généralement, le client est plus sensible au nécessaire cout
de la sécurité qui inclue aussi du temps homme jamais facile à vende au
début.
My 2 cents
Le 14/05/2020 à 16:21, Benoît SERRA a écrit :
Disons que mettre le firewall sur le même hôte que les cm que tu protèges est
une aberration, mais si tu mets ton firewall sur un autre hôte, ou que tu
utilises les fonctions de virtualisation propres à chaque constructeur, c'est
moins pire comme solution.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
