tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
Date Thu, 17 Dec 2009 10:55:40 GMT
Rainer Jung wrote:
> On 17.12.2009 10:02, André Warnier wrote:
>> Martin B. Smith wrote:
>>> On 12/16/2009 11:01 PM, Bill Barker wrote:
>>>> "André Warnier" <> wrote in message
>>>>> Martin B. Smith wrote:
>>>>>> Howdy!
>>>>>> I'm trying to ensure that only specific instances of Apache are
>>>>>> allowed to proxy requests into my Tomcat 5.5.28 instances.
>> ...
>>>> Yes, but if the OP wants to block all access to Tomcat, it is even
>>>> easier to just not have the worker configured on those Apaches that
>>>> shouldn't contact it.
>> That assumes that the OP has access to the Apache webservers he wants to
>> block. And it does not block an Apache webserver, controlled by someone
>> else, to insert the proxying statements to use the Tomcat.
>> That's why I was thinking of the "secret". This way, only the webservers
>> to which Bill gives the secret would be able to connect.
>> As a result, I'm guessing that the OP wants to restrict access to
>>>> certain webapps.
>>>> The good news is that with the AJP connector, request.getLocalName()
>>>> returns the name of the Apache server (as specified by the ServerName
>>>> directive), not the Tomcat server. And request.getLocalAddr() returns
>>>> the IP address of request.getLocalName() as it resolves on the Tomcat
>>>> machine. With that information it isn't hard to write a Filter that
>>>> does what you want. For the truely lazy, it would also be trivial to
>>>> copy RemoteAddrValve to LocalAddrValve and have it check localAddr
>>>> instead of remoteAddr.
>> Right. But this makes another couple of assumptions : 1) that the OP is
>> a Java programmer and 2) that he can insert a filter or a Valve into
>> Tomcat (as opposed to just being someone who can change some
>> configuration elements).
>> ...
>>> André, thank you for the suggestions. I had considered them, but wanted
>>> some additional, more specific protections without going to mod_jk.
>> In the meantime, I checked on the Apache forum.
>> Unfortunately, as it stands now, some AJP parameters can be set in
>> Apache via the "key=value" elements of ProxyPass and ProxySet, but
>> unfortunately it seems that "secret" is not amongst them.
>>> Bill, your post is a gem. Indeed, I can always use network ACLs and
>>> iptables and mod_jk, but I was really hoping to do mod_proxy_balancer.
>>> While there's some administrative separations between the programmers
>>> and the system administrators that prevent me from writing servlets on
>>> top of Tomcat, this is a nice tip.
>> All in all, I personally like Bill's "lazy" suggestion the best : create
>> another Address Valve that checks the local instead of the client 
>> address.
> It will be hard to find a workaround, that cannot be forged. If it is 
> more about administrative control and not so much about security, then 
> the getLocal* stuff might suffice, or you can add a request header via 
> mod_headers in Apache and check for that header in your Tomcat filter.
> Using the real IP address were the connection came from of course would 
> make it much harder to manipulate. I don't know how to do that at the 
> moment.

This is an interesting discussion, which maybe also ties into the other 
thread about detecting early that a client as gone away.

Just as a suggestion/question by someone who has no idea how the code is 
structured : how flexible is the <Connector> with respect to the Java 
Servlet Spec ?  How about doing this at the Connector level ?
After all, that one should be the first in line to know
a) where this connection is coming from
b) if the connection to the client is still alive

On the face of it (to me anyway), it just looks like moving some code 
from a Valve to the Connector, and maybe save the overhead of a Valve in 
the process.  Which Valve is Tomcat-specific anyway.

> mod_proxy_ajp doesn't support the "secure" attribute, not only per 
> documentation, but I also checked the source code.
Nice confirmation.  Thanks.

  Of course "secure" is
> only secure as long as you can't read the config files or sniff the 
> traffic. The same would be true for adding and checking a custom request 
> header.
Right.  But I believe that in this case, we can reasonable suppose that 
these Apache/Tomcat connections are over a relatively private channel, 
not over the Internet.  Otherwise, there is always the iptables/firewall 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message