| Historique des versions | ||
|---|---|---|
| Version 1.0 | Février 2001 | |
| Article sous licence GNU FDL | ||
L'adage dit que la curiosité est un vilain défaut. Si cela est parfois vrai dans la vie courante, il n'en va pas de même pour l'informatique et en particulier dans le domaine de l'administration réseau. Les manipulations qui vont être décrites ici permettent non seulement la détection d'un éventuel problème physique ou logique, mais également de repérer facilement des problèmes de sécurité trop évidents.
Les données circulent sur un réseau qui parcourt physiquement, sous la forme d'impulsions électriques, le media utilisé pour relier les machines. Chaque interface fait son travail en n'écoutant que les messages qui lui sont adressés de manière directe ou implicite. De la même manière, lorsqu'une interface envoie sur le réseau une information sous la forme d'un ou plusieurs paquet(s), cette expédition est faite à l'attention d'une machine bien précise. Ceci étant, il n'empêche que les impulsions électriques parcourent l'ensemble du réseau. Il est donc tour à fait concevable qu'une interface puisse écouter passivement tous les paquets qui passent.
Il existe un utilitaire sous GNU/Linux (et pour tous les Unix) qui permet de faire cette manipulation : tcpdump. Cet utilitaire, originellement écrit par Van Jacobson, Craig Leres et Steven McCanne, repose sur la bibliothèque libpcap. Cette dernière est une interface permettant la capture de paquets réseau. Il s'agit là de deux éléments logiciels Libres sous licence BSD. Nous baserons l'ensemble de cet article sur libpcap version 0.6.1 et tcpdump 3.6.1. Il est conseillé de régulièrement mettre à jour la bibliothèque et l'utilitaire pour plusieurs raisons : chaque version apporte son lot d'extensions et nous avons remarqué un problème de changement de mode de l'interface réseau.
Puisque nous parlons de mode de l'interface, précisons qu'en temps normal, l'interface ne s'occupe que des paquets qui la concerne. Il faut passer en mode "promiscuous" pour que la carte puisse "écouter" tout ce qui passe. Ne vous inquiétez pas, la libpcap fait cela pour vous.
Ce n'est pas un hasard si tcpdump est l'utilitaire le plus couramment utilisé pour ces manipulations. Il s'agit tout simplement du logiciel le plus complet et le plus performant en la matière. Commençons tout d'abord avec quelque chose de simple (notez que seul le root peut utiliser tcpdump pour des raisons qui vous paraîtront évidentes dans la suite de l'article) :
# tcpdump tcpdump: listening on eth0
Je vous fait grâce de la sortie générée sur un réseau d'une trentaine de machines accédant à Internet via une machine NAT :)
La commande utilisée ainsi, sans aucun paramètre, vous permettra tout simplement d'afficher toutes les informations relatives aux paquets qui circulent sur la première interface réseau. Ceci inclut TCP, UDP, IP, ICMP... et ce, pour tous les ports. Bref, vous pouvez avoir, selon le réseau, beaucoup de choses à lire. Heureusement, il est possible de filtrer pour n'obtenir que les informations qui nous intéressent.
Il est possible de sélectionner les paquets à "écouter" en fonction d'expressions. Ainsi, ne seront affichées / traitées que les informations pour lesquelles le résultat de l'expression est vérifié. Une expression est composée d'un mot clé suivi d'une valeur numérique ou autre. Ainsi, il est possible de classer les mots clés en catégories :
Si tout ceci ne vous paraît pas limpide, nous allons tâcher de clarifier cela avec quelques exemples :
# tcpdump src 192.168.0.1
Ici, les seuls paquets affichés sont ceux en provenance de 192.168.0.1. Nous pouvons également préciser nos préférences en ajoutant un critère :
# tcpdump src 192.168.0.1 and port 80
Là, le seul port qui nous intéresse est 80 (http). Si nous poussons le vice, nous pouvons spécifier l'ensemble des paramètres nécessaires :
# tcpdump src host 192.168.0.1 and dst host 212.208.225.1 and port 53 and udp
Voici une ligne complète qui ne laisse vraiment passer que les paquets qui nous intéressent, c'est à dire, en provenance de 192.168.0.1 vers 212.208.225.1, sur le port 53 en udp. Et ce qui nous intéresse ici, ce sont les requêtes sur le serveur DNS du provider Internet.
Pour faire vos tests, utilisez cette commande (adaptée à vos besoins) sur une console virtuelle et sur une seconde console, lancez une requête sur le serveur DNS (nslookup www.linux.org par exemple). Vous verrez alors apparaître des lignes ressemblant à ceci sur la première console :
tcpdump: listening on eth0 22:33:29.070616 raven.32778 > ns1.rmcnet.fr.domain: 47038+[|domain] (DF) 22:33:29.072863 raven.32779 > ns1.rmcnet.fr.domain: 45315+[|domain] (DF) 22:33:29.128966 raven.32780 > ns1.rmcnet.fr.domain: 47039+[|domain] (DF)
Pour poursuivre avec cet exemple, nous allons maintenant utiliser deux des options de la commande tcpdump. Attention, il s'agit d'options qui ne concernent en rien la composition des expressions de filtrage :
# tcpdump -x -X -s 0 src host 192.168.0.1 and dst host 212.208.225.1 and port 53 and udp
Nous avons demandé l'affichage du contenu des paquets au format hexadécimal et ascii (-x -X) et ce, quelle que soit leur taille (-s 0). Nous obtenons les informations désirées :
tcpdump: listening on eth0 20:30:39.189321 raven.32929 > ns1.rmcnet.fr.domain: 5314+ A? www.linux.org. (31) (DF) 0x0000 4500 003b 0000 4000 4011 ca00 c1fd d9b4 E..;..@.@....... 0x0010 c1fc 1303 80a1 0035 0027 213d 14c2 0100 .......5.'!=.... 0x0020 0001 0000 0000 0000 0377 7777 056c 696e .........www.lin 0x0030 7578 036f 7267 0000 0100 01 ux.org.....
Il s'agit de notre requête sur le serveur DNS. Nous pouvons bien sûr, inverser sourcers et destination pour obtenir la réponse du serveur :
20:40:51.479467 ns1.rmcnet.fr.domain > raven.32929: 38062 1/2/2 A 198.182.196.56 (136) (DF) 0x0000 4500 00a4 81b5 4000 f311 94e1 c1fc 1303 E.....@......... 0x0010 c1fd d9b4 0035 80a1 0090 7f6d 94ae 8180 .....5.....m.... 0x0020 0001 0001 0002 0002 0377 7777 056c 696e .........www.lin 0x0030 7578 036f 7267 0000 0100 01c0 0c00 0100 ux.org.......... 0x0040 0100 0014 7300 04c6 b6c4 38c0 1000 0200 ....s.....8..... 0x0050 0100 0211 e600 1102 4e53 0849 4e56 4c4f ........NS.INVLO 0x0060 4749 4303 434f 4d00 c010 0002 0001 0002 GIC.COM......... 0x0070 11e6 0010 034e 5330 0641 4954 434f 4d03 .....NS0.AITCOM. 0x0080 4e45 5400 c03b 0001 0001 0002 11e6 0004 NET..;.......... 0x0090 cff5 227a c058 0001 0001 0002 10bb 0004 .."z.X.......... 0x00a0 d0ea 0122 ..."
Ceci est, certes, un peu long, mais cela permet de constater combien tcpdump peut être utile. Vous en doutez ?
Nous voici dans le vif du sujet. Récupérer les paquets concernant les requêtes DNS est une activité certes amusante, mais peu informative. Nous pourrions également récupérer les paquets en provenance d'un serveur web et à destination d'un utilisateur sur le réseau local. Ceci est plus intéressant mais n'apporte rien sans un utilitaire d'analyse comme ethereal dont nous parlerons plus loin.
Penchons-nous donc sur un domaine plus intéressant et surtout, plus démonstratif : les accès à un serveur POP3. Comme nous l'avons fait pour l'exemple précédent, nous pouvons capturer le contenu de paquets à destination d'un serveur POP3
# tcpdump -X -s 0 dst host 192.168.0.10 and src host 192.168.0.1 and port 110 and tcp
Et voici le suprenant résultat :
20:51:50.690745 193.253.217.180.42034 > 193.252.19.209.pop3: P 0:11(11) ack 79 win 5808 (DF) 0x0000 4500 003f 0000 4000 4006 c939 c1fd d9b4 E..?..@.@..9.... 0x0010 c1fc 13d1 a432 006e b862 482d 520a 6b11 .....2.n.bH-R.k. 0x0020 8018 16b0 c3cf 0000 0101 080a 00a9 c278 ...............x 0x0030 0bfa 1f75 7573 6572 206f 6b6b 690d 0a ...uuser.bidon.. 20:51:50.745300 193.253.217.180.42034 > 193.252.19.209.pop3: P 11:25(14) ack 84 win 5808 (DF) 0x0000 4500 0042 0000 4000 4006 c936 c1fd d9b4 E..B..@.@..6.... 0x0010 c1fc 13d1 a432 006e b862 4838 520a 6b16 .....2.n.bH8R.k. 0x0020 8018 16b0 33d0 0000 0101 080a 00a9 c27e ....3..........~ 0x0030 0bfa 1f7a 7061 7373 2079 746b 6b76 7875 ...zpass.coucou 0x0040 0d0a
La partie intéressante est bien sûr les deux derniers paquets. On lit clairement dans leur contenu ASCII les mentions "user.bidon" et surtout, "pass.coucou". En effet, dans la RFC 1725 décrivant le protocole Post Office en Version 3 (POP3), on découvre que les informations d'identification et d'authentification circulent de manière non chiffrée entre le client et le serveur.
Il serait possible en une seule journée de récupérer, grâce à tcpdump et un script Perl ou Awk, l'ensemble des noms d'utilisateurs et des mots de passe POP3 de toutes les personnes possédant un compte email dans une entreprise. Mais, dans la réalité, ceci est encore plus simple ...
Inutile de réinventer la roue, il existe déjà une application permettant de faire cela en toute simplicité, pour peu que l'on connaisse un peu la syntaxe utilisée par tcpdump. La version testée dans ces pages est la 0.8.15. Comme cette valeur l'indique, il s'agit d'une application encore en cours de développement. Mais l'étendue des fonctionnalités est déjà très impressionnante.
Ethereal est capable d'analyser les captures provenant bien sûr de tcpdump (qu'il est capable d'invoquer directement), mais également de plusieurs autres logiciels libres ou propriétaires (NetXray, Shomiti, snoop, LANalyzer, Lucent/Ascend ou même les logs pppd). En terme d'analyse, Ethereal est capable de complètement désassembler des paquets pour en tirer toutes les informations utiles. Inversement, Ethereal est en mesure de recomposer une transaction complète et d'afficher, par exemple, les résultats de n'importe quelle requête HTTP. De manière plus claire, il est quasiment capable de reconstruire les fichiers HTML qui ont transité sur le réseau, tout comme toutes les images, etc.