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