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 <
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
