Je commencerai par dire que cette question est très large et montre très peu de recherches originales, et que cette réponse ne doit pas être considérée comme un encouragement à ce type de question. Au lieu de cela, cette réponse espère fournir des conseils de sécurité extrêmement basiques aux personnes qui commencent tout juste par l'analyse de logiciels malveillants.
En supposant que vous exécutez des logiciels malveillants connus et précédemment recherchés, la façon dont vous isolez votre environnement dépend fortement de la capacité de ce logiciel malveillant. Certaines règles générales qui s'appliquent à la plupart des logiciels malveillants modernes peuvent être les suivantes:
Isolez votre machine virtuelle d'Internet. Cela peut être aussi simple que de ne pas configurer le transfert d'interface vers la machine invitée, et empêche le malware de communiquer avec les nœuds de commande et de contrôle potentiels qui pourraient l'obliger à agir de manière imprévisible.
Utilisez un hyperviseur approprié. Il y en a quelques-uns sur le marché, notamment VirtualBox, HyperV, QEMU et macOS Hypervisor.framework
, pour n'en nommer que quelques-uns; certains d'entre eux sont activement ciblés par des logiciels malveillants et, selon la version, peuvent être vulnérables à la propagation de logiciels malveillants sur la machine invitée.
N'installez certainement pas les ajouts d'invités ou les analogues d'une autre plate-forme. L'objectif littéral de ce type de logiciel est d'établir une intégration entre l'invité et l'hôte, en affaiblissant efficacement la séparation entre eux. Je ne suis pas un chercheur de malware, mais je serais surpris s'il n'y avait pas de malware ciblant spécifiquement ce type de surface.
Pour traiter directement certains de vos points:
Dans quelle mesure une machine virtuelle peut-elle être isolée de l'hôte?
À ce stade, une machine virtuelle peut être assez complètement isolée, mais certaines fonctions doivent encore passer par l'hôte plus ou moins directement, avec peu de protection contre l'hyperviseur. Dès le départ, la plupart des machines virtuelles non KVM (comme VirtualBox) ne partageront pas de noyau avec le système d'exploitation hôte. À lui seul, cela sert de bloqueur contre de nombreuses classes d'exploit, bloquant notamment la possibilité d'exécuter des appels système arbitraires contre votre noyau hôte (avec l'astérisque notable qu'une implémentation de la couche VM cassée peut permettre aux logiciels malveillants de contourner cela de manière moins évidente).
Cependant, votre machine virtuelle dispose toujours d'un espace de processus dans le matériel de votre machine hôte - et bien que cela ne soit généralement pas un risque car les systèmes d'exploitation modernes fournissent une isolation de l'espace de processus décent, il peut toujours être utilisé pour exploiter des attaques de très bas niveau comme un marteau , où un processus écrit séquentiellement dans la mémoire d'une manière spécifique jusqu'à ce qu'il puisse lire les blocs de mémoire adjacents qui ne lui appartiennent pas - permettant effectivement une fuite de mémoire entre les processus.
Il convient également de noter que l'isolement a tendance à disparaître quelque peu lorsque vous souhaitez effectuer essentiellement tout type d'E / S: l'entrée et la sortie signifient nécessairement un passage, ce qui expose une surface d'attaque qui peut être exploitée pour effectuer des actions d'hôte. Cela inclut le passage HID comme une souris et un clavier, ainsi que des choses comme le passage réseau - bien que cela dépend généralement de la façon dont le passage d'E / S est implémenté dans votre machine virtuelle.
Dois-je (ou puis-je?) Mettre en place un pare-feu entre l'invité et l'hôte?
Cela dépend, mais ce n'est généralement pas une mauvaise idée . La plupart des principales plates-formes prennent en charge les pare-feu de niveau hyperviseur. Ceux-ci sont tout au plus aussi permissifs que le pare-feu sur votre machine hôte, qui est à son tour tout aussi permissif que le pare-feu sur votre LAN ou VLAN. Si vous souhaitez tirer parti de cela au lieu de couper complètement l'accès au réseau en déconnectant les interfaces réseau virtuelles, je vous recommande de faire une recherche sur les ports et les hôtes de vos cibles de logiciels malveillants sélectionnés et de partir de là.
Les modules complémentaires invités constituent-ils un risque pour la sécurité?
Oui . Ils permettent toutes sortes d'intégrations entre votre machine hôte et votre machine invitée, et ne comportent pas toujours de spécifications ouvertes où vous pouvez voir ce qui est ouvert; voir au dessus.
Qu'en est-il des répertoires partagés?
Cela dépend de la façon dont vous le faites, mais c'est souvent une mauvaise idée . De nombreux hyperviseurs le font en créant un lecteur virtuel monté sur la machine invitée dont la racine se trouve dans ce répertoire. En fonction de la mise en œuvre de ce mécanisme, qui peut varier légèrement entre les frameworks, vous pouvez être en sécurité ou non, selon le malware que vous essayez de tester.
Ma préoccupation est que vous avez effectué très peu de recherches à ce sujet et que vous pourriez finir par endommager votre machine ou vos données. Avant de continuer, je vous conseille de vous pencher sur les différents mécanismes d'isolement sur les systèmes d'exploitation courants (KVM, comment ils s'intègrent avec les cadres de virtualisation de plus haut niveau ( machine virtuelle ), les conteneurs ( conteneur ) et le chroot
mécanisme ( chroot ) pour nommer quelques-uns), lorsque chacun est approprié, et ce qu'ils peuvent et ne peuvent pas faire. À ce stade, vous pourrez mieux juger si vous pouvez jouer en toute sécurité avec des logiciels malveillants dans un environnement correctement isolé.
Enfin, vous ne devriez pas essayer de travailler avec des logiciels malveillants nouveaux ou peu connus (sauf si vous êtes un chercheur chevronné en sécurité, mais cette réponse ne s'adresse pas aux chercheurs chevronnés en sécurité). Les acteurs malveillants sont extrêmement créatifs en ce qui concerne ce qu'ils exploitent et comment ils l'exploitent. Pour vous en faire une idée, jetez un œil à toutes les discussions récentes de DEFCON qui ne sont pas centrées sur l'ingénierie sociale ou l'accès physique par des moyens mécaniques.