Le 27 avril 2011 21:59, Jean Baptiste FAVRE
<fr-sag@jbfavre.org> a écrit :
Bonsoir,
On 27/04/2011 11:37, Valentin Surrel wrote:
> Bonjour la liste,
>
> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau
> entre un client et nous. Problème, on a un frontal qui fait du SSL et
> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs
> d'application.
>
> Un moyen de trouver les requêtes que fait le client est de faire ça :
>
> ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
>
> 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer
> la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir
> d'option pour ceci dans ngrep.
>
> Auriez-vous des pistes à me suggérer (on peut très difficilement tout
> enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi
> impossible du fait de sa taille) ?
>
> Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4
> et ensuite de décoder le HTTPS ? (avec wireshark ?)
Je suppose que le cookie (de session ?) est généré (et donc géré) par
le(s) serveur(s) applicatif(s) et non par le reverse ?
1. Est-il envisageable de faire sauter le SSL entre le reverse et le
serveur applicatif ? Ce qui simplifierait l'écoute réseau.
2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le
flux est bien en SSL, est-il envisageable de forcer l'utilisation du
chiffrement null entre le reverse et le serveur applicatif ? Le flux
circulerait alors en clair bien qu'en SSL (négo toussa) ce qui
simplifierait l'écoute réseau.
3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement
juste pour ces utilisateurs là.
4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un
peu de ménage dans les headers, voire ajouterait ces propres cookies (de
mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la
requête pourrait être débarrassée du cookie de session.
5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il
possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise
le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Mes 2 cents,
JB