Bonjour, j'ajouterai à cela de vérifier que :
- le RP ne mets pas en cache des pages contenant un set-cookie (vérifier les etag, cache-control, pragma, expire & co le cas échéant supprimer ces entêtes). - le critère de load balacing en amont effectivement l'IP source parfois même le port source surtout avec des IP en sortie loadbalancée Je suis également partisan d'ajouter son propre header pour suivre par où est passé un session. J'ai déjà vu des équipement insérer leurs IP au début, au milieu et à la fin du header X-forwarded-For. Pour debuger tu peux également utiliser Charles Proxy ( http://www.charlesproxy.com/) que j'ai découvert récement et qui est très abouti Question quel est le reverse utilisé ? HTH Le 27 avril 2011 21:59, Jean Baptiste FAVRE <fr-...@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 > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
