Bonjour la liste.
Toujours un plaisir de lire assidûment vos nombreux et savoureux échanges. :-)
Aujourd’hui je me lance pour une question qui me taraude depuis pal mal de
temps à propos de la { possible | réelle } compromission d'architectures à base
de " firewalls virtuels "
Je lance donc une bouteille à la mer sur le sujet à tous les volontaires {
étudiants IT Sec | hard core hackers | pen testers | IT Sec Officers | RSSI |
net admin | sys admin | autres etc.... } de la liste afin d’avoir et partager
vos avis éclairés et retours d’expériences en prod, et bonnes pratiques sur le
sujet. :-)
1) Autrefois au temps jadis, en mode old school, on mettait un firewall
“physique” en coupure de réseau entre deux interfaces électroniques distinctes.
Mais ça s’était avant ...
2) depuis, "on" a inventé les firewalls « virtuels » et le « *SDN* / *SD
Everything* » est passé par là avec un détour par les nuages.
(Comme chacun sait, ca fuit, les nuages... mais aussi, un firmware (binaire
de bas niveau) ou une vm (binaire de haut niveau) c’est toujours un peu
“virtuel” ;-) )
3) la question qui me préoccupe ici c’est le mode hybride, dans un contexte
small/branch Office en LAB/TPE/PME/PMI/datacenter/... :
un ou plusieurs firewall (vm) qui tournent sur un hyperviseur du marché {
VMware | hyperV | KVM | XEN | oVIRT | ... }
- avec une patte de la vm fw bridgée cote Wan,
- et l’autre bridgée côté Lan, dmz, iot, wifi, ....
Dans cette configuration l’hyperviseur :
- opère et n’as pas d’IP sur la couche ISO/L2 côté WAN,
- et il a une ip d'administration côté interne.
WAN xdsl/cable/fibre <==> BOX FAI <==> Hypervisor_WAN_IF_bridge_noIP <==>
Hypervisor_CPU_RAM ( host n x VM_FW ) <==> Hypervisor_LAN_IP_admin <==> reste
du réseau interne
Exemple de config graphique ici, mais SANS IP coté WAN :
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_simple-infra-map.jpg
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_full-infra-diag.jpg
3.a) le point positif c’est qu’on peut se faciliter l’administration (snapshot,
souplesse etc ) et *densifier* le rendement/ratio puissance de calcul/coût au
watt dans ce mode de fonctionnement.
3.b) *SAUF QUE* : avant, en mode old school c’était les firewalls « physiques »
qui protégeaient l’infra, les hyperviseurs et le reste, et PAS l'inverse :
l'hyperviseur qui protège le FW !!!
3.c) ma crainte est donc :
- quelle confiance relative peut on raisonnablement accorder aux
architectures de firewall virtuelles ?
- *Jusqu'à quel point pouvons nous être sur ou pas* de la compromission
d'une machine hôte qui héberge des FW virtuels ?
- jusqu'à quel point nos hyperviseurs préférés sont-il "béton" ??
Nous savons tous que l’informatique n’est pas toujours une science "exacte"
et je m’attends à ce qu’un jour ou l’autre une attaque soit réussie contre un
hyperviseur côté WAN en couche 2 / bridge :
- via { DDOS | flooding | magic packet | os fingerprint | faille, bug, etc
... }
- et au détriment de la vm fw qui ne verra rien passer (par définition) de
ce qui se passe à l’étage en dessous sur la couche hôte !
3.d) D'après ce que j'ai pu comprendre également si j'en crois la description
officielle, et faute d'avoir mis les doigts jusqu'à présent dans des solutions
Fortinet, le mode VDOM de Fortinet ressemble peu ou prou à de la virtualisation
de Firewall ? => VRAI / FAUX ? jusqu'à quel point et à quel niveau, sur quel
périmètre ?
https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-virtual-domains-54/1-VDOM-overview/1-Introduction.htm
3.e) je n’ai principalement pas/plus le temps, pour faire des pentests massifs
et approfondis sur le sujet, et suivre en veille permanente la sécurité IT
comme dans les temps anciens, d'où ma question ici présente pour partager les
avis et retours d'expérience
3.f) dans la bien nommée revue MISC MAG il me semble avoir vu passer, il y a
fort longtemps, des articles sur le crack d’un hyperviseur et la compromission
et l’évasion de données des vm et / ou rebond sur la couche hôte sans que les
vm n’y voient que du feu.
Est ce toujours vrai / possible ? étant donné que les éditeurs corrigent /
durcissent dans une lutte sans fin leur produits, et que sauf erreur de ma
part, nos hyperViseurs favoris ne sont pas développés en langage ADA ou avec
des techniques de programmation par preuve logicielle et mathématique, mais
plus par du patching au fil de l’eau et des découvertes de bug, failles etc. Me
trompe-je ?
3.g) faute de mieux et/ou d'outils et de suite firewall opensource disponible,
je n'ai pas encore trouvé le moyen ni le temps d'activer BHYVE de façon secure
et industrielle sur une distrib firewall comme PFSense ou OPNSense, Untanglle,
Endian, ...
https://forum.netgate.com/topic/105832/bhyve-package-100usd ==> au point
mort ?
https://www.ixsystems.com/community/threads/freenas-11-2-with-pfsense-as-guest-vm.72060/
https://davidnelson.me/?p=439
==> Cela me semblerait bien pratique cependant qu'un projet comme PFSense
intègre un paquet supplémentaire pour activer BHYVE en natif, un peu comme le
ferait un Windows avec Hyper-V intégré ... ou VDOM de Fortinet ? Au moins la
machine hote avec les binaires PFSense pourrait faire office de vrai firewall
pour les autres VM pfsense hébergées ... (I had a dream ...)
Par ailleurs PFSense / Netgate supporte un nouveau projet depuis plusieurs mois
de firewall Cloud à très haut débit : "TNSR"
https://www.netgate.com/blog/tnsr-release-19-05-is-here.html basé sur les
technos opensource dpdk.org et fd.io
La question est y a-t-il eu des hacks ou alertes de secu serieux sur ces
technos ? sont-elles concues en mode "Security-by-Design" ?
4) Du côté de la pratique :
4.a) avons nous qq part sur le continent numérique français ou globish des
guides de bonnes pratiques pour monter et exploiter de façons secure de tels
cas de figure de pare-feux virtualisés en bordure extérieure ? Ou des retours
d’expérience sur ce qu’il ne faut pas faire ? ANSSI ? Autre ?
Concernant l'ANSII, j'ai trouvé ceci :
https://www.ssi.gouv.fr/administration/bonnes-pratiques/
https://www.ssi.gouv.fr/uploads/2017/12/guide_cloisonnement_systeme_anssi_pg_040_v1.pdf
https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/
https://www.ssi.gouv.fr/administration/guide/recommandations-pour-choisir-des-pare-feux-maitrises-dans-les-zones-exposees-a-internet/
https://www.ssi.gouv.fr/uploads/2015/03/NP_Guide_DDoS.pdf
https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Virtualisation_NoteTech_v1-1.pdf
"Enfin, il est généralement aisé de « remonter » un système invité
défaillant sur une autre machine physique à partir d’une image saine.
Néanmoins, seule la mise en œuvre du principe de défense en profondeur permet
de localiser précisément l’origine de la compromission (système invité,
systèmehôte, matériel, données, etc.). Risque 3 : Dans une architecture avec
virtualisation, les machines virtuelles peuvent par exemple communiquer sur des
réseaux physiques par le biais d’une carte unique appartenant à la machine
physique qui les héberge. Les flux de données de chaque machine virtuelle sont
donc traités par cette unique carte réseau. Dès lors, il n’est pas possible de
garantir un cloisonnement des flux au niveau de la ressource partagée. En cas
d’erreur ou de compromission de la carte réseau, un accès aux données des
différents flux d’information est possible (cf. figure 4)"
https://www.ssi.gouv.fr/uploads/2018/01/guide_preconisations-pare-feux-zone-exposee-internet_anssi_pa_044_v1.pdf
- cf page 20
- "Ainsi, les technologies de pare-feux virtualisés utilisées dans le cadre
des passerelles sécurisées avec Internet sont déconseillées."
- "Dans une passerelle Internet sécurisée, il est néanmoins possible
d’envisager de virtualiser plusieurs instances de filtrage réseau. En
particulier, dans le cas d’infrastructures complexes, l’utilisation d’instances
de filtrage distinctes virtualisées peut permettre de répartir des règles de
flux par besoins fonctionels pour en faciliter l’exploitation (lecture des
règles plus facile, gestion des règles par des équipes exploitantes
distinctes...). Mais dans ce cas, une attention particulière doit être apportée
au durcissement du socle matériel et logiciel."
- et on on évoque bien "la compromission du pare-feu virtualisé ou de
l’hyperviseur sous-jacent" ;
4.b) Que conseillez vous donc de votre côté *dans la vraie vie et en
production*, pour faire des tests bullet-proof en condition réelles et valider
une archi à base de firewall virtuels ? ==> Metasploit ? Parrot ?
https://cisofy.com/lynis ? Autre ?
4.c) Enfin, à votre avis, ou dans vos best practises :
- Quelles sont les hyperviseurs { ESXi | Proxmox | XEN | Hyper-V | ... }
que vous préconnisez pour la mise en place de pare-feu virtualisés ?
- Depuis combien de temps avez vous mis en place de type de solutions ?
- Quels sont les incidents les plus récurrents ?
- Combien d'attaques / compromissions détectées (?) par semaine, mois, etc
... ? sous quel délai sont-elles détectés si c'est le cas ? (un jour / semaine
/ mois plus tard ?)
- Comment se comporte la pile L2 d'un hyperviseur quand on le floode, DDOS,
etc .... et avant que le paquet ne soit transmis en RAM à la VM concernée ?
--- cela donne-t-il lieu à un exploit de l'hôte ?
--- cela donne-t-il accès à toutes les vm de l'hôte ?
--- quelles solutions de contres-mesures peut-on simplement mettre en place
? {avant | après} ?
- Quelles sont les best practices de sécu sur un segment externe ? Linux
Bridge ou Open vSwitch ? https://pve.proxmox.com/wiki/Open_vSwitch
--- est-ce que nous avons connaissance régulièrement de failles ou
limitation de sécurité sur le module "bridge" du kernel Linux ? idem pour Open
vSwitch ?
--- quel est le niveau de confiance et de sécurité relatif / stress test /
pentest / résilience / montée en charge de LinuxBridge vs Open_vSwitch ?
- Faut-il rajouter un nouveau firewall filtrant IPS/IDS en mode L2/bridge
en amont d'un hyperviseur hébergeant des VM de firewall ?
--- même si l'hyperviseur n'a pas d'adresse IP coté WAN ?
--- Techniquement ça ressemble à se rajouter de la sécurité, mais en fait à
l'opposé de l'objectif initial de simplification et souplesse par la virtu ...
--- fail2ban dans la couche hyperviseur ? y-a-t-il un équivalement de
Fail2ban pour ESXi ?
- comment sont protégées les infra Cloud avec fw logiciel en VM exposé sur
Internet, dans un contexte Azure, GoogleCloud, AWS, OpenStack, OVH Public
Cloud, etc ... par exemple ?
--- y a-t-il un infra firewall matérielle qui filtre sur la couche L2 en
amont des hyperviseurs exposés à l'internet ?
--- mais comment ne pas être trop strict / restrictif dans ce cas ? un FW
en amont d'un autre FW : bonjour la complexité !
--- par exemple dans le passé, avec l'IPS Netasq il m'était arrivé de
constater que celui-ci bloquait des applis parce que ces applis étaient mal
codées (IE6 etc ...) , et qu'avec les paramètres par défaut qui étaient la
stricte application du protocole http par exemple plus rien ne passait ; il
fallait alors autoriser des exeptions dans l'ASQ.
6) Un grand Merci d'avance pour vos partages :-) et retours éclairés et
passionnés en ce jour pas troll ;-)
Jean-Christophe
PS ==> Firewall physiques vs firewall virtuels : au prochain sujet de philo du
bac ?
7) [Annexes et Refs] :
https://www.ssi.gouv.fr/administration/bonnes-pratiques/
https://www.ssi.gouv.fr/uploads/2017/12/guide_cloisonnement_systeme_anssi_pg_040_v1.pdf
https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/
https://www.ssi.gouv.fr/administration/guide/recommandations-pour-choisir-des-pare-feux-maitrises-dans-les-zones-exposees-a-internet/
https://www.ssi.gouv.fr/uploads/2018/01/guide_preconisations-pare-feux-zone-exposee-internet_anssi_pa_044_v1.pdf
https://www.ssi.gouv.fr/uploads/2018/01/guide_preconisations-pare-feux-zone-exposee-internet_anssi_pa_044_v1.pdf#section*.4
https://www.ssi.gouv.fr/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/
https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Virtualisation_NoteTech_v1-1.pdf
https://www.ssi.gouv.fr/uploads/2016/08/np_nettoyage-politique-pare-feu.pdf
https://www.ssi.gouv.fr/uploads/2012/01/anssi-guide-passerelle_internet_securisee-v2.pdf
https://www.ssi.gouv.fr/administration/guide/comprendre-et-anticiper-les-attaques-ddos/
https://www.ssi.gouv.fr/uploads/2015/03/NP_Guide_DDoS.pdf
https://www.ssi.gouv.fr/uploads/2014/12/secnumcloud_referentiel_v3.1_anssi.pdf
https://www.ssi.gouv.fr/uploads/2015/03/NP_Guide_DDoS.pdf
https://www.google.com/search?q=pfsense+bhyve+plugin
https://forum.netgate.com/topic/105832/bhyve-package-100usd
https://github.com/churchers/vm-bhyve
https://www.ixsystems.com/community/threads/freenas-11-2-with-pfsense-as-guest-vm.72060/
https://www.ixsystems.com/community/threads/pfsense-as-iohyve-virtual-machine-with-ethernet-pci-passthrough-under-freenas-11-2.72244/
https://davidnelson.me/?p=439
https://shaner.life/bhyve-pfsense-2-4-no-console-menu/
https://www.netgate.com/blog/tnsr-release-19-05-is-here.html
https://www.dpdk.org/
https://fd.io/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-proxmox.html
https://pve.proxmox.com/wiki/Open_vSwitch
https://blog.zwindler.fr/2017/07/18/deploiement-de-proxmox-ve-5-sur-un-serveur-dedie-part-2/
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_full-infra-diag.jpg
https://blog.zwindler.fr/2017/05/02/proxmox-lets-encrypt/
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_simple-infra-map.jpg
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_full-infra-diag.jpg
https://www.sdxcentral.com/open-source/definitions/what-is-open-vswitch/
https://northboundnetworks.com/blogs/sdn/what-is-open-vswitch
https://www.openvswitch.org/
https://cisofy.com/lynis/
https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-virtual-domains-54/1-VDOM-overview/1-Introduction.htm
https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-virtual-domains-54/1-VDOM-overview/2-Benefits.htm#Benefits
https://docs.openstack.org/security-guide/networking/services-security-best-practices.html
https://docs.openstack.org/newton/networking-guide/fwaas.html
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
