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