PROJET AUTOBLOG


Geekfault

Site original : Geekfault

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

uMatrix le firewall pour navigateur

mercredi 11 mai 2016 à 18:48

Geekfault sur uMatrix
C’est la mode en ce moment de parler de bloqueur de pub et de bloqueur de bloqueur de pub.
Tout le monde a sa collection d’extensions pour protéger sa vie privée : privacy badger, disconnect, ghostery, adblock, adblock plus, ublock, noscript, cookie monster.
Protéger sa vie privée c’est bien mais installer quinze addons pour ça c’est un peu chiant. Et si l’un de vos site favoris se met à déconner à cause de l’une de vos extension ? Vous allez devoir les tester une par une pour trouver qui fait un peu trop de zèle…
Finalement un seul addon pourrait remplacer tout ce beau monde.

uMatrix

C’est une extension miracle permettant de whitelister et blacklister les éléments d’une page web selon pas mal de critères. Elle est certe un peu moins intuitive que les traditionnels bloqueurs de pub mais avec un petit peu de pratique vous n’aurez plus de soucis tout en conservant le même résultat.
À l’origine l’extension s’apelait http switchboard et n’était compatible qu’avec les navigateurs basés sur chromium mais est maintenant dispo également sur Firefox. Elle est opensource et développée par Raymond Hill qui est également connu pour uBlock et son fork uBlock Origin.

La puissance de cette extension réside dans sa matrice :
    – Horizontalement on retrouve les types d’éléments blocables : les cookies, les css, les images, les plugins, les scripts, les XHR, les frames et enfin Autre.
    – Verticalement on retrouve les différents domaines. Tout d’abord les 1st-parties, c’est à dire tous les sous-domaines du site visité (si par exemple vous visitez geekfault.org vous y trouverez static.geekfault.org). Ensuite vous trouverez tous les domaines extérieurs (souvent indésirables).
En combinant les deux axes vous pouvez définir des règles précises de manières assez intuitives et très visuelles. Il est ainsi aisé d’autoriser les vidéos provenant de youtube et ses javascripts tout en n’autorisant pas les cookies lorsque vous consultez un autre site web mais de les autoriser lorsque vous visitez youtube. Bref c’est très flexible.

À cela vous pouvez ajouter les traditionnelles listes utilisées par adblock, ublock et consorts. Et vous obtenez l’extension pour les remplacer toutes.

Mise en route

Allez mettons un peu cela en pratique. Commencez par désactiver vos extensions habituelles et installez uMatrix.
Ensuite allons faire un tour dans ses règlages. Vous trouverez deux trois ptits bonus sympatoche comme la suppression des cookies au bout d’un délai configurable, la suppression du stockage local, le vidage du cache automatique, le spoof du referrer pour les third party (ouai c’est pas spécialement clair : ça signifie ne plus dire aux domaines externes de quel site on vient réellement), spoof l’user-agent aléatoirement en changeant régulièrement (ça signifie mentir concernant votre navigateur et votre système d’exploitation). Avec cet options vous serez bien moins traçable qu’auparavant. Malheureusement certains sites peuvent ne pas apprécier et de ce fait déconner un peu, mais vous verez que c’est (des)activable à la volée également.
Page des règlages d'uMatrix
Un autre onglet contient les règles séparées en deux. D’un côté les règles permanentes et de l’autre les temporaires. Vous pouvez sauvegarder les règles temporaires en permanentes si elles vous conviennent. Vous pouvez également les importer depuis un fichier texte ici ce qui peut être plutôt pratique.
Le dernier onglet vraiment utile vous permet d’ajouter des blacklists célèbres et de les maintenir à jour automatiquement.
Bon bha maintenant yapuka !

Mise en pratique

Bon prenons un exemple assez simple. Sur le screenshot plus haut concernant Geekfault, on voit 7 cookies, 7 fichiers css, 8 javascripts. Il fait également appel à 10 javascripts hébergés chez ajax.googleapis.com et également un javascript dans un domaine blacklisté. On voit que tout est autorisé sauf le javascript issu du domaine blacklisté.

Allons voir un site un peu plus … dégueulasse.
Matrice Clubic de base
Alors là on voit 2 cookies bloqués pour clubic.com 16 images venant d’img.clubic.com 4 cookies bloqués pour www.clubic.com pas mal de contenu autorisé provenant également de ce domaine. Ensuite c’est la valse des domaines externes avec pas mal de js bloqués et des cookies.

Si par exemple je veux pouvoir liker leurs articles, il suffit de whitelister facebook.net en cliquant sur la partie supérieure de la case pour qu’elle passe verte, puis de cliquer sur le bouton refresh et hop de nouveaux domaines apparaissent (du facebook.com ce coup-ci) avec des frames bloquées et des images elles aussi bloquées. Si j’ai vraiment envie de les voir il me faudra les whitelister en cliquant sur la partie supérieures de ces cases puis rafraichir.
Clubic un peu plus facebuk
Et là on voit encore apparaitre des nouvelles choses (les joies du web2.0) : du javascript en provenance de staticxx.facebook.com. Bref on whitelist et on rafraichis. Et là ça y est le contenu est bien là.
Clubic avec facebook complètement whitelisté

Bref c’est un poil chiant mais c’est ça d’avoir des règlages par défaut assez safe. Si vous voulez pas vous retapper cette manip à chaque fois, vous pouvez enregistrer ces règles temporaires en tant que règles permanentes en cliquant sur le cadenas.
Et si ? Oui tiens ! Et si on veux avoir ces règlages non pas uniquement disponible pour culbique.com mais aussi sur tous les autres sites web ? Facile il suffit de changer le scope de vos règles : tout en haut à gauche vous voyez le scope de vos règles : ici clubic.com. Si vous cliquez dessus vous pouvez choisir *, clubic.com ou bien www.clubic.com. On choisis * qui indique n’importe quel site on refait la manip précédente de whitelistage puis un enregistre et c’est bon.
En deux coups de cuillière à pot c’est joué.

Conclusion

Bon bha voilà j’espère que vous n’allez pas suivre l’exemple donné et continuerez à bloquer facebook et que vous éviterez de visiter clubic.com mais que vous utiliserez quand même uMatrix.
Page Github du projet
Lien d’installation pour Firefox
Lien d’installation pour Chrome
Lien d’installation pour Opera

Chiffrer son GNU/Linux, avec LVM et LUKS

mardi 23 septembre 2014 à 00:27

lock

Vous avez vu un peu toutes les déclarations sur l’espionnage de masse toussa toussa ? (Non, ce n’est pas Lord cette fois :D) Hé bien nous allons apprendre à chiffrer vos partitions, pour y stocker votre système d’exploitation et vos données.

Euh, mais attends, “pourquoi ?” d’abord s’il te plaît

Petit rappel : le chiffrement de vos données permet de “protéger” vos données sur deux types d’action :

Remarque ÜBER importante : tel que démontré par de nombreux papiers, l’intégrité (“malleability” en anglais) n’est pas assurée avec certains méthodes d’enchaînements, comme CBC (Cipher-Block Chaining). N’utilisez plus CBC, utilisez à la place XTS (ciphertext stealing), tel que disponible avec cryptsetup (méthode qui est devenue par défaut), car même sans être infaillible, il permet de “mitiger” le problème (une véritable solution serait de signer les données, mais ceci est beaucoup plus gourmand en ressources mémoire et calculs).

Enfin, comme vous l’avez peut-être remarqué, j’ai mis entre guillemets le mot “protéger”, car il faut être conscient qu’avec les moyens à disposition de nos jours (puissance de calcul, failles et erreurs humaines), aucun chiffrement n’est inviolable (à deux-trois détails près). Et souvent, la faille, c’est vous.

Bien, maintenant que nous savons pourquoi, entrons dans les détails.

 

Let’s go!

Dans ce tutoriel, le but est de pouvoir chiffrer le contenu de notre disque dur ; le plus simple est d’utiliser un conteneur LVM pour les données et de chiffrer le tout avec un conteneur LUKS.
Par conséquent, il n’y a qu’un seul chiffrement/déchiffrement, ce qui est bien plus simple.

Au cours de ce tutoriel, nous allons voir plusieurs cas de figures concernant le déchiffrement de notre système, lors du démarrage :

  1. soit vous avez un accès physique à la machine avec clavier et vous pouvez y brancher un support externe, comme une clef USB
  2. soit vous n’avez qu’un accès distant (comme un serveur par exemple), et là la clef devra se trouver sur le même support mémoire que votre partition.

Tout de suite, on peut remarquer que le cas de figure 2 est beaucoup moins sécurisé que le cas de figure 1. Vu que nous n’avons pas d’accès physique, pour y brancher tout autre support mémoire et apporter notre clef secrète ainsi que notre noyau, il faut donc malheureusement créer une partition qui contiendra donc notre clef et notre noyau, et surtout qui ne sera pas chiffrée. Le seul avantage de ce cas de figure est de pouvoir démarrer le système automatiquement, et de garder en sécurité le système (relativement) en supprimant la clef.

Remarque : soyez-en bien conscient, la faille est béante ; ce système n’est pas là pour protéger vous et vos données, vu que mettre sur le même support les données chiffrées et la clef n’est pas très malin, mais il est pour unique but de faire perdre du temps, mais très peu.

Maintenant que nous avons compris quelques détails, commençons par préparer le support.

 

Préparation du support

Avec votre outil préféré, il faut « découper en partitions » votre support (le mot “partitionner” n’existe pas). Si vous êtes dans le cas de figure 1, faites une unique partition (ou selon vos souhaits).

Par contre, dans le cas de figure 2, il faudra créer au minimum une (petite) partition d’amorçage – /boot – et une autre partition pour les données chiffrées. Pour /boot, une taille de 64 Mio est ce qui est de plus correct, pas trop grande, et surtout, pas trop petite. Si vous faites une partition trop petite et venez à manquer de place dedans, vous devrez refaire un partitionnement, et donc déplacer vos fichiers temporairement, ce qui est long et fastidieux, alors évitez de vous faire perdre votre propre temps quitte à mettre 128 Mio. Ainsi, pour créer des partitions selon le cas de figure 2, vous pouvez suivre ces commandes :

gdisk /dev/sda

Note : pour éviter les répétitions dans le tutoriel, et uniquement si vous suivez le cas de figure n°2, remplacez de votre propre initiative /dev/sda1 par /dev/sda2. Je rappelle que ce cas de figure est déconseillé, mais nécessaire dans certains cas.

Remarque : évitez au maximum de donner des infos sur le contenu de votre disque, donc, pas de label comme « cypher h4ck3r », et concernant le type, “Linux filesystem” par défaut fonctionne très bien.

Vérifions en lançant ls /dev/sd* pour voir si le nombre de partitions correspond (de la forme /dev/sdXY, avec X une lettre, et Y un chiffre). Si oui, continuons.

Voilà pour le partitionnement, comme sur n’importe quelle distribution GNU/Linux, continuons avec le vif du sujet !

 

Ze vif ofe ze sujet : le conteneur LUKS

Pour avoir un conteneur LUKS (Linux Unified Key Setup), il faut une passphrase, c’est comme un mot de passe, mais en plus long… Cette passphrase, nous allons la stocker dans un fichier chiffré pour la “protéger” (concernant le cas de figure n°2, je détaillerai plus bas le changement).

Avant de continuer, la question suivante pourrait se détacher : « pourquoi utiliser une clef chiffrée pour déchiffrer le conteneur LUKS, plutôt que d’utiliser la passphrase directement ? »

Voici quelques arguments ;

Cette commande peut paraître assez longue lors de son exécution, car il faut avoir généré de l’entropie pour permet au « générateur de nombres pseudo-aléatoires » (PRNG) d’avoir les données les plus « aléatoires » possible (à ne pas confondre avec un « générateur de probabilités infinies », qui lui requiert des coordonnées).

Prenons en une quantité de 255 octets.
head -c 255 /dev/random | base64 -w0 -- | tr -d '\n' | gpg --symmetric --armor -- > clef_luks.gpg

Remarque : pour éviter des soucis avec les pipes |, la commande tr -d '\n' permet de supprimer les éventuels retours à la ligne qui pourraient nous poser problème.

Autre remarque : le choix entre /dev/random et son homologue /dev/urandom n’a ici que peu d’importance, suivant l’importance que vous lui accordez.

Créons maintenant notre conteneur LUKS, avec luksFormat
gpg --decrypt clef_luks.gpg | cryptsetup --key-file - --cipher serpent-xts-essiv:sha256 luksFormat /dev/sda1

Note : Si quelque chose n’a pas fonctionné, vous pouvez rajouter l’option --verbose, juste après cryptsetup.

Comme vous pouvez le remarquer, nous n’utilisons pas le chiffrement AES selon l’algorithme Rijndael, mais celui de l’algorithme Serpent, qui est aussi réputé car arrivé en deuxième place, après Rijndael.

Félicitations, vous venez de créer votre conteneur LUKS. 🙂

Montons le tout de suite dans le système, comme ceci :
gpg --decrypt clef_luks.gpg | cryptsetup --key-file - open --type luks /dev/sda1 vador

Remarque : en dessous de la version 1.6, si vous rencontrez l’erreur --type: unknown option, remplacez la nouvelle syntaxe open --type luks par luksOpen.

Nous voilà donc avec le périphérique LUKS monté dans /dev/mapper/vador
Note : le nom “vador” importe peu, vous pouvez lui donner le nom que vous souhaitez.
Note : je suis sûr que vous avez compris la référence “Luks/Vador”, non ? … Non ? Tant pis.

Considérez le comme une partition vide, donc actuellement nous ne pouvons pas y stocker de données directement ; et puis nous sommes limité à une seule partition, donc un seul système de fichiers, or nous en voulons plusieurs.

Voilà donc qu’entre en jeu le conteneur LVM (Logical Volume Manager).

 

Le conteneur LVM

Nous allons donc créer des “groupes de volumes” (VG), avec les différentes commandes que voici (adaptez bien sûr à vos besoins)

Initialiser et créer le groupe de volume (on peut se permettre de ne pas exécuter pvcreate, comme l’indique la documentation) :
vgcreate lvm-name /dev/mapper/vador

créer les “partitions” à l’intérieur du volume :
lvcreate --name root --size 20G lvm-name
lvcreate --name swap --size 2G lvm-name
lvcreate --name var --size 20G lvm-name
lvcreate --name home --extents 100%FREE lvm-name

Oui, pour la dernière, nous n’utilisons pas --size, mais --extends 100%FREE pour prendre toute la place restante.

Encore une fois, félicitations ! Pour faire un parallèle avec une installation sans chiffrement, c’est comme si vous venez à peine de créer les partitions. Mais vous voilà avec un système chiffré, ce n’est pas rien. Admirez le résultat (ainsi que la taille concrètement allouée à home) avec la commande lvdisplay lvm-name cette commande nous permet ainsi de savoir où nos volumes LVM sont situés, en suivant pour chacun des volumes la ligne “LV Path”, ce qui revient à /dev/<VG name>/<LV Name> (soit /dev/lvm-name/home pour notre volume home).

À cette étape, vous pouvez très bien reprendre le processus d’installation sans devoir refaire vos partitions (ce ne serait vraiment pas pratique autrement), après avoir déchiffré le conteneur LUKS, en exécutant vgchange --available y lvm-name ou si vous ne vous connaissez pas le nom vgscan && vgchange --available y ce qui vous permet de reprendre à cette étape et de poursuivre avec la création des systèmes de fichiers.

 

Les systèmes de fichiers

Après avoir créer nos “partitions” avec LVM, il est temps d’y mettre un système de fichiers, pour pouvoir y stocker les données ; par contre, ne vous trompez, comme déjà fait remarqué précédemment, nos “partitions” sont dans /dev/lvm-name/, et non pas /dev/sda comme l’indique de base le handbook Gentoo.

Commençons par créer la swap – car ça s’oublie facilement – et de l’activer si nos sommes sur un liveUSB/CD :

mkswap --label swap /dev/lvm-name/swap
# Si nous sommes dans un liveUSB/CD et que nous souhaitons entrer dans un “chroot”
swapon /dev/lvm-name/swap

Et puis, les systèmes de fichiers : me concernant, je vais utiliser le système de fichiers XFS.
mkfs.xfs -L root /dev/lvm-name/root
mkfs.xfs -L var /dev/lvm-name/var
mkfs.xfs -L home /dev/lvm-name/home

On oublie pas de monter les systèmes de fichiers (oui, car dans la RAM, ça ne sert à rien …)

mkdir /mnt/gentoo/
mount /dev/lvm-name/root /mnt/gentoo
mkdir /mnt/gentoo/{boot,home,var}
touch /mnt/gentoo/{boot,home,var}/.keep

Remarque : la commande touch est facultative, mais nous a permit de créer des fichiers vides dans les dossiers boot, home et var, tous nommés “.keep” (donc cachés) ; ces fichiers ont pour unique rôle d’éviter de voir les dossiers concernés supprimés de / et d’empêcher le montage des partitions à leur emplacement. Une petite sécurité pour valider le démarrage, surtout quand on ne peut pas voir la séquence de démarrage.

Note : nous nous occuperons de notre support de démarrage plus tard.

Nous y voilà, notre hiérarchie de fichiers est en place.

Et maintenant ?

Et maintenant, c’est “très simple”, vous pouvez reprendre normalement l’installation de votre système d’exploitation GNU/Linux préféré. Maintenant, suivez le handbook ou tout autre document et reprenez un peu plus tard.

Une fois le système de base installé et le noyau presque prêt, reprenons ensemble.
Nous allons nous créer un système de base, qui va pouvoir permettre de déchiffrer le conteneur LUKS et monter le système de fichiers, avec l’aide de genkernel.

 

J’ai deux amours, le noyau et Genkernel

Commencez par configurer votre kernel, avec “make menuconfig”. Importante chose, mettez en dur au moins les systèmes de fichiers de /boot et de / (respectivement ext2 et xfs dans notre exemple).

Maintenant, faisons appel à genkernel et voyons sa magie agir avec la commande suivante :

Remarque : faites attention à certaines options, comme --no-mrproper, qui empêche de supprimer les fichiers temporaires, et donc de perdre votre fichier .config :

genkernel --clean --no-mrproper --no-install --no-symlink --kernel-config=/usr/src/linux/.config --disklabel --lvm --luks --gpg --all-ramdisk-modules all

Comme vous pouvez le voir, nous rajoutons le support LVM, LUKS et optionnellement GPG, si votre clef est chiffré symétrique. Si vous utilisez du RAID, rajoutez --mdadm (voir genkernel(8)).

Une fois la compilation terminée, trois fichiers ont été créés dans /var/tmp/genkernel/, nommés “kernel-genkernel-x86_64-<version>-<name>”, “initramfs-<version>-<name>” et “System.map-genkernel-x86_64-<version>-<name>”. Mais avant de les copier dans /boot, reprenons ce dernier.

Nous avions mis de côté notre support de stockage, il est temps de le reprendre. Pour être démarrable, il faut par contre une simple partition et un simple système de fichiers. C’est là aussi que les deux cas de figure cités en début de tutoriel diffèrent :

  1. Dans le cas de figure n°1, il vous faut donc un support externe, telle qu’une clef USB, ou équivalent (les cartes SD fonctionnent aussi) :
    • déterminez après l’avoir branchée (*hmmhmm*) sa “position” dans /dev. Dans notre cas de figure, prenons /dev/sdb,
    • comme pour notre support mémoire système, utilisez fdisk /dev/sdb pour créer une partition dédiée à cette tâche ; dans notre exemple, ce sera /dev/sdb1,
    • ensuite, créons un système de fichiers de type ext2, avec la commande mkfs.ext2 -m0 -c /dev/sdb1 (Conseil, avec un FS en ext2, ça prendra du temps, du coup, prévoyez pas trop grand, comme indiqué en début d’article),
    • pour finir, montez ce nouveau système dans /boot comme ceci mount /dev/sdb1 /boot et voilà.
  2. Dans le cas de figure n°2, nous devons stocker la clef sur le même support ; or rappelez-vous, nous l’avons déjà fait (trop génial ce thican). On va donc simplement :
    • créer un système de fichiers mkfs.ext2 -m0 -c /dev/sda1
    • puis monter le nouveau système dans son emplacement mount /dev/sda1 /boot et c’est tout.

Remarque : ne copiez pas bêtement les commandes non plus, car si vous formattez avec un FS la partition qui sert de conteneur LUKS, “bravo”, vous gagnez le droit de tout recommencer.

Ensuite, copiez les fichiers créés par genkernel ainsi que votre fichier clef_luks.gpg dans la partition de démarrage (/boot), et maintenant, occupons nous du bootloader.

 

Le bootloader, pour un démarrage tout en douce(u)r

Le bootloader est un logiciel, de petite taille, qui se charge d’exécuter les scripts et programmes de base permettant au système de démarrer. D’expérience, je vous aurais conseillé extlinux, mais je n’ai pas réussi à le faire fonctionner à distance, donc nous allons prendre LILO, qui fonctionne.

Note : Si vous avez une idée du soucis, n’hésitez pas à m’écrire pour me donner quelques détails. 😉

Créez donc votre fichier /etc/lilo.conf avec ces informations, sans toutefois oublier d’adapter les noms de fichiers, bien sûr, mais aussi la variable “boot=” avec /dev/sdb (selon notre exemple) pour un support externe, ou /dev/sda pour un système distant :

# /etc/lilo.conf

# Should work for most systems, and do not have the sector limit:
lba32
# If lba32 do not work, use linear:
#linear

# MBR to install LILO to: (BE CAREFUL)
boot=/dev/sdb
map=/boot/.map
timeout=0
default=gentoo

image=/boot/kernel-genkernel-x86_64--
label=gentoo
read-only # read-only for checking
initrd=/boot/initramfs--
append="doluks crypt_root=/dev/sda1 root_keydev=/dev/sdb1 root_key=/boot/clef_luks.gpg dolvm lvmraid=lvm-name real_root=/dev/lvm-name/root rootfstype=xfs"

Remarque : Si vous êtes sur une machine distante, tel un serveur, il sera tout aussi difficile d’y taper un mot de passe au moment du démarrage comme le fait d’y brancher un support externe. Pour cela, et comme je l’avais mentionné, on va donc déchiffrer la clef, pour la stocker en clair avec le kernel et l’initramfs. Reprenons en premier notre clef, pour la déchiffrer et stocker ses données en clair dans un autre fichier :

# Plaçons-nous dans le dossier /boot du système de fichier, en dehors du chroot
cd /mnt/gentoo/boot
# Déchiffrons la clef et stockons les données dans un autre fichier. Le mot de passe vous sera demandé.
gpg --decrypt clef_luks.gpg > clef_luks.txt

Une fois ceci de fait, il faut remodifier le fichier /etc/lilo.conf pour indiquer d’utiliser ce nouveau fichier plutôt que la clef chiffrée. Pour celà, modifiez le contenu de la variable root_key=/boot/clef_luks.gpg en root_key=/boot/clef_luks.txt.

Comme vous pouvez le voir, rien de bien compliqué. Une fois le fichier /etc/lilo.conf correct et écrit, exécutez simplement la commande lilo et … et c’est tout !

Si si, pour de vrai, vous avez fini ! Redémarrez simplement, ou fermez vous-même les systèmes de fichiers (pour apprendre, par exemple) :
umount -l /mnt/gentoo/{home,boot,var,}
swapoff /dev/lvm-name/swap
vgchange -a n lvm-name
crytpsetup luksClose vador
reboot

Je vous souhaite bonne continuation pour le reste, et merci à vous d’avoir suivi ce tutoriel.

DNSsec, DANE ou la mort des CA

lundi 11 août 2014 à 10:48

CDNS-ethernetlockVous avez vu un peu toutes les déclarations sur l’espionnage de masse toussa toussa ? Les scandales sur les autorités de certifications (aussi appelé “tiers de confiance” haha), les soucis de vie privée et tout le toutim ?

Bon et si on faisait quelque chose pour protéger sa vie privée sans pour autant filer des thunes à des soit disant tiers de confiance… On va utiliser le DNS pour renforcer nos connexions TLS et plus si affinité.

Donc dans l’ordre on va faire du DNSSec sinon le reste ne sert pas à grand chose, ensuite on va commencer par sécuriser notre petit SSH, ensuite notre serveur Web puis notre joli SMTP et ça sera un bon début !

DNSSec, t’es un peu chiant mais tu es indispensable

Bon là c’est l’étape préliminaire. Elle est pas indispensable techniquement, mais si l’on met des certificats et autres hash pour valider l’utilisation d’autres services dans le DNS, il faut sécuriser le DNS afin que les infos ne soient pas usurpables.

Donc là on va bosser sur Bind9, tout d’abord on active dnssec. Pour ça on modifie
/etc/bind/named.conf.options
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

Bon maintenant on va s’attaquer à la partie crypto. Je rentrerai pas dans tous les détails (loin de là) c’est une mise en pratique cependant je suis obligé de vous expliquer un peu le bordel des clés : il y a déjà deux types, les KSK (key signing key) et les ZSK (zone signing key). Une ZSK est une “petite” clé qui signe la zone. On la change régulièrement (pas plus de quelques semaines de durée de vie). Cependant pour garantir tout de même une sécurité pas trop dégueue, on signe cette clé via la KSK qui elle est plus grande et renouvelée beaucoup moins souvent (une fois par an environ, lorsqu’on renouvelle le nom de domaine par exemple). Vu que l’on change régulièrement la ZSK et que la propagation DNS est ce qu’elle est, il y a donc une période où l’on signe la zone avec l’ancienne ZSK et également avec la nouvelle ZSK, puis on supprimme l’ancienne. Il y a donc un roulement à faire (qui peut-être automatisé). La période de vie de la clé est indiquée à l’intérieur de celle-ci.

Action !

Donc il va nous falloir une KSK et une ZSK. Vu qu’on aura un joli bordel de clés, utilisons un dossier à part : /etc/bind/keys . On génère la KSK puis la ZSK : dnssec-keygen -K /etc/bind/keys/ -f KSK lord.re
dnssec-keygen -K /etc/bind/keys/ lord.re

Et maintenant on signe la zone :
dnssec-signzone -S -o lord.re -K /etc/bind/keys/ /etc/bind/zones/lord.re
On a maintenant notre fichier de zone classique et le fichier de zone signé /etc/bind/zones/lord.re.signed. On indique à bind de servir la zone signé dans le fichier de conf, on reload et c’est bon ! Vous remarquerez que dnssec-signzone se débrouille tout seul pour trouver les bonnes clés.

C’est fini ! Ah en fait non. DNSSec c’est toute une chaîne. Votre partie à vous est sécurisée, la partie parente est sécurisée (enfin ça dépend du TLD), mais il n’y a pas le lien entre votre domaine et le TLD. Il faut fournir un enregistrement de type DS (cela fait partie des glue records) à votre registrar pour lier les maillons de la chaîne. Pour créer cet enregistrement :
dnssec-dsfromkey -1 -K /etc/bind/keys/ -f /etc/bind/zones/lord.re.signed lord.re
À savoir que certains TLD sont plus longs que d’autres pour prendre en compte ce DS.

Bon bha … ça marche ?
$ dig +dnssec lord.re

; <<>> DiG 9.9.5 <<>> +dnssec lord.re
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39131 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1460 ;; QUESTION SECTION: ;lord.re. IN A ;; ANSWER SECTION: lord.re. 600 IN A 90.0.0.105 lord.re. 600 IN RRSIG A 5 2 600 20140908115752 20140809115752 11250 lord.re. hshNikmVmI8YcRtOvTHzmwQIHbEVZTu7TVUY/vT5y6RC/IgwFs4dVvTO WXL42d7pOBzbabqwjU00SAd0Um3TXY7Zo3tT2NzUnBTSzWnLDoT2dj7Z i3UnqPqnu2MQA+0mxDgKojDiJbIuYz5kXvM1FQSb2ooSbLMoL2SnTMNt Yz8= lord.re. 600 IN RRSIG A 5 2 600 20140908115752 20140809115752 47592 lord.re. J1wQ3NZlboTIZTKRXA3IRjI/pWuxGxbAAVw9MWo3g/dbM6jM/HYth6/5 MFYPk/r4Xj8+NcMNWi4uaAw7I0/F8T3qA2Eb4dl8F3quSa4jBFm1rx50 ls5Z/fdzKSiIq8LqKEgKJlK7G6OJjbN+edJbRsgSlUNhQgmMnr/vjV0N 2SA= lord.re. 600 IN RRSIG A 5 2 600 20140908115752 20140809115752 55107 lord.re. F7TnXt/mEfZTBa9Ni9ukqRMSBuntO8jFkytCiaVVKFTC34NprV28G/K0 /KDX9om8f+BHxaJlrZB/kzbVI/GEnlz2am1kSNFEsIHigOxW+xCh8HL5 TkAcKqxHvGEeM4+bxFQjY0NN6sU0/RcGtHPyg0cnDzVLeCnN1TqnaAFA ORI= ;; Query time: 43 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Sun Aug 10 15:02:36 CEST 2014 ;; MSG SIZE rcvd: 553

Regardez la présence du flag ad dans la réponse. Attention si vous consultez en direct le Bind autoritaire, vous n'aurez pas le flag ad, utilisez un autre serveur DNS pour cette requête.

NB: oui je vous mens, en vrai ça ne marche pas, il n'y a pas le champ ad sur mon domaine, cependant online.net ne permet pas d'envoyer le DS record.

SSH, mon amour, je vais te protéger !

Voilà le truc : lorsqu'on a un serveur généralement on installe un serveur SSH dessus. SSH c'est super sécurisé sauf qu'il y a un point faible dans le protocole qui est le TOFU. TOFU c'est Trust On First Use. Lorsqu'on se connecte à un serveur SSH, le client va récupérer l'empreinte unique du serveur SSH. Cette empreinte ne change jamais (en dehors des réinstallation bien entendu). S'il s'agit de la première connexion à ce serveur, le client va stocker cette empreinte de son côté. Toutes les autres fois où le client va se connecter, il va récupérer l'empreinte serveur et la comparer à l'empreinte stockée lors de la première connexion. Si celle-ci est identique, pas de soucis, sinon un joli message d'avertissement vous préviendra d'une éventuelle attaque de type Man in the middle. On voit donc que le moment sensible est donc la récupération de l'empreinte lors de la première connexion.

L'astuce consiste donc tout simplement à publier cette empreinte dans le serveur DNS. Pour ça il existe le champ SSHFP (ssh fingerprint, thanks Captain Obvious). Pour générer ce champs, on peut tout simplement demander à ssh de le faire avec la commande ssh-keygen -r mon.serveur.ssh et paf vous n'avez plus qu'à insérer dans votre zone DNS. Bien entendu il faut aussi règler votre client SSH pour regarder ce champs (ce qui n'est pas le cas par défaut sur Gentoo). Donc il faut éditer le fichier /etc/ssh/ssh_config et y rajouter VerifyHostKeyDns yes
Une fois cela fait vous verrez une ligne supplémentaire lors de la première connexion :

The authenticity of host 'lord.re (90.0.0.105)' can't be established.
ECDSA key fingerprint is 6f:9e:ca:ce:e6:3d:85:72:3b:0d:0e:77:94:a5:53:b4.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Par contre rien ne vous assure que la résolution est validée par DNSSec. Veillez à ce que votre résolveur le fasse !

Toi aussi Nginx tu pourras arrêter de faire râler les navigateurs avec ton certif auto-signé (ou presque)

Remarquez bien le "ou presque" parceque c'est que de la théorie. En fait on va utiliser un autre type de champs DNS qui sera valable pour toutes les connexions de type TLS (rien de spécifique à un serveur web).

Bon on a un serveur web avec son certificat auto-signé qui fait râler (à juste titre) les navigateurs. Ce qu'on va faire c'est qu'on va foutre ce certificat dans notre DNS et donc notre zone DNS sera à considérer comme notre tiers de confiance. Le soucis c'est qu'actuellement la partie cliente ne suit pas et donc ne vérifie pas l'existence de ce fameux champs et râle quand même lors de l'utilisation d'un certificat auto-signé. Mais bon, on peut rêver d'un futur radieux où toutes les connexions TLS vérifieront ce champs et donc arrêteront de couiner.

Donc, enlevons nos gants et foutons les doigts dans la mélasse. On va utiliser le champ de type TLSA. Donc il va falloir hasher notre certificat puis dans le champ : indiquer l'utilisation de ce champs, le type d'info qu'on y met, le type de hash, le hash en question, le numéro de port, le protocole de transport et le nom de domaine bien entendu.

Pour un serveur web ça donne : ça nous donne _443._tcp.lord.re. IN TLSA 3 0 1 8281d07d690fdf2c21df532ffc110d09fc4728e72df2fc776be793859b1d9ea8 Cette ligne est valable pour le TCP 443 pour lord.re. avec un certificat auto-signé (le 3), qui est un certificat complet (le 0) qu'on a hashé par sha256 (le 1). Pour générer le hash : openssl x509 -in moncertificat.crt -outform DER | openssl sha256

Comme dit précédemment vous pouvez répétez l'opération pour n'importe quel service utilisant TLS (irc, smtp, …) mais rien ne garanti que le client fasse la vérification de ce champs DNS.

Toutefois DANE c'est l'avenir, autant l'adopter au plus vite.

Pas de jaloux Postfix, toi aussi tu y passes.

Avec le serveur mail on peut surcharger le DNS en deux endroits : faire du DANE comme pour tout le TLS mais aussi faire du SPF et du DKIM, ce qui a pour but de réduire la possibilité de spam et de spoof. Donc pour le DANE comme précédemment, un champs TLSA de la forme _25._tcp.lord.re IN TLSA 3 0 1 blablablabla

Bon ça c'est bon maintenant on gère facilement, rien de spécifique. On peut demander au serveur mail de faire la vérification DANE également (la méthode varie en fonction de votre serveur mail).

Puis on va se créer un SPF qui veux dire Sender Policy Framework. C'est un champs qui permet d'annoncer les seuls serveurs autorisés à envoyer des mails pour un domaine. Typiquement dans mon cas, le seul serveur de mail autorisé à envoyer des mails provenant de *@lord.re est zoid.lordtoniok.com. Donc je créé une entrée DNS de la forme : lord.re. 3600 IN SFP "v=spf1 +a:zoid.lordtoniok.com -all" Et voilà ! Rien de plus dans ce cas. C'est une petite protection sympatoche qui ne mange pas de pain.

Maintenant je survole DKIM car là c'est plus compliqué. DKIM consiste à faire signer les mails sortants de son serveur en fonction du domaine d'expédition. Lorsqu'un serveur reçoit un mail provenant de notre nom de domaine, il est possible pour le destinataire de vérifier que le message a bien été émis par le serveur émetteur. C'est donc une bonne technique anti-phishing et anti-spoof. La mise en place est plus compliqué car il y a la signature à faire côté smtp, cependant on trouve de nombreux tutos.

Des ptits outils pour se simplifier la vie

Il existe pleins d'outils pour aider :

Conclusion

Vous voilà dans l'internet du futur, où les CA sont mortes et enterrées car rendues inutiles par DANE et en plus c'est encore plus sécurisé qu'avant.

Configurer Postfix en tant que serveur de mail secondaire

mardi 29 octobre 2013 à 19:31

Introduction

Les lecteurs de cet article sont supposés avoir des bases dans la configuration d’un serveur SMTP (ici, Postfix), au moins en tant que serveur de courrier primaire, ainsi que sur sur l’écriture d’une zone DNS. Cet article ne couvre pas la mise en place d’un partage de charge (load-balancing) de serveurs SMTP, mais la mise en place d’un serveur secondaire en cas d’indisponibilité du serveur primaire.

De la même manière qu’avec le courrier classique, un mail ne doit pas être perdu. Quand un facteur veut déposer du courrier dans une boîte aux lettres, et qu’il ne peut pas le faire (portail fermé, boîte aux lettres pleine, ou pour d’autres raisons), dans la plupart des cas il essaiera une autre fois puis renverra le courrier à l’expéditeur, si l’adresse y est indiquée.

Un serveur SMTP fonctionne globalement de la même manière. Si un mail ne peut pas être livré, le serveur d’origine du mail retentera plusieurs fois, et abandonnera au bout d’un certain nombre d’essais, ou d’un certain temps, selon les configurations.

Pour être sur que tous les mails reçus sur un domaine soient acceptés, il est nécessaire de mettre en place un ou plusieurs serveurs SMTP secondaires. La première étape pour cela est d’indiquer, à ceux qui veulent envoyer du mail sur un domaine, qu’il existe plusieurs serveurs SMTP sur lesquels envoyer des mails. Ensuite, nous verrons comment indiquer à un serveur SMTP qu’il fait office de serveur secondaire pour un domaine, et qu’il doit donc transférer les mails dès que possible au serveur SMTP primaire.

Configuration de la zone DNS

Pour indiquer la présence d’un serveur de mails sur un nom de domaine (et donc, pour pouvoir recevoir des mails sur ce nom de domaine), on utilise l’enregistrement DNS “MX” (pour Mail eXchanger). Cet enregistrement indique le(s) nom(s) de domaine sur lesquels envoyer les mails. Voici par exemple, les enregistrements MX correspondant à mon domaine pstch.net :

pstch.net. 86400 IN MX 16 mx0.pstch.net.
pstch.net. 86400 IN MX 32 mx1.pstch.net.

Comme vous le voyez, il existe deux serveurs de mails disponibles pour ce nom de domaine. La valeur d’un champ MX est composé de deux parties :

Le serveur primaire est celui qui a l’ordre de préférence le plus bas (ici, mx0.pstch.net). La priorité est donc inverse à l’ordre de préférence. On peut avoir plusieurs serveurs qui partagent le même ordre de préférence, pour faire de la répartition de charges, mais ce sujet n’est pas couvert par cet article. Le nom d’hôte peut être externe (appartenir à un autre domaine), mais doit toujours pouvoir être traduit en une adresse IP. La convention est de nommer mes serveurs de mails “mx”, suivi d’un indice indiquant sa priorité (mx0, ou mx, utilisé pour le serveur primaire, les nombres plus hauts pour les serveurs auxiliaires).

Vous l’aurez compris, pour indiquer la présence d’un serveur SMTP secondaire, si vous n’en utilisez qu’un actuellement, il vous faudra rajouter un enregistrement MX, avec un ordre de préférence plus grand, et avec le nom d’hôte du serveur SMTP que vous souhaitez configurer comme secondaire. Voici un exemple provenant de ma zone DNS (pour le nom de domaine pstch.net), avec les deux enregistrements MX et les enregistrements A (permettant de résoudre un nom d’hôte en une adresse IPv4) correspondants :

IN MX 16 mx0.pstch.net.
IN MX 32 mx1.pstch.net.
mx0 IN A 91.203.212.181
mx1 IN A 151.236.21.168

(N’oubliez pas de mettre à jour le numéro de série de la zone DNS, et de le recharger, avec ‘rndc reload’ (Bind), par exemple.)

Maintenant, les serveurs SMTP qui enverront du mail au domaine pstch.net essaieront d’abord sur mx0.pstch.net, puis si ce dernier est indisponible, sur mx1.pstch.net, qui gardera alors le mail pour mx0.pstch.net, et reessaiera plusieurs fois de le lui livrer.

Pourquoi un serveur secondaire ?

Nous avons dit en première partie que, de toute façon, un serveur SMTP essaie plusieurs fois de livrer du courrier à un domaine. Dans ce cas là, pourquoi mettre en place un serveur secondaire ?

Car cela nous permet de changer la configuration du serveur SMTP secondaire, pour qu’il garde les mails plus longtemps qu’un serveur extérieur au domaine ne l’aurait fait. Cela permet aussi de garder la trace des mails qui sont “en file d’attente” (c’est à dire, qui n’ont pas encore été livrés au serveur de destination).

Configurer Postfix pour qu’il relaie les mails vers le serveur primaire

Configurer postfix pour lui indiquer d’être un serveur secondaire est assez trivial, car il suffit de lui indiquer le nom de domaine pour lequel il relaie le mail. Postfix se chargera lui-même d’essayer de transmettre le mail vers le serveur primaire, puis de le mettre en file d’attente (“deferred”) si le serveur primaire n’est pas disponible. La variable à utiliser pour cela est “relay_domains”. Il suffit d’indiquer, dans le fichier de configuration de postfix utilisé (“main.cf”, par exemple), le nom de domaine pour lequel le serveur est secondaire, par exemple ici pour “pstch.net” :

relay_domains = $mydestination pstch.net

La liste de domaines indiqués dans relay_domains doit inclure $mydestination, et les domaines doivent être séparés par des espaces.

Il peut aussi être nécessaire d’utiliser la variable “relay_recipient_maps”, pour limiter les adresses pour lesquelles Postfix va relayer les mails. Cela peut être utile pour lutter contre le spam (messages indésirables) directement au niveau du serveur SMTP.

N’oubliez pas de recharger votre configuration postfix, avec la commande ‘postfix reload’ (ou en redémarrant le serveur Postfix).

Test de la configuration

Soit un domaine example.com, dont les enregistrements MX pointent vers les domaines primaire.example.com et secondaire.example.com, primaires et secondaires respectivement. Nous allons tester le comportement des serveurs SMTP de ce domaine quand primaire.example.com devient indisponible.

Cache DNS

Une fois que tout cela est en place, il y a une première étape à ne pas oublier : vider les caches DNS des serveurs. En effet, si un serveur a encore en mémoire les informations oboslètes qui étaient utilisés avant le changement de la zone DNS, cela peut créer une confusion (serveur secondaire ne se reconnaissant pas comme secondaire, par exemple). Si vous utilisez des serveurs DNS BIND locaux, la commande à utiliser est :

root@primaire:~# rndc flush
root@secondaire:~# rndc flush

Simuler une panne du serveur primaire

Pour simuler une panne du serveur SMTP primaire, nous allons simplement l’arrêter. Si le serveur primaire est un serveur postfix, on peut utiliser la commande :

root@primaire:~# postfix stop

Envoyer un mail au domaine

Dans cette situation, si j’envoie un mail au domaine example.com, le serveur SMTP essaiera d’abord de s’adresser à primaire.example.com, puis comme celui-ci est indisponible, enverra le mail à secondaire.example.com.

J’envoie donc un mail à partir d’une adresse GMail, au domaine example.com. Je vois alors apparaître dans les journaux du serveur SMTP sur secondaire.example.com, les lignes suivantes :

postfix/smtpd[6041]: connect from mail-we0-f180.google.com[74.125.82.180] 
postfix/smtpd[6041]: 2F322100A0A7: client=mail-we0-f180.google.com[74.125.82.180]
postfix/cleanup[6047]: 2F322100A0A7: message-id=<CAMeDZSBecpb0OS3Pu75f_f7qOV2-vpq9L3tDo9qYik2gaFuB_Q@mail.gmail.com>
preeza postfix/qmgr[23261]: 2F322100A0A7: from=<hugo.geoffroy@gmail.com>, size=1691, nrcpt=1 (queue active)
preeza postfix/smtpd[6041]: disconnect from mail-we0-f180.google.com[74.125.82.180] 
preeza postfix/smtp[6048]: connect to primaire.example.com[XX.XX.XX.XX]:25] Connection refused 
preeza postfix/smtp[6048]: 2F322100A0A7: to=<test@example.com>, relay=none, delay=0.22, delays=0.2/0.01/0.02/0, dsn=4.4.1, status=deferred (connect to primaire.example.com[XX.XX.XX.XX]:25: Connection refused)

On voit que le serveur reçoit un mail des serveurs SMTP de Google, qui se sont donc bien adressés au serveur secondaire en voyant que le primaire n’était pas disponible. Après avoir réceptionné le mail, et s’être déconnecté des serveurs de Google, le serveur secondaire essaie de se connecter au serveur primaire pour lui livrer le mail. Cependant, la connexion est refusée, car le serveur primaire n’est pas disponible. Postfix marque alors le mail comme “deferred” (différé), et essaiera de le livrer plus tard. Ces 2 dernières lignes peuvent se répéter plusieurs fois dans le temps, à chaque fois qu’un nouvelle tentative de livraison aura lieu.

Gérer la file d’attente

Si on utilise la commande “postqueue”, on peut avoir des informations, et gérer, la file d’attente de Postfix. Par exemple la commande “postqueue -p” permet d’afficher la liste des mails en file d’attente, et la raison pour laquelle ils sont en liste d’attente :

root@secondaire:~# postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
2F322100A0A7 1691 Thu Oct 10 13:19:23 hugo.geoffroy@gmail.com
                               (connect to primaire.example.com[XX.XX.XX.XX]:25: Connection refused)
                                      test@example.com
-- 3 Kbytes in 1 Request.

La commande “postqueue -f”, elle, permet de “flusher” la file d’attente, ce qui équivaut à dire à Postfix de retenter de livrer tous les mails en file d’attente :

root@secondaire:~# postqueue -f

Si nous exécutons cette commande pendant que le serveur primaire est toujours indisponible, nous pouvons voir dans les journaux du serveur SMTP secondaire une nouvelle tentative, toujours infructueuse.

Fin de la panne

Nous considérons que le panne du serveur SMTP primaire a été réparée, et nous allons donc le redémarrer. Si le serveur primaire est un serveur postfix, on peut utiliser la commande :

root@primaire:~# postfix start

Livraison du mail au serveur primaire

Quelques minutes après avoir redémarré le serveur primaire (pour éviter d’attendre, vous pouvez toujours exécuter la commande “postqueue -f” sur le serveur secondaire, pour vider la file d’attente) nous pouvons voir apparaître sur les journaux du serveur SMTP :

postfix/qmgr[23261]: 2F322100A0A7: from=<hugo.geoffroy@gmail.com>, size=1691, nrcpt=1 (queue active)
preeza postfix/smtp[6842]: 2F322100A0A7: to=<test@example.com>, relay=primaire.example.com[XX.XX.XX.XX]:25], delay=473, delays=473/0.02/0.22/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D8F8A1D41C7)

On peut voir ici que le mail a finalement été livré au serveur primaire, au bout de 473 secondes (7 minutes et 53 secondes). Notre domaine peut donc maintenant recevoir les mails même si le serveur primaire est indisponible !

Configuration supplémentaire

On a configuré un serveur de mail secondaire, mais nous ne connaissons pas encore ses paramètres et son comportement exact : combien de temps le mail sera gardé ? à quelle fréquence le serveur tente de livrer le mail à nouveau ?

Pour configurer ce comportement, Postfix met à notre disposition les variables suivantes :

Toutes ces valeurs doivent être spécifiées comme un nombre, suivi de l’unité :

Par exemple :

maximal_queue_lifetime = 2w

Postfix renvoie les messages fréquemment (avec l’intervalle indiquée par minimal_backoff_time) quand ils sont arrivés, et au fur et à mesure de l’attente, le temps entre chaque envoi augmente, jusqu’à un maximum (maximal_backoff_time).

Conclusion

Postfix est assez simple à configurer, nous l’avons vu en constatant que la mise en place d’un serveur SMTP secondaire n’est qu’une affaire de quelques minutes.

Notez que la mise en place d’un serveur SMTP secondaire peut être plus compliquée quand on utilise des systèmes anti-spam au niveau SMTP. Ne laissez pas votre serveur SMTP secondaire être un contournement de votre système antispam.

N’hésitez pas à critiquer, poser des questions ou chercher de l’aide en commentaires.

Références

Accélération matérielle du décodage vidéo (VLC et VAAPI)

mardi 7 août 2012 à 07:46

La carte graphique de mon desktop a grillé aujourd’hui et j’en ai donc profité pour virer cette merde de nVidia (F-U!) pour une ATI HD6450, une des moins chères de mon vendeur d’informatique.

Après m’être battu plus d’une heure dans la config de Xorg (AMD? F-U also tiens!) pour faire marcher la carte correctement, je me suis attardé sur une des fonctionnalités de cette nouvelle carte, ses capacités de décodage matériel du H.264.

Décodage matériel

Je ne parlerai pas ici des capacités de rendu vidéo de Xorg ou du mode overlay de VLC. Le but est uniquement d’accélérer le décodage des vidéos compressées en H.264 (et parfois d’autres codecs selon le GPU, mais le H.264 est le plus répandu de nos jours).

Concrètement, VLC envoie le flux compressé au GPU, attend le flux décompressé en retour. Tout le reste (affichage, stream, recompression) est à charge du CPU.

Ce qui est intéressant c’est que mon desktop de plus de 4 ans est maintenant capable de décoder des flux HD 1080p sans soucis, chose dont il était incapable avant sa mise à jour à 40€ !

VAAPI

Pour offrir du décodage matériel, VLC implémente VAAPI (Video Acceleration API). Initialement développée par Intel sous forme libre, cette API peut aussi servir d’interface avec les technologies propres à AMD (XvBA) et nVidia (VDPAU).

Selon votre GPU, installez le driver approprié :

Exécutez ensuite vainfo pour vérifier que tout fonctionne. Il devrait retourner la liste des capacités matérielles de votre GPU, par exemple sur ma carte Intel GMA HD 3000 :
tito@sigma:~$ vainfo
libva: VA-API version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Intel i965 driver - 1.0.15
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264Baseline : VAEntrypointVLD
VAProfileH264Baseline : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD

VLC

Il n’y a plus qu’à activer l’option dans les préférences de VLC, sous “Lecture & Codecs” cocher “Utiliser l’accéléaration matérielle du GPU.”

Tests

J’ai la flemme de faire des tests (je vois clairement à l’utilisation CPU que ça marche) mais je vous montre ce joli screenshot fait par quelqu’un d’autre :

D’après mes estimations et différents tests, je dirais que cela soulage le CPU d’environ 60% du travail de décompression !

Conclusion

Les performances sont améliorées mais pas encore optimales. L’idéal serait d’envoyer le flux compressé directement à la carte graphique et qu’elle-même se charge de l’affichage.

Ici on envoie le flux compressé puis la carte renvoie le flux brut, que VLC traite avant de renvoyer à la partie affichage du GPU (via Xorg). Pas optimal donc mais mieux que rien.

Source