Re: Issues with getRemoteAddress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filippo, On 5/27/2011 4:21 AM, Filippo Machi wrote: we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); Note that forward here does not return an HTTP response to the client: the forward is performed on the server. I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... No, this should not interfere. On Thu, May 26, 2011 at 7:12 PM, André Warnier a...@ice-sa.com wrote: And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactly what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve). If the request is (allegedly) coming from localhost but is instead looking like it's coming from the outside, how do you *know* that it's coming from localhost? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3lRooACgkQ9CaO5/Lv0PC0fACeIlxcrD7vmVxonF4yGoBHWEJA J1gAn2en+sra+FomSSatZclXINdPxZSj =K7QD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
Ciao Andrè, thanks for your answer! I really appreciate all the time you spend, thanks again. Please find my inline answers.. On Thu, May 26, 2011 at 7:12 PM, André Warnier a...@ice-sa.com wrote: Hi. First, tell us what precise version of Tomcat you are using (x.y.z format). we're using tomcat 7.0.12 Then, one minute I think that I am starting to understand your setup, but the next minute I am lost again. Sorry, maybe I wasn't clean enough, but it looks to me that you have quite a clear picture of our setup and issue The way I understand it now (please correct whatever needs to be) : 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : 85.214.x.x (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to 127.0.0.1:8080 - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). there are other clients (browsers) accessing serverA using the server name (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : something like 93.35.x.x (just an idea, to distinguish them from the above) And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) Or else, what is the problem precisely ? One more question : this IP-filter Valve, is that something written in-house ? Yes, we coded the filter. (At some point, we may want to see the content of the conf/server.xml of your Tomcat also. Make a copy, remove any sensitive information like exact IP addresses, passwords etc., and paste it directly into a message here. Do not paste it as an attachment, this list often strips them). As requested, but I don't think my colleagues change it too much since we're now setting up our production environment. ?xml version='1.0' encoding='utf-8'? !-- Note: A Server is not itself a Container, so you may not define subcomponents such as Valves at this level. Documentation at /docs/config/server.html -- Server port=8005 shutdown=SHUTDOWN !-- Security listener. Documentation at /docs/config/listeners.html Listener className=org.apache.catalina.security.SecurityListener / -- !--APR library loader. Documentation at /docs/apr.html -- Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / !--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -- Listener className=org.apache.catalina.core.JasperListener / !-- Prevent memory leaks due to use of particular java/javax APIs-- Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / !-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html -- GlobalNamingResources !-- Editable
Re: Issues with getRemoteAddress
Filippo Machi wrote: we're using tomcat 7.0.12 Ok. 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : 85.214.x.x (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to 127.0.0.1:8080 - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). there are other clients (browsers) accessing serverA using the server name (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : something like 93.35.x.x And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) One more question : this IP-filter Valve, is that something written in-house ? Yes, we coded the filter. I do not see anything particularly wrong in the server.xml which you sent. But it does confirm that you have a single Host in Tomcat. One additional question : The crontab PHP script sends a request to Tomcat from time to time. Is that request directed to a specific application that only the PHP script is using, or is that same application also used by other clients ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
On Fri, May 27, 2011 at 11:20 AM, André Warnier a...@ice-sa.com wrote: Filippo Machi wrote: we're using tomcat 7.0.12 Ok. 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : 85.214.x.x (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to 127.0.0.1:8080 - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). there are other clients (browsers) accessing serverA using the server name (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : something like 93.35.x.x And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) One more question : this IP-filter Valve, is that something written in-house ? Yes, we coded the filter. I do not see anything particularly wrong in the server.xml which you sent. But it does confirm that you have a single Host in Tomcat. One additional question : The crontab PHP script sends a request to Tomcat from time to time. Is that request directed to a specific application that only the PHP script is using, or is that same application also used by other clients ? Yes, we have only one web application used by all our clients, included the php script. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
Filippo Machi wrote: On Fri, May 27, 2011 at 11:20 AM, André Warnier a...@ice-sa.com wrote: Filippo Machi wrote: we're using tomcat 7.0.12 Ok. 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : 85.214.x.x (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to 127.0.0.1:8080 - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). there are other clients (browsers) accessing serverA using the server name (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : something like 93.35.x.x And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) One more question : this IP-filter Valve, is that something written in-house ? Yes, we coded the filter. I do not see anything particularly wrong in the server.xml which you sent. But it does confirm that you have a single Host in Tomcat. One additional question : The crontab PHP script sends a request to Tomcat from time to time. Is that request directed to a specific application that only the PHP script is using, or is that same application also used by other clients ? Yes, we have only one web application used by all our clients, included the php script. Mmm. That's a bit more complicated for what I had in mind. Would it be a problem to have 2 separate instances of that application (one for the PHP script, one for the other clients) ? I have little time now, but what I have in mind would be roughly as follows : - you add a second Host in your server.xml file, with a hostname of e.g. internal.company.com - for that second Host, you create a separate webapps directory, e.g. (tomcat_dir)/webapps2 - in that directory, you copy your application, e.g. as (tomcat_dir)/webapps2/yourapp/* (the same application name, and exactly all the same files, no changes) - in the local hosts file of your machine, you add the line 127.0.0.1 internal.company.com - you change your PHP script to access http://internal.company.com:8080; instead of http://127.0.0.1:8080; The rest later, I have to go now.. but think about it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issues with getRemoteAddress
Hi all, we're experiencing an issue with the getRemoteAddress method (HttpServletRequest). We don't know whether is something known depending on tomcat or if it's something malicious, affecting our servers. We have a filter that authorizes incoming requests using different patterns, one of these is based on ip checking. Requested performed by localhost are granted. Since we have an external service, installed on the same host running the tomcat, and this service invokes b2b requests on the tomcat istance (using 127.0.0.1), we noticed the following strange behaviour: sometimes requests are rejected since the ip obtained invoking the getRemoteAddress method results equals to 85.18.x.x. How can I say that? We considered both the log of the tomcat and the log of the external service described above and the content matches. I mean, each time this kind of failure occurs (it happened different times), the external service log the http response and, since the ip checking fails, it receives an html page, the login page! So, a request issued by a service running on localhost and sent as a get to a tomcat istance running on localhost appears to be issued from the ip address I mentioned above but we are sure that the client and the server are talking each other. This failure occurs periodically, at the same hour of the day. Besides, since we added some logs to have a better picture, we noticed that sometimes even during user interactions from external but known ips some requests appear to be issued by the address 85.18.x.x. Anyway, users are able to see web pages without any issues, since in this case their requests are authorized by a cookie and not by ip checking. Has anybody a clue of what is happening? Thanks in advance fil
Re: Issues with getRemoteAddress
Hi. In addition to what you explained below, could you explain the network setup ? In particular, are users always accessing the tomcat server directly, or through a firewall, and/or through a front-end like Apache httpd ? And what is this external service ? is that another webserver ? On what ports does all this run/listen/communicate ? Also, when you mention 85.18.x.x, is that literally 85.18.x.x, or did you just obscure the real IP address for privacy reasons ? and if so, when you say 85.18.x.x, does that mean that it is always the same IP address exactly, or do these last x.x vary ? I guess that what I am saying really is : your explanation below is rich in words, but relatively poor in real data, so it is a bit hard to give you real answers. Also, just as a tip : if the pages returned by Tomcat (or this external service) contain links, and these links are sometimes relative (e.g. a href=/img/logo.gif..) and sometimes absolute (e.g. a href=http://someserver.company.com/img/logo.gif;..), it may be that some user accesses take one route through the network, and other user acesses take another route, and this may explain why getRemoteAddress sometimes shows different addresses. Filippo Machi wrote: Hi all, we're experiencing an issue with the getRemoteAddress method (HttpServletRequest). We don't know whether is something known depending on tomcat or if it's something malicious, affecting our servers. We have a filter that authorizes incoming requests using different patterns, one of these is based on ip checking. Requested performed by localhost are granted. Since we have an external service, installed on the same host running the tomcat, and this service invokes b2b requests on the tomcat istance (using 127.0.0.1), we noticed the following strange behaviour: sometimes requests are rejected since the ip obtained invoking the getRemoteAddress method results equals to 85.18.x.x. How can I say that? We considered both the log of the tomcat and the log of the external service described above and the content matches. I mean, each time this kind of failure occurs (it happened different times), the external service log the http response and, since the ip checking fails, it receives an html page, the login page! So, a request issued by a service running on localhost and sent as a get to a tomcat istance running on localhost appears to be issued from the ip address I mentioned above but we are sure that the client and the server are talking each other. This failure occurs periodically, at the same hour of the day. Besides, since we added some logs to have a better picture, we noticed that sometimes even during user interactions from external but known ips some requests appear to be issued by the address 85.18.x.x. Anyway, users are able to see web pages without any issues, since in this case their requests are authorized by a cookie and not by ip checking. Has anybody a clue of what is happening? Thanks in advance fil - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
Ciao André! Thaks for your answer. Let me add some further info. The service I was talking about is a php script we put in the crontab and it accesses directly to the tomcat asking the url (127.0.0.1:8080/...) I'm omitting the final part of the ip just for privacy. There are just a little set of ips that seem to be involved in the scenario I described and they don't change. About the user interaction, we experienced the issue with some pages that are asked directly to the tomcat that is listening on the port 8080. I checked the jsp page and the css file we saw is asked by the ip is refereced by the page as follows link rel=stylesheet type=text/css href=/.../services.css Inspecting the access log of the tomcat I found that - 151.x.x.x - - [26/May/2011:06:56:59 +0200] GET /.../Terminal.jsp.. (this is the request of our user) - 85.18.x.x - - [26/May/2011:06:56:59 +0200] GET /fo/Service/css/services.css (this is a css included in the jsp above but it seems to be requested by another ip and this request is authenticated using a cookie) Thanks Fil On Thu, May 26, 2011 at 12:21 PM, André Warnier a...@ice-sa.com wrote: Hi. In addition to what you explained below, could you explain the network setup ? In particular, are users always accessing the tomcat server directly, or through a firewall, and/or through a front-end like Apache httpd ? And what is this external service ? is that another webserver ? On what ports does all this run/listen/communicate ? Also, when you mention 85.18.x.x, is that literally 85.18.x.x, or did you just obscure the real IP address for privacy reasons ? and if so, when you say 85.18.x.x, does that mean that it is always the same IP address exactly, or do these last x.x vary ? I guess that what I am saying really is : your explanation below is rich in words, but relatively poor in real data, so it is a bit hard to give you real answers. Also, just as a tip : if the pages returned by Tomcat (or this external service) contain links, and these links are sometimes relative (e.g. a href=/img/logo.gif..) and sometimes absolute (e.g. a href= http://someserver.company.com/img/logo.gif;..), it may be that some user accesses take one route through the network, and other user acesses take another route, and this may explain why getRemoteAddress sometimes shows different addresses. Filippo Machi wrote: Hi all, we're experiencing an issue with the getRemoteAddress method (HttpServletRequest). We don't know whether is something known depending on tomcat or if it's something malicious, affecting our servers. We have a filter that authorizes incoming requests using different patterns, one of these is based on ip checking. Requested performed by localhost are granted. Since we have an external service, installed on the same host running the tomcat, and this service invokes b2b requests on the tomcat istance (using 127.0.0.1), we noticed the following strange behaviour: sometimes requests are rejected since the ip obtained invoking the getRemoteAddress method results equals to 85.18.x.x. How can I say that? We considered both the log of the tomcat and the log of the external service described above and the content matches. I mean, each time this kind of failure occurs (it happened different times), the external service log the http response and, since the ip checking fails, it receives an html page, the login page! So, a request issued by a service running on localhost and sent as a get to a tomcat istance running on localhost appears to be issued from the ip address I mentioned above but we are sure that the client and the server are talking each other. This failure occurs periodically, at the same hour of the day. Besides, since we added some logs to have a better picture, we noticed that sometimes even during user interactions from external but known ips some requests appear to be issued by the address 85.18.x.x. Anyway, users are able to see web pages without any issues, since in this case their requests are authorized by a cookie and not by ip checking. Has anybody a clue of what is happening? Thanks in advance fil - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filippo, On 5/26/2011 8:22 AM, Filippo Machi wrote: The service I was talking about is a php script we put in the crontab and it accesses directly to the tomcat asking the url (127.0.0.1:8080/...) Okay: when you use 127.0.0.1, you should always be using the loopback address. That's good. If you were using a non-localhost hostname (like myserver.mydomain.it) then your remote address would likely appear to be the external IP address of the server because, well, that's just how TCP/IP works. I'm omitting the final part of the ip just for privacy. There are just a little set of ips that seem to be involved in the scenario I described and they don't change. Okay. Since they don't change, what is the relationship between the IP address you are observing and the network setup you have? Is 85.18.x.x the external IP address of the server? I wonder if your server is re-writing URLs in an HTTP response that are fully-qualified. So, instead of the URL being relative like /foo/bar it's being sent as http://myserver.mydomain.it/foo/bar; and so your client is therefore appearing to come from the server's external IP address. Simple question: do you trust 85.18.x.x? If so, why not just add it to the list of trusted IP addresses in your filter? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3eXgQACgkQ9CaO5/Lv0PCB/wCdGsDiCNV8rQz9u2JJixEmKEWd rwgAn0uXaBOuCwkZ6YiMLTaRk2+FzUm3 =dqU7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
Ciao Christopher, we don't trust 85.18.x.x., it doesn't belong to us, that's why I posted my question. We're not able to explain how is possible that a request from localhost to localhost appear to be issued from a different ip. Anyway, I'm going deeper following your hint about the rewrite. May we assume that a redirect will cause the same symptom? thanks Fil On Thu, May 26, 2011 at 4:04 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filippo, On 5/26/2011 8:22 AM, Filippo Machi wrote: The service I was talking about is a php script we put in the crontab and it accesses directly to the tomcat asking the url (127.0.0.1:8080/...) Okay: when you use 127.0.0.1, you should always be using the loopback address. That's good. If you were using a non-localhost hostname (like myserver.mydomain.it) then your remote address would likely appear to be the external IP address of the server because, well, that's just how TCP/IP works. I'm omitting the final part of the ip just for privacy. There are just a little set of ips that seem to be involved in the scenario I described and they don't change. Okay. Since they don't change, what is the relationship between the IP address you are observing and the network setup you have? Is 85.18.x.x the external IP address of the server? I wonder if your server is re-writing URLs in an HTTP response that are fully-qualified. So, instead of the URL being relative like /foo/bar it's being sent as http://myserver.mydomain.it/foo/bar; and so your client is therefore appearing to come from the server's external IP address. Simple question: do you trust 85.18.x.x? If so, why not just add it to the list of trusted IP addresses in your filter? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3eXgQACgkQ9CaO5/Lv0PCB/wCdGsDiCNV8rQz9u2JJixEmKEWd rwgAn0uXaBOuCwkZ6YiMLTaRk2+FzUm3 =dqU7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
Hi. First, tell us what precise version of Tomcat you are using (x.y.z format). Then, one minute I think that I am starting to understand your setup, but the next minute I am lost again. The way I understand it now (please correct whatever needs to be) : 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to 127.0.0.1:8080 - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : (just an idea, to distinguish them from the above) And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Or else, what is the problem precisely ? One more question : this IP-filter Valve, is that something written in-house ? (At some point, we may want to see the content of the conf/server.xml of your Tomcat also. Make a copy, remove any sensitive information like exact IP addresses, passwords etc., and paste it directly into a message here. Do not paste it as an attachment, this list often strips them). (*) If this is what happens, it is indeed bizarre, and it should never happen. It introduces a strong suspicion that there is something wrong with the Valve.. As a separate comment, not to mix with the above : In all generality, if your serverA is connected to the Internet, it is not surprising per se, that your server would receive from time to time a request, directed to the same URL as the one used by your PHP script, but coming from an external unknown IP. That happens all the time, as there are plenty of nefarious bots out there looking for server weaknesses all the time. But these external unknown IP clients should then receive the login page in return. If your PHP script receives this login page however, then it looks as if your IP-filter Valve may be mixing up its requests/responses. What is a bit scary there, is that it may also be sending responses to the external unknown clients, that were supposed to go to the PHP script. As a second separate comment : From what I guess of your setup, it looks like you could already improve your server management as follows : At the moment, it looks like in Tomcat you have one single Host tag. This Host is then automatically the default host, to which all requests go to be processed. So that means that anyone sending a request to the IP address of your Tomcat server (even if they do not know its proper DNS name), will get a response. If you would define a second Host name= (where xxx is the real DNS name of your server), then : - all requests that are properly addressed to that name, would be served by that second Host. That is where you would put your real applications (and still your Valve). - all requests which lack a proper name, will be served by the default Host. This default Host could then just return always a go get lost page. Most of the bots will just target the IP address of your server, so most of these requests will land on the default Host, and get that page. (Of course it could also be more restrictive, and /only/ accept requests from 127.0.0.1 e.g.) This is not really security yet, but it is an easy way to separate 90% of the trash, from the real requests. Filippo Machi wrote: Ciao Christopher, we don't trust 85.18.x.x., it doesn't belong to us, that's why I posted my question. We're not able to explain how is possible that a request from localhost to localhost appear to be issued from a different ip. Anyway, I'm going deeper following your hint about the rewrite. May we assume that a redirect will cause the same symptom? thanks Fil On Thu, May 26, 2011 at 4:04 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filippo,
Re: Issues with getRemoteAddress
On 26/05/2011 15:43, Filippo Machi wrote: Ciao Christopher, we don't trust 85.18.x.x., it doesn't belong to us, that's why I posted my question. We're not able to explain how is possible that a request from localhost to localhost appear to be issued from a different ip. If it's not one of your IPs why do you think that the request is definitely from an internal system, rather than an external one? p Anyway, I'm going deeper following your hint about the rewrite. May we assume that a redirect will cause the same symptom? thanks Fil On Thu, May 26, 2011 at 4:04 PM, Christopher Schultz ch...@christopherschultz.net wrote: Filippo, On 5/26/2011 8:22 AM, Filippo Machi wrote: The service I was talking about is a php script we put in the crontab and it accesses directly to the tomcat asking the url (127.0.0.1:8080/...) Okay: when you use 127.0.0.1, you should always be using the loopback address. That's good. If you were using a non-localhost hostname (like myserver.mydomain.it) then your remote address would likely appear to be the external IP address of the server because, well, that's just how TCP/IP works. I'm omitting the final part of the ip just for privacy. There are just a little set of ips that seem to be involved in the scenario I described and they don't change. Okay. Since they don't change, what is the relationship between the IP address you are observing and the network setup you have? Is 85.18.x.x the external IP address of the server? I wonder if your server is re-writing URLs in an HTTP response that are fully-qualified. So, instead of the URL being relative like /foo/bar it's being sent as http://myserver.mydomain.it/foo/bar; and so your client is therefore appearing to come from the server's external IP address. Simple question: do you trust 85.18.x.x? If so, why not just add it to the list of trusted IP addresses in your filter? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
