2011/4/27 Jean Baptiste FAVRE <fr-...@jbfavre.org>: > 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.
Pour rebondir là dessus, même si leur proxy est niquel, puisque vous récupéré l'ip par laquelle il vient, (X-REAL-IP), est-ce que ce n'est pas votre serveur applicatif qui casse la session si l'ip change au cours de la session ? Ces utilisateurs sont peut être derriere un proxy qui load balancent deux accès internet... du coup l'ip peut changer une requete sur deux pour ceux là. > > 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 > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB <ste...@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
