Note: Mon souci est lié au fait que quand j’active le https (CONFIDENTIAL) au niveau du tomcat (car l’admin alteon n’a pas l’habitude du gérer la redirection https…), je n’accède plus au serveur (j’ai une page blanche et ça n’aboutit jamais)

Carlos

J'ai voulais faire ceci car on a un altéon et dès l'activation du https au niveau de tomcat… on n'accède plus au serveur. on y accède uniquement si on attaque le serveur par son adresse IP ou en localhost…
J'ai toujours le problème, je ne sais pas si c'est lié au fait que le xforward pourrait ne pas être activé au niveau de l'alteon… je n'ai pas accès à cette partie… j'ai demandé aux admin de me le confirmé.. au niveau des access_* logs acces, je vois que l'adresse du LBL et si je suis en localhost je vois bien 127.0.0.1…

Je lisais cet article et j’ai essayé d’appliquer cette procédure sur un tomcat 5.5.17 mais je bloque sur la notion de déploiement du .jar je pense.

Quelqu’un pourrait me dire s’il vous plaît comment je dois faire exactement? Le placer sur tomcat_home/server/bin ou bien tomcat_home/common/bin et redémarrer le service, cela ne doit pas suffire car je n’ai même pas par ex. des logs RemoteIpValve dans catalina.log

Merci par avance et je m’excuse de cette question si basique…

Carlos

Effectivement le but n’est pas de perdre de l’information mais d’en garder le minimum.

Je vais donc voir comment faire avec un module Apache (voir retoucher le mod_proxy) pour conserver uniquement l’IP client et supprimer les IPs des proxies après avoir tracé le tout dans l’access_log.

Merci .

Concernant l’extraction de la première ip, cette perte d’information me semble assez risquée.

Le premier problème que je vois est le « spoofing » de header « x-forwarded-for » :
Il faut s’assurer que le premier composant réseau qui manipule « x-forwarded-for » dans votre infrastructure écrase le header plutôt que de l’enrichir pour prévenir le spoofing « à la X-Forwarded-For Spoofer Firefox Plugin.

Il y a probablement d’autres risques si on continue le raisonnement.

J’imagine un compromis :
1. Vous dumpez le header « X-Forwarded-For » dans les logs d’un Apache avec LogFormat « %{X-Forwarded-For}i %l %u %t « %r » %>s %b » common ou équivalent si c’est autre chose qu’un Apache.
2. Dans votre couche applicative, vous remplacez la valeur du header « x-forwarded-for » par un « xforwardedFor = StringUtils.subStringBefore(xforwardedFor , ",")« . En java, ce serait un servlet filter de quelques lignes de code, en module apache (e.g. mod_perl) ou dans votre couche perl, il y a surement une solution. J’ai regardé rapidement mod_headers, ca ne me semble pas possible, je n’ai pas trouvé d’expression language ou équivalent pour manipuler la chaine de caractères.

Cyrille

Bravo pour cet article très instructif.

J’en profite pour te poser une petite question.

J’ai une application (Apache+Perl+Oracle) qui utilise le paramètre X-Forwarded-For pour tracer les utilisateurs qui se connecte. Le problème est lorsque ceux-ci passent par des proxies nous avons des erreurs (le champs qui stock les IPs dans l’application est trop petit et nous ne pouvons pas l’agrandir car il s’agit d’un fournisseur externe qui malheureusement fait la sourde oreille).

Sachant que le format du paramètre X-Forwarded-For est « client1, proxy1, proxy2″, aurais-tu une solution pour ne garder que « client1″ et supprimer le reste au niveau de l’Apache en frontal de l’application (Apache 2.0.52) ?

Dans tous les cas, bravo pour cet excellent blog

Je serai en vacances pour le JUG d’Octobre, je vous propose donc le JUG de Novembre .

Cyrille (Xebia)

Merci énormément pour ces explications que je garderai soigneusement sous le coude, la réponse s’y trouve.


La RemoteIpValve ne regarde le paramètre X-Forwarded-For que si elle fait confiance à l'adresse IP qui se connecte au Tomcat (ie l'@ ip du serveur web). Par défaut, seules les adresses en 10.*, 192.168.*, 169.254.* et 127.* sont reconnue comme de confiance.


En effet, l’adresse ip que Apache présente à tomcat est l’adresse publique du serveur, le fait de rajouter le paramètre internalProxies a tout de suite résolu le problème.
Pour info, je n’utilise pas de l’IP V6.

Un grand merci aussi d’avoir enrichi Tomcat avec cette valve très pratique.

PS : Bravo, votre dîner est offert au prochain JUG

Pouvez vous indiquer l’adresse IP que voit le serveur Tomcat ? N’utiliseriez vous pas par hasard IP V6 ? C’est une mauvaise surprise que j’ai déjà eu .

L’adresse IP que voit le serveur Tomcat apparait dans les logs générées par l’AccessLogValve ou en invoquant request.getRemoteAddr().

La RemoteIpValve ne regarde le paramètre X-Forwarded-For que si elle fait confiance à l’adresse IP qui se connecte au Tomcat (ie l’@ ip du serveur web). Par défaut, seules les adresses en 10.*, 192.168.*, 169.254.* et 127.* sont reconnues comme de confiance.

Si votre serveur web utilise une adresse IP qui ne fait pas partie de ces plages, vous devez la déclarer avec l’attribut internalProxies. Exemple si votre serveur web présente l’adresse 85.158.206.34 au serveur Tomcat :

<Valve
   className="org.apache.catalina.valves.RemoteIpValve"
   internalProxies="85\.158\.206\.34"
   remoteIpHeader="X-Forwarded-For" />

Pour aider au diagnostique, vous pouvez activer les logs de la RemoteIpValve en ajoutant dans $TOMCAT_BASE/conf/logging.properties la directive :

org.apache.catalina.valves.RemoteIpValve.level=FINEST

Les messages de log apparaitront dans $TOMCAT_BASE/logs/catalina.${date(yyy-MM-dd)}.log.

Si la RemoteIpValve ne fait pas confiance à l’adresse IP de votre serveur web, vous verez le message de log :

Sep 18, 2010 12:14:43 PM org.apache.catalina.valves.RemoteIpValve invoke
Skip RemoteIpValve for request /foo with originalRemoteAddr '85.158.206.34'

En revanche, si la RemoteIpValve fait confiance à l’adresse IP présentée par le serveur web, le message de log est du type

Sep 18, 2010 12:14:43 PM org.apache.catalina.valves.RemoteIpValve invoke
Incoming request /foo with originalRemoteAddr '85.158.206.34', originalRemoteHost='85.158.206.34', originalSecure='false', originalScheme='http' will be seen as newRemoteAddr='82.66.240.18', newRemoteHost='82.66.240.18', newScheme='http', newSecure='false'

Normalement, il y a assez d’informations pour débugger.

Cyrille (Xebia)

j’ai déclaré la valve dans mon server.xml
<Valve className="org.apache.catalina.valves.RemoteIpValve" remoteIPHeader="X-Forwarded-For"/>

J’utilise tomcat 6.0.26 et apache 2.2.9-10+lenny6 en mod proxy

Ayant fait un tcpdump je vois bien que apache renseigne la vraie adresse du client dans le header http : X-Forwarded-For cependant lorsque je fais request.getRemoteAddr() j’obtiens l’adresse ip de mon serveur au lieu du client.

Qu’est ce qui cloche ?

Merci pour cet article. J’ai essayé celà sur mon serveur de test et ça marchait.

Tout content je cours mettre en prod mon exploit, je fais un petit test question d’être sûr (on ne sait jamais) et là PAM ça ne marche pas. Pourtant j’ai la même config apache / tomcat entre la test et la prod

Je me suis cassé la tête dessus mais sans succès.

Si quelqu’un peut m’aider ou me donner des pistes, j’en serai très reconnaissant.

Merci

* Qui génère le redirect ? Tomcat ? Un serveur Apache ou équivalent en amont ?
* Si c’est Tomcat qui génère la 302 ? Le moteur Tomcat ? Comment le ferait-il ? La webapp ? Une Security Constraint dans web.xml ? Spring Security ? Url Rewrite Filter ?
* La requête 302 apparait-elle dans l’access log Tomcat ?

Cyrille

PS : par 302, j’entends l’ensemble des codes 3xx de redirection.

En revanche, je ne saisis pas votre point « sur les redirects générés lors de l’accès à un répertoire sans le / final ».

Qu’est ce qui ne marche pas ? L’identification du protocole http/https ou la résolution de l’adresse ip de l’appelant ?

Cyrille

Emmanuel.

Emmanuel.

Cyrille (Xebia).

Emmanuel.

Pouvez-vous essayer cette version xebia-tomcat-extras-tc55-1.0.0.jar destinée à Tomcat 5.x ?
J’ai testé avec Tomcat 5.5.28.

Cyrille (Xebia)

Je reproduis sur Tomcat 5.5.28. Je prépare une version pour Tomcat 5.5 juste pour vous .

Cyrille

Pouvez-vous vérifier que vous n’êtes pas victime d’un problème de repackaging astucieux de Tomcat par une distribution Linux comme décrit dans Since java.logging is the default commons-logging implementation in Tomcat, why is it not working in my Linux distribution? ?

Avez-vous un jar tomcat-juli.jar dans le répertoire $CATALINA_HOME/bin ? Si vous avez installé Tomcat 5 avec un RPM pour RHEL, la commande pour lister les fichiers installés devraient-être « yum list installed tomcat5« .

Si vous utilisez un Tomcat packagé par une distribution Linux, une solution plus radicale mais surtout dans l’esprit du produit est de la remplacer par une installation Tomcat standard téléchargée sur http://tomcat.apache.org/ .

Cyrille