A few weeks ago, I posted about some upcoming sessions I was giving on hardening your WebSphere and Open Liberty production environments. Those sessions are over and so I wanted to take a second to summarize what topics are covered in those sessions and then provide the links to the session replays that folks can watch for more information.
To start off with, hardening your Liberty production environment is about more than just hardening Liberty itself (although there are plenty of hardening tips that do apply to Liberty directly). Your application server is running inside an operating system such as Linux, Windows, or z/OS, and steps need to be taken to ensure that the operating system is secure. Your entire production environment needs to be protected from outside threats by firewalls, typically an external perimeter firewall and an internal firewall, which creates a demilitarized zone (DMZ) in between the two. Administrators need to understand what portions of their environment should run inside the DMZ versus what portions should run behind the internal firewall, and how to secure the links between the DMZ and the internal production environment. Finally, the application itself needs to be developed in a way that leverages Java EE security to define roles and fence off access to the application endpoints to only those users with an appropriate role.
To help address these areas, I presented two sessions over the past two weeks:
- Open Liberty Security Hardening Overview - Part 1: https://www.youtube.com/watch?v=HXACAMq-r-o
This session covers the first two areas that I just talked about, hardening the operating system that your application server is running in and hardening the network environment surrounding your production deployment.
Hardening the operating system environment primarily deals with file system permissions. Should you lock down the Liberty installation binaries so that only approved users can even run the server script? What users need access to a Liberty server's configuration files such as server.xml or jvm.options? You might be surprised to find out that files such as server.xml do NOT need to be writeable by the user ID that the Liberty server is running under; the server ID needs read access to its configuration files, but it does not need to be able to write to them. Making your server's configuration files read only doesn't necessarily directly prevent an attack, but it can mitigate the damage of other types of attacks. Assume, theoretically, that an attacker is able to come in over the network and inject arbitrary code that runs under the identity of the application server. Restricting the access that that identity has could limit the damage that such a theoretical attacker can do. Other topics that pertain to operating system hardening include disabling dynamic configuration and application updates, and choosing an appropriate user registry for your environment.
Hardening the network environment pertains to properly setting up firewalls to create a DMZ, and then choosing what runs inside the DMZ and what runs behind the internal firewall. In short, a Liberty application server should NEVER run in the DMZ. You can run appropriate network appliances such as Data Power or an F5 load balancer, or HTTP servers such as IBM HTTP Server or NGINX, inside the DMZ since those devices support features like rate limiting to address denial of server attacks. Incoming client requests should be terminated at one of those devices and proxied through the internal firewall to the Liberty application server. Other topics covered under network hardening include the use of TLS for all application traffic, use of mutual TLS if possible, and ways to prevent attackers from obtaining information about your server by restricting what headers are sent back to clients.
- Open Liberty Security Hardening Overview - Part II: https://www.youtube.com/watch?v=-EOCaSIH2s4
This session covers the last hardening area that I talked about previously - application hardening. Liberty implements the Java Enterprise Edition specification, which provides the ability to restrict access to application endpoints to certain defined "roles", and then to map those roles to actual users or groups. This session (which, by the way, is only about half the length of the first one) goes into how that is accomplished, either with flat files or via annotations, and provides some best practices for how to go about it, such as by defining an initial "Deny All" rule to deny access to all application endpoints. Other topics include an example of how to properly configure access to a form login, and a review of ensuring that your application can only be accessed over a secured connection.
For those interested in more detail, check out the sessions linked above! The first one is about an hour and the second one is half of that, so even those sessions can't go into extreme detail about every setting.
If you want the most complete information available, I'd recommend checking out the two white papers on this page:
https://community.ibm.com/community/user/wasdevops/blogs/james-mulvey1/2021/05/20/twas-security-hardeningFinally, if you have any further questions, please feel free to drop me a note at gpicher@us.ibm.com!
#WebSphere#Seurity#Liberty