RemoteAddrValve and RemoteHostValve

[Zak Mc Kracken]

Hi all,

I'd like to filter incoming requests with this criterion:

if it's www.somewhere.com -> OK
else if it's 1.2.3.4 -> OK
else -> KO

Is it possible to do that by combining RemoteHostValve and
RemoteAddrValve? How? I simply tried to write them one after another,
but all is blocked, it seems they cannot be used together...

Thanks in advance for any help.

Marco.

[Robert Koberg]

Post by Zak Mc Kracken
Hi all,
if it's www.somewhere.com -> OK
else if it's 1.2.3.4 -> OK
else -> KO
Is it possible to do that by combining RemoteHostValve and
RemoteAddrValve? How? I simply tried to write them one after another,
but all is blocked, it seems they cannot be used together...

Why not a simple filter with request.getRemoteAddr()/
request.getRemoteHost() ?

-Rob

[Gregor Schneider]

What in the documentation
(http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html) is the
part you don't understand?

Rgds

Gregor

[Zak Mc Kracken]

Post by Gregor Schneider
What in the documentation
(http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html) is the
part you don't understand?

Thanks for replying. Maybe it's me, but what I gather from the
documentation is that it's not possible to combine the two filters as I
want, i.e.: telling a list of acceptance criteria and having all the
rest forbidden, or, vice versa, telling what is denied and having the
rest accepted. I was asking if I am missing something, cause if that is
the case, to me it's quite baffling.

Cheers.

Marco.

[André Warnier]

Zak Mc Kracken wrote:
[...]

Let's try this another way.

You want to allow requests from either www.somewhere.com, or one or more
IP addresses, and block all the rest.

First, filtering requests on the base of a DNS hostname is "expensive" :
it forces Tomcat to do a reverse DNS lookup. That is because when a
request comes in, it does not come in with a DNS name for the client,
but just with an IP address of the client. So Tomcat has to ask the DNS
system for the name (or names) that correspond to IP address a.b.c.d
(the client's address), and then match those names with the rule.
There is also a good chance that some clients have (of course) an IP
address and a DNS name, but their reverse DNS is not set up properly.
In that case, you would be denying clients that maybe you don't want to
deny.

What I'm getting at, is that if you want to accept requests from
"www.somewhere.com", you might already know the IP address (or the range
of IP addresses), that correspond to this name.
If so, then you can just use the Remote Address Filter Valve, and forget
about the Remote Host Filter Valve. And it will be much more efficient.

The second part is that for the Remote Address Filter Valve, both the
allow and deny attributes are regular expressions, giving you a lot of
flexibility in which addresses you allow or deny.

As a practical example :
Suppose that you want to allow requests from "www.somewhere.com", and
from any IP address in the range 112.23.90.0-112.23.90.255, and deny all
others.
You would first do a DNS lookup for the hostname "www.somewhere.com", to
get its IP address (nslookup www.somewhere.com).
Suppose this gives you "213.87.32.100".

Then you would configure your Valve as follows :

<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="213\.87\.32\.100,112\.23\.90\.\d{1,3}" />

Now suppose that, within the range 112.23.90.0-112.23.90.255 (which you
in principle accept), you want nevertheless to deny the subrange
112.23.90.21-112.23.90.30, then you would change the Valve as follows :

<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="213\.87\.32\.100,112\.23\.90\.\d{1,3}"
deny="112\.23\.90\.(2[1-9]|30)"
/>

If you do not understand the expressions above like
"112\.23\.90\.(2[1-9]|30)", then that is a question of "regular
expressions" which you need to look up, but it's not really something
specific to Tomcat.


Final note : if you accept/deny ranges of IP addresses, it is probably a
good idea to not deny requests from "localhost", if only just for
testing. So add "127\.0\.0\.1" to your accept range.

[Caldarale, Charles R]

Subject: Re: RemoteAddrValve and RemoteHostValve
What I'm getting at, is that if you want to accept requests from
"www.somewhere.com"

Post by Zak Mc Kracken
if it's www.somewhere.com -> OK
else if it's 1.2.3.4 -> OK
else -> KO

is ambiguous. It's very odd for a request to come *from* www.somewhere.com ...

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

[Zak Mc Kracken]

Thank you all for replies and detailed explanation. Now I understand
what's happening. My specific problem is restrict a single web
application to clients coming from localhost only. This was not working
(everything blocked):

<Context>
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="localhost"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1" deny="" />
</Context>

I am using a Mac and, after your replies, I tried to see what
request.getRemoteAddr() and request.getRemoteHost(). Well, it turns out
that they both return "0:0:0:0:0:0:0:1%0", so now everything works with:

<Context>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1,0:0:0:0:0:0:0:1\%0" deny="" />
</Context>


Moreover, André's reply is pretty convincing, although it seems to imply
that RemoteHostValve should be avoided (isn't DNS reverse lookup
cached?) and cannot be chained with RemoteAddrValve. Of course one can
do what you suggests, although this is a bit impractical in large
networks where one wouldn't like to care about IP changes of symbolic
names. Worse, I don't see what I could do to grant access to single PCs
in those LANs where users have fixed host names for their PCs, but
DHCP-assigned IPs (OK, maybe it's a theoretical case, I would probably
switch to user/password).

Cheers.

Marco.

[André Warnier]

Zak Mc Kracken wrote:
..., although it seems to imply

Post by Zak Mc Kracken
that RemoteHostValve should be avoided (isn't DNS reverse lookup
cached?)

Well, I suppose it probably is, at some level. At the level of the
Remote Host Valve possibly, if the designers thought about it, or else
at some underlying level.
But there can be other problems :
- not all clients really have a proper reverse DNS mapping by mere
sloppiness in their registration process. It is frequent to be able to
forward-resolve a hostname, but to get an "unknown domain" when trying
the reverse lookup of that IP address
- there are cases where it's not due to sloppiness, but to the sheer
difficulty/impossibility to do a proper reverse registration. One
example is when you have a variable IP address provided by your ISP, but
you arrange to re-register your hostname/IP whenever the IP changes,
with a service like dyndns.org. Someone trying to reach your server
through its hostname will succeed (because the forward mapping from
myhost.dyndns.org works), but when doing a reverse lookup they will get,
if anything, the canonical name that your ISP gives to this temporary
connection.

and cannot be chained with RemoteAddrValve.

This is nitpicking, but I don't think that they cannot be chained per
se. The problem in this case is to specify the attributes in a way that
makes sense, which in this case is rather difficult to say the least.
The problem is that each Valve operates independently, and either allows
or denies access absolutely, they do not cooperate.
It would in my view make a lot more sense to have a single Remote Access
Valve to which one could specify, in "allow" or "deny", a hostname
AND/OR an IP address expression. Like
<Valve className="x" allow="localhost,www.mydomain.com,192\.168\.1"
deny=".*\.badguys.com,10\.20\.30\.0" />
That's how it works in Apache httpd, and it seems to me to make a lot
more sense than these two separate Valves.

Of course one can

Post by Zak Mc Kracken
do what you suggests, although this is a bit impractical in large
networks where one wouldn't like to care about IP changes of symbolic
names.

True, but usually such networks have a specific range (or ranges) of IP
addresses. We have several customers like that.

Worse, I don't see what I could do to grant access to single PCs

Post by Zak Mc Kracken
in those LANs where users have fixed host names for their PCs, but
DHCP-assigned IPs (OK, maybe it's a theoretical case, I would probably
switch to user/password).

Yes, and in most cases you would then probably want to couple that with
some kind of SSO and automatic network authentication, à la jCIFS or
Jespa or Kerberos.
These access Valves are a first line of defense, and as far as the
Address Valve is concerned, a pretty effective one when applicable,
because it is difficult (and rather pointless) for someone to fake
someone else's IP address.
But you should not consider this as an authentication mechanism, since
after all anyone can be behind that workstation.

[Zak Mc Kracken]

Thanks again.

Post by André Warnier
It would in my view make a lot more sense to have a single Remote Access
Valve to which one could specify, in "allow" or "deny", a hostname
AND/OR an IP address expression. Like
<Valve className="x" allow="localhost,www.mydomain.com,192\.168\.1"
deny=".*\.badguys.com,10\.20\.30\.0" />
That's how it works in Apache httpd, and it seems to me to make a lot
more sense than these two separate Valves.

Yes, that would be useful. Maybe I'll find time to write something alike.

Cheers.

Marco.

[Gregor]

marc,
do i understand you correct that you only whant to accept requests
from "localhost"?
next: wouldn't authorization solve your problem?

rgds

gregor

Post by Zak Mc Kracken
Thank you all for replies and detailed explanation. Now I understand
what's happening. My specific problem is restrict a single web
application to clients coming from localhost only. This was not
<Context>
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="localhost"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1" deny="" />
</Context>
I am using a Mac and, after your replies, I tried to see what
request.getRemoteAddr() and request.getRemoteHost(). Well, it turns
out that they both return "0:0:0:0:0:0:0:1%0", so now everything
<Context>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1,0:0:0:0:0:0:0:1\%0" deny="" />
</Context>
Moreover, André's reply is pretty convincing, although it seems to i
mply that RemoteHostValve should be avoided (isn't DNS reverse looku
p cached?) and cannot be chained with RemoteAddrValve. Of course one
can do what you suggests, although this is a bit impractical in lar
ge networks where one wouldn't like to care about IP changes of symb
olic names. Worse, I don't see what I could do to grant access to si
ngle PCs in those LANs where users have fixed host names for their P
Cs, but DHCP-assigned IPs (OK, maybe it's a theoretical case, I woul
d probably switch to user/password).
Cheers.
Marco.
---------------------------------------------------------------------

[Zak Mc Kracken]

marc,
do i understand you correct that you only whant to accept requests from
"localhost"?

I have a Java web application that computes some data from an existing
Java-based infrastructure and output it as simple plain text. The output
is intended to be consumed by other PHP applications on the same server,
not by end-users.

next: wouldn't authorization solve your problem?

Yes, but localhost-only is simpler in my case.

Marco.

[Gregor Schneider]

Post by Zak Mc Kracken
Yes, but localhost-only is simpler in my case.

ehem, still not sure if i got you right:

you've been asking the valve-stuff because you want to limit the
access to requests coming from localhost only?
why then not make tomcat listen on localhost only? configuration for
that's a walk in the park...

rgds

gregor

[Zak Mc Kracken]

Post by Gregor Schneider
you've been asking the valve-stuff because you want to limit the
access to requests coming from localhost only?

Yep!

Post by Gregor Schneider
why then not make tomcat listen on localhost only? configuration for
that's a walk in the park...

My Tomcat is serving a number of webapps, I want to restrict access to
one only (the others are proper end-user-dedicated applications).
Furthermore, it's more modular if I can set up such restriction rules
into the app's WAR, rather than at Tomcat configuration level. So, it
should be as previously explained, or am I missing something?

Cheer.

M.

[Gregor Schneider]

Post by Gregor Schneider
you've been asking the valve-stuff because you want to limit the
access to requests coming from localhost only?

Yep!

Post by Gregor Schneider
why then not make tomcat listen on localhost only? configuration for
that's a walk in the park...

My Tomcat is serving a number of webapps, I want to restrict access to one
only (the others are proper end-user-dedicated applications). Furthermore,
it's more modular if I can set up such restriction rules into the app's WAR,
rather than at Tomcat configuration level. So, it should be as previously
explained, or am I missing something?

That wasn't clear to me.

Have you ever thought about fronting Tomcat with Apache HTTPD, then
connecting it via mod_jk?

Thus, Tomcat would listen on localhost only, and Apache HTTPD takes
care about forwarding appropriate requests to Tomcat on localhost.

Besides, you could use Apache's mod_authz
(http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html) to specify
the authorized ips / hosts.

Might be a little bit more work beforehand, but that would be my
preferred solution.

Rgds

Gregor

[Zak Mc Kracken]

Thanks Gregor, that's very interesting for production environments. I'll
try it.

Cheers.

M.

Post by Gregor Schneider

Post by Gregor Schneider
you've been asking the valve-stuff because you want to limit the
access to requests coming from localhost only?

Yep!

Post by Gregor Schneider
why then not make tomcat listen on localhost only? configuration for
that's a walk in the park...

My Tomcat is serving a number of webapps, I want to restrict access to one
only (the others are proper end-user-dedicated applications). Furthermore,
it's more modular if I can set up such restriction rules into the app's WAR,
rather than at Tomcat configuration level. So, it should be as previously
explained, or am I missing something?

That wasn't clear to me.
Have you ever thought about fronting Tomcat with Apache HTTPD, then
connecting it via mod_jk?
Thus, Tomcat would listen on localhost only, and Apache HTTPD takes
care about forwarding appropriate requests to Tomcat on localhost.
Besides, you could use Apache's mod_authz
(http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html) to specify
the authorized ips / hosts.
Might be a little bit more work beforehand, but that would be my
preferred solution.
Rgds
Gregor

[Caldarale, Charles R]

Subject: Re: RemoteAddrValve and RemoteHostValve
Have you ever thought about fronting Tomcat with Apache HTTPD, then
connecting it via mod_jk?

Are you serious? You want to add complexity and overhead just to control access to one webapp? Since a working <Valve> setup was already provided, why not just use that?

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

[Gregor Schneider]

Hi Chuck,

On Mon, Mar 2, 2009 at 3:07 PM, Caldarale, Charles R

 Since a working <Valve> setup was already provided, why not just use that?

Ehem - was it? I understood that there was one open issue that Zac
needed to combine a hostname and IP-adress - which was not possible
since both RemoteAdressValve & RemoteHostValve cannot be combined -
something with IPs via DHCP - or did I get that wrong?

Beside, setting up mod_jk is all that complicated - as long as you
know your Apache.

My prefered solution still would be AAA - however, according to the OP
that was not an option due to his requirements.

If the valve does everything the OP asked for - hey, go for it!

Sorry if I confused anyone here - will stop just "scanning" the
threads but read them properly - word of a boyscout!

Gregor

[Caldarale, Charles R]

Subject: Re: RemoteAddrValve and RemoteHostValve
I understood that there was one open issue that Zac
needed to combine a hostname and IP-adress

Early in the thread, someone pointed out that there's never any need to specify a host name, and, in fact, doing so increases overhead considerably. All that's needed is the set of IP addresses that are allowed to run this webapp, and configure the <Valve> inside the <Conext> of interest.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

[Zak Mc Kracken]

Post by Gregor Schneider
What in the documentation
(http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html) is the
part you don't understand?

Thanks for replying. Maybe it's me, but what I gather from the
documentation is that it's not possible to combine the two filters as I
want, i.e.: telling a list of acceptance criteria and having all the
rest forbidden, or, vice versa, telling what is denied and having the
rest accepted. I was asking if I am missing something, cause if it works
as I got it from the docs, to me it's quite baffling.

Cheers.

Marco.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Christopher Schultz]

Zak,

Post by Zak Mc Kracken
if it's www.somewhere.com -> OK
else if it's 1.2.3.4 -> OK
else -> KO

You could always use our favorite urlrewrite tool:
http://tuckey.org/urlrewrite/

This can manage many criteria, "chained" or not.

- -chris

[Edward Song]

I'm always a few days behind the thread, but wanted to share.
If I had only known that I can configure the Valve at the Context level
(from Chuck's prior email).

Regardless, I recently wrote a java filter to filter IP's at the application
level, which replicates the valve functionality.
http://j2eewebprogrammer.blogspot.com/2008/12/filtering-ip-traffic-using-java-filter.html

HTH

On Mon, Mar 2, 2009 at 12:18 PM, Christopher Schultz <

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zak,

Post by Zak Mc Kracken
if it's www.somewhere.com -> OK
else if it's 1.2.3.4 -> OK
else -> KO

http://tuckey.org/urlrewrite/
This can manage many criteria, "chained" or not.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmsFQIACgkQ9CaO5/Lv0PC2mACdEmW+hq/u2W+jY7kgr9Md4Qhm
dBQAnRxW3YE+wsbX3Nabkauk513AtYpc
=DXBg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

[Christopher Schultz]

Ed,

Post by Edward Song
Regardless, I recently wrote a java filter to filter IP's at the application
level, which replicates the valve functionality.
http://j2eewebprogrammer.blogspot.com/2008/12/filtering-ip-traffic-using-java-filter.html

Does this filter provide capability not provided by urlrewrite?
(http://tuckey.org/urlrewrite/)

- -chris