Hi André, > Paul Klinkenberg wrote: >> 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 > > On Tomcat, you can set the AJP Connector to only listen on the local IP > address of the Tomcat server host. That means that only "local LAN" clients > (including the httpd front-end, presumably) can connect to that <Connector>. > So this already stops any external client (be it workstation or server) from > even connecting to Tomcat using AJP. > It also, presumably, insures that only your internal httpd front-ends can > potentially connect to Tomcat via AJP. > > Now if you do not even trust your internal servers/clients, /then/ you need > additional measures. But in such a case, whether you use a "secret" which the > front-end must provide, or whether you use an additional header or Jk > variable, is only a choice; but any of those requires some setup on the > front-ends. > > The same is for the other Connectors, like HTTP/HTTPS. If you do not want > people to connect through these, disable them or have them also only listen > on a local IP address.
Thanks for these tips. I see there are quite a few options to secure the AJP connector, which is great. For the project I am currently working on, I have to take into consideration that the user might already have Tomcat installed, and then probably with the default configuration. That would mean the AJP connector is available, and http connector as well. When someone now wants to add the mod_cfml valve to their setup, I will warn them in the install/config notes to lock down their tomcat server, if they haven't done so already. Next to this, I would like to be able to make the valve "secure by default", without having to rely on external settings. For this "secure by default", a required shared secret key seems like a solution to me. Remote users accessing either the http connector or ajp connector (only possible if the server is not firewalled), would need to have that key in order to get the valve to create a new context. I _do_ trust the internal servers/clients, I just want to make sure that if a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the weakest link to be able to hack the server. I hope that makes sense? 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 --------------------------------------------------------------------- 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
