Interception du trafic à mémoriser pour statistiques / analyse

Question

Je souhaite configurer une plate-forme de surveillance statistique pour surveiller un service spécifique, mais je ne suis pas sûr de savoir comment s'y prendre. Traiter les données interceptées ne me concerne pas, mais comment s'y prendre. Une idée était de configurer un proxy entre l'application cliente et le service afin que tout le trafic TCP soit d'abord acheminé vers mon proxy, le mandataire déléguant ensuite les messages interceptés à un thread / fork en attente pour transmettre le message et recevoir les résultats. L'autre était d'essayer de renifler le trafic entre le client et l'amp; service.

Mon objectif principal est d'éviter toute perte sérieuse de vitesse de transmission entre le client et application mais obtenez des communications complètes à 100% entre le client et l'amp; service.

Environnement: UBuntu 8.04

Langue: c / c ++

En arrière-plan, je pensais utiliser une base de données sqlite fonctionnant entièrement en mémoire ou un memcache dameon de 20-25 Mo asservi à mon processus.

Mise à jour:    Plus précisément, j'essaie de suivre l'utilisation des clés pour un démon memcache, en stockant le nombre de jeux / de succès / d'échecs sur la clé. L'idée est que la plupart des clés ont une sorte de caractère de séparation [`| _- #] pour créer une sorte d'espace de nom. L'idée est d'intervenir entre le démon et le client, de séparer les clés à l'aide d'un séparateur configuré et d'enregistrer des statistiques.

Answer 1

Vous n'avez pas mentionné une approche: vous pouvez modifier memcached ou votre client pour enregistrer les statistiques dont vous avez besoin. C’est probablement l’approche la plus facile et la plus propre.

Entre le proxy et l'approche libpcap, il y a quelques compromis:

- If you do the packet capture approach, you have to reassemble the TCP
  streams into something usable yourself. OTOH, if your monitor program
  gets bogged down, it'll just lose some packets, it won't break the cache.
  Same if it crashes. You also don't have to reconfigure anything; packet
  capture is transparent. 

- If you do the proxy approach, the kernel handles all the TCP work for
  you. You'll never lose requests. But if your monitor bogs down, it'll bog
  down the app. And if your monitor crashes, it'll break caching. You
  probably will have to reconfigure your app and/or memcached servers so
  that the connections go through the proxy.

En résumé, le proxy sera probablement plus facile à coder, mais son implémentation peut être une douleur royale, et il vaut mieux qu'il soit parfait ou qu'il supprime votre mise en cache. Changer l’application ou le memcached me semble être l’approche la plus saine.

BTW: Vous avez examiné les rapports statistiques intégrés de memcached? Je ne pense pas que cela soit suffisamment granulaire pour ce que vous voulez, mais si vous ne l'avez pas vu, jetez un coup d'œil avant de faire le travail réel :-D

Answer 2

Que voulez-vous suivre exactement? Si vous voulez un simple nombre de paquets ou d'octets, ou des informations d'en-tête de base, iptables l'enregistrera pour vous:

iptables -I INPUT -p tcp -d $HOST_IP --dport $HOST_PORT -j LOG $LOG_OPTIONS

Si vous souhaitez des informations plus détaillées, consultez la cible iptables ULOG , qui envoie chaque paquet à l'espace utilisateur pour analyse.

Voir http://www.netfilter.org pour des documents très approfondis .

Answer 3

Si vous voulez utiliser le renifleur, il serait peut-être plus simple d’utiliser tcpflow au lieu de tcpdump ou de libpcap. tcpflow ne produira que la charge TCP, vous n'aurez donc pas à vous soucier de réassembler vous-même le flux de données. Si vous préférez utiliser une bibliothèque au lieu de coller plusieurs programmes, libnids pourrait vous intéresser.

libnids et tcpflow sont également disponibles sur d'autres versions Unix et ne vous limitent pas à Linux (contrairement à iptables).

http://www.circlemud.org/~jelson/software/tcpflow/ http://libnids.sourceforge.net/

Answer 4

iptables fournit libipq , une bibliothèque de mise en file d'attente de paquets dans l'espace utilisateur. A partir de la page de manuel:

  

Netfilter fournit un mécanisme pour   passer des paquets hors de la pile pour   mettre en file d'attente vers l'espace utilisateur, puis recevoir   ces paquets dans le noyau   avec un verdict précisant quoi faire   avec les paquets (tels que ACCEPT ou   LAISSEZ TOMBER). Ces paquets peuvent aussi être   modifié dans l'espace utilisateur avant   réinjection dans le noyau.

En définissant des règles iptables personnalisées qui transmettent les paquets à libipq, en plus de spécifier leur verdict, il est possible d'effectuer une inspection des paquets pour l'analyse statistique.

Une autre option viable est de collecter manuellement les paquets au moyen du socket libpcap ou PF_PACKET avec le support socket-filter.