Salut, Perso je ne suis vraiment pas fan des firewall VM, principalement à cause des flood et petits paquets. (quoi que avec dpdk why not, mais bon si la vm plante ...).
Par contre, faire du firewalling sur l'hyperviseur au niveau des bridges des vms (iptables FORWARD), je ne vois pas soucis en terme de performance. (comme sur proxmox ou openstack par exemple). Comme cela le firewall est "distribué" sur l'ensemble des hyperviseurs. Maitenant niveau securité, comme les ip destinations ne sont pas porté par l'hyperviseur (en tout cas si pas de nat 1:1), je ne pense pas qu'on puisse remonter dans le host avec une faille netfilter. (mais je ne suis pas assez expert pour l'affirmer) Si je ne dis pas de bétise,le firewalling chez google cloud fonctionne comme ca ----- Mail original ----- De: "Jean-Christophe Janczak" <[email protected]> À: "frnog-tech" <[email protected]> Envoyé: Lundi 1 Juillet 2019 08:17:45 Objet: [FRnOG] [TECH] [IT SECURITY] Virtualisation de firewall, pentest, compromissions 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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
