+1, j'avais pas pensé à celle-là tient ;) M'enfin, bloquer la session sur 1 IP (avec le roaming 3G toussa), faut être... enfin bon, bref :p
JB On 27/04/2011 23:29, Steven Le Roux wrote: > 2011/4/27 Jean Baptiste FAVRE <[email protected]>: >> 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/ >> > > > _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
