I've scoured the internet for clarity on how to effectively harden tomcat running on windows, but have come up empty handed. I'm assuming tomcat on windows is generally intended for development and not designed for production deployments, but please correct me if I'm wrong.
CIS benchmarks published for tomcat running on linux allude to changing the tomcat to startup as a user other than root and then recursively setting linux permissions more strictly on CATALINA_HOME, but I'm unable to translate all these linux specific permissions to the more complex windows permissions model. i.e I can't use chmod, I need to use cacls or xcacls to set permissions and permissions in windows are totally different than linux.
I think tomcat should be using a gMSA to startup the service and that the permissions should be set under CATALINA_HOME to be more strict for that service account, but cannot find clarity on exactly what to set. I'm seeking the guidance of tomcat wizards to please help guide me in the right direction because I feel that this is a critical first step in hardening tomcat service running on windows and don't want to advise changes that actually make tomcat more insecure than it already is running under local system.
My thought is that I'm not the only one with this question and I feel a genuine effort here will benefit more than just me in this community because there are plenty of people running tomcat on windows, even in production environments, which are insecure and need to be protected from malicious users.
Tomcat itself is pretty secure. However there are some basic considerations for security that are more or less OS-independent.
First and foremost is the generally-accepted stricture that an OS implementing a TCP/IP stack will not permit a non-privileged app to open and listen on any port numbered less than 4096. I think that whatever rationale originally justified this has been disproven, but nevertheless bot the Unix/Linux and Windows platforms do enforce it. That's one of the reasons why Tomcat's default http and https ports are 8080 and 8443, respectively.
It's really not good practice to run any application under a privileged (admin) user unless you absolutely have to and that's especially true when the app is directly connected to the Internet. Tomcat is no exception. Or perhaps is especially no exception since all of the apps and services in a Tomcat server are running in a single JVM, so once you crack into Tomcat, you effectively pwn everything inside it - and if it's running as admin/root, by extension, most of the rest of the OS/LAN/IT installation.
Web servers such as Apache have the same problem, but they avoid the security issue by changing their effective owner once the privileged work (opening the protected ports) is done. Tomcat is written in Java under write-once/run-anywhere rules and there's no OS-independent way of changing an app's userID, so instead the usual solution is to use a more secure service (such as Apache or IIS) run as a proxy server for Tomcat (technically, it's a reverse proxy. but only pedants will argue). So, for example, a copy of Apache runs listening to ports 80 and 443 and tunnels requests to Tomcat over port 8009 using one of its proxy modules.
When you do this, you can run as user "tomcat" (or whatever non-admin userID you like) and because you have no elevated privileges, a compromised Tomcat can do relatively little damage.
As far as filesystem rights go, the differences between Windows and Linux are mostly moot. Basically, the tomcat userID has to have file privileges equal to the greatest common denominator of both the Tomcat server itself and all of the apps and services that Tomcat contains, since they'll all be running under the same userID. If you want a webapp to write to some other user's directory, set that directory's ACL to permit userID tomcat to write to it. It's that simple.
Java apps aren't magic. The JVM looks to the OS just like any other application program, thus has the same rights and privileges and is subject to the same rules. Within the JVM, of course, there is a sandbox, although that's usually not a first-line security mechanism. Mostly any internal access control is managed by the applications themselves. That's true not only of files, but also things like database connections (since usually all users of a webapp are pulling Connections from a common pool and thus have the same database access rights).
Tim Holloway wrote:Almost forgot. One extra that the Windows distros of Tomcat includes is the extra stuff that allows you to run Tomcat as a Windows Service. When doing so, the service userID would be set to "tomcat" or whatever userID you select for the Tomcat server to run under.
When I do this what group would the user be part of? gMSA's on windows include things for regenerating random passwords for the user, so perhaps that would be better to use a service account. However what I'm really looking for is a definitive guide on what permissions to set under CATALINA_HOME after making the change to the windows tomcat service to no longer use "local system", which I've read is even worse than using local admin account. Something like this guide is what I'm after, but after reading through it, it's confusing me more than helping me on what windows permissions to actually set.
What I really want is something like this guide, but for windows telling me exactly how to set CATALINA_HOME file / directory permissions.
Thanks Much, I do really appreciate the feedback and help. I know everyone says tomcat can run everywhere, but it seems it's only truly secured on the linux platform and really could use some help trying to secure it on windows.
The tomcat user is a normal application user just like the one you sign in as.
The Windows Service Manager is fine with that.