Défense contre les attaques
La figure suivante représente les composants de virtualisation qui forment l'"environnement d'exécution" Oracle VM Server for SPARC. Ces composants ne sont pas strictement séparés. La configuration la plus simple consiste à combiner toutes ces fonctions dans un domaine unique. Le domaine de contrôle peut également faire office de domaine d'E/S et domaine de service pour d'autres domaines.
Figure 3 Composants de l'environnement d'exécution
Supposons qu'une personne malveillante tente de rompre l'isolement puis de manipuler l'hyperviseur ou un autre composant de l'environnement d'exécution pour atteindre un domaine invité. Vous devez protéger chaque domaine invité de la même manière que vous le feriez pour n'importe quel serveur autonome.
La suite de ce chapitre présente les menaces possibles et les différentes mesures que vous pouvez prendre pour les contrer. Chacune de ces attaques tente de surmonter ou d'éliminer l'isolement des différents domaines qui s'exécutent sur une plate-forme unique. Les sections suivantes décrivent les menaces qui pèsent sur chaque partie d'un système Oracle VM Server for SPARC :
Environnement opérationnel
L'environnement opérationnel comprend les systèmes physiques et leurs composants, les architectes de centre de données, les administrateurs et les membres du département informatique. Une violation de la sécurité peut se produire en n'importe quel point de l'environnement opérationnel.
La virtualisation place une couche logicielle entre le matériel proprement dit et les domaines invités qui exécutent les services de production, ce qui accroît la complexité. Par conséquent, planifiez et configurez avec soin le système virtuel et méfiez-vous des erreurs humaines. Méfiez-vous également des tentatives de personnes malveillantes d'accéder à l'environnement opérationnel par le biais de "l'ingénierie sociale".
Les sections suivantes décrivent les menaces caractéristiques que vous pouvez contrer au niveau de l'environnement opérationnel.
Menace : configuration incorrecte non intentionnelle
En matière de sécurité, la préoccupation principale pour un environnement virtualisé est d'assurer l'isolement du serveur en séparant les segments du réseau, en prévoyant un accès administratif séparé et en répartissant les serveurs dans des classes de sécurité, lesquelles correspondent à des groupes de domaines partageant les mêmes exigences et privilèges de sécurité.
Création de canaux de communication inutiles entre les domaines invités de production et l'environnement d'exécution
Création d'accès inutiles à des segments du réseau
Création de connexions non intentionnelles entre des classes de sécurité distinctes
Migration non intentionnelle d'un domaine invité dans la mauvaise classe de sécurité
Allocation insuffisante de matériel pouvant entraîner une surcharge inattendue des ressources
Affectation de disques ou de périphériques d'E/S au mauvais domaine
Configurez attentivement les ressources virtuelles afin d'éviter les erreurs suivantes :
Contre-mesure : création d'instructions opérationnelles
Gestion des patchs pour tous les composants de l'environnement
Mise en place d'une procédure d'implémentation des modifications sécurisée, traçable et bien définie
Vérification des fichiers journaux à intervalles réguliers
Surveillance de l'intégrité et de la disponibilité de l'environnement
Avant de commencer, définissez soigneusement les instructions opérationnelles applicables à votre environnement Oracle VM Server for SPARC. Ces instructions décrivent les tâches à effectuer et la manière de les effectuer. Il s'agit des tâches suivantes :
Effectuez régulièrement des contrôles pour vous assurer que ces instructions restent à jour et adaptées, et pour vérifier qu'elles sont suivies au jour le jour.
En plus de ces instructions, vous pouvez prendre plusieurs mesures plus techniques pour réduire le risque d'actions non intentionnelles. Reportez-vous à la section Logical Domains Manager.
Menace : erreurs dans l'architecture de l'environnement virtuel
Lorsque vous déplacez un système physique vers un environnement virtualisé, vous pouvez en général conserver la configuration du stockage existante en réutilisant les LUN d'origine. Toutefois, la configuration réseau doit être ajustée par rapport à l'environnement virtualisé et l'architecture résultante peut différer considérablement de l'architecture utilisée sur le système physique.
Vous devez vous poser la question de savoir comment préserver l'isolement des classes de sécurité distinctes et connaître leurs besoins. Vous devez également prendre en compte le matériel partagé de la plate-forme et les composants partagés tels que les commutateurs réseau et SAN.
Pour optimiser la sécurité de votre environnement, assurez-vous de préserver l'isolement des domaines invités et des classes de sécurité. Lors de la conception de l'architecture, anticipez les erreurs possibles et les attaques et mettez en oeuvre des moyens de défense. Une bonne conception permet de limiter les éventuels problèmes de sécurité tout en permettant la gestion de la complexité et des coûts.
Contre-mesure : affectation attentive de domaines invités aux plates-formes matérielles
Utilisez des classes de sécurité, c'est-à-dire des groupes de domaines partageant les mêmes exigences et privilèges de sécurité, pour isoler les domaines les uns des autres. En affectant à une plate-forme matérielle donnée des domaines invités appartenant à la même classe de sécurité, vous empêchez qu'une éventuelle violation de l'isolement ne se propage à une autre classe de sécurité.
Contre-mesure : planification d'une migration de domaine Oracle VM Server for SPARC
La fonction de migration de domaine en direct peut rompre l'isolement si un domaine invité est migré par inadvertance vers une plate-forme assignée à une autre classe de sécurité, comme illustré dans la figure suivante. Planifiez donc avec soin la migration des domaines invités afin de vous assurer qu'aucune migration entre classes de sécurité différentes n'est autorisée.
Figure 4 Migration de domaine d'une classe de sécurité à une autre
Pour réduire ou éliminer la vulnérabilité de sécurité présentée par l'opération de migration, vous devez échanger et installer manuellement les certificats d'hôte générés par ldmd hors bande entre la paire machine source/machine cible. Pour plus d'informations sur la configuration des certificats SSL, reportez-vous à Configuration des certificats SSL pour la migration du manuel Guide d’administration d’Oracle VM Server for SPARC 3.4.
Contre-mesure : configuration correcte des connexions virtuelles
Si vous n'assurez pas le suivi de toutes les connexions réseau virtuelles, il est possible qu'un domaine puisse accéder de manière indue à un segment du réseau. Un tel accès peut par exemple contourner le pare-feu ou une classe de sécurité.
Pour réduire les risques d'erreurs d'implémentation, planifiez et documentez soigneusement toutes les connexions virtuelles et physiques de votre environnement. Optimisez le plan de connexion des domaines pour plus de simplicité et de facilité de gestion. Documentez précisément votre plan et vérifiez l'exactitude de votre implémentation par rapport à votre plan avant le passage en production. Même une fois votre environnement virtuel en production, vérifiez régulièrement l'implémentation par rapport au plan.
Contre-mesure : utilisation du balisage VLAN
Vous pouvez utiliser le balisage VLAN pour consolider plusieurs segments Ethernet sur un même réseau physique. Cette fonctionnalité est également disponible pour les commutateurs virtuels. Pour limiter les risques liés à des erreurs logicielles dans l'implémentation des commutateurs virtuels, configurez un commutateur virtuel par carte NIC physique et réseau VLAN. De plus, pour vous protéger contre des erreurs dans le pilote Ethernet, évitez d'utiliser des VLAN balisés. Toutefois, la probabilité que de telles erreurs se produisent est faible car la vulnérabilité des VLAN balisés est bien connue. Les tests d'intrusion effectués sur le serveur Sun SPARC T-Series d'Oracle avec le logiciel Oracle VM Server for SPARC n'ont pas mis en évidence cette vulnérabilité.
Contre-mesure : utilisation des dispositifs de sécurité virtuels
Les dispositifs de sécurité tels que les filtres de paquets et les pare-feux sont des instruments d'isolement et protègent l'isolement des classes de sécurité. Ces dispositifs sont soumis aux mêmes menaces que tout autre domaine invité, c'est pourquoi leur utilisation ne garantit pas une protection complète contre une violation d'isolement. Par conséquent, évaluez avec soin tous les aspects des risques et de la sécurité avant de prendre la décision de virtualiser un tel service.
Menace : effets secondaires du partage des ressources
Le partage des ressources dans un environnement virtualisé peut conduire à des attaques par déni de service (DoS, denial-of-service), qui surchargent une ressource jusqu'à ce qu'un autre composant tel qu'un autre domaine soit affecté.
Emballement des zones de cache partagées par les strands et assignées à deux domaines invités
Surcharge de la bande passante de la mémoire
Dans un environnement Oracle VM Server for SPARC, seules certaines ressources sont susceptibles d'être affectées par une attaque par déni de service. Les ressources de CPU et de mémoire sont assignées de manière exclusive à chaque domaine invité, ce qui empêche la plupart des attaques par déni de service. Mais même l'assignation exclusive de ces ressources peut ralentir un domaine invité de l'une des manières suivantes :
Contrairement aux ressources de CPU et de mémoire, les services de disque et les services réseau sont généralement partagés par les domaines invités. Ces services sont fournis aux domaines invités par un ou plusieurs domaines de service. Etudiez avec soin comment assigner et répartir ces ressources entre les domaines invités. Notez que toute configuration permettant à la fois des performances maximales et une exploitation optimale des ressources réduit les risques d'effets secondaires.
Evaluation : effets secondaires liés aux ressources partagées
Qu'il soit assigné à un domaine de manière exclusive ou partagé par plusieurs domaines, un lien réseau peut être saturé ou un disque peut être surchargé. De telles attaques affectent la disponibilité d'un service pendant toute la durée de l'attaque. Leur cible n'est pas compromise et aucune donnée n'est perdue. Vous pouvez facilement réduire les effets de cette menace, mais vous devez la garder à l'esprit, même si elle se limite aux ressources réseau et de disque dans Oracle VM Server for SPARC.
Contre-mesure : affectation attentive des ressources matérielles
Assurez-vous que vous affectez uniquement les ressources matérielles requises aux domaines invités. Veillez à annuler l'affectation d'une ressource inutilisée lorsque celle-ci n'est plus nécessaire ; c'est le cas par exemple d'un port réseau ou d'une unité de DVD requis uniquement lors d'une installation. En appliquant cette pratique, vous réduisez le nombre de points d'entrée possibles pour une personne malveillante.
Contre-mesure : affectation attentive des ressources partagées
Les ressources matérielles partagées, telles que les ports réseau physiques, constituent une cible potentielle pour des attaques par déni de service. Pour limiter l'impact d'attaques par déni de service à un seul groupe de domaines invités, déterminez avec soin quels domaines invités partagent quelles ressources matérielles.
Par exemple, vous pouvez regrouper des domaines invités partageant des ressources matérielles en fonction de leur disponibilité ou de leurs exigences en matière de sécurité. Outre le regroupement, vous pouvez appliquer différents types de contrôles des ressources.
Vous devez vous poser la question de savoir comment partager les ressources de disque et les ressources réseau. Vous pouvez limiter les problèmes en séparant l'accès au disque au moyen de chemins d'accès physiques dédiés ou de services de disque virtuel dédiés.
Résumé : effets secondaires liés aux ressources partagées
Toutes les contre-mesures décrites dans cette section exigent que vous maîtrisiez les aspects techniques de votre déploiement et leurs implications en matière de sécurité. Veillez à planifier avec soin, à bien documenter et mettez en place l'architecture la plus simple possible. Assurez-vous de connaître les implications du matériel virtualisé afin de pouvoir vous préparer à déployer le logiciel Oracle VM Server for SPARC en toute sécurité.
Les domaines logiques font preuve de robustesse face aux effets du partage de CPU et de mémoire, car le partage qui se produit effectivement est très limité. Néanmoins, il est préférable d'appliquer des contrôles de ressources tels que la gestion des ressources Solaris dans les domaines invités. L'utilisation de ces contrôles vous protège contre les défauts de comportement des applications, que vous travailliez dans un environnement virtualisé ou non virtualisé.
Environnement d'exécution
Les composants de l'environnement d'exécution sont présentés dans la section Figure 3. Chaque composant fournit des services donnés qui, ensemble, constituent la plate-forme globale sur laquelle les domaines invités de production peuvent s'exécuter. Une configuration correcte des composants est primordiale pour garantir l'intégrité du système.
Tous les composants de l'environnement d'exécution sont des cibles potentielles pour une personne malveillante. Cette section décrit les menaces qui pèsent sur chaque composant dans l'environnement d'exécution. Certaines menaces et contre-mesures peuvent s'appliquer à plusieurs composants.
Menace : manipulation de l'environnement d'exécution
En manipulant l'environnement d'exécution, il est possible de prendre le contrôle de plusieurs façons. Par exemple, il est possible d'installer des microprogrammes manipulés dans pour intercepter toutes les entrées/sorties d'un domaine invité à partir d'un domaine d'E/S. Ce type d'attaque peut permettre d'accéder à la configuration du système et de la modifier. Une personne malveillante qui prend le contrôle du domaine de contrôle d'Oracle VM Server for SPARC peut reconfigurer le système comme elle l'entend, et une personne malveillante qui prend le contrôle d'un domaine d'E/S peut apporter des modifications aux dispositifs de stockage connectés, tels que des disques d'initialisation par exemple.
Evaluation : manipulation de l'environnement d'exécution
Une personne malveillante qui parvient à entrer dans ou dans n'importe quel domaine de l'environnement d'exécution peut lire et manipuler toutes les données mises à la disposition de ce domaine. Un accès de ce type peut s'effectuer par l'intermédiaire du réseau ou par le biais d'une erreur dans la pile de virtualisation. Ce type d'attaque est difficile à mettre en oeuvre car en général, et les domaines ne peuvent pas être attaqués directement.
La mise en oeuvre de contre-mesures pour éviter une manipulation de l'environnement d'exécution est une pratique de sécurité courante et doit être implémentée sur n'importe quel système. Les pratiques de sécurité courantes constituent une barrière protectrice supplémentaire pour l'environnement d'exécution et réduisent un peu plus les risques d'intrusion et de manipulation.
Contre-mesure : sécurisation des chemins d'accès interactifs
Assurez-vous de ne créer que les comptes absolument nécessaires pour les applications qui s'exécutent sur le système.
Assurez-vous que les comptes requis pour l'administration sont sécurisés en recourant à l'authentification basée sur une clé ou à des mots de passe forts. Ces clés ou mots de passe ne doivent pas être partagés par différents domaines. Envisagez également d'implémenter une authentification à deux facteurs ou une "règle des deux personnes" pour l'exécution de certaines actions.
N'utilisez pas des connexions anonymes pour les comptes tels que root, afin que toutes les commandes exécutées sur le système puissent être tracées et attribuées à un utilisateur donné. Utilisez plutôt des droits pour accorder à des administrateurs donnés l'accès aux seules fonctions qu'ils sont autorisés à effectuer. Assurez-vous que l'accès au réseau d'administration utilise toujours un protocole de chiffrement tel que SSH et que les stations de travail des administrateurs sont traitées comme des systèmes à haute sécurité.
Contre-mesure : réduction du SE Oracle Solaris
L'intégrité de n'importe quel logiciel installé sur un système étant susceptible d'être compromise, vous devez veiller à n'installer que les logiciels indispensables pour minimiser les failles de sécurité.
Contre-mesure : sécurisation du SE Oracle Solaris
En plus d'effectuer une installation minimale du SE Oracle Solaris, configurez les packages logiciels de manière à "sécuriser" le logiciel contre les attaques. Exécutez tout d'abord des services réseau limités afin de désactiver tous les services réseau à l'exception de SSH. Cette stratégie est le comportement par défaut sur les systèmes Oracle Solaris 11. Pour plus d'informations sur la sécurisation du SE Oracle Solaris, reportez-vous au manuel Oracle Solaris 10 Security Guidelines et au manuel Oracle Solaris 11 Security Guidelines.
Contre-mesure : recours à la séparation des rôles et à l'isolement des applications
Les applications de production sont nécessairement connectées à d'autres systèmes et sont, par conséquent, plus exposées aux attaques extérieures. Ne déployez pas les applications de production sur un domaine qui fait partie de l'environnement d'exécution. Au contraire, déployez-les uniquement sur des domaines invités dépourvus de privilèges particuliers.
L'environnement d'exécution doit uniquement fournir l'infrastructure nécessaire pour ces domaines invités. En séparant l'environnement d'exécution des applications de production, vous pouvez introduire un certain niveau de précision dans les privilèges d'administration. Un administrateur de domaine invité de production n'a pas besoin d'accéder à l'environnement d'exécution et un administrateur d'environnement d'exécution n'a pas besoin d'accéder aux domaines invités de production. Si possible, affectez les différents rôles de l'environnement d'exécution, tels que le domaine de contrôle et le domaine d'E/S, à des domaines différents. Une configuration de ce type permet de limiter les dommages si l'un des domaines est compromis.
Vous pouvez également étendre la séparation des rôles à l'environnement réseau utilisé pour la connexion des différents serveurs.
Contre-mesure : configuration d'un réseau de gestion dédié
Connectez tous les serveurs équipés de processeurs de service à un réseau de gestion dédié. Cette configuration est également recommandée pour les domaines de l'environnement d'exécution. S'ils sont connectés en réseau, hébergez ces domaines sur leur propre réseau dédié. Ne connectez pas directement les domaines de l'environnement d'exécution aux réseaux qui sont affectés aux domaines de production. Vous avez la possibilité d'effectuer toutes les tâches d'administration en vous connectant à la console unique mise à disposition par le processeur de service d'Oracle ILOM, mais cette configuration rend l'administration tellement lourde qu'elle en devient impraticable. En séparant les réseaux de production et d'administration, vous vous protégez contre les écoutes électroniques et les manipulations. Ce type de séparation élimine également le risque d'une attaque dirigée contre l'environnement d'exécution et menée depuis les domaines invités via le réseau partagé.
Figure 5 Réseau de gestion dédié
Oracle ILOM
Gère les contrôles environnementaux de base tels que la vitesse du ventilateur et l'alimentation du châssis
Permet les mises à niveau du microprogramme
Fournit la console système pour le domaine de contrôle
Tous les systèmes Oracle SPARC actuels incluent un contrôleur système intégré (Oracle ILOM) qui assure les fonctions suivantes :
Vous pouvez accéder à via une connexion série ou utiliser SSH, HTTP, HTTPS, SNMP, ou IPMI pour y accéder via un port réseau. Les serveurs Fujitsu M10 utilisent XSCF à la place d'Oracle ILOM pour exécuter des fonctions similaires.
Menace : déni de service du système complet
Mettre hors tension tous les invités en cours d'exécution
Installer un microprogramme manipulé pour accéder à un domaine invité au moins
Une personne malveillante qui parvient à prendre le contrôle d'Oracle ILOM peut compromettre le système de multiples façons. Il peut notamment :
Ces scénarios concernent tous les systèmes qui disposent de ce type de contrôleur. Dans un environnement virtualisé, les dommages peuvent être beaucoup plus importants que dans un environnement physique car de nombreux domaines qui sont hébergés dans le même boîtier système sont menacés.
De même, une personne malveillante qui parvient à prendre le contrôle du domaine de contrôle ou d'un domaine d'E/S peut aisément désactiver tous les domaines invités dépendants en arrêtant les services d'E/S correspondants.
Evaluation : déni de service du système complet
Oracle ILOM est en principe connecté à un réseau administratif qui doit être bien protégé et isolé des réseaux de production normaux.
De même, une personne malveillante peut violer la sécurité d'un domaine de service à partir du réseau ou par le biais d'une erreur dans la pile de virtualisation, puis bloquer les E/S invitées ou arrêter le système. Bien que les dommages soient limités car les données ne sont ni perdues, ni compromises, ils peuvent affecter un grand nombre de domaines invités. Veillez donc à vous protéger contre cette menace possible pour limiter les dommages potentiels.
Contre-mesure : sécurisation d'Oracle ILOM
Placement du port réseau d'Oracle ILOM dans un segment de réseau distinct du réseau administratif qui est utilisé pour les domaines dans l'environnement d'exécution.
Désactivation de tous les services qui ne sont pas requis pour le fonctionnement normal, tels que HTTP, IPMI, SNMP, HTTPS et SSH.
Configuration de comptes administrateur dédiés et personnels qui accordent uniquement les droits requis. Pour permettre une traçabilité maximale des actions effectuées par les administrateurs, assurez-vous de créer des comptes administrateur personnels. Ce type d'accès est particulièrement important pour l'accès à la console, les mises à niveau de microprogrammes et la gestion des configurations de démarrage.
En tant que processeur de service, contrôle des fonctions essentielles telles que l'alimentation du châssis, les configurations de démarrage d'Oracle VM Server for SPARC et l'accès par console au domaine de contrôle. Les mesures suivantes permettent de sécuriser Oracle ILOM :
Hyperviseur
L'hyperviseur réel, qui est implémenté dans le microprogramme et pris en charge par les CPU des systèmes.
Des modules de noyau qui s'exécutent dans le domaine de contrôle pour configurer l'hyperviseur.
Des modules de noyau et des démons qui s'exécutent dans les domaines d'E/S et les domaines de service pour fournir des E/S virtualisées, ainsi que des modules de noyau qui communiquent par le biais de canaux de domaines logiques (LDC, Logical Domain Channels).
Des modules de noyau et des pilotes de périphériques qui s'exécutent dans les domaines invités pour accéder aux périphériques d'E/S virtualisées ainsi que les modules de noyau qui communiquent par le biais de canaux de domaines logiques (LDC).
L'hyperviseur est la couche du microprogramme qui implémente et contrôle la virtualisation du matériel réel. L'hyperviseur est formé des composants suivants :
Menace : rupture de l'isolement
Une personne malveillante peut détourner des domaines invités ou l'ensemble du système en s'introduisant dans l'environnement d'exécution isolé fourni par l'hyperviseur. C'est la menace qui peut entraîner les plus graves dommages sur un système.
Evaluation : rupture de l'isolement
Une conception de système modulaire peut améliorer l'isolement en accordant différents niveaux de privilèges aux domaines invités, à l'hyperviseur et au domaine de contrôle. Chaque module fonctionnel est implémenté dans un module de noyau, un pilote de périphérique ou un démon distinct et configurable. Cette modularité requiert des API nettes et des protocoles de communication simples qui réduisent le risque global d'erreurs.
Même si l'exploitation d'une erreur semble peu probable, l'une des conséquences possibles est la prise de contrôle totale de l'ensemble du système par la personne malveillante.
Contre-mesure : validation des signatures des microprogrammes et des logiciels
Même si vous pouvez télécharger les patchs des microprogrammes système et du SE directement à partir d'un site Web d'Oracle, ces patchs peuvent avoir été manipulés. Avant d'installer le logiciel, vérifiez les sommes de contrôle MD5 des packages logiciels. Oracle publie les sommes de contrôle de tous les logiciels téléchargeables.
Contre-mesure : validation des modules de noyau
Oracle VM Server for SPARC utilise plusieurs pilotes et modules de noyau pour implémenter le système de virtualisation global. Tous les modules de noyau et la plupart des fichiers binaires distribués avec le SE Oracle Solaris portent une signature numérique. Servez-vous de l'utilitaire elfsign pour vérifier la signature numérique de chaque pilote et module de noyau. Vous pouvez utiliser la commande pkg verify d'Oracle Solaris 11 pour vérifier l'intégrité d'un élément binaire Oracle Solaris. Consultez la page Web https://blogs.oracle.com/cmt/entry/solaris_fingerprint_database_how_it.
Vous devez commencer par établir l'intégrité de l'utilitaire elfsign. Utilisez l'outil de génération de rapports et d'audit de base (BART) pour automatiser le processus de vérification des signatures numériques. Le document Integrating BART and the Solaris Fingerprint Database in the Solaris 10 Operating System (http://www.oracle.com/technetwork/articles/systems-hardware-architecture/o11-005-bart-solaris-fp-db-276999.pdf) indique comment associer BART et la base de données d'empreintes Solaris pour effectuer automatiquement des vérifications d'intégrité similaires. Bien que la base de données d'empreintes ait été abandonnée, les concepts décrits dans ce document peuvent être repris et peuvent servir à utiliser de façon analogue elfsign et BART.
Vous pouvez utiliser la fonctionnalité Verified Boot en tant que contre-mesure pour la validation des modules de noyau. Pour configurer la validation automatisée des modules noyau au moment de l'initialisation, définissez les stratégies Verified Boot dans Oracle ILOM. Consultez les documents spécifiques à votre plate-forme à l'adresse http://docs.oracle.com/en/hardware/. Pour valider des modules de noyau dans le domaine de contrôle, définissez les stratégies Verified Boot dans Oracle ILOM. Pour valider des modules de noyau dans des domaines invités, utilisez Logical Domains Manager pour définir les stratégies Verified Boot.
Domaine de contrôle
Le domaine de contrôle, qui joue souvent les rôles de domaine d'E/S et de domaine de service, doit être protégé car il peut modifier la configuration de l'hyperviseur, lequel contrôle toutes les ressources matérielles connectées.
Menace : déni de service du domaine de contrôle
L'arrêt du domaine de contrôle peut entraîner un déni de service des outils de configuration. Le domaine de contrôle n'étant indispensable que pour les modifications de configuration, les domaines invités peuvent indifféremment accéder à leurs ressources réseau et leurs ressources de disque par le biais d'autres domaines de service.
Evaluation : déni de service du domaine de contrôle
Attaquer le domaine de contrôle via le réseau équivaut à attaquer n'importe quelle autre instance du SE Oracle Solaris correctement protégée. Les dommages causés par un arrêt ou un déni de service du domaine de contrôle sont relativement faibles. Toutefois, des domaines invités peuvent être affectés si le domaine de contrôle joue également pour eux le rôle de domaine de service.
Contre-mesure : sécurisation de l'accès à la console
Evitez de configurer un accès réseau administratif aux domaines de l'environnement d'exécution. Ce scénario exige d'utiliser le service de console vers le domaine de contrôle pour effectuer toutes les tâches d'administration. L'accès par console à tous les autres domaines est toujours possible par le biais du service vntsd s'exécutant sur le domaine de contrôle.
Réfléchissez bien avant d'implémenter cette solution. Bien qu'elle réduise le risque d'attaques via le réseau administratif, cette solution signifie qu'un seul administrateur peut accéder à la console à la fois.
Pour plus d'informations sur la configuration sécurisée de vntsd, reportez-vous à la section Procédure d’activation du démon du serveur de terminal du réseau virtuel du manuel Guide d’administration d’Oracle VM Server for SPARC 3.4.
Logical Domains Manager
Logical Domains Manager s'exécute dans le domaine de contrôle et sert à configurer l'hyperviseur, ainsi qu'à créer et à configurer tous les domaines et les ressources matérielles associées. Assurez-vous que l'utilisation de Logical Domains Manager est consignée et surveillée.
Menace : utilisation non autorisée d'utilitaires de configuration
Une personne malveillante peut prendre le contrôle de l'ID utilisateur d'un administrateur ou un administrateur d'un autre groupe peut accéder de manière illicite à un autre système.
Evaluation : utilisation non autorisée d'utilitaires de configuration
Assurez-vous qu'un administrateur ne dispose pas d'un accès à un système dont il n'a pas besoin en implémentant une gestion des identités efficace. Implémentez également un contrôle d'accès strict et détaillé ainsi que d'autres mesures telles que la règle des deux personnes.
Contre-mesure : application de la règle des deux personnes
Envisagez d'implémenter une règle des deux personnes pour Logical Domains Manager et d'autres outils d'administration par le biais de droits. Application d'une règle en présence de deux personnes à l'aide d'un RBAC Solaris 10 (https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_rule). Cette règle protège votre système contre les attaques d'ingénierie sociale, les comptes d'administration non fiables et les erreurs humaines.
Contre-mesure : utilisation de droits pour Logical Domains Manager
En utilisant des droits pour la commande ldm, vous pouvez implémenter un contrôle d'accès détaillé et une traçabilité complète. Pour plus d'informations sur la configuration des droits, reportez-vous au manuel Guide d’administration d’Oracle VM Server for SPARC 3.4. L'utilisation de droits permet de protéger votre système des erreurs humaines car les fonctions de la commande ldm ne sont pas toutes accessibles à tous les administrateurs.
Contre-mesure : sécurisation de Logical Domains Manager
Désactivez les services non indispensables du gestionnaire de domaines. Logical Domains Manager fournit des services réseau pour l'accès aux domaines, ainsi que pour leur surveillance et leur migration. La désactivation des services réseau réduit la surface d'exposition aux attaques de Logical Domains Manager au minimum requis pour un fonctionnement normal. Ce scénario permet de lutter contre les attaques par déni de service et les autres tentatives d'utilisation abusive de ces services réseau.
Remarque - Bien que la désactivation des services du gestionnaire de domaines permette de réduire la surface d'exposition aux attaques, il n'est pas possible de prévoir les effets secondaires d'une telle désactivation pour une configuration donnée.
Service de migration sur le port TCP 8101
Pour désactiver ce service, reportez-vous à la description des propriétés ldmd/incoming_migration_enabled et ldmd/outgoing_migration_enabled dans la page de manuel ldmd(1M).
Prise en charge XMPP (Extensible Messaging and Presence Protocol) sur le port TCP 6482
Pour plus d'informations sur la désactivation de ce service, reportez-vous à la section Transport XML du manuel Guide du développeur d’Oracle VM Server for SPARC 3.4.
Notez que la désactivation de XMPP empêche d'utiliser certains outils de gestion et certaines fonctions essentielles d'Oracle VM Server for SPARC. Reportez-vous à Interface XML d'Oracle VM Server for SPARC.
Protocole SNMP (Simple Network Management Protocol) sur le port UDP 161
Activez le service SNMP pour utiliser MIB Oracle VM Server for SPARC. Installez MIB Oracle VM Server for SPARC en toute sécurité. Voir Procédure d’installation du package logiciel MIB Oracle VM Server for SPARC du manuel Guide d’utilisation d’Oracle VM Server for SPARC Management Information Base et Chapitre 3, Gestion de la sécurité du manuel Guide d’utilisation d’Oracle VM Server for SPARC Management Information Base.
Désactivez le service SNMP. Pour plus d'informations sur la manière de désactiver ce service, reportez-vous à la section Procédure de suppression du package logiciel MIB Oracle VM Server for SPARC du manuel Guide d’utilisation d’Oracle VM Server for SPARC Management Information Base.
Déterminez si vous souhaitez utiliser Base MIB (Management Information Base) Oracle VM Server for SPARC pour observer les domaines. Cette fonction nécessite que le service SNMP soit activé. En fonction de votre choix, effectuez l'une des opérations suivantes :
Service de découverte sur l'adresse de multidiffusion 239.129.9.27 et le port 64535
Remarque - Notez que ce mécanisme de détection est également utilisé par le démon ldmd pour détecter les collisions lors de l'affectation automatique d'adresses MAC. Si vous désactivez le service de repérage, la détection de collision d'adresses MAC ne fonctionnera pas et par conséquent, l'allocation d'adresses MAC ne fonctionnera pas correctement non plus.Il est impossible de désactiver ce service pendant que le démon de Logical Domains Manager, ldmd, est en cours d'exécution. Au lieu de cela, utilisez la fonction IP Filter d'Oracle Solaris pour bloquer l'accès à ce service, ce qui réduit la surface d'exposition aux attaques de Logical Domains Manager. Le blocage de l'accès empêche l'utilisation non autorisée de l'utilitaire, ce qui permet de lutter efficacement contre les attaques par déni de service et les autres tentatives d'utilisation abusive de ces services réseau. Reportez-vous au Chapitre 20, IP Filter in Oracle Solaris (Overview) du manuel Oracle Solaris Administration: IP Services et à la section Using IP Filter Rule Sets du manuel Oracle Solaris Administration: IP Services.
Désactivez les services réseau suivants lorsque vous ne les utilisez pas :
Voir également la section Contre-mesure : sécurisation d'Oracle ILOM.
Domaine de service
Un domaine de service fournit des services virtuels aux domaines invités sur le système. Les services peuvent inclure un service de commutateur virtuel, de disque virtuel ou de console virtuelle.
La section Figure 6 présente un exemple de domaine de service qui propose des services de console. Le domaine de contrôle héberge fréquemment les services de console, ce qui en fait également un domaine de service. Les domaines de l'environnement d'exécution associent souvent des fonctions de domaine de contrôle, de domaine d'E/S et de domaine de service dans un ou deux domaines.
Menace : manipulation d'un domaine de service
Une personne malveillante qui prend le contrôle d'un domaine de service peut manipuler des données ou écouter toutes les communications qui s'effectuent via les services offerts. Ce contrôle peut comprendre l'accès de la console aux domaines invités, l'accès aux services réseau ou l'accès aux services de disque.
Evaluation : manipulation d'un domaine de service
Bien que les stratégies d'attaque soient les mêmes que pour une attaque dirigée contre un domaine de contrôle, les dommages potentiels sont moindres car la personne malveillante ne peut pas modifier la configuration système. Les dommages possibles sont par exemple le vol ou la manipulation de données offertes par le domaine de service, mais pas la manipulation de sources de données. Selon le service concerné, une personne malveillante peut être contrainte d'échanger des modules de noyau.
Figure 6 Exemple de domaine de service
Contre-mesure : séparation des domaines de service de manière granulaire
Dans la mesure du possible, chaque domaine de service ne doit proposer qu'un seul service à ses clients. Une telle configuration permet de garantir qu'un seul service est compromis si un domaine de service subit une attaque. Tenez compte toutefois de la complexité accrue du système avant d'opter pour une configuration de ce type. Notez que la présence de domaines d'E/S redondants est fortement recommandée.
Contre-mesure : isolation des domaines de service et des domaines invités
Faites en sorte que le domaine de service et le domaine invité ne partagent pas le même port réseau. En outre, ne raccordez pas d'interface de commutateur virtuel à un domaine de service. Pour les domaines de service Oracle Solaris 11, ne raccordez pas de carte VNIC aux ports physiques utilisés pour les commutateurs virtuels.
Si vous devez utiliser le même port réseau pour les SE Oracle Solaris 10 et Oracle Solaris 11, placez le trafic du domaine d'E/S dans un réseau VLAN qui n'est pas utilisé par des domaines invités.
Si vous ne pouvez implémenter aucune des solutions précédentes, ne raccordez pas le commutateur virtuel dans le SE Oracle Solaris 10 et appliquez des filtres IP dans le SE Oracle Solaris 11.
Vous pouvez isoler aussi bien les domaines de service Oracle Solaris 10 que les domaines de service Oracle Solaris 11 des domaines invités. Les solutions suivantes sont présentées dans l'ordre d'implémentation à privilégier :
Contre-mesure : limitation de l'accès aux consoles virtuelles
Assurez-vous que l'accès aux différentes consoles virtuelles est limité aux seuls utilisateurs qui doivent y accéder. Cette configuration garantit qu'aucun administrateur n'a accès à toutes les consoles, ce qui empêche l'accès aux consoles autres que celles assignées à un compte compromis. Reportez-vous à la section Procédure de création des services par défaut du manuel Guide d’administration d’Oracle VM Server for SPARC 3.4.
Domaine d'E/S
Tout domaine qui a directement accès à un périphérique d'E/S physique tel que des ports ou des disques réseau est un domaine d'E/S. Pour plus d'informations sur la configuration des domaines d'E/S, reportez-vous au Chapitre 6, Configuration de domaines d’E/S du manuel Guide d’administration d’Oracle VM Server for SPARC 3.4.
Un domaine d'E/S peut également être un domaine de service s'il offre des services d'E/S à des domaines invités, ce qui permet à ces derniers d'accéder au matériel.
Menace : survenance d'un déni de service d'un domaine d'E/S ou d'un domaine de service
Une personne malveillante qui bloque les services d'E/S d'un domaine d'E/S bloque par la même occasion l'ensemble des domaines invités dépendants. Il est possible de lancer une attaque par déni de service réussie en surchargeant l'infrastructure du réseau ou du disque ou en introduisant une erreur dans le domaine. Chacune de ces attaques peut provoquer un blocage ou une erreur grave du domaine. De même, une personne malveillante qui suspend les services d'un domaine de service provoque le blocage immédiat de tout domaine invité qui dépend de ces services. Si le domaine invité se bloque, il se remet à fonctionner lorsque le service d'E/S reprend.
Evaluation : survenance d'un déni de service d'un domaine d'E/S ou d'un domaine de service
Les attaques par déni de service sont fréquemment effectuées par le biais du réseau. Ce type d'attaque peut réussir car les ports réseau sont ouverts à la communication et peuvent être submergés par le trafic réseau. La perte de service qui en résulte bloque les domaines invités dépendants. Une attaque similaire peut être dirigée contre les ressources de disque par le biais de l'infrastructure SAN ou en attaquant le domaine d'E/S. Le seul dommage qui en résulte est un arrêt temporaire de tous les domaines invités dépendants. Bien que l'impact d'un déni de service sur les tâches puisse être conséquent, les données ne sont ni compromises, ni perdues, et la configuration du système reste intacte.
Contre-mesure : configuration des domaines d'E/S de manière granulaire
La configuration de plusieurs domaines d'E/S permet de réduire l'impact d'une défaillance ou d'une perte de fiabilité d'un domaine. Vous pouvez affecter des emplacements PCIe individuels à un domaine invité pour lui accorder des capacités de domaine d'E/S. Si le domaine root propriétaire du bus PCIe tombe en panne, ce bus est réinitialisé, ce qui entraîne l'arrêt brutal du domaine auquel l'emplacement individuel a été affecté. Cette fonctionnalité n'élimine pas complètement la nécessité de disposer de deux domaines root possédant chacun un bus PCIe distinct.
Contre-mesure : configuration d'un matériel et de domaines root redondants
La haute disponibilité participe également à l'amélioration de la sécurité car elle permet aux services de résister aux attaques par déni de service. Oracle VM Server for SPARC implémente des méthodologies de haute disponibilité telles que l'utilisation de disques et de ressources réseau redondants dans des domaines d'E/S redondants. Cette option de configuration permet des mises à niveau progressives des domaines d'E/S et protège contre l'impact d'une défaillance d'un domaine d'E/S due à une attaque par déni de service. Depuis l'apparition de SR-IOV, les domaines invités sont en mesure d'accéder directement à des périphériques d'E/S individuels. Cependant, si SR-IOV ne peut pas être implémenté, envisagez de créer des domaines d'E/S redondants. Reportez-vous à la section Contre-mesure : séparation des domaines de service de manière granulaire.
Menace : manipulation d'un domaine d'E/S
Un domaine d'E/S a directement accès à des périphériques back-end, généralement des disques, qu'il virtualise puis propose aux domaines invités. Après une attaque réussie, une personne malveillante dispose d'un accès total à ces périphériques et peut lire des données sensibles ou manipuler des logiciels sur les disques d'initialisation des domaines invités.
Evaluation : manipulation dans un domaine d'E/S
Une attaque dirigée contre un domaine d'E/S est aussi probable qu'une attaque réussie sur un domaine de service ou le domaine de contrôle. Le domaine d'E/S est une cible particulièrement prisée car il offre potentiellement un accès à un grand nombre de périphériques de disque. Tenez donc compte de cette menace lorsque vous travaillez avec des données sensibles dans un domaine invité s'exécutant sur des disques virtualisés.
Contre-mesure : protection des disques virtuels
Lorsqu'un domaine d'E/S est compromis, la personne malveillante dispose d'un accès total aux disques virtuels du domaine invité.
Chiffrement du contenu des disques virtuels. Sur les systèmes Oracle Solaris 10, vous pouvez utiliser une application capable de chiffrer ses propres données, telle que les tablespaces chiffrés pgp/gpg ou Oracle 11g. Sur les systèmes Oracle Solaris 11, vous pouvez utiliser des ensembles de données chiffrés ZFS pour assurer un chiffrement transparent de toutes les données stockées dans le système de fichiers.
Répartition des données sur plusieurs disques virtuels dans plusieurs domaines d'E/S. Un domaine invité peut créer un volume entrelacé (RAID 1/RAID 5) qui s'étend sur plusieurs disques virtuels obtenus à partir de deux domaines d'E/S. Si l'un de ces domaines d'E/S est compromis, la personne malveillante auteur de l'attaque ne pourra que difficilement utiliser la portion de données disponible.
Protégez le contenu des disques virtuels en effectuant les opérations suivantes :
Domaines invités
Les domaines invités ne font pas partie de l'environnement d'exécution, mais ils sont la cible d'attaque la plus probable car ils sont connectés au réseau. Une personne malveillante qui pénètre dans un système virtualisé peut lancer des attaques contre l'environnement d'exécution.
Contre-mesure : sécurisation du SE du domaine invité
Le système d'exploitation sur le domaine invité est souvent la première ligne de défense contre toute attaque. Sauf s'il s'agit d'une attaque provenant de l'intérieur du centre de données, une personne malveillante doit s'introduire dans un domaine invité qui a des connexions externes avant de tenter de rompre l'isolement du domaine invité et de capturer l'intégralité de l'environnement. Par conséquent, vous devez sécuriser le SE du domaine invité.
Pour sécuriser davantage le SE, vous pouvez déployer votre application dans des zones Solaris Zone, qui isolent un peu plus le service réseau de l'application du système d'exploitation du domaine invité. Une attaque réussie sur le service compromet uniquement la zone concernée, et non le système d'exploitation sous-jacent, ce qui permet d'éviter que la personne malveillante n'étende son contrôle au-delà des ressources affectées à la zone. Il est ainsi plus difficile à la personne malveillante de rompre l'isolement de l'invité. Pour plus d'informations sur la sécurisation du système d'exploitation invité, reportez-vous aux Oracle Solaris 10 Security Guidelines et aux Oracle Solaris 11 Security Guidelines.