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 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 <
>> 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
>
>
