Vous attendez la suite de mon article sur ce qui passe par les oreilles d'un android ? Hé bien vous allez attendre encore un peu ...

Lorsque vous récupérez via tcpdump un flux SSL (au hasard du https), il est chiffré et c'est justement l'intérêt du SSL de vous empêcher de lire ce flux.

Mais si si vous maitrisez une des deux extrémités, il devrait être normal que vous puissiez lire ce flux. C'est pourquoi nous allons le faire.

Côté serveur

Dans le cas où vous maitrisez le côté serveur, il suffit d'ouvrir la trace tcpdump (sauvegardée avec l'option -s0 -w file) sous wireshark et de le configurer pour qu'il utilise la clé serveur pour déchiffrer le flux :comme ici et de choisir de suivre le flux ssl au lieu du flux TCP.

C'est simple et efficace.

Côté client

Maintenant si vous êtes côté client sans certificat client, vous êtes coincés. Et c'est là que j'ai une solution à vous proposer.

Il existe plusieurs moyen pour espionner vos processus, tout d'abord vous pouvez créer un wrapper autour de la lib SSL et utiliser LD_PRELOAD pour la charger avant le processus. C'est bien mais difficile à mettre en œuvre, surtout si le processus tourne déjà, je vous laisse explorer cette voie de votre côté.

La deuxième solution est d'utiliser ptrace pour espionner le processus. Techniquement complexe, cette méthode nous est grandement facilitée par l'outil ltrace.

Pour la suite je vais supposer que les services à espionner passent par openssl, mais rien ne vous empêche de faire la même chose avec gnutls.

Espionner un processus

C'est simple :

# vous le lancez directement : 
$  ltrace ma commande
# ou vous espionnez un processus qui tourne déjà 
$ ltrace -p pid

Ça vous montre le fonctionnement, mais c'est aussi illisible qu'un strace.

Espionner le SSL

Ajoutons quelques options pour trier ce fouillis :

$ ltrace -l /usr/lib/libssl.so.0.9.8 -s 20000 -e SSL_read,SSL_write

Et voilà, la liste des appels ! Mais ce n'est pas suffisant.

Ajoutons les lignes suivantes dans /etc/ltrace.conf (ou dans ~/.ltrace.conf) :

int SSL_read(addr,string[retval],int);
int SSL_write(addr,string[arg3],int);

On relance la commande et maintenant nous avons le contenu de la communication en clair.

Mais il y a un petit bug dans ltrace, string[retval] devrait couper les chaines de SSL_read en fonction de la valeur de retour, mails ne le fait pas.

Corrigeons cela avec un petit script de formatage et cette fois nous avons toute la communication en clair !

$ ltrace -l /usr/lib/libssl.so.0.9.8 -s 20000 -e SSL_read,SSL_write -p pid 2> /tmp/trace
$ perl -pe 's/(SSL_read.*?, ")(.*)(".*? )(\d+)$/$1.substr($2,0,$4).$3.$4/e' /tmp/trace | less

Si vous avez aimé, il y a aussi :

1. Analyse réseau

Voici quelques ordre de grandeur qui vous permettront d'avoir les idées un peu plus claires sur les performances de votre système. Imaginez que le swap est 100 000 fois plus lent que la mémoire du processus ! Qu'un algorithme de création d'arbre peut être plus lent qu'un algorithme linéaire si chaque nœud de l'arbre se retrouve sur une page différente (pensez à vos centaines de malloc pour remplir un arbre) !

Notez que l'important ce sont les ordres de grandeur, vous pouvez facilement trouver des éléments qui font le double ou la moitié de ces performances.

Interprétations

Sérieusement, pas besoin de giga de swap sur votre serveur. Mettez un tout petit peu et vous monitorez dès que ca dépasse, imaginez la division par un nombre à 5 chiffres du nombre de pages vues sur votre serveur ! Pour ma part je préfère répondre à moins de requêtes par seconde et garder un serveur utilisable.

Mais sur votre station de travail vous faites ce que vous voulez, on est en général plus patient :-)

Pas de gettime à gogo dans votre code pour mesurer les perf, ça tue les perfs ...

Le réseau fait a peu près aussi bien que votre disque.

Pas de malloc à gogo pour des structures morcelées et très utilisées. faites une structure unique si vous devez en avoir beaucoup.

Le SSD c'est bien mais ca vaut pas l'accès direct au flash.

Étant donné la vitesse de compression un swap compressé peut vraiment valoir le coup.

Le cache processeur sert vraiment à quelque chose ... si on sait coder pour qu'il soit utilisé (ou laisser le compilateur faire).

Le fork c'est un peu lent, prévoyez un prefork correct sur vos applications fréquemment appelées.

Avoir beaucoup de processus n'est pas si coûteux en soi (context switch).

PS : Si vous avez des données pour compléter ce tableau, n'hésitez pas à me laisser des commentaires.

Si vous avez aimé, il y a aussi :

1. Que faire et ne pas faire en raid

HA Cékoikece

Qu'est-ce que la haute disponibilité ? Déjà on ne dit pas HD mais HA (high availability) ;-).

Il s'agit de fournir un taux de disponibilité très important. En général la disponibilité se mesure en 9, deux 9, trois 9 ... Cela indique le pourcentage de disponibilité. Deux 9 c'est 99%, sur un an ça correspond à 88h de non disponibilité. C'est assez faible.

Mais faible ou élevé, tout dépend de ce dont on parle. Si on parle d'un site web, 99% c'est faible mais suffisant, si on parle d'un service financier on préfèrera 99.999%

Les pannes

Les causes des indisponibilités peuvent être multiple :

• bug
• erreur humaine
• coupure de courant
• chalutier qui coupe un câble
• bombe H sur batiment
• ...

Les éléments pouvant être coupés sont nombreux :

• électricité
• salle d'hébergement
• électronique
• disques
• réseau
• système d'exploitation
• logiciel

Que faire ?

Pour éviter d'avoir trop de problèmes la meilleurs solution est ... d'ajouter des problèmes.

C'est comme pour le fromage, ajouter du fromage ajoute des trous, ajouter des trous enlève du fromage. De même ajouter des machines ajoute des problèmes ajouter des problèmes enlève de la disponibilité.

Un bon exemple du succès de la méthode est celui des avions. Savez-vous qu'il y a plusieurs avaries par jour sur des avions en vol dans le monde ? Non ? Hé bien c'est tout simplement parce que tout est multiplié dans un avion et qu'un réacteur qui ne marche plus, ce n'est pas si grave, il y en a d'autres. Du coup la probabilité que tout tombe en panne en même temps est beaucoup plus faible. Et les cas graves sont très rares, surtout au vu du nombre de vols quotidiens.

Dans l'informatique c'est pareil, tout peut être doublé, voire triplé :

• l'électricité : l'arrivée électrique, l'onduleur, le générateur
• la climatisation
• les serveur double alim
• les routeurs /switchs / firewall double attachés
• les baies doublées et séparées
• les datacenter doublés
• les disques doublés, en raid ou en san
• les serveurs doublés
• les os différents

Technologies

A chaque fois que vous multipliez quelque chose, il faut vérifier que la technologie située sur la couche du dessus le supporte. A quoi bon mettre du loadbalancing sur une application qui stocke toutes ses informations en local !

Pour faire de la haute disponibilité, c'est en général la notion de failover qui prédomine. Si un câble réseau tombe, un deuxième prend le relai. Si une alimentation grille, on va utiliser une autre ...

Cette notion a l'avantage d'être simple et d'avoir moins d'impacts sur la couche du dessus. En revanche elle est en générale plus lente à être mise en place car on fait en sorte de ne pas impacter le reste du monde. Mais bien évidemment tout dépend de ce dont on parle. Le failover en électricité est instantané. Par contre le failover sur une base oracle est un poil plus long à activer.

Une deuxième notion de haute disponibilité est plus liée à la montée en charge : le loadbalancing. Une fois mis en place dans le but de gérer une montée en charge il peut aussi servir à faire de la haute disponibilité. En général cette mise en place implique une complexité plus grande, mais aussi une réactivité plus grande.

Et c'est là qu'on arrive à une confusion courante.

Il est important de ne pas confondre haute disponibilité et montée en charge !

Si vous installez un service sur 3 machines, 2 pour gérer la montée en charge et la 3e pour la haute disponibilité. Il faut considérer cette 3e comme éteinte. Il ne faut jamais dire qu'on va utiliser temporairement cette machine pour gérer des pics de charge. Tout d'abord parce qu'en informatique le temporaire dure longtemps (allez en parler aux stagiaires qui ont mis les dates sur 2 chiffres en 1970 dans une base de données) et ensuite parce que la perte de cette machine ne doit pas provoquer de problème sur le service quelle que soit la situation.

En résumé, le même matériel ne peut pas servir à la fois à la haute disponibilité ET à la montée en charge !

Solutions

Cet article n'est qu'un aperçu, vais donc simplement évoquer ici différentes solution "logicielles" de haute disponibilité sans entrer dans les détails. Si cela vous intéresse allez y jeter un œil :

• keepalived est un loadbalancer réseau, il permet de gérer à la fois le loadbalancing de connexions TCP ou UDP vers plusieurs machines et la redondance du loadbalancer.
• heartbeat un démon qui surveille en continu l'activité de machine apparié et déclence certaines actions en cas de besoin (comme récupérer son ip). Le site en lui-même est une très bonne ressource sur la haute disponibilité
• mysql cluster est un moyen de faire tourner plusieurs serveurs mysql en parallèle sur la même base de données et donc d'augmenter à la fois les performances et la disponibilité
• memcached est un moyen de partager des ressources entre des applications distribuées sur plusieurs machines sous la forme clé/valeur. Il ne garanti pas la disponibilité des données et donc est plus proche du cache que de la haute dispo
• haproxy est un loadbalancer HTTP, c'est-à-dire qu'il fait reverse proxy et redirige les requêtes vers plusieurs serveurs web en fonction de leur activité.
• ofcs2 est du loadbalancing appliqué aux systèmes de fichier. Deux machines peuvent accéder en même temps à un fichier situé sur le même disque (réseau de préférence).

...

Et j'en oublie des centaines d'autres, à vous de vous faire une idée de ce qui est possible en allant chercher l'outil qui vous convient le mieux.

Si vous avez aimé, il y a aussi :

1. Hébergement
2. Round robin DNS
3. Exécution non simultanée de crons

Les processus comme je l'ai déjà décrit, forment une grande famille.

La famille processus

Dans la famille processus je voudrais le père

Les processus se reproduisent par fork (Mitose en français). Ce qui veut dire qu'à la genèse il n'y avait qu'un processus que nous ne nommerons pas Adam mais init.

Tous les processus possèdent un identifiant (pid) ainsi qu'un identifiant de processus parent (ppid) permettant de les repérer dans un arbre généalogique (pstree).

Comment reconnait-on le père du fils lors du fork d'un processus ? Uniquement par le code de retour de la méthode fork qui vaut 0 pour le fils et donne le pid du fils au père. En dehors de cela les 2 processus sont rigoureusement identiques.

Dans la famille processus je voudrais la mère

Désolé, il n'y a pas de femme chez les processus, la reproduction est asexuée, mais c'est une idée à creuser ...

Dans la famille processus je voudrais le fils

Lorsqu'un processus forke, en général le père poursuit sa vie comme si de rien n'était, par contre le fils va muter. La mutation génétique chez les processus est bien plus violente que chez les êtres vivants. En effet, le code (l'ADN en français) est intégralement relu et remplacé depuis un nouveau fichier sur le disque. C'est ce qu'on appelle un exec.

Il existe quelques cas de processus qui ne fonctionnent pas comme ceci, mais qui laissent leur père mourir (ingrats !) et qui prennent leur place. C'est le cas des démons (un parricide est-il un démon ?) dont le but est de devenir indépendants (émancipés) et ne plus avoir de problèmes d'adolescence (le tty du père) ou de famille (le groupe de processus).

Dans la famille processus je voudrais le grand-père

Lorsqu'un processus meurt, sa dépouille est remise à son père. Elle est essentiellement constituée de son code de retour.

Lorsque le père est déjà mort, c'est le doyen qui a la charge de récupérer le code de retour, par exemple avec la méthode wait.

Dans la famille processus je voudrais le zombie

Si le père ne s'occupe pas des funérailles du fils bien aimé, celui-ci erre dans les méandres du noyau en attendant que quelqu'un veuille bien l'enterrer.

C'est ce qu'on appelle un zombie, caractérisé par la lettre Z ou par le mot defunct dans la liste des processus. Il est impossible de tuer un zombie (il est déjà mort). Seul son ascendant le plus proche le peut.

Heureusement l'ascendant universel, père de tous les processus, j'ai nommé init, prend soin de la dépouille de tous les enfants qui lui sont confiés. Donc si le père d'un zombie meurt, init s'occupera de le faire disparaître.

Les non processus

Chez les amis des processus voudrais le thread

Le thread n'est pas vraiment un processus, c'est un élément de processus, tout comme la main est un élément du corps. Avoir plusieurs threads permet à un processus de faire plusieurs choses en même temps tout en restant une seule entité. Cela permet par exemple de dédier une main au traitement et un pied à l'affichage (oui on s'y prend souvent comme des pieds pour faire des IHM, sauf certains qui y dédient la casquette).

Chez les amis des processus je voudrais le binaire

Le binaire (ou fichier exécutable) est le modèle du processus, l'ADN si vous préférez. Sans binaire, impossible de créer un processus. Celui-ci est inerte et manipulable aisément.

Chez les amis des processus je voudrais la bibliothèque

La bibliothèque c'est un bout de code qui peut être réutilisé par des processus, tout comme les plasmides , elles s'intègrent à n'importe quel autre processus pour leur apporter une fonctionnalité donnée.

Chez les amis des processus je voudrais le thread noyau

Le thread noyau est un cas particulier de thread, il tourne dans l'espace noyau et ne partage donc sa mémoire qu'avec le noyau mais ne rentre dans aucun processus. On devrait les appeler des anges puisque ce sont des être invisibles (ou presque) agissant au compte de dieu (le noyau).

Chez les amis des processus je voudrais le core

Le core, ou core dump est la version fossilisée d'un processus mort au combat. Lorsqu'un processus meurt il est effacé de la mémoire, mais s'il meurt dans des conditions exceptionnelle, par exemple s'il s'est pris un coup de signal (man kill) dans la tête et qu'un résineux est à proximité (ulimit -c) on le coule dans l'ambre pour une analyse ultérieure. gdb est un grand ami médecin qui est aussi légiste, il saura vous aider le temps venu.

Si vous avez aimé, il y a aussi :

1. Processus et threads
2. Brutus Processus
3. Processus de boot

Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Préparer son terminal

Nous allons enregistrer ce qui se passe sur le terminal, lequel va tourner en ncurses, il est donc important pour la lisibilité des logs de le dimensionner à la même taille que l'écran de boot, c'est-à-dire 80x25.

Modifiez la taille de votre fenêtre de terminal jusqu'à ce que les variables $COLUMNS et $LINES vaillent respectivement 80 et 25.

Préparer son bootloader

Quel que soit votre bootloader configurez le de façon à ce qu'il ne lance pas de mode graphique, sinon vous ne pourrez pas stocker les logs de ce qui se passe.

Choisit son qemu

Installez qemu. Puis en fonction du matériel à émuler choisissez qemu-system-i386 ou qemu-system-x86_64 ou une autre architecture si vous travaillez sur d'autres machines.

Lancer le tout

Préparez un 2e terminal pour tuer qemu , ca sera plus simple que d'attendre qu'il se termine proprement (killall qemu pour les impatients).

$ sync
$ ssh -t localhost "qemu-system-x86_64 -m 512 -curses -hda /root/sda" | tee logs

Pourquoi sync ? au cas où vous auriez fait des modification impactant le boot, on force l'écriture de celles-ci sur le disque.

Pourquoi ssh ? Pour profiter de l'option -t qui crée un terminal virtuel même lorsqu'on travaille dans un pipe.

Pourquoi tee ? Pour stocker les logs de ce qui se passe tout en gardant la main sur le clavier. Tout est tellement rapide qu'il peut y avoir des erreurs invisibles.

Pourquoi -m 512 (512Mo de ram): prenez une valeur inférieure à votre matériel mais malgré tout proche pour éviter les effets de bord.

Pensez à ajouter les disques dont vous pourriez avoir besoin selon le niveau de boot que vous voudriez tester.

Lire les logs

Bon, qemu s'est lancé, le boot a planté, mais vous n'avez pas eu le temps de voit l'erreur.

Commencez par tuer le qemu s'il vous gêne. Puis lisez les logs :

$ less -R logs

Pourquoi -R ? parce que cette option vous permet de ne pas traduire les caractères spéciaux que qemu écrit à travers ncurses et vous permet de voir le contenu des logs tels qu'ils sont apparus à l'écran.

Mode graphique

Si vous ne voulez pas de logs ou que vous ne pouvez pas empêcher le mode graphique de se lancer, vous pouvez faire sans. Dans ce cas, à vous de vous connecter à la machine de façon à ce qu'un serveur X soit accessible (par exemple avec ssh -X).

La commande devient alors :

$ sync
$ qemu-system-x86_64 -m 512 -hda /root/sda

PS : Et ça marche avec les outils de virtualisation comme xen.

Si vous avez aimé, il y a aussi :

1. Chargeeeez !
2. Sécurité du processus de boot
3. Présentation, cours

Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Raid 1

Le choix de ceux qui ne veulent pas de pertes.

Tous les disques sont des copies intégrales. L'avantage le plus important est que lors de la perte d'un disque tout fonctionne comme si de rien n'était. On peut donc remplacer ce disque (ou pas :-).

Un autre avantage existe lors des lectures non séquentielles (lors de la lecture de 2 fichiers par exemple), dans ce cas il est possible d'utiliser un disque pour chaque lecture et donc d'accélérer ce type de lecture. Par contre la lecture d'un seul gros fichier n'est pas accélérée (sous linux).

Il n'y a en revanche aucun impact sur l'écriture, c'est le disque le plus lent qui détermine la vitesse d'écriture (la vitesse devrait être à peu près identique pour chacun).

Notez qu'on peut faire du raid 1 avec plus de 2 disques.

Le Raid 1 peut être matériel, logiciel avec le driver md ou logicielle avec LVM (support du miroring), enfin il est possible de faire du raid1 réseau avec drbd.

Raid 5

Le choix des économes.

En raid 5 chaque disque est découpé en bande, pour chaque groupe de bandes situées au même endroit des disques, une des bandes est choisie pour contenir des octets de redondance (la différence avec le 4 c'est le choix de la bande). Ainsi ce type de raid peut survivre au crash d'un des disques (la redondance permet de reconstruire la bande manquante), mais pas de plusieurs.

L'avantage du raid 5 est que lorsqu'on a de nombreux disques on économise des disques de redondance en n'en achetant qu'un pour la redondance et les autres pour les données.

Mais le raid 5 est assez limité en performances. La lecture se passe comme pour le raid 1. Par contre l'écriture nécessite la lecture de chacune des bandes d'un groupe pour écrire la bande de données, puis calculer et écrire la bande de redondance. C'est donc très lent, à éviter pour les bases de données actives.

D'autre part, lors du crash d'un disque, toutes bandes des disques doivent être lues pour reconstituer une bande manquante. Ce qui implique des baisses de performances énormes, auxquelles il faut ajouter la baisse de performances due à la reconstruction du disque qu'on va remettre. Comme les disque tournent à fond, il n'est pas rare de voir un autre disque exploser en vol à ce moment là -> fin des données.

Le raid 5 peut être matériel ou logiciel avec le driver md de linux.

Raid 6

Le choix des très gros disques.

Le raid 6 fonctionne de la même façon que le raid 5 mais ajoute un deuxième disque de redondance. Ce ne sont pas simplement les données de redondance qui sont dupliquée, mais le calcul qui est différent, toutefois le concept est identique.

Le raid 6 soufre des mêmes inconvénients que le raid 5, il utilise même un disque de plus donc est un peu plus cher, de plus cela provoque une écriture supplémentaire pour chaque groupe de bandes.

Mais le raid 6 résiste au crash de 2 disques, ce qui est intéressant lorsque les disques sont assez gros et que la reconstruction du raid comment à être assez longue (et donc le risque de perte plus gros).

Le raid 6 peut être matériel ou logiciel avec le driver md de linux.

Raid 10

Le choix des riches.

Le raid 10 consiste à accumuler plusieurs raid 1 avec du raid 0 pour en augmenter la taille et les performances.

Le raid 10 offre les avantages simultanés du raid 1 et du raid 0. La perte d'un disque n'empêche pas le raid de tourner et l'utilisation de plusieurs disques en striping permet d'augmenter les performances de lectures.

Le seul inconvénient, c'est qu'il coûte deux fois le prix du raid 0.

Il peut se faire en matériel ou logiciel, md ou lvm.

Raid 0+1

Le mauvais choix.

Le raid 0+1 consiste à mettre 2 raid 0 en parallèle pour les redonder avec du raid 1. On pourrait croire que c'est la même chose que du raid 10, mais non. Et même si certains veulent vous faire croire que les performances sont meilleures, il n'en est rien.

Mais surtout imaginez un instant la perte d'un disque. Dans ce cas un des raid 0 sous-jacent est perdu. Il faut donc le recréer avec un nouveau disque (ce qui est à peu près instantané puisqu'on le laisse vide), puis reconstruire le raid 1 situé au dessus. Et cette deuxième partie va être longue puisqu'elle doit être faite sur la taille totale du raid 0, contrairement au raid 10 qui ne l'aurait fait que sur la taille totale du disque perdu.

Petit récapitulatif

Si vous avez aimé, il y a aussi :

1. Que faire et ne pas faire en raid
2. LaVoMatic
3. L’avenir du disque

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

init

Init est lancé par le noyau après lecture de la racine. Il lit sa configuration dans /etc/inittab. Il peut donc être détourné par modification du disque : GoTo partition /

Parmi les paramètres qu'on peut lui passer il y a 1 et S, 1 renvoie au problème ci-dessus et S lance lui-même sulogin, donc même vérification. Ces paramètres viennent du noyau : GoTo noyau

Init est un binaire choisi par le noyau, or il est possible de dire au noyau de changer d'init à travers le bon paramètre. Par exemple, je peux ajouter init=/bin/sh aux paramètres du noyau pour qu'init ne soit jamais lancé qu'un shell apparaisse à sa place. Ça y est je suis root ! C'est d'ailleurs la technique pour changer de mot de passe root lorsque vous l'avez perdu.

Pour changer d'init GoTo noyau.

Init peut aussi être lancé par initrd, il souffre dans ce cas exactement des mêmes problèmes que lorsqu'il est lancé par le noyau : GoTo initrd.

Note upstart, initrdng... :
Il se peut (et ca va être de plus en plus courant) qu'init ou rc soit remplacé par autre chose, type upstart. Dans ce cas seul les noms des paramètres et le format des fichiers change. Mais les impacts sont exactement les mêmes.

Initrd

Initrd prend ses paramètres de la ligne de commande du noyau, mais généralement (il y a plein d'initrd différents) ils sont passés tels quels à init.

D'autre part initrd peut être chargé par 2 moyens, j'ai décrit le bootloader comme un moyen mais le noyau peut aussi charger lui-même l'initrd si on lui demande (avec le paramètre initrd=). On peut donc détourner son chargement par plusieurs moyens : GoTo noyau, GoTo bootloader.

Il est aussi possible de modifier directement l'initrd, par exemple lors d'une réinstallation distante. Celui-ci contenant tout ce qu'on veut, modifier son contenu permet de lancer n'importe que processus ... GoTo partition /boot

Noyau

Le noyau en lui-même ne vous rend pas root mais rien ne vous empêche d'y faire une modification pour qu'il vous fasse root une fois le système chargé.

Le noyau est chargé depuis la partition /boot donc une modification de cette partition et c'est gagné : GoTo partition /boot

Le noyau prend ses paramètres du bootloader, parmi ceux-ci de nombreux paramètres permettent de détourner le système : root= init= initrd= et surement bien d'autres. GoTo bootloader

Partition /

Jusque là, nous n'avons évoqué que les risques mais pas encore de faille. C'est parce qu'aucune interférence de l'utilisateur n'a été possible, tout est automatisé. Mais ça va changer.

Lors du montage de la racine, il y a une interférence possible : le disque contenant / peut avoir été modifié, voire remplacé, pour modifier /etc/inittab, /sbin/init, /etc/init.d/rc ou toute autre chose.

Pour éviter ce problème, il y a deux possibilités :

• mettre un cadenas sur la machine pour garantir l'intégrité physique du disque
• chiffrer le disque

Dans le premier cas, le problème est remonté aux autres couches pour garantir l'intégrité logique et éviter qu'on réussisse à booter sur un autre OS pour modifier le disque. GoTo bootloader.

Dans le deuxième cas, le chiffrement (par exemple avec luks ou truecrypt) doit être assuré par une clé.

• si cette clé est sur la machine et son mot de passe aussi : elle est dans un élément de boot (initrd, partition de boot ...) on reporte le problème GoTo partition /boot
• si cette clé ou son mot de passe n'est pas sur la machine (carte à puce, mot de passe, clé usb ...) alors il y a besoin d'un personne présente à chaque boot ...
• le chiffrement peut aussi être assuré par une puce (TPM) qui ne quitte pas la machine, auquel cas, on garanti que le disque ne quittera pas la machine pour être lu ou modifié (mais pas de garantie contre le formatage), par contre il peut être lu sur place par un autre OS.

Dans tous les cas, seul le démarrage post-noyau est préservé, pour le reste GoTo bootloader.

bootloader

Le bootloader est la source de tous les maux. C'est en effet par lui que l'utilisateur a tout loisir de modifier des paramètres de démarrage.

Le bootloader passe ses paramètres au noyau qui les passe à l'initrd qui les passe à init. Ces paramètres viennent de la configuration du bootloader mais pour un certain nombre de bootloader ils peuvent être directement demandés à l'utilisateur. Dans ce cas il y a moyen d'interdire cette modification à travers un mot de passe. Par exemple grub.

Le bootloader charge sa configuration puis choisit et charge le noyau et l'initrd, tout ceci depuis la partition de boot. Dans tous les cas il doit lire une version non chiffrée, ce qui interdit le chiffrement de cette partition.

Pire, le bootloader est incapable de savoir que le disque n'a pas changé. Donc un simple ajout de disque permet de le faire booter sur un noyau/initrd différent.

Vous ne pouvez presque rien y faire: GoTo partition /boot.

Bon en supposant qu'il n'y a pas de problème, le bootloader est chargé par le bios, il peut donc être détourné : GoTo Bios.

Partition /boot

J'inclue dans la définition de la partition de boot tout ce qui contient la configuration du bootloader, le bootloader lui-même, le noyau et l'initrd, même si ils peuvent être physiquement à des endroits différents. Protéger la partition de boot est très complexe, car tout doit être accessible en clair depuis des outils ayant des fonctionnalités très restreintes.

Les possibilités sont :

• sceau physique sur la machine
• TPM

Mettre un gros cadenas sur la machine permet d'éviter une lecture ou une modification de /boot. Mais il on ne se prémunit pas d'une personne un peu patiente avec un accès complet à la machine.

La dernière solution, complexe à mettre en place et sans garantie absolue est d'utiliser une puce TPM qui va vérifier (mesurer) le bootloader à chaque étape de son chargement, puis vérifier chaque élément que le bootloader charge avant de lancer le noyau.

Bios

Le bios s'exécute tout seul depuis lui-même, il se charge puis lis ses paramètres. Parmi ces paramètres il y a la séquence de boot, qui peut elle-même être modifiée par l'utilisateur.

Il est donc possible, voire facile de dire au bios de booter sur une clé USB et de prendre le contrôle du disque et donc de la machine. Pour éviter ce cas de figure il est possible de mettre un mot de passe au bios. Ainsi on est sûr de booter sur le bon disque, mais seulement s'il y a un cadenas sur la machine puisque le bios ne vérifie pas que le disque n'a pas été remplacé.

GoTo Matériel.

Matériel

Il est possible de changer le bios lui-même. Et ce de plusieurs façons. Si c'est un flash, il est possible de le remplacer logiciellement, si c'est une rom il est possible de la remplacer matériellement.

Et enfin le plus simple pour remplacer le bios est de remplacer la carte mère. Hop ni vu ni connu ...

Pour se protéger de cela ? Le cadenas ... ou la puce TPM, dont la mise en place est toujours très complexe et non garantie.

Conclusion

Résumons-nous car cet article commence à être un peu long. Différencions les cas dont on veut se protéger.

Accès réseau

Si l'attaquant n'a accès à la machine que par le réseau, on est tranquille pour ce qui est de la séquence de boot : No problemo.

Accès KVM

Si l'attaquant n'a accès à la machine que par KVM (pas de possibilité de toucher aux périphériques). Mettre un mot de passe sur le bootloader, le bios et vérifier que le mode rescue demande le mot de passe root devrait suffire. En effet les seul moyen d'attaque sont les paramètres de lancement du système.

N'oubliez pas que le simple accès KVM permet des choses comme le reboot via les magic keys

Accès cadenassé

Si on suppose que l'attaquant peut apporter un CD ou une clé usb sur le système, paramétrer le bios pour booter sur un disque et y mettre un mot de passe est un moyen simple à mettre en place pour éviter le boot sur un autre système.

Mais attention, il ne faut pas que l'utilisateur puisse ouvrir la machine, il pourrait réinitialiser le bios.

Accès au disque sans droit de boot

A partir du moment où l'attaquant a accès au disque c'est presque foutu. Si l'attaquant n'est pas une personne autorisée à booter la machine, il est possible de chiffrer le disque avec une clé qui ne se trouve pas sur le disque. Il faudra alors la rentrer à chaque démarrage. L'attaquant ne disposant pas de cette clé, il me pourra ni lire ni modifier les données où le système. Mais c'est déjà une solution assez contraignante.

D'autant plus que pour être complète cette solution doit garantir le noyau et l'éventuel initrd sur lequel on boote et donc vérifier soi même à chaque boot qu'on utilise une partition de boot non modifiée.

On en arrive au dernier cas ...

Accès complet

Lorsque l'attaquant a un accès complet à la machine, il n'existe qu'un moyen de se protéger (et encore) : la puce TPM.

Elle permet de :

• protéger le bios d'un changement
• protéger le bootloader d'un changement
• protéger le noyau d'un changement
• protéger le contenu du disque d'un changement

Mais tout cela est compliqué et nécessiterait un autre article que je ne suis pas encore prêt à faire, je n'ai même pas de puce TPM chez moi.

PS : Notez une dernière chose que je n'ai pas abordé, le chiffrement des données. Le chiffrement du disque contenant les données (/home et /srv selon vos besoins) devient obligatoire dès qu'on prévoit qu'il y aura un accès physique. Il doit de préférence se faire avec un moyen propre à l'utilisateur (mot de passe / clé / carte à puce ...) pour éviter les attaques à travers le boot de l'OS.

PPS : Considérez qu'a partir du moment où quelqu'un a un accès physique à votre machine c'est mort.

PPPS : Sauf si votre machine est une carte à puce.

PPPPS : Et encore ...

Bon courage !

Si vous avez aimé, il y a aussi :

1. Processus de boot
2. Mesurer le temps de boot
3. Réinstallation distante