Op 29 apr. 2015, om 17:48 heeft Christopher Schultz
<ch...@christopherschultz.net> het volgende geschreven:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Paul,
On 4/29/15 11:17 AM, Paul Klinkenberg wrote:
The reason I want to add the IP restriction in the valve, is to
make 100% sure that the request (for creating a new Tomcat context)
is indeed coming from the frontend webserver.
I think there are better ways to do this. Among them:
1. Firewall rule that only allows access to the AJP port from a
certain IP address/range.
2. Use of the "secret" configuration parameter for mod_jk/AJP connector
In production, we tunnel AJP from our web servers to our application
servers using stunnel, and stunnel connections are only allowed from
the range of IPs used by our web servers. Then, we actually have the
AJP connector listen on ::1 so nobody from the outside can connect to
us, except through such a tunnel.
This valve is a setup not just for me, where I could tweak server
settings and such, but for anyone who uses the mod_cfml connector.
It is installed by default by the Railo/Lucee installers
(getrailo.org <http://getrailo.org/> / lucee.org
<http://lucee.org/>)
It seems a little fragile, because it requires configuration beyond
what an installer can auto-configure for you (i.e. it has no idea what
the IP address of the web server(s) is(are)).
Therefor, I cannot rely on an incoming header, as it could
originate from anywhere. Also, a remote system could call the AJP
endpoint on the Tomcat server, with this JkEnvVar set to a spoofed
value. (if the port is not firewalled off course) So the problem
with both options is, that they cannot be fully trusted.
If you are that paranoid, you also can't trust the source IP address
in the IP header, so you are back to square 1: you can't trust
anything, so don't build your security around this lack-of-trust.
If I am able to find out where the AJP request came from, then I
can validate the caller.
The only way to check the caller would be to get ahold of the Socket
that Tomcat is using to communicate. That's not easily done, since
Tomcat wants to protect its sockets from code messing-around with the
state of those Sockets.
If you don't trust mod_jk to send you the right values, then you also
can't trust the REMOTE_ADDR value that is pointing to the "real"
client. Basically, it comes down to this: you either trust mod_jk or
not. If you don't, then all bets are off.
If you *can* trust mod_jk, then just forward an environment variable
using JkEnvVar: that technique can't be modified by the client
injecting an HTTP header or anything like that. But of course, you
still have to trust mod_jk and the connection the request came from.
This is what the firewall should be used for, IMO.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVQP1VAAoJEBzwKT+lPKRYkcwQAKEJ4L4xqd7h2TRoA0TaAZYk
MsnpJy9fKSOB+18jAgN8d1vcctV9+zabgRqT+BhK6rArc3RcaO4puLgNe2k3IduH
AMHXQARLyYFSH42q7cAFyiRV5jVhDdTKr+pEhKTNbXdwdoOxPQMknTpfK01ESPkA
kVAKWnT2GdLq9eo3nSGlTXyKJrBLNPa2LhHHQXmc/VaSIO6wFR3pEP/DkoOdU430
QVmDinvruNEvSSNf0ef8UTeBhLOYFb099GfIOFq57r46B5s63469yQCwRrCKK7c9
g89Xm8j44TI445nj1J7BpbHfwLZxFsKRVwln2MZ0RKxX7ow/Zs/teQj7FpG6pbr2
7RGPi7jn0bo5GVe15S8cQMhPt7144FwuO97dhzPPUD+Dqv6hXuuNO92uJbDjllCl
GW5pzhHqKZ7BJ54q6RZsreArz/PRE+Cih/fs+MhjmHy6W/Aj5HeOVF8aJmn4/KvZ
T+Ran+gsMCP6yJoT/kBUgUEF0UG2tCgMhS30x3g2y/aGokbeqOX4QND2PtEyz2Mh
9sX9wAfCDNmAtgZU5tGOVh4rKvA0CvZz8JUteOTL/ohgNBwUfkc4zYpYHbX6qwoV
N1BxwxRWA+gC931vmJFSrmwwBjbmaBoCVYwpyi+Yh6HPhOKWU+78S63qgXE15sqw
OCfKtYQalTmKga46o2gI
=Ee12
-----END PGP SIGNATURE-----
