Linux Attitude

Niveau :      
Résumé : tcpdump ssl ; ptrace ; ltrace

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

Niveau :      
Résumé : quelques ordre de grandeur

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.

Niveau :      
Résumé :

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

Niveau :      
Résumé : /proc/<pid>

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.

Niveau :      
Résumé : ssh qemu-system -hda /dev/sda

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.

Niveau :      
Résumé : Raid 10, raid 0+1, raid 5, raid 6

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)

Niveau :      
Résumé :

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