[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: RemoteAddrValve and RemoteHostValve
From:       André_Warnier <aw () ice-sa ! com>
Date:       2009-02-28 19:41:20
Message-ID: 49A99360.9030401 () ice-sa ! com
[Download RAW message or body]

Zak Mc Kracken wrote:
..., although it seems to imply
> 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
> 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
> 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.


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

[prev in list] [next in list] [prev in thread] [next in thread]