Analyse du trafic avec Debian Lenny

En utilisant mon appareil de surveillance réseau, nous avons remarqué un lien dans MRTG toujours sous forte charge. Sur ce lien, beaucoup de différents trafics s’agrègent, nous avons donc décidé d’analyser quelles quantités de protocoles et donc d’applications le trafic cumulatif consiste.

Comme vous pouvez le voir facilement, il y a beaucoup de trafic chaque jour sauf le week-end et les jours fériés.

Une application OSS qui pourrait faire cela est ntop. Extrait de www.ntop.org:

"ntop est une sonde de trafic réseau qui montre l'utilisation du réseau, similaire à ce que fait la commande top Unix populaire. ntop est basé sur libpcap et a été écrit de manière portable afin de fonctionner virtuellement sur chaque plateforme Unix et sur Win32 également. Les utilisateurs de ntop peuvent utiliser un navigateur web (par exemple, netscape) pour naviguer à travers les informations de trafic de ntop (qui agit comme un serveur web) et obtenir un aperçu de l'état du réseau. Dans ce dernier cas, ntop peut être vu comme un simple agent de type RMON avec une interface web intégrée."

Préliminaire et Avertissement

Veuillez être conscient que les droits légaux dans certains pays peuvent interdire de faire des choses comme celles mentionnées dans cet article, que vous ne violez pas les droits légaux. Soyez également conscient que la recette suivante décrit la manière dont nous avons mis en œuvre notre solution, je ne donne aucune garantie qu’elle fonctionne pour vous.

1. Le Lien

Le lien a une vitesse de 10 MBit/s et est une passerelle de routage entre 2 sites situés à quelques kilomètres l’un de l’autre. Un court calcul sur la quantité de données qui transitent par ce lien a donné le résultat qu’elle devrait être dans la plage de ~25 GigaOctets/Jour. D’un côté du lien se trouvent environ 2000 systèmes, de l’autre côté environ 200, et environ une douzaine de relations de communication entre les deux côtés qui nous intéressent. Plus tard, nous avons remarqué qu’environ 40 à 50 millions de paquets transitent par ce lien chaque jour de 7h à 17h.

Comme ntop analyse tout le trafic et montre les relations de communication, par exemple sous la forme de top-talkers et autres, nous avons supposé que ntop utiliserait beaucoup de RAM pour construire des tables sur toutes les relations de communication, nous avons donc pensé que la sonde devrait avoir autant de RAM que possible.

2. La Sonde

Nous avons décidé d’utiliser une vieille boîte inutilisée, de faire une installation minimale de Debian Lenny et de l’utiliser comme sonde ntop. Nous avons seulement fait une installation minimale car nous ne voulions pas gaspiller la précieuse RAM pour X11 ou d’autres applications inutiles, inutiles pour ce cas d’utilisation. Nous avons décidé d’utiliser Debian car il est facilement adaptable à nos besoins, et il est connu pour sa stabilité. Mais vous pouvez construire une sonde comme celle décrite ici avec n’importe quelle autre distribution Linux que vous connaissez, les *BSD peuvent également être une bonne base.

Nous avons décidé de placer cette sonde près du routeur qui gère ce lien, et de configurer un port miroir pour avoir accès à tout le trafic circulant sur ce lien.

Nous avons équipé la sonde d’une seconde NIC, car nous avons besoin d’une NIC pour la capture de trafic, et voulions pouvoir administrer la sonde à distance par SSH. La première NIC (eth0) a été configurée sans adresse IP, car elle est uniquement utilisée pour capturer le trafic du port miroir du routeur, et non pour effectuer une communication active. De plus, eth0 doit être mise en mode promiscuous (pour voir tout le trafic), ce qui est fait par libpcap. La seconde NIC (eth1), qui est utilisée uniquement pour l’administration à distance, a été configurée avec une adresse IP statique.

Heureusement, la vieille boîte utilisée comme sonde était équipée de 2 Go de RAM (ce qui était suffisant), d’un processeur AMD Athlon(tm) 64 Processor 3800+, et d’un disque local de 80 Go. Le disque a été partitionné de cette manière :

# fdisk -l

Disque /dev/sda: 80.0 Go, 80026361856 octets 255 têtes, 63 secteurs/piste, 9729 cylindres Unités = cylindres de 16065 * 512 = 8225280 octets Identifiant de disque: 0x37aa37aa Périphérique Démarrer Fin Blocs Id Système /dev/sda1 1 131 1052226 83 Linux /dev/sda2 132 162 249007+ 82 Linux swap / Solaris /dev/sda3 163 9729 76846927+ 5 Étendu /dev/sda5 163 9729 76846896 83 Linux

/dev/sda1 est une partition de 1 Go pour Lenny, /dev/sda2 une petite partition swap, et /dev/sda5 à utiliser pour les fichiers de capture. Les systèmes de fichiers sont ext3, mais xfs peut également être un bon candidat pour de si gros fichiers.

3. Rapport Hors Ligne

ntop est capable d’analyser le trafic en temps réel, ou il peut également lire des fichiers pcap pour une analyse et un rapport ultérieurs.

Nous avons décidé d’utiliser d’abord l’approche hors ligne, pour capturer le trafic sur le lien avec tcpdump de 7h à 17h par un court script shell piloté par cron, et de faire l’analyse dans un second temps.

Le script shell ressemble à un script d’initialisation Sys-V :

#!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin do_start() { ifconfig eth0 up; tcpdump -i eth0 -w /media/capture/`date +%F_%R`_tcpdump.pcap & } do_stop() { pkill -SIGTERM tcpdump; ifconfig eth0 down; } case "$1" in start) do_start 2>&1 ;; stop) do_stop ;; *) echo "Usage: $0 start|stop" >&2 exit 3 ;; esac

La capture de trafic de 7h à 17h produit des fichiers d’une taille d’environ 30 Go :

-rw-r--r-- 1 root root 32725662515 Jan 14 17:00 2020-01-14_07:00_tcpdump.pcap

La lecture d’un fichier de capture se fait par

ntop -m 10.80.192.0/18,10.81.20.0/24 -f /media/capture/2010-01-13_10\:30_tcpdump.pcap -n -4 -w3000 --w3c -p /etc/ntop/protocol.list

Pour une explication détaillée des commutateurs et paramètres de ligne de commande de ntop, veuillez consulter sa page de manuel, et les ajuster à vos besoins.

Vous pouvez ensuite examiner le rapport de ntop dans le navigateur web sur le port 3000 du système où ntop fonctionne.

4. Rapport En Ligne

Une autre possibilité d’utiliser ntop est que ntop lui-même capture le trafic sur eth0 et fait un rapport en ligne en temps réel, afin que vous puissiez voir ce qui se passe quelques secondes plus tard, et (avec le plugin rrd activé) obtenir de très jolis graphiques (conviviaux pour la gestion !) où vous pouvez zoomer avec votre souris.

5. Premières Conclusions

Comme prévu, nous avons vu qu’environ 70 % de tout le trafic était induit par un système, le Proxy Internet. Le trafic associé aux applications productives était dans la plage de 3 à 5 %. Pour aggraver la situation, ce trafic productif est associé à des applications interactives, comme Citrix, Telnet et SAP. Nous avons décidé que la prochaine étape devrait être de prioriser/structurer le trafic avec l’aide de (par exemple) diffserv, ou TOS mangling.

6. ngrep

Nous avons maintenant décidé d’analyser le trafic lié au proxy, quels sites Web seraient les plus visités. Une telle analyse plus approfondie n’est pas possible avec ntop, mais avec ngrep, il est facile de capturer uniquement le trafic qui (par exemple) va vers un système ou vient/va vers un port, ou beaucoup plus. Ngrep est également capable de rechercher des expressions dans la charge utile, donc la prochaine approche était d’utiliser ngrep pour capturer uniquement le trafic lié au Proxy Internet et l’analyser davantage.

Ceci se fait simplement par

ngrep -d eth0 host 10.89.1.17 -O /media/capture/snap.pcap

Inutile de dire que ce type simple de capture pourrait également être fait avec tcpdump.

Lorsqu’il est fait de 7h à 17h, cela pourrait produire un fichier d’environ 14 Go :

-rw-r--r-- 1 root root 14223354675 Jan 25 16:26 snap.pcap

Maintenant, ce fichier doit être analysé. L’idée est

lire le fichier avec tcpdump, le déverser dans stdout,
grep pour “get http://“,
couper le FQDN des sites,
jeter les entrées dupliquées qui sont en courtes séries (car elles peuvent appartenir à un clic dans le navigateur résultant en une ligne de get consécutifs),
et compter et trier ces données selon leur occurrence.

Cela pourrait être fait en plusieurs étapes en utilisant des fichiers intermédiaires, ou être une commande où plusieurs outils de ligne de commande sont pipés ensemble :

tcpdump -r snap.pcap -A | grep -i "get http://" | awk '/http/ { print $2 }' | cut -d/ -f1-3 | grep http | sed '$!N; /^\(.* \\1$/!P; D' | sort | uniq -c | sort -r > urls.txt

Cela prend un certain temps et vous obtenez un fichier trié par ordre décroissant de la fréquence à laquelle les sites trouvés dans le fichier de capture sont visités. Je ne suis pas sûr à 100 % si toutes nos hypothèses faites ci-dessus sont correctement traitées, mais les chiffres dans le fichier semblent réalisables.

13418 http://www.gxxxxx.dx 10184 http://www.gxxxxx-axxxxxxxx.cxx 8281 http://www.fxxxxxxx.dx 5470 http://www.bxxx.dx 4269 http://www.sxxxxxx.dx 2550 http://www.gxxx.cxx 2047 http://www.bxxxxxxx-zxxxxxx.dx 2044 http://www.fxxxxxxx.cxx 1618 http://www.exxxxxxx.dx 1410 http://www.lx-bx.dx ....

Une autre façon d’obtenir un rapport sur les sites Web visités serait d’interpréter le fichier journal du Proxy Internet, peut-être avec Calamaris (dans le cas de Squid ou d’un Proxy qui produit des journaux traitables par Calamaris). Sans un journal de proxy, je ne sais pas comment un tel rapport pourrait être produit.

Enfin, nous tenons à souligner que aucune information liée aux utilisateurs n’a été évaluée dans ce projet.

7. URL

Debian

Appareil de surveillance réseau

MRTG

Ntop

tcpdump + libpcap

RRD

ngrep

Squid

Calamaris

AWK 1 Liners

SED 1 Liners