Lire dans les paquets

Niveau :
Résumé : ngrep ; net­sed ; tcp­dump | strings

Grep

Pour lire ce qui passe en TCP en fil­trer des mots clés vous avez plu­sieurs tech­ni­ques.

Com­men­çons par la tech­ni­que bour­rin, mais qui mar­che :

# on dumpe en gardant les data, dont on extrait les chaines de caractère
$ tcpdump -s0 -w - port 80 | strings | egrep "html|head"

Pra­ti­que et facile à mémo­ri­ser. Cette tech­ni­que per­met pas mal de cho­ses, mais est à con­si­dé­rer pour des ser­veur peu char­gés.

Ngrep

Ngrep lui, est capa­ble de vous sor­tir uni­que­ment les paquets dont les don­nées mat­chent une expres­sion. L’usage n’est pas for­cé­ment le même que le pré­cé­dent, ici on a un paquet com­plet :

$ ngrep "html|head" "port 80"

Pra­ti­que quand on est à la recher­che d’un paquet foi­reux, ou qu’on veut loguer ce qui ce passe pen­dant un pro­blème.

Sed

Un autre outil pour tes­ter une appli­ca­tion réseau, c’est net­sed (du paquet bien nommé). Une com­mande bien utile qui crée un proxy tcp ou udp capa­ble de modi­fier les paquets en direct.

Il ne fait ça qu’avec des expres­sions basi­ques :

# Attention pas de résolution de nom
$ netsed tcp 1080 1.2.3.4 80 's/Developpement/Production'
# Test 
$ telnet localhost 1080

Atten­tion, con­trai­re­ment à ce qu’on pour­rait croire, ce ne sont pas des vraies expres­sion sed, on est assez limité. D’autre part net­sed fonc­tionne sur des paquets, ce qui veut dire que dans un petit nom­bre de cas, il ne fait pas ce qu’on veut (don­nées à mat­cher répar­tie sur 2 paquets).

En fait, il faut pren­dre cet outil pour ce qu’il est, un outil de test et de debug. D’autant plus qu’il faut tou­cher au client pour le redi­ri­ger vers le port d’écoute de net­sed.