Packetbeat, un utilitaire Open Source d’Analyse de paquets

Dans la lignée des outils Open Source Gratuits et pratiques, voici un nouveau Venu : Packetbeat

1 ) Découverte de Packetbeat

opensource

Packetbeat s’installe sur un serveur Linux, et s’appuie sur 2 services connus et un peu « à la mode » :

Elasticsearch est un moteur de recherche très rapide base sur Apache Lucene. Il permet d’indexer rapidement beaucoup de données et y accéder en un temps record. On comprendra le besoin de ce dernier pour stocker de grandes quantités de données que sont les analyses de capture réseau.

Kibana permet de creuser dans ces quantités de données. Analyse de logs, Graph, data viz (data visualisation = l’art de grapher des données afin de les rendre compréhensibles).

L’agent Packetbeat s’installe sur la machine dont on veut écouter le traffic. Il est donc possible d’écouter le trafic interne (au sein d’un serveur web) ou de récupérer du trafic issu d’un mirroring de port.

2 ) Comment ça marche ?

Packetbeat servira d’agent collecteur de paquets. Il s’appuie sur libpcap afin de décoder les paquets entrants et calculer les métriques à partir des timestamp qu’il voit passer. Une fois ces métriques calculées, Packetbeat les envoie à Elasticsearch afin qu’il les enregistre.

à partir de la configuration qu’on lui donne, Il  ne se concentre que sur quelques services. Pas de mapping très évolué ici, on ne filtre que sur le port :

[protocols] 

[protocols.http] ports = [80, 8080, 8081, 5000, 8002]

[protocols.mysql] ports = [3306]

[protocols.redis] ports = [6379]

On se demande alors comment filtrer sur une ressource particulière dans le cas du mirroring de port ? Peut être est-ce prévu dans la Roadmap ?

Une fois l’agent installé et configuré, Il faut lui fournir un Elasticsearch à qui fournir des métriques :

3 ) L’installation

Je vous conseille de vous pencher sur l’installation d’ELK http://www.elasticsearch.org/overview/elkdownloads/

et ensuite d’installer Packetbeat sur le serveur Monitoré. Rien de bien difficile ici, si ce n’est l’habitude de la ligne de commande.

Pensez à bien installer les dashboards spécifiques à Kibana pour Packetbeat :

 $ curl -L -O https://github.com/packetbeat/dashboards/archive/v0.1.0.tar.gz
 $ tar xzvf v0.1.0.tar.gz
 $ cd dashboards-0.1.0/
 $ ./load.sh

Afin de voir apparaitre les 3 dashboards utiles  :

Capture d’écran 2014-05-26 à 18.25.33

4) Quelques captures d’écran

Packetbeat Search :

Se concentre sur la liste des appels HTTP réalisés auprès du serveur, avec les temps de réponse associés :

Capture d’écran 2014-05-26 à 18.26.28

Kibana permet alors de filtrer dans la liste des appels en ajoutant des filtres (GET, string contenu dans l’appel …)  :

Capture d’écran 2014-05-26 à 18.28.33

On voit alors apparaitre quelques surprises (eh oui ! w00t w00t ) Merci les scripts kiddies  :

Capture d’écran 2014-05-26 à 18.29.34

Une autre section des dashboards permet d’obtenir des temps de réponse moyens :

Capture d’écran 2014-05-26 à 18.50.43

Sur toutes les requêtes en appel au serveur.

On retrouvera la superbe vue Géographique de classement par IP :

Capture d’écran 2014-05-26 à 18.58.47

Un graphique représentant les requêtes :

Capture d’écran 2014-05-26 à 18.58.43

Sur du HTTP, la répartition des erreurs connues (400, 500) …

Capture d’écran 2014-05-26 à 18.58.36

Le type de contenu transféré :

Capture d’écran 2014-05-26 à 18.58.30

Et les requêtes lentes :

Capture d’écran 2014-05-26 à 18.58.23

5) Avis

L’avis après quelques jours d’utilisation est difficile à donner. Pour monitorer des temps de réponse sur un petit serveur WEB avec un service de type MySQL, pas de problème. On aura cependant vitre l’impression d’arriver au bout des métriques qui semblent pauvres : Il manque ici cruellement de métriques concernant le réseau, et le browser. Finalement, on se retrouve avec un analyseur de logs , de jolis graphiques mais peu de matière en vue diagnostiquer un problème de lenteur, sauf si cette dernière est applicative.

D’autre part, le manque de filtre sur l’adresse IP lors de la collecte de paquets montre ici ses limites : pas question de monitorer une ferme de serveurs, à moins de passer plusieurs heures à constituer plusieurs dashboard par serveur  / ressource concernée.

Je vois plutôt l’intérêt de Packetbeat en complément d’un Cacti bien configuré afin de relier des charges CPU / mémoire, des charges réseau, avec des temps de réponse dégradés pour pas cher. Mais pour une utilisation commerciale, ce n’est pas suffisant.

Une plateforme de Démonstration est disponible ici demo.packetbeat.com