2011/4/27 Jean Baptiste FAVRE <fr-...@jbfavre.org>: > +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
C'est encore une option dans certains forum (check ip ou comment s'emmêler les couches OSI :) )... > > JB > > > On 27/04/2011 23:29, Steven Le Roux wrote: >> 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/ >>> >> >> >> > > _______________________________________________ > 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/
