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