Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: planet-libre

Niveau :      
Résumé : ip link add link eth0 vlan1 type vlan id 1

Je suis de retour !

Désolé pour le lag ... mais je réponds aux commentaires.

Problème

Aujourd'hui, un problème qu'on m'a posé récemment. Comment faire lorsqu'on a un parc de box (routeur wifi, machine embarquée, ...) et qu'on veut pouvoir à tout moment se connecter physiquement sur son port ethernet et la configurer en utilisant ip (par ssh, snmp ...).

La première solution est d'avoir une configuration réseau immuable sur ces machines ET de répertorier d'une façon ou d'une autre un identifiant unique pour chacune de ces machines qu'on peut alors faire correspondre à une ip. C'est assez contraignant et ça impacte fortement la configuration réseau des machines. Ça risque de nous empêcher de réutiliser ce port pour communiquer dans un réseau existant le reste du temps.

La deuxième solution serait d'utiliser un protocole type zeroconf pour configurer automatiquement le réseau lorsqu'on se branche, l'inconvénient est de réussir à le désactiver lorsque la machine se retrouve dans son réseau de destination qui n'utilise pas nécessairement zeroconf tout en le gardant actif pour le configurateur.

Je vous propose donc une solution différente : l'ip unique. Toutes les machines à configurer ont la même IP. C'est bien beau me direz-vous, mais comment fait-on pour éviter les conflits sur le réseau de destination ? Et comment fait-on pour que ces machines communiquent ensemble ?

C'est tout simple, on met cette IP sur un vlan prédéfini. Ainsi vous n'avez plus aucune contrainte sur la configuration réseau de l'appareil. Ce peut être une box en bridge ou en routeur, une machine physique avec un routage complexe, ou une machine configurée en dhcp.

Solution pour linux

Pour ajouter une interface réseau virtuelle associée à un vlan :

# le vlan 1 sur l'interface eth0 sera dans l'interface virtuelle vlan1 
$ ip link add link eth0 vlan1 type vlan id 1 

# ou, pour ceux qui n'aiment pas le couteau suisse, ip, il y a l'outil d'origine
$ vconfig add eth0 1 # pas le choix, l'interface s'appellera nécessairement eth0.1

Et il suffit de lui configurer une ip choisie en dur et c'est fini, vous pouvez mettre n'importe quelle configuration pour eth0 ...

$ ip addr add 192.168.254.254/28 dev eth0.1

Pour faire ceci en statique, sur une debian like il faut modifier /etc/network/interfaces en nommant l'interface à configurer eth0.1 Pour les redhat like il faut créer le fichier /etc/sysconfig/network-script/ifcfg-eth0.1

Niveau :      
Résumé : ntp.conf ; fudge

Pour vérifier le bon fonctionnement de votre démon ntp, vous êtes amené à taper la commande suivante qui liste les source de temps utilisées :

$ ntpdc -p

Cette commande met une étoile face à la source de référence utilisée pour la synchronisation. Le choix se fait entre autre en fonction du stratum de la source. Je rappelle que les serveurs NTP disposant d'une source de temps matérielle fiable (horloge atomique) ont pour stratum 1. Ceux qui se synchronisent sur eux, 2, et ainsi de suite.

Étant donné qu'il y a un grand nombre de serveurs publics de strate 2 et 3, vous devriez avoir accès à des serveurs de strate 4, ou au pire 5. Mais si le serveur a une strate plus élevée, il se peut que l'horloge choisie ne soit plus le serveur, mais l'horloge locale qui a une strate définie par défaut à 5 sur certaine distributions.

Et là c'est le drame, vous n'êtes plus synchronisés !

Pour résoudre ce problème, il y a plusieurs méthodes, se résumant toutes en la configuration des serveurs de temps :

# ntp.conf

# mettre l'option prefer sur le serveur voulu
serveur xxx.com prefer
# réduire la strate du serveur
fudge xxx.com stratum 4

# augmenter la strate de l'horloge locale
# 127.127 pour les horloges non réseau
# 1.0 pour l'horloge système
fudge 127.127.1.0 stratum 10

Niveau :      
Résumé : vlock; vlock -ns

Vous avez vu apparaître dans l'article sur tmux, un petit outil pour verrouiller le terminal, il s'appelle vlock.

Son unique fonctionnalité est le locker un terminal et de demander un mot de passe pour être débloqué.

Mine de rien ça lui fait quand même deux cas d'usage :

  • bloquer l'accès physique à une machine
  • bloquer l'accès virtuel à un shell

Virtuel

Avec la commande suivante :

$ vlock

Vous bloquez votre terminal en cours, et seul un mot de passe peut le débloquer. C'est utile essentiellement lorsque vous êtes connecté en ssh à distance sur une machine.

Physique

L'option -a permet de locker toutes les consoles locales (ctrl-alt-Fx, ou alt-Fx), en pratique il locke la console en cours et empêche d'en changer. Il faut donc déjà être sur une console locale.

Si vous êtes sur X, vous êtes aussi sur une console locale (remarquez le ctrl-F7 pour y aller). Mais le shell qui va lancer votre commande ne l'est pas, il est dans le terminal virtuel de xterm, rxvt, konsole et consorts. Pour locker toutes les consoles, il faut donc utiliser l'option -n qui ouvre une nouvelle console (avec openvt) avant de continuer avec l'option -a.

Enfin notez que l'utilisateur local a en général accès aux magic keys, et une de ces magic keys sert justement à tuer le processus en avant plan (alt-sysrq-k), par exemple pour garantir qu'il n'y a pas de keylogger. Si vous ne voulez pas vous faire tuer votre session par cette combinaison de touche vous pouvez utiliser l'option -s. C'est là qu'on voit que cette combinaison nommé SAK n'est pas si sécurisée que ça puisqu'elle peut être désactivée...

Donc je résume :

# en tant qu'utilisateur normal et seulement depuis une console texte
$ vlock -a
# en tant que root
$ vlock -sn

Quand le lancer

Et c'est là qu'est la difficulté, en toute logique le lancement doit se faire par le processus qui dispose du terminal à un instant donné, surtout dans le cas de blocage du terminal virtuel. La bonne solution est de le lancer après un certain temps d'inactivité, et seule l'application peut savoir quand le lancer. C'est donc à vous de trouver les settings spécifiques à l'application pour le faire.

Mon article précédent indique comment faire pour tmux, malheureusement je n'ai pas trouvé de solution pour bash qui ne propose que la variable TMOUT qui termine complètement le shell.

Niveau :      
Résumé : tmux

Aujourd'hui tout le monde connaît et utilise screen. Miracle de la technologie, il permet de survivre aux déconnexions, de lancer des commandes longues sans avoir peur, de faire passer tous ses shells dans une seule connexion et on le trouve souvent associé à l'indémodable irssi.

Comme vous le savez peut-être screen n'est plus maintenu. Ayant un code un difficile à lire et à maintenir, des développeurs ont choisi lui faire un concurrent plutôt que de le reprendre.

Ce concurrent se nomme tmux. Il dispose de la plupart des fonctionnalités de screen et d'autres en plus. Comme vous le verrez, votre problème sera essentiellement de vous adapter aux nouveaux raccourcis. Pour le reste c'est tout bon.

Tmux dispose de presque toutes les fonctionnalités de screen sauf la communication par port série (rapport choucroute, toussa).

Commençons par le lancement :

# lancer un nouveau multiplexeur
$ screen 
$ tmux
# s'attacher à un multiplexeur existant 
$ screen -d -r
$ tmux attach

Les raccourcis :

  • Nouvelle fenêtre
    • screen : ctrl-a ctrl-c
    • tmux : ctrl-b c
  • Se détacher :
    • screen : ctrl-a d
    • tmux : ctrl-b d
  • Passer à la fenêtre suivante
    • screen : ctrl-a <espace>
    • tmux : ctrl-b n

Je dois dire que ça y est je suis passé entièrement à tmux, le mélange ctrl-a ctrl-b entre screen et tmux commençait à être difficile. A propos d'adaptation, j'ai eu une seule difficulté c'est de m'habituer au nouveau scrollback. Il n'est pas possible de le faire à la souris, comme dans screen avec l'astuce du termcapinfo. Remarquez, c'est plus propre car du coup il n'y a pas de mélange des bufffer de scrollback entre les différents terminaux. Donc la méthode propre dans tmux c'est ctrl-b suivi de pgUp et là vous êtes en mode copy (qui permet entre autre le scrollback), vous pouvez alors naviguer avec pgUp, pgDown ou les touches directionnelles. Et pour Revenir au mode normal, Esc tout simplement.

Dans un prochain article nous verrons comment changer la configuration de tmux, même si les valeurs par défaut sont plutôt bonnes.

Niveau :      
Résumé : ngrep

I'm back ! Ça faisait longtemps ! Vous m'avez manqué.

J'ai quelques petits articles pour vous. Oui c'est vraiment la reprise, même si c'est pas encore du triple A.

Aujourd'hui ngrep. Ngrep est un pote de tcpdump, il sait utiliser les mêmes filtres que tcpdump et stocker les paquets dans un format pcap lisible par wireshark si besoin. Mais son intérêt principal est qu'il sait matcher le contenu des paquets.

Là où en tcpdump vous feriez :

$ tcpdump host 10.0.0.1 and port 80

Vous pouvez utiliser ngrep récupérer un paquet particulier :

$ ngrep 'GET' 'host 10.0.0.1 and port 80'

Dans les options les plus utiles on trouve :

  • -O pour sauvegarder les paquets et les analyser ensuite, par exemple avec wireshark
  • -x pour dumper la version hexadécimale du paquet (pratique pour un protocole binaire)
  • -X pour matcher sur la version hexadécimale du paquet (pratique pour un protocole binaire)
  • -K1 pour tuer la connexion en envoyant un paquet RST à la source du paquet en question (pas de garantie 100% avec cette méthode :)

Et un exemple pour la route pour couper la connexion de celui qui dirait du mal de vous sur un serveur irc :

$ ngrep -K1 'peck sux' 'dst 10.0.0.1 and dst port 6667'

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é : tcpdump, wireshark

Espionnage

Tout le monde le sait, les téléphones nous espionnent. Mais que communiquent-ils ? A qui communiquent-ils ? Que peut-on y faire ?

Aujourd'hui nous somme armés d'une vraie distribution GNU. Nous pouvons donc utiliser des vrais outils.

# on se connecte sur le téléphone
$ ./adb shell
# mettez votre debian dans ce $ROOT
$ chroot $ROOT
$ apt-get install tcpdump
$ nohup tcpdump -i any -s 0 -w /tmp/dump.`date +"%Y-%d-%m"` &

maintenant déconnectez-vous et laissez tourner toute la journée dans son coin après avoir vérifié qu'il reste de la place sur le disque.

Quelque temps plus tard; :

# sur le téléphone
$ chroot debian
$ pkill tcpdump
# sur le pc
$ ./adb get $ROOT/tmp/dump.*

Analyse

Maintenant revenons à notre poste et regardons ce qui s'est passé. Pour cela on utilise wireshark.

On ouvre le fichier dump et c'est parti :

  • on trie par protocole -> LARQ, DNS, ipv6, http, https, ...
  • on trie par adresse -> on a la liste de qui communique avec notre machine
  • on liste des requêtes dns -> on a les noms des précédents

Ce que j'ai découvert pour l'instant

LARQ (limited automatic repeat request) : protocole utilisé pour la retransmission rapide de frame en cas de perte sur la couche de liaison. Très pratique pour améliorer la qualité des transmissions. On ne trouve quasiment pas d'infos sur le net à ce sujet, à part un brevet.

IPv6 : il est activé par défaut chez moi, ouf

DNS : il semble qu'android utilise le resolver public de google (pratique pour ne pas être embêté par les limitations de l'opérateur et les problèmes de configuration).