James, On 4/9/2020 12:11 PM, James H. H. Lampert wrote: > On 4/6/20 2:13 PM, Mark Eggers wrote: >> # Secure your proxy - localhost for now - this is IMPORTANT >> <Proxy "*"> >> Require ip 127 >> </Proxy> > > Dear Mr. Eggers: > > It seems I was right about how what you said about this, and what the > docs say about it, appeared to contradict each other: with that in the > VirtualHost with the ProxyPass and ProxyPassReverse directives, it > blocked all outside access through the proxy. > > Once I commented out those lines, I got proxied straight to the default > ROOT context. > > Then, when I reactivated the valve in the manager app, I found that I > was still able to get into it via the proxy, but not directly. > > I've now put this in >> <Proxy "https://qux.baz.com/manager";> >> Require ip xx.yy.zz.qq >> </Proxy> >> <Proxy "https://corge.bax.com/manager";> >> Require ip xx.yy.zz.qq >> </Proxy> > > where xx.yy.zz.qq is my office IP address. I could get in just fine. > Then I changed the IP address to something different, restarted my > browser, and I could still get in. I also tried it with "/*" on the ends > of the URLs, and with "/html" on the ends, and with "/html/*" on the > ends. I also went back to the original "*" on one of them, and it went > back to locking me out of everything. Something doesn't seem right here. >
I'll play with this a little later. Please note that when you change Apache HTTPD configurations you must restart Apache HTTPD. This is one of the reasons why I prefer mod_jk. I can change the mapped URLs on the fly without having to restart Apache HTTPD (albeit with some small hit to performance). The way that I have things set up for a client is to have a machine with two interfaces and use an <Alias> directive in server.xml. I then run an additional HTTP/1.1 connector and bind it to the internal interface only. The internal interface is protected by VPN with a two factor authentication. I could further protect the sensitive applications by using the remote address filter and restricting access to the management and build systems subnets. To access the manager application, you have to connect to the VPN, and then browse to the following: http://internal.dns.domain.com:port/manager/html This will will bring up a manager interface that is appropriate for: https://external.dns..domain.com and all the applications running there. This is mostly used by the client's internal Jenkins build system to publish applications to the appropriate Tomcat server. It can also be used by a JMX application for Tomcat monitoring. My urimapping.properties file contains lines like: !/manager|/*=worker_name !/jmxmonitor|/*=worker_name This blocks proxying the manager and JMX applications by mod_jk. This has been running in production since I set it up, and has survived both random script kiddie attacks and security audits by the client's customers. You could look at mimicking this behavior with mod_proxy by using an exclamation mark (not tested). Something like the following: ProxyPass /manager ! ProxyPass /jmxmonitor ! per the documentation here: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass Apparently, the documentation would recommend something like the following: <Location "/manager"> ProxyPass "!" </Location> <Location "/jmxmonitor"> ProxyPass "!" </Location> I think that the above is probably easier to read and more specific. Place the directives in the appropriate virtual host. You could also be more expressive with LocationMatch and regular expressions. Once this is done you could access the manager application directly by using the appropriate port and configuring AWS's firewall rules to allow your office IP address through the port. Again, I have not tried this since I use mod_jk. Again, please remember to restart Apache HTTPD after any configuration changes. . . . just my two cents /mde/
signature.asc
Description: OpenPGP digital signature
