Hi Christopher, Thanks for taking the time to respond; again much appreciated.
Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the "secret" configuration parameter for ajp like you suggested. Or maybe using a shared "secret" key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg > 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----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
