You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Filippo Machi <fi...@gmail.com> on 2011/05/26 11:41:53 UTC
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
Posted by Pid <pi...@pidster.com>.
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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
Re: Issues with getRemoteAddress
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <aw...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues with getRemoteAddress
Posted by André Warnier <aw...@ice-sa.com>.
Filippo Machi wrote:
> On Fri, May 27, 2011 at 11:20 AM, André Warnier <aw...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues with getRemoteAddress
Posted by Filippo Machi <fi...@gmail.com>.
On Fri, May 27, 2011 at 11:20 AM, André Warnier <aw...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Issues with getRemoteAddress
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues with getRemoteAddress
Posted by Filippo Machi <fi...@gmail.com>.
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 <aw...@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 user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- A "Service" is a collection of one or more "Connectors" that share
a single "Container" Note: A "Service" is not itself a "Container",
so you may not define subcomponents such as "Valves" at this level.
Documentation at /docs/config/service.html
-->
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more
named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking &
non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
URIEncoding="UTF-8" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!--
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that
processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes
them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web
applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common"
-->
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b"
resolveHosts="false"/>
</Host>
</Engine>
</Service>
</Server>
>
>
> (*) 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="xxxxxxxx"> (where "xxxxxxx" 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.
Thanks for the advice, we're going to consider that. Even if the most
important thing to us is to understant what's going on
in order to be sure not to have heavier issues tomorrow, when the setup of
the production environment is completed and all
our application are migrated to the new environment.
bye
Fil
>
>
>
>
>
>
> 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 <
>> chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Issues with getRemoteAddress
Posted by André Warnier <aw...@ice-sa.com>.
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="xxxxxxxx"> (where "xxxxxxx" 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 <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues with getRemoteAddress
Posted by Filippo Machi <fi...@gmail.com>.
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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Issues with getRemoteAddress
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues with getRemoteAddress
Posted by Filippo Machi <fi...@gmail.com>.
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 <aw...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Issues with getRemoteAddress
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org