Démarrage automatique et sécurisation d'un serveur Linux avec un système de fichiers crypté

16

J'installe de nouveaux serveurs Ubuntu et j'aimerais sécuriser les données qu'ils contiennent contre le vol. Le modèle de menace est des attaquants désirant le matériel ou plutôt des attaquants naïfs désirant les données.


Veuillez prendre note de cette section.

Le modèle de menace n'inclut pas les attaquants intelligents désirant les données; Je suppose qu'ils feront une ou plusieurs des actions suivantes:

  1. Raccordez un onduleur à un câble d'alimentation afin de faire fonctionner la machine en continu.

  2. Insérez une paire de ponts Ethernet entre l'ordinateur et le point de terminaison réseau qui reliera le trafic sur un réseau sans fil de portée suffisante pour que l'hôte maintienne la connectivité réseau.

  3. Ouvrez la boîte et utilisez une sonde sur le bus mémoire pour saisir des trucs intéressants.

  4. Utilisez des périphériques TEMPEST pour sonder ce que fait l'hôte.

  5. Utiliser des moyens légaux (comme une ordonnance d'un tribunal) pour m'obliger à divulguer les données

  6. Etc.


Donc, ce que je veux, c'est avoir une partie, ou idéalement la totalité, des données sur le disque sur une partition cryptée, avec le matériel clé nécessaire pour y accéder sur un support externe quelconque. Deux méthodes auxquelles je peux penser pour stocker le matériel clé sont:

  1. Stockez-le sur un hôte distant accessible via le réseau et configurez suffisamment de réseau pour le récupérer pendant le processus de démarrage. La récupération serait autorisée uniquement à l'adresse IP attribuée à l'hôte sécurisé (ne permettant donc pas l'accès aux données chiffrées si elles étaient démarrées sur une autre connexion réseau) et pourrait être désactivée par les administrateurs si la machine était découverte comme étant volée.

  2. Stockez-le sur un périphérique de stockage USB qui est en quelque sorte beaucoup plus difficile à voler que l'hôte lui-même. Le localiser à distance de l'hôte, comme au bout d'un câble USB de cinq mètres menant dans un autre coin de la pièce, ou même dans une autre pièce, réduirait probablement considérablement les chances des attaquants de le prendre. Le sécuriser d'une manière ou d'une autre, par exemple en le chaînant à quelque chose d'immobile, ou même en le mettant dans un coffre-fort, fonctionnerait encore mieux.

Alors, quelles sont mes options pour configurer cela? Comme je l'ai déjà dit, je préférerais que tout (à part peut-être une petite partition de démarrage qui ne contient pas / etc) soit crypté, de sorte que je n'ai pas à me soucier de l'endroit où je place les fichiers, ou de l'endroit où ils ' re atterrissage accidentel.

Nous utilisons Ubuntu 9.04, si cela fait une différence.

Curt J. Sampson
la source
1
Votre modèle de menace porte-t-il des uniformes avec trois lettres dessus? :)
Sven
Ils ne portent pas d'uniformes. :-) Mais sérieusement, non; toute agence gouvernementale, secrète ou non, est susceptible d'être assez intelligente pour prendre tout le matériel, pas seulement ce qu'elle peut saisir rapidement.
Curt J. Sampson
1
Votre question semble se contredire. D'abord, vous dites "je voudrais sécuriser les données sur eux contre le vol", puis vous dites "n'inclut pas les attaquants intelligents désirant les données". Vous souciez-vous des données ou non?
Zoredache
1
Je m'en soucie oui. Si vous pouvez, pour un coût similaire, le sécuriser contre les attaquants intelligents ainsi que les attaquants stupides, parfait, je le ferai. Sinon, au moins j'évite la situation où quelqu'un achète un disque d'occasion dans une boutique de recyclage et découvre toutes les données de mes clients à ce sujet.
Curt J. Sampson
+1 pour avoir réellement réfléchi au modèle de menace, ce que de nombreuses personnes ayant une question similaire oublient de faire.
sleske

Réponses:

8

Je connais une variante intelligente de l'option 1 appelée Mandos.

Il utilise une combinaison d'une paire de clés GPG, Avahi, SSL et IPv6, tous ajoutés à votre disque RAM initial pour récupérer en toute sécurité le mot de passe de la clé de sa partition racine. Si le serveur Mandos n'est pas présent sur le réseau local, votre serveur est une brique chiffrée ou le serveur Mandos n'a pas vu de pulsation du logiciel client Mandos pendant une période de temps donnée, il ignorera les demandes futures pour cette paire de clés et le serveur. est une brique cryptée au prochain démarrage.

Page d'accueil de Mandos

Mandos README

Haakon
la source
1
Idée intéressante. Je suppose que vous seriez en train de démarrer PXE les clients afin que la paire de clés publique / privée ne soit pas sur le disque dur. Pourtant, vous pouvez espionner la paire de clés du fil, puis l'utiliser, en combinaison avec un reniflement de la transmission de la clé de chiffrement en bloc par l'ordinateur serveur, pour déchiffrer le lecteur. L'ensemble du "serveur ne distribuera pas de clé s'il n'a pas entendu de battement de coeur dans la fenêtre de temps xxx" sonne également comme un bon moyen de mettre un humain dans la boucle. Projet soigné. Pas trop difficile à vaincre si vous avez un accès physique, mais soigné.
Evan Anderson
2
Evan, tu veux lire la FAQ dans le README de Mandos, je pense ....
Curt J. Sampson
Hm. Je ne comprends pas pourquoi Mandos ne fonctionne que sur un réseau local. Est-ce parce qu'il ne peut pas configurer d'adresse IP et de routes pour utiliser Internet?
Curt J. Sampson
1
Curt, Mandos utilise des adresses locales de liaison ipv6 pour communiquer, ce qui est limité au réseau local. Cela signifie cependant qu'il n'a pas besoin de configuration externe (dhcp) ni de conflit avec d'autres serveurs sur le même LAN. en.wikipedia.org/wiki/…
Haakon
1
En tant que co-auteur de Mandos, je ne peux qu'être d'accord avec Haakon. Il existe en fait un moyen pour Mandos d'utiliser des adresses IPv4 globales en utilisant le noyau ip=et les mandos=connectparamètres, voir ce courrier: mail.fukt.bsnet.se/pipermail/mandos-dev/2009-F February / mais notez que cela est quelque peu fragile car le les clients ne tenteront de se connecter au serveur spécifié qu'une seule fois et échoueront irrévocablement dans le cas contraire. La configuration recommandée est via le LAN. Je peux également mentionner que Mandos est disponible dans Ubuntu depuis 9.04 (et également dans les tests Debian)
Teddy
6

Si vous cherchez simplement à vous protéger contre des attaquants non techniques, je pense que votre meilleur pari est une meilleure sécurité physique.

Ma pensée est donc:

Si vous recherchez une botte ne nécessitant aucune interaction humaine pour entrer dans le matériel clé, vous n'allez pas trouver de solution qui sera à l'abri du vol, même occasionnel, par un attacheur possédant des compétences techniques (ou, plus exactement, le capacité de payer une personne ayant des compétences techniques).

Mettre du matériel clé dans quelque chose comme une clé USB n'offrirait aucune sécurité réelle. L'attaquant pourrait simplement lire la clé de la clé USB. La clé USB ne peut pas savoir si l'ordinateur auquel elle a été branchée est l'ordinateur serveur ou l'ordinateur portable de l'attaquant. Tout ce que l'attaquant a à faire est de s'assurer qu'il prend tout ou, dans le cas de votre clé USB, au bout d'un câble extensible USB de 15 pieds de long coincé dans un coffre-fort, branchez simplement le câble extensible sur leur PC et lisez la clé.

Si vous allez transférer la clé sur le réseau, vous la "chiffrerez" probablement. Tout ce que l'attaquant a à faire est d'écouter le processus de saisie, de voler le serveur, puis de rétroconcevoir tout "chiffrement" que vous avez fait lorsque vous avez envoyé la clé sur le réseau. Par définition, l'ordinateur serveur qui reçoit une clé "chiffrée" de l'ensemble du réseau doit pouvoir "déchiffrer" cette clé pour l'utiliser. Donc, vraiment, vous ne cryptez pas la clé - vous la codez simplement.

En fin de compte, vous avez besoin d'une intelligence (artificielle?) Présente pour entrer la clé dans le serveur. Celui qui peut dire "Je sais que je ne divulgue la clé à personne d'autre qu'à l'ordinateur serveur, et je sais qu'elle n'a pas été volée". Un humain peut le faire. Une clé USB ne peut pas. Si vous trouvez une autre intelligence qui peut le faire, je pense que vous aurez quelque chose de commercialisable. > sourire <

Il est très probable, je pense, que vous perdrez la clé et détruirez vos données sans gagner en sécurité. Au lieu de votre stratégie avec des jeux de cryptage, je pense que vous feriez mieux d'avoir une sécurité physique plus forte.

Éditer:

Je pense que nous travaillons à partir de différentes définitions du terme «modèle de menace», peut-être.

Si votre modèle de menace est le vol de matériel, la solution que vous proposez: le chiffrement du disque ne fait, à mon avis, rien pour contrer la menace. La solution que vous proposez ressemble à une contre-mesure contre le vol de données, pas le vol de matériel.

Si vous voulez empêcher le vol du matériel, vous devez le verrouiller, le verrouiller, l'enfermer dans du béton, etc.

J'ai déjà dit ce que je voulais dire au sujet du vol des données, donc je ne reviendrai pas là-dessus, sauf pour dire: si vous allez mettre la clé dans un appareil physique et que vous ne pouvez pas protéger l'ordinateur serveur contre le vol, vous ne pouvez pas non plus protéger l'appareil clé contre le vol.

Je suppose que votre meilleure solution "bon marché" consiste à truquer une sorte d'échange de clés basé sur le réseau. Je mettrais un ou plusieurs humains dans la boucle pour authentifier la "libération" de la clé en cas de redémarrage. Cela provoquerait un temps d'arrêt jusqu'à ce que l'humain "libère" la clé, mais au moins cela vous donnerait une chance de découvrir pourquoi une "libération" de la clé était demandée et de décider si oui ou non.

Evan Anderson
la source
Ceci est un bon ajout à l'analyse de sécurité, donc je lui ai donné une note positive, mais ce n'est pas une réponse à ma question car vous utilisez un modèle de menace différent. Notez ce que j'ai dit dans la question à propos de qui je suis et ne défend pas.
Curt J. Sampson
1
Quant à une meilleure sécurité physique, je voudrais d'abord examiner les options moins coûteuses. Dans notre environnement actuel, il nous en coûterait plusieurs milliers de dollars pour installer quelque chose qui ne pourrait pas être rapidement vaincu par quelqu'un avec une paire de coupe-boulons.
Curt J. Sampson
En relisant cela, je ne suis pas sûr que vous soyez clair que mon modèle de menace n'est pas le vol de matériel en soi , ce qui n'est fondamentalement qu'un inconvénient, mais le vol concomitant de données qui l'accompagne. C'est précisément pourquoi ma solution proposée est une contre-mesure contre le vol de données, plutôt que le vol de matériel.
Curt J. Sampson
Il est intéressant de voir un commentaire sur une question de près de 8 ans. Si votre solution fonctionne pour vous, je m'en réjouis certainement.
Evan Anderson
Je pensais juste «je ne devrais pas nécropost», puis j'ai vu ces derniers commentaires. Je pense que le modèle de menace de Curt est le même que le mien ... pour protéger les données contre quelqu'un qui vole le matériel. Plusieurs commentaires sur ce sujet et des articles similaires ont déclaré que les gens pouvaient simplement «espionner» le processus clé et le découvrir plus tard. Seul un processus vraiment ridiculement mauvais pourrait être interrompu par une sorte de relecture. Aussi ... "tout ce que l'attaquant a à faire est" ... "rétroconcevoir tout cryptage que vous avez fait" ... De qui parlons-nous? Quelles sont les chances pour un voleur ordinaire d'avoir une telle capacité ... ou même le désir de le faire?
darron