tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Issues with getRemoteAddress
Date Thu, 26 May 2011 17:12:00 GMT
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


Mime
View raw message