Cet article vise à fournir la démarche pour l'installation d'un ordinateur de salon avec comme préoccupations :
Ce tutorial pars des pré-requis suivant :
Les 2 derniers points sont déjà relativement bien traités sur Internet, ce tutoriel se concentrera donc sur la première problématique. Même si le niveau de sécurité n'est pas optimum, il représentera malgré tout un niveau qui pourra dissuader un bon nombre de personnes malveillantes. Le concept vise à placer une grande partie du système sur un support chiffré. Seul le /boot sera accessible à l'attaquant, votre machine sera donc vulnérable aux attaques de type evil maiden (en) (l'attaquant accède à votre machine pour y placer un /boot corrompu qui interceptera la clé de déchiffrement de votre système de fichiers).
Des solutions existent pour parer ces attaques mais ne serons pas mise en place dans un premier temps :
Côté sécurité réseau, nous mettrons en place une protection contre les indésirables avec l'outil PeerGuardian Linux (anciennement appelé blockcontrol et encore avant, moblocker). Cet outil permet par exemple d'empêcher les connexions vers ou depuis des IPs appartenant à des sociétés qui relève les addresses IP procédant à un téléchargement illicite.
La topologie cible est la suivante :
DISK0 : [[gpt][bios-grub][classic ][classic ][========== raid-linux ===========]] DISK1 : [[gpt][bios-grub][classic ][classic ][========== raid-linux ===========]] LUKS : [ [swapLUKS][========== LUKS contnr ==========]] LVM : [ [=========== raid0mvg ============]] FS : [ [= /boot=][==swap==][= / =][========= /home ==========]]
Cette opération peut être très longue mais il est conseillé de le faire. Pour chaque disques durs, lancez cette commande qui tournera en tâche de fond :
shred --iterations=N --verbose /dev/sda & shred --iterations=N --verbose /dev/sdb & ...
N correspond au nombre de passes de nettoyage. Adaptez cette valeur en fonction du degré de confidentialité des données présentes en clair sur le support. 1 est déjà une bonne valeur.
Voici le schéma de partionnement ciblé :
| Nom | Taille | FS | Type de partition |
|---|---|---|---|
| GRUB-x | 0,008 Go | Vide | Partition de démarrage BIOS |
| Boot-x | 1 Go | Vide | Partition RAID Linux |
| Swap-x | 1/2 à 1 votre quantité de RAM | Vide | Partition d'échange Linux |
| MyFS-x | le reste | Vide | Partition RAID Linux |
Pour le partitionnement nous allons utiliser l'utilitaire de disque, plutôt que GParted, qui nous simplifiera la vie. Lancez l'Utilitaire de disque : System > Administration > Disk Utility. Pour chacun de vos disque-durs, créez une table de partition GPT : Sélectionnez le disque > Formater le disque > Table de partitions GUID.
Pour chacun de vos disque-durs, créez ces 4 partitions dans cet ordre. Sélectionnez votre disque-dur > Cliquez sur l'espace libre > Créer une partition. Pour changez le type de partition, créez d'abord votre partition. Ensuite sélectionnez là et cliquez sur Modifier la partition.
Vous n'êtes pas bleusaille? Très bien. Débrouillez-vous avec ce bref rappel :
| Action | Commande |
|---|---|
| Lancer le logiciel de partionnement | sudo parted /dev/sdX |
| Écrire une table de partitions GPT | mklabel gpt |
| Ajouter une partition | mkpart nom debut fin |
Pour assembler les grappes RAID nous avons besoin de apt://mdadm. Notre /boot sera dans un RAID1 et GRUB impose que si la partition de /boot est dans un RAID alors la version des metadata doit être la 0.90. Pour cette raison, nous n'utiliserons pas l'Utilitaire de disque pour la création du RAID (qui utilise la version 1.20). Par contre, pour le RAID qui contiendra la racine nous utiliserons les metadata version 1.20. Pourquoi? La version 0.90 place les metadata à la fin de la partition. Pour notre dernière partition, la fin de la partition correspond aussi à la fin du disque. Lorsque mdadm cherche les metadata sur le disque il peut croire que tout le disque appartient au RAID (expérience vécu). Mais utiliser la v1.20 des metadata entraine un autre problème comme l'alignement des block LUKS et LVM, ce qui peut nous empêcher d'atteindre des performances optimales. N'hésitez pas à changer votre schéma de partitions pour combiner l'utilisation de plusieurs famille de RAID par exemple.
Dans tout les cas, ne mettez pas vos partitions de swap dans un RAID. Le swap n'est pas connu pour sa séquentialité des accès, il vaut mieux avoir de petits blocs de 4ko plutôt que les 128ko tout boudinés d'un RAID…
mdadm --create /dev/md0 --metadata=0.90 --raid-devices=2 --level=1 /dev/sd[ab]2 mdadm --create /dev/md1 --metadata=1.2 --raid-devices=2 --chunk=128 --level=0 /dev/sd[ab]4
Le mode d'opération que nous allons utiliser est XTS (en), plus adapté au chiffrement de disque.
Nous n'utiliserons pas d'ESSIV (en) car XTS (en) embarque son propre mécanisme pour choisir son vecteur d'initialisation (IV). Ajouter l'ESSIV (en) apporterai un gain négligeable de protection comparé à son impact sur les performances source source officielle. Nous utiliserons du plain64 pour nos IV parce qu'en fonction de la taille de vos disques et de la taille des blocs, l'utilisation du plain(32bits) peut introduire une faille de sécurité du à la répétition des IV.
Le chiffrement que nous utiliserons est l'AES. Le chiffrage Serpent, même s'il est cryptographiquement plus sûr, est suffisamment lourd pour former un goulot d'étranglement sur le débit des disques.
Pour le container LUKS en RAID, on va utiliser l'option align-payload (qui permet de modifier la où commence les blocs de données du container) pour aligner le container avec notre RAID. Par défaut cette valeur est de 8 (secteurs x 512o = 4Ko) que nous plaçons à 512. La formule optimale est : (chunk_size/512o)*qt_data_disk. Un RAID5 de 3 disques aura une valeur de qt_data_disk de 2 un RAID0 de 3 disques aura une valeur de 3. Pensez à adapter cette valeur si vous avez personnalisé la taille du chunk de vos RAIDs.
cryptsetup luksFormat --cipher=aes-xts-plain64 --hash=sha256 --key-size=512 /dev/sda3 cryptsetup luksFormat --cipher=aes-xts-plain64 --hash=sha256 --key-size=512 /dev/sdb3 cryptsetup luksFormat --cipher=aes-xts-plain64 --hash=sha256 --key-size=512 --align-payload=512 /dev/md1
Vous pouvez maintenant déverrouiller les conteneurs LUKS pour obtenir vos partitions mappées dans /dev/mapper/ :
cryptsetup luksOpen /dev/sda3 unlocked-swapa cryptsetup luksOpen /dev/sdb3 unlocked-swapb cryptsetup luksOpen /dev/md1 unlocked-md1
Les disques sont partitionnés, les RAID assemblés et les conteneurs LUKS en place et déverrouillés ; nous allons pouvoir segmenter notre espace de stockage pour y placer les système de fichiers (ou formater).
La création d'un LVM se fait en 4 petites étapes :
Les 3 premières étapes se font simplement :
apt-get install lvm2 pvcreate /dev/mapper/unlocked-md1 vgcreate rootvg /dev/mapper/unlocked-md1
Créons maintenant le volume logique (partition) qui accueillera la racine de notre système de fichier, ici de 80Gio :
lvcreate --name systemlv --size 80g rootvg
On veut maintenant créer un autre volume logique pour accueillir notre /home avec le reste d'espace disponible. Commençons par se renseigner sur l'espace qu'il nous reste :
>>> vgdisplay --- Volume group --- VG Name rootvg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 966,51 GiB PE Size 4,00 MiB Total PE 237187 Alloc PE / Size 20480 / 80,00 GiB Free PE / Size 226947 / 886,51 GiB VG UUID bslw15-...-dsf54f
Il nous reste 226.947 PE de 4Mio soit 907788Mio. Affectons-les :
lvcreate --name homelv --size 907788m rootvg
Nous avons certes fini de créer nos partitions mais aux yeux d'Ubuntu ce sont chacune des volumes distinct. Ubuntu n'acceptera pas de s'installer sur ces volumes sans table de partitions. On va lui jouer un petit tour pour le piéger en créant nous mêmes le système de fichier. Cette étape est d'autant plus importante que nous devons de plus créer des systèmes de fichiers qui alignés à nos blocs logiques, on en profitera aussi pour désactiver la journalisation sur la partition de /boot
Cet alignement se fait en paramètrant les valeurs stride et stripe-width lors de la création du système de fichier. Les formules optimales sont :
mkfs.ext4 -b 4096 -E stride=16,stripe-width=16 -O ^has_journal -L boot /dev/md0 mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 -L system /dev/mapper/rootvg-systemlv mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 -L home /dev/mapper/rootvg-homelv mkswap /dev/mapper/unlocked-swapa mkswap /dev/mapper/unlocked-swapb
La préparation du domaine de stockage est maintenant terminée et Ubuntu peut y être installé.
| Périphérique | Utiliser comme | Formater? | Point de montage |
|---|---|---|---|
| /dev/mapper/rootvg-homelv | ext4 | Non | /home |
| /dev/mapper/rootvg-systemlv | ext4 | Non | / |
| /dev/md0 | ext4 | Non | /boot |
| En chargeur d'amorçage, choisissez : /dev/sda | |||
Ubuntu est sur votre RAID chiffré! sauf qu'avec toutes ces couches (RAID, LUKS et LVM), l'installateur ne s'y retrouve plus et à besoin d'un coup de pouce pour comprendre comment démarrer votre machine. Nous allons rentrer dans notre installation toute fraîche et lui expliquer tout ça.
Pour entrer, on va se chrooter ; on pourra lancer des commandes comme si nous avions démarrer notre nouvelle installation :
mount /dev/mapper/rootvg-systemlv /target mount /dev/mapper/rootvg-homelv /target/home mount /dev/md0 /target/boot mount -t devpts devpts /target/dev/pts mount -t proc /proc /target/proc mount -t sysfs /sys /target/sys mount --bind /dev /target/dev chroot /target/
Notre installation ne sait démarrer ni le RAID, ni le LVM, ni le LUKS. On va devoir installer ces logiciels comme au début de notre installation :
apt-get install mdadm lvm2 cryptsetup
Lorsque la machine démarre, un mini-linux (initrd) est lancé pour en démarrer un plus gros (le notre) ensuite. Il faut que ajouter des modules à initrd pour qu'il puisse démarrer le RAID, le LVM et le LUKS. Tout ces modules vont beaucoup alourdir l'initrd jusqu'à atteindre une taille non-standard et normalement interdite. C'est pour ces raisons que nous avions utiliser GPT et des partition bios-grub au tout début. Pour ajouter les modules, éditez ce fichier comme suit:
raid1 raid0 #raid5 dm-crypt dm-mod aes sha256 xts sd_mod blkcipher
Il faut aussi faire en sorte que cet l'initrd nous demande de saisir un mot de passe pour qu'il puisse déverrouiller les conteneur.
ln --symbolic /usr/share/initramfs-tools/hooks/cryptroot /etc/initramfs-tools/hooks/ ln --symbolic /usr/share/initramfs-tools/scripts/local-top/cryptroot /etc/initramfs-tools/scripts/local-top/ touch /etc/initramfs-tools/conf.d/cryptroot
Vous vous souvenez que les partitions de swap ont chacune leurs propres conteneur LUKS? Plutôt que d'avoir à saisir à chaque démarrage leurs clefs, nous allons générer des clefs très sures (plus sure que n'importe quel mot de passe) que l'on va stocker à l'intérieur du conteneur chiffré du système (pour qu'elle ne soit pas exposées). Ainsi, lorsque l'on déverrouillera le premier conteneur chiffré les clefs seront disponible et nous déverrouilleront alors les partitions de swap. Ces commandes générer les clefs, les placent dans /etc/ssl/private puis supprime les anciens mots de passe du swap:
dd if=/dev/urandom of=/etc/ssl/private/swapa.key bs=64k count=1 dd if=/dev/urandom of=/etc/ssl/private/swapb.key bs=64k count=1 dd if=/dev/urandom of=/etc/ssl/private/system.key bs=64k count=1 cryptsetup luksAddKey /dev/sda3 /etc/ssl/private/swapa.key cryptsetup luksAddKey /dev/sdb3 /etc/ssl/private/swapb.key cryptsetup luksAddKey /dev/md1 /etc/ssl/private/system.key cryptsetup luksKillSlot --key-file /etc/ssl/private/swapa.key /dev/sda3 0 cryptsetup luksKillSlot --key-file /etc/ssl/private/swapb.key /dev/sdb3 0
Vous connaissez fstab? crypttab c'est son complément pour les volumes chiffrés. Ce fichier explique où sont les conteneur chiffrés et comment le système doit les déverrouiller:
# <target name> <source device> <key file> <options> unlocked-md1 /dev/md1 none luks,retry=1 unlocked-swapa UUID=x x x x -uuid- de -/dev/sda3 x x x x /etc/ssl/private/swapa.key luks,swap unlocked-swapb UUID=x x x x -uuid- de -/dev/sdb3 x x x x /etc/ssl/private/swapb.key luks,swap
Maintenant qu'on a bien détailler au système la procédure de démarrage, on installe le nouvelle initrd :
update-initramfs -k all -c
Vous pouvez maintenant redémarrer :)
exit umount /target/boot umount /target/proc umount /target/sys umount /target/dev/pts umount /target/dev umount /target/home umount /target/ vgchange -an rootvg cryptsetup luksClose /dev/mapper/unlocked-swapa cryptsetup luksClose /dev/mapper/unlocked-swapb cryptsetup luksClose /dev/mapper/unlocked-md1 reboot now
Nous avons maintenant une plateforme qui démarre. Nous allons transformer cette brique chiffrée en mediacenter fonctionnel.
Script d'installation rapide:
add-apt-repository ppa:wsnipex/xbmc-xvba add-apt-repository ppa:nginx/development add-apt-repository ppa:deluge-team/ppa add-apt-repository ppa:jre-phoenix/pgl-experimental apt-get update apt-get autoremove transmission-gtk apt-get install ssh screen \ fglrx xbmc-standalone xbmc-eventclients-wiiremote \ nginx-full php5-fpm php5-gd php5-mysql mysql-server mysql-client \ deluged deluge-web python-pip pgld pip install flexget # Copier les script dans /etc/init.d/ update-rc.d deluge-daemon defaults update-rc.d xbmc-wiiremote defaults
A virer:
ssh-keygen -G candidates -b 4096
Tester la primalité du groupe d'échange :
ssh-keygen -f candidates -T moduli
Remplacer l'ancien groupe d'échange (/etc/ssh/moduli) par le nouveau. Vous pouvez re-générer d'avantage de groupes et les concatener ensemble pour plus de sécurité (il faut juste qu'ils soient de la même taille).
apt-get install libbluetooth-dev g++ libcwiid1 xbmc-eventclients-common
compile, copier libwiiuse.so dans /usr/local/bin, modifier le makefile pour utiliser /usr/local/bin/libwiiuse.so, compiler
Générer une clef privée RSA :
openssl genrsa -out /etc/ssl/private/transmission.4096.key 4096 openssl dhparam -out /etc/ssl/private/transmission.dh2048.key 2048 chmod o-r /etc/ssl/private/transmission.* chown root:www-data /etc/ssl/private/transmission.*
On génère ensuite une CSR :
openssl req -new -key /etc/ssl/private/transmission.4096.key
Cette demande de signature ne dévoile pas d'informations à un attaquant cryptographiques, vous pouvez maintenant fournir cette requête de signature auprès d'une autorité de certification racine. Vous en trouverez pour quelques centaines d'euros… ou bien il y a CaCert (Open-source, soutenu par GNU) et StartSSL (privé, gratuit, d'avantage reconnu) :) Ne pas oublier de concatener les certificats de la chaine de certification au votre (de l'intermediaire le plus bas au plus haut et commencant par le votre).
add-apt-repository ppa:nginx/development apt-get update apt-get install nginx-full
Activer l'accélération matérielle pour ATI (obsolète) XvBA (décompression vidéo materielle)
On l'a vu précédemment, votre système dispose en partie d'une protection contre les pannes car votre GRUB et votre /boot sont sur une grappe RAID1. Par contre, votre /home et le reste du système sont sur un RAID0 ; une partie du système est donc plus sensible à la panne (le défaut d'un seul disque d'une grappe RAID0 entraine le défaut de toute la grappe). Des solutions RAID proposent de tolérer le défaut d'un (RAID5) ou de deux disques (RAID6) sans mettre en défaut toute la grappe. De cette façon, si un disque tombe en panne vous aurez un avertissement et pourrez changer le(s) disque(s) défaillant(s) sans avoir perdu vos données!
Ce qui suit s'appuie sur un, voire deux articles de ce site.
On ne peut plus convertir une grappe RAID de niveau 0 vers un autre niveau atteignable (niveaux 5 et 6, par exemple). Je vous propose d'envoyer un paquet de café d'arabica de Colombie aux développeurs de mdadm accompagné d'une requête d'ajout de fonctionnalité (ou plutôt de correction de regression par rapport à raidreconf).
Admettez qu'il serait plutôt cocasse de sauvegarder nos données si durement protégées…
shred --iterations=N --verbose /dev/sdX cryptsetup luksFormat --cipher=aes-xts-plain64 --hash=sha256 --key-size=512 /dev/sdX cryptsetup luksOpen /dev/sdX unlocked-sdX mkfs.ext4 /dev/mapper/unlocked-sdX mkdir ./myBackup mount /dev/mapper/unlocked-sdX ./myBackup mkdir ./myBackup/root mkdir ./myBackup/home cp -axv ./mySystem/root/. ./myBackup/root/ cp -axv ./mySystem/home/. ./myBackup/home/
Une fois la sauvegarde terminée, on désactive une-à-une les couches logicielle de notre ancien RAID pour les rendre disponibles :
umount ./mySystem/root umount ./mySystem/home vgchange --available n rootvg vgremove rootvg pvremove /dev/md1 cryptsetup luksClose unlocked-md1 mdadm --stop /dev/md1
Vous pouvez maintenant reproduire l'étape de création des différentes couches logiques, RAID, LUKS et LVM. Seul la commande de création du RAID diffère : au lieu d'un RAID0 de 2 disques nous souhaitons un RAID5 de 3 disques en précisant que le 3ème disque n'est pas encore disponible (puisqu'il sert à contenir notre sauvegarde). Ce qui donne la commande :
mdadm --create /dev/md1 --metadata=1.2 --raid-devices=3 --chunk=128 --level=5 /dev/sd[ab]4 missing
Une fois que vous avez créer les autres couches, reste la création du système de fichier, le remontage et le transfère de votre sauvegarde sur votre nouvel assemblage :
mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 -L system /dev/mapper/rootvg-systemlv mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 -L home /dev/mapper/rootvg-homelv mount /dev/mapper/rootvg-systemlv ./mySystem/root mount /dev/mapper/rootvg-homelv ./mySystem/home cp -axv ./myBackup/root/. ./mySystem/root/ cp -axv ./myBackup/home/. ./mySystem/home/
On libère notre disque de sauvegarde pour sa future mission : intégrer la nouvelle grappe RAID.
umount ./myBackup/root umount ./myBackup/home cryptsetup luksClose unlocked-sdX
Pour des questions d'alignement, vous devez reproduire le même schèma de partitionnement que sur vos autres disques. Personnellement, j'affiche avec précision mon schéma de partionnement avec la commande :
parted /dev/sdX unit s print
pour ensuite les ré-appliquer sur le nouveau disque. Pour les habitués du RAID, sfdisk ne fonctionnera pas avec nos tables de partitions GPT.
Faite ensuite participer votre disque à vos grappe RAID (celle de /boot et de root) :
mdadm --grow /dev/md0 --raid-devices=3 mdadm --add /dev/md0 /dev/sdX2 mdadm --add /dev/md1 /dev/sdX4
Le système entame ensuite une phase de synchronisation qui peut être extrêmement longue. Observez patiemment l'évolution de votre synchronisation avec la commande :
watch cat /proc/mdstat