Passionnant et très utile article sur le blog en anglais de James Bottomley (merci LWN.net pour le résumé) : il étudie la sécurité des solutions d'hébergement Cloud en se basant sur la solution retenue : serveurs dédiés, serveurs partagés, serveurs virtuels, conteneurs, et en comparant les profils d'attaques verticales et horizontales.
Comme vous aimez les conclusions rapides, sachez déjà que la solution conteneurs l'emporte haut la main.
Une attaque verticale c'est du code traversé : de la requête web à la base de donnée jusqu'à la réponse dans le navigateur ou l'application, et qui contient potentiellement des bugs, elle concerne uniquement votre hébergement :
all code that is traversed to provide a service all the way from input web request to database update to output response potentially contains bugs; the bug density is variable for the different components but the more code you traverse the higher your chance of exposure to exploitable vulnerabilities. We’ll call this the Vertical Attack Profile (VAP) of the stack.
Une attaque horizontale par contre peut se propager d'hébergement en hébergement :
In an IaaS cloud, part of the vertical profile belongs to the tenant (The guest kernel, guest OS and application) and part (the hypervisor and host OS) belong to the CSP. However, the CSP vertical has the additional problem that any exploit in this piece of the stack can be used to jump into either the host itself or any of the other tenant virtual machines running on the host. We’ll call this exploit causing a failure of containment the Horizontal Attack Profile (HAP).
La surveillance est répartie différemment selon l'hébergement, par exemble sur un serveur partagé l'hébergeur doit surveiller toute la pile : le matériel, le noyau, les librairies et le middleware, vous n'êtes responsable que de la couche applicative, tandis qu'avec un conteneur il surveille le matériel et le noyau hôte.
Mais les attaques sont aussi réparties différemment. Dans un hébergement partagé, si vous attaquez le noyau vous pouvez compromettre tout le système, donc tous les hébergements tandis qu'il est plus difficile de sortir d'un conteneur.
Compte tenu de quelques autres facteurs que je ne résume pas ici — veuillez lire cet article avant de commenter —, les équipes de sécurité de l'hébergeur bossent « mieux » avec des conteneurs, qui sont donc plus fiables, quoi qu'en dise votre contrat. Mais que ça ne vous dispense pas des opérations habituelles de base : backup, backup ET backup (sauvegarde, sauvegarde ET sauvegarde de leurs petits noms).
# Contourner la sécurité
Posté par claudex . Évalué à 8.
J’ai un peu lu en diagonal, mais il me semble qu’il exclut des types d’attaques. Par exemple, quand on a accès directement au matériel (serveur dédié). On a aussi accès au BIOS, on peut donc installer un BIOS frauduleux qui ne pourra pas être supprimé1, chose qui n’est pas possible avec les containers ou les VM. Un autre point intéressant avec le matériel virtualisé, c’est qu’on peut plus facilement introduire des contre-mesures pour certaines failles. Par exemple, pour meltdown, il était possible d’émuler un CPU qui ne présente pas les instructions permettant d’utiliser la faille.
il y a une démo d’un BIOS qui une fois installé, fais croire que les mises à jour suivantes sont réussies alors que c’est toujours le malware qui tourne. Il a aussi accès à la mémoire de l’OS et peut complètement se cacher de toute détection. ↩
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Pas convaincant
Posté par gasche . Évalué à 6.
L'argument principal utilisé pour conseiller les conteneurs plutôt que les machines virtuelles (qui me semblent clairement plus sécurisées) est qu'avec les machines virtuelles c'est à l'utilisateur de maintenir son noyau à jour question sécurité, alors qu'avec les conteneurs il ne choisit pas le noyau et c'est le fournisseur de service qui le maintient, et le maintient sans doute mieux.
Cet argument me semble bancal. On pourrait utiliser exactement le même pour dire que les machines partagées sont plus sécurisées en moyenne que les machines où l'utilisateur contrôle tout, et pourtant l'auteur ne les conseille pas.
L'analyse repose sur l'idée que la maintenance du système est assurée soit par le fournisseur, bien, soit par l'utilisateur, mal. Même si on ne suppose pas que les utilisateurs compétents et dévoués sont majoritaires, on peut aussi remarquer qu'il existe des tierces parties qui peuvent se charger de maintenir des morceaux de la stack pour l'utilisateur. Le fournisseur peut le faire dans certains schémas, mais on peut aussi compter sur une distribution pour maintenir un kernel, ou sur un fournisseur de machines virtuelles (par exemple Red Hat fournit des conteneurs de base dans lequel on peut déployer ses applications, remplaçant une partie du rôle du fournisseur). On peut avoir des tiers à qui on fait aussi ou plus confiance qu'au fournisseur de machines pour la maintenance de sécurité.
Il me semble qu'il y a deux choses à dire :
Pour un utilisateur non-expert, le mieux est d'avoir le moins d'opérations de maintenance à faire possibles, en déléguant la plus grande partie de la pile applicative à des tiers de confiance. Mais pas forcément le fournisseur ! On peut tout à fait louer les services d'un fournisseur qui déploie des machines virtuelles (sur un hyperviseur, donc), et utiliser un fournisseur tiers de machines virtuelles en qui on a confiance pour configurer et maintenir le kernel. On peut aussi utiliser une distribution en qui on a confiance pour configurer et maintenir la grande majorité de la couche applicative—le plus possible.
Pour un fournisseur de machines qui ne veut pas fournir de machines dédiées (trop cher), l'interface la plus protégée du code des utilisateurs est un hyperviseur—tant qu'on en prend plus petit et plus simple que le kernel Linux, et plus attentif à la sécurité. Il peut bien sûr proposer une interface au-dessus à ses clients, par exemple "conteneurs" ou même "login sur une machine partagée" (ou déploiement clicodrome d'applications fixées à l'avance), mais il a intérêt à construire ça au-dessus de machines virtuelles séparées s'il veut limiter au maximum les risques d'attaques d'un utilisateur à l'autre. (Bien sûr, un gain en sécurité peut avoir un coût en performance.)
[^] # Re: Pas convaincant
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
L'erreur de l'article est de croire que les utilisateurs finaux ont le même niveau de compétence OS que l'hébergeur. Je pense qu'en moyenne, c'est complètement faux. Certains fournisseurs de cloud patchent leur noyau avant la sortie des noyaux officiels.
"La première sécurité est la liberté"
# C'est faux
Posté par pasBill pasGates . Évalué à 4.
Ce n'est absolument pas le cas. L'isolation des conteneurs est loin, très très loin, d'être d'avoir la même fiabilité que l'isolation d'une VM par dessus un hyperviseur. Si une conteneur se fait avoir il y a des chances que le système hôte et tous les conteneurs sur cet hôte prennent un coup dans les dents. Av c une isolation par hyperviseur c'est beaucoup beaucoup plus difficile.
[^] # Re: C'est faux
Posté par ZeroHeure . Évalué à 6.
C'et exactement ce qu'il dit dans l'article. C'est bien la peine de mettre une note invitant à lire avant de commenter. Je suis en train de préparer mon fouet, tu peux encore l'éviter en te dépêchant !
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: C'est faux
Posté par pasBill pasGates . Évalué à 2. Dernière modification le 25 juin 2018 à 19:23.
Ah mais j'ai lu :
Faut pas utiliser le mot conteneur alors … Moi je te faisais confiance pour proprement rapporter le contenu de l'article :)
[^] # Re: C'est faux
Posté par ZeroHeure . Évalué à 2.
:-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: C'est faux
Posté par Jiel (site web personnel) . Évalué à 2.
Pas forcément. Avec un gestionnaire de conteneurs on peut restreindre sérieusement les droits et les choses que le conteneur a le droit de faire.
[^] # Re: C'est faux
Posté par Renault (site web personnel) . Évalué à 3.
Il n'empêche que les conteneurs reposent sur un noyau commun. Une faille dedans exploitée et tes accès sont bien plus larges que ton conteneur.
Avec une VM l'isolation est plus stricte rendant la sortie de la machine virtuelle moins probable.
[^] # Re: C'est faux
Posté par pasBill pasGates . Évalué à 4.
Il y a la théorie qui dit que les conteneurs sont une primitive d'isolation, et il y a la triste réalité qui est que les conteneurs ont besoin d'un système extrèmement bancal de filtrage des appels systèmes car la plupart ne supportent pas les namespaces (la tech qui est à la base des conteneurs Linux).
Ensuite, il y a le fait qu'un hyperviseur est quelque chose de beaucoup, beaucoup, plus simple et petit qu'un kernel Linux, avec une surface d'attaque bcp plus réduite.
[^] # Re: C'est faux
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Par ailleurs il ne faut pas oublier que fondamentalement, ni les containers, ni les VMs ne sont des outils de sécurité. Ils ne dispensent pas de traiter la primitive de sécurité "isolation" et tout ce qui s'y rattache tant d'un point de vue technique que process.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.