Que faire si des siloviki se présentent chez votre hébergeur

kdpv — Reuters

Si vous avez loué un serveur, vous n'avez pas un contrôle total sur celui-ci. Cela signifie qu'à tout moment, des personnes spécialement formées peuvent se rendre chez l'hébergeur et demander toutes vos données. Et l'hébergeur les remettra si la demande est faite légalement.

Vous ne voulez vraiment pas que les logs de votre serveur web ou les données des utilisateurs tombent entre de mauvaises mains. Il est impossible d'atteindre une protection parfaite. Se protéger contre un hébergeur qui possède l'hyperviseur et vous fournit une machine virtuelle est presque impossible. Cependant, il est peut-être possible de réduire légèrement les risques. Le chiffrement des machines louées n'est pas aussi inutile qu'il y paraît au premier abord. Par la même occasion, examinons les menaces liées à l'extraction de données des serveurs physiques.

Modèle de menace

En règle générale, l'hébergeur s'efforcera de protéger au maximum les intérêts du client, autant que la loi le permet. Si une demande dans une lettre d'organes officiels ne requiert que les logs d'accès, l'hébergeur ne fournira pas les dumps de toutes vos machines virtuelles contenant des bases de données. En tout cas, il ne devrait pas. Si l'on demande toutes les données, l'hébergeur copiera les disques virtuels avec tous les fichiers et vous ne serez même pas au courant.

Quelle que soit l'évolution des événements, votre principal objectif est de rendre une attaque trop complexe et coûteuse. Il existe généralement trois types principaux de menaces.

Officiel

Le plus souvent, un courrier papier est envoyé au bureau officiel de l'hébergeur avec une demande de fournir les données nécessaires conformément à l'arrêté en vigueur. Si tout est en ordre, l'hébergeur fournit les logs d'accès nécessaires et d'autres données aux autorités officielles. En général, il suffit de demander les données nécessaires.

Il arrive que, si cela est vraiment nécessaire, des représentants des forces de l'ordre se rendent en personne dans le centre de données. Par exemple, lorsque vous avez votre propre serveur dédié et que les données ne peuvent être récupérées que physiquement.

Dans tous les pays, l'accès à une propriété privée, les perquisitions et d'autres actions nécessitent des preuves que ces données peuvent contenir des informations importantes pour une enquête criminelle. De plus, un mandat d perquisition dûment établi est requis. Il peut y avoir des nuances liées aux spécificités de la législation locale. L'essentiel à comprendre est que, si les procédures officielles sont correctement suivies, les représentants du Data Center ne laisseront passer personne au-delà du point de contrôle.

De plus, dans la plupart des pays, il n'est pas possible de simplement s'emparer d'équipements en fonctionnement. Par exemple, en Russie, jusqu'à la fin de 2018, selon l'article 183 du Code de procédure pénale, partie 3.1, il était garanti que lors de la saisie, le retrait des supports d'information électroniques se faisait en présence d'un spécialiste. À la demande du propriétaire légal des supports d'information électroniques ou du détenteur des informations qu'ils contiennent, le spécialiste participant à la saisie, en présence de témoins, copiait les informations sur d'autres supports d'information électroniques.

Puis, malheureusement, ce paragraphe a été supprimé de l'article.

Secret et non officiel

C'est déjà le territoire d'action des collègues spécialement formés de la NSA, du FBI, du MI5 et d'autres organisations aux acronymes. Le plus souvent, la législation des pays prévoit des pouvoirs très étendus pour de telles structures. De plus, il y a presque toujours une interdiction légale de toute divulgation directe ou indirecte du simple fait de collaborer avec de telles agences sécuritaires. En Russie, il existe des normes analogues. normes juridiques.

En cas de menace de ce type pour vos données, elles seront presque certainement extraites. De plus, en plus de la simple saisie, tout l'arsenal non officiel de portes dérobées, de vulnérabilités zero-day, l'extraction de données depuis la mémoire vive de votre machine virtuelle et d'autres réjouissances peuvent être utilisés. L'hébergeur sera alors obligé d'assister au maximum les spécialistes des forces de l'ordre.

Employé malveillant

Tous les gens ne sont pas également bienveillants. Certains administrateurs de centre de données peuvent décider de gagner un peu d'argent en vendant vos données. La suite des événements dépend de leurs autorisations et accès. Le plus désagréable est qu'un administrateur ayant accès à la console de virtualisation a un contrôle total sur vos machines. Il est toujours possible de prendre un snapshot avec tout le contenu de la mémoire vive et de l'examiner tranquillement par la suite.

— serveur dédié virtuel.

Vous avez donc une machine virtuelle fournie par votre hébergeur. Comment pouvez-vous organiser le chiffrement pour vous protéger ? En réalité, il est presque impossible de le faire. De plus, même un serveur dédié d'un tiers peut finalement s'avérer être une machine virtuelle, dans laquelle les dispositifs nécessaires sont connectés.

Si le but de la machine distante n'est pas seulement de stocker des données, mais d'effectuer certains calculs, la seule option pour travailler avec un système non fiable sera de mettre en œuvre le chiffrement homomorphe. Cela signifie que le système pourra effectuer des calculs sans possibilité de comprendre exactement ce qu'il fait. Malheureusement, les frais généraux pour mettre en œuvre un tel chiffrement sont si élevés que son application pratique est actuellement limitée à des tâches très spécifiques.

De plus, pendant que la machine virtuelle est en fonctionnement et effectue certaines actions, tous les volumes chiffrés sont accessibles, sinon le système d'exploitation ne pourrait tout simplement pas travailler avec eux. Cela signifie qu'avec un accès à la console de virtualisation, vous pouvez toujours prendre un snapshot de la machine en cours d'exécution et extraire toutes les clés de la mémoire vive.

De nombreux fournisseurs ont tenté de mettre en place un chiffrement matériel de la RAM afin que même l'hébergeur n'ait pas accès à ces données. Par exemple, la technologie Intel Software Guard Extensions crée des zones dans l'espace d'adressage virtuel, protégées contre la lecture et l'écriture externes de cette zone par d'autres processus, y compris le noyau du système d'exploitation. Malheureusement, vous ne pourrez pas faire entièrement confiance à ces technologies, car vous serez limité par votre machine virtuelle. De plus, il existe déjà des exemples de victimes de cyberattaques réussies de cette technologie. Pourtant, le chiffrement des machines virtuelles n'est pas aussi inutile qu'il pourrait sembler.

Chiffrer les données sur VDS

Je précise tout de suite que tout ce que nous allons faire ci-dessous ne peut pas assurer une protection complète. L'hyperviseur permettra de créer les copies nécessaires sans arrêter le service et sans que vous ne vous en aperceviez.

• Si l'hébergeur transfère une image « froide » de votre machine virtuelle, vous êtes relativement en sécurité. C'est le scénario le plus courant.
• Si l'hébergeur fournit un instantané complet de la machine en fonctionnement, c'est assez grave. Toutes les données seront montées dans le système en clair. De plus, il sera possible d'explorer la RAM à la recherche de clés privées et d'autres données similaires.

Par défaut, si vous avez déployé un système d'exploitation à partir d'une image vierge, l'hébergeur n'a pas accès en tant que root. Il est toujours possible de monter un support avec une image de secours et de changer le mot de passe root en effectuant un chroot dans l'environnement de la machine virtuelle. Mais cela nécessitera un redémarrage, ce qui sera remarqué. De plus, tous les partitions chiffrées montées seront verrouillées.

Cependant, si le déploiement de la machine virtuelle ne se fait pas à partir d'une image vierge, mais à partir d'une image préparée à l'avance, l'hébergeur peut souvent ajouter un compte privilégié pour aider en cas d'urgence pour le client. Par exemple, pour réinitialiser un mot de passe root oublié.

Même dans le cas d'un instantané complet, ce n'est pas si terrible. L'attaquant ne pourra pas accéder aux fichiers chiffrés si vous les avez montés depuis un système de fichiers distant d'une autre machine. Oui, en théorie, il est possible d'explorer un dump de la mémoire vive et d'extraire des clés de chiffrement à partir de là. Mais en pratique, c'est très complexe et il est très peu probable que le processus aille plus loin qu'un simple transfert de fichiers.

Commandons une machine

Pour nos besoins de test, nous prenons une machine simple dans la section de commande des serveurs. Nous n'avons pas besoin de beaucoup de ressources, donc nous allons choisir l'option avec paiement pour les mégahertz et le trafic utilisés. Cela suffira pour jouer.

Le classique dm-crypt de la partition entière n'a pas fonctionné. Par défaut, le disque est attribué en un seul morceau, avec root sur toute la partition. Réduire la partition ext4 sur un root monté est pratiquement garanti de donner un brique à la place d'un système de fichiers. J'ai essayé) Le tambour n'a pas aidé.

Créons un conteneur chiffré

Nous n'allons donc pas chiffrer l'ensemble de la section, mais utiliser des conteneurs cryptographiques, notamment VeraCrypt, qui a été audité et est fiable. Cela suffit pour nos besoins. Tout d'abord, téléchargez et installez le paquet CLI à partir du site officiel. Vous pouvez également vérifier la signature.

wget https://launchpad.net/veracrypt/trunk/1.24-update4/+download/veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
dpkg -i veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb

Nous allons maintenant créer le conteneur quelque part dans notre répertoire personnel, afin de pouvoir le monter manuellement après un redémarrage. Dans la version interactive, définissez la taille du conteneur, le mot de passe et les algorithmes de chiffrement. Vous pouvez choisir le chiffrement patriote Kuznechik et la fonction de hachage StriBOG.

veracrypt -t -c ~/my_super_secret

Installs maintenant nginx, montons le conteneur et téléchargeons les informations secrètes.

mkdir /var/www/html/images
veracrypt ~/my_super_secret /var/www/html/images/
wget https://upload.wikimedia.org/wikipedia/ru/2/24/Lenna.png

Modifions légèrement /var/www/html/index.nginx-debian.html pour obtenir la page souhaitée et nous pourrons vérifier.

Connectons-nous et vérifions

Le conteneur est monté, les données sont accessibles et livrées.

Voici la machine après redémarrage. Les données sont en sécurité dans ~/my_super_secret.

Si absolument nécessaire et que vous souhaitez un peu de hardcore, vous pouvez chiffrer l'ensemble du système d'exploitation, afin qu'il nécessite une connexion SSH et un mot de passe après le redémarrage. Cela suffira également dans le scénario d'une simple confiscation de « données froides ». Voici un guide utilisant dropbear et le chiffrement à distance des disques. Bien que cela soit compliqué et excessif dans le cas d'un VDS.

Bare metal

Il n'est pas si simple de mettre en place son propre serveur dans un centre de données. Un serveur dédié tiers peut s'avérer être une machine virtuelle, à laquelle tous les appareils sont connectés. Cependant, les choses deviennent intéressantes en termes de protection lorsque vous avez la possibilité d'héberger votre propre serveur physique de confiance dans un centre de données. C’est alors que vous pouvez pleinement tirer parti du dm-crypt traditionnel, de VeraCrypt ou de tout autre chiffrement de votre choix.

Il faut comprendre qu'en cas de chiffrement total, le serveur ne pourra pas se redémarrer seul après un reboot. Il sera nécessaire de se connecter à l'interface locale IP-KVM, IPMI ou à un autre équivalent similaire. Ensuite, nous saisissons manuellement la clé maître. Le schéma n'est pas idéal en termes de continuité et de tolérance aux pannes, mais il n'y a pas de véritable alternative si les données sont si précieuses.

NCipher nShield F3 Hardware Security Module

Une option plus douce implique que les données sont chiffrées et que la clé est directement dans le serveur, dans un HSM (Hardware Security Module) spécial. En général, ce sont des dispositifs très fonctionnels qui assurent non seulement la cryptographie matérielle, mais aussi des mécanismes de détection des tentatives d'effraction physique. Si quelqu'un commence à forer votre serveur avec une meuleuse, le HSM avec une source d'alimentation indépendante réinitialisera les clés qu'il conserve en mémoire. L'attaquant obtiendra des données chiffrées. De plus, le redémarrage peut se faire automatiquement.

La suppression des clés est une option beaucoup plus rapide et humaine que l'activation d'une charge de thermite ou d'un déclencheur électromagnétique. Vos voisins dans le centre de données risquent de vous en vouloir longtemps pour de tels dispositifs. Surtout dans le cas de l'utilisation de TCG Opal 2 le chiffrement sur les supports eux-mêmes, vous n'avez pratiquement aucune surcharge. Tout cela se déroule de manière transparente pour le système d'exploitation. Cependant, il faut faire confiance à un certain Samsung et espérer qu'il utilise un AES256 fiable et non un banal XOR.

Il ne faut pas oublier que tous les ports superflus doivent être physiquement désactivés ou simplement remplis de composé époxy. Sinon, vous offrez aux attaquants la possibilité de mener des attaques DMA. Si vous avez un port PCI Express ou Thunderbolt exposé, y compris un USB avec son support, vous êtes vulnérable. L'attaquant pourra réaliser une attaque par ces ports et accéder directement à la mémoire contenant les clés.

Dans un scénario tout à fait sophistiqué, l'attaquant pourra réaliser une attaque de cold boot. Il suffit de verser une bonne dose d'azote liquide sur votre serveur, d'extraire brut de la mémoire gelée et d'en faire un dump contenant toutes les clés. Souvent, pour mener cette attaque, un simple spray de refroidissement et une température d'environ -50 degrés suffisent. Il existe aussi une méthode plus délicate. Si vous n'avez pas désactivé le démarrage depuis des dispositifs externes, l'algorithme de l'attaquant sera encore plus simple :

1. Geler les barrettes de mémoire sans ouvrir le boîtier
2. Brancher sa clé USB de démarrage
3. Utiliser des utilitaires spéciaux pour extraire des données de la mémoire vive qui ont survécu au redémarrage grâce au gel.

Diviser pour mieux régner

Ok, nous n'avons que des machines virtuelles, mais nous voulons tout de même réduire les risques de fuite de données.
On peut envisager de revoir l'architecture et de séparer le stockage des données et le traitement dans différentes juridictions. Par exemple, le frontend avec des clés de chiffrement chez un hébergeur en République tchèque, et le backend avec des données chiffrées quelque part en Russie. Dans le cas d'une tentative standard de saisie, il est extrêmement peu probable que les forces de l'ordre puissent procéder simultanément dans différentes juridictions. De plus, cela nous protège en partie contre le scénario de capture de snapshot.

Ou bien, on peut considérer une option complètement propre : le chiffrement de bout en bout. Bien sûr, cela sort du cadre du cahier des charges et n'implique pas d'effectuer des calculs sur la machine distante. Néanmoins, c'est tout à fait une option acceptable lorsqu'il s'agit de stockage et de synchronisation de données. Par exemple, cela est très bien implémenté dans Nextcloud. Ainsi, la synchronisation, la gestion des versions et d'autres fonctionnalités du côté serveur ne disparaîtront pas.

Au total

Il n'existe pas de systèmes parfaitement sécurisés. L'objectif est simplement de rendre une attaque plus coûteuse que le bénéfice potentiel.

Une certaine réduction des risques d'accès aux données sur un serveur virtuel peut être obtenue en combinant le chiffrement et le stockage séparé chez différents hébergeurs.

Une option plus ou moins fiable est d'utiliser son propre serveur physique.

Et l'hébergeur devra de toute façon être dignes de confiance. C'est sur cela que repose toute l'industrie.

Source : habr.com