Harden Your On-Premises Mule Runtime Engine Installation
Harden on-premises runtime after Mule applications deploy successfully and before you use the instance in production. Run as a non-root user, install as a service, restrict file permissions, and configure TLS or FIPS. This is the Harden stage in On-Premises Runtimes Overview.
Use secure configuration files for passwords and keystores. Keep those files outside the Mule application archive when DevOps must change them without a redeploy.
Follow the Hardening Checklist
To begin hardening a Mule runtime engine installation that you are hosting on-premises:
-
Run Mule as a non-privileged User.
-
Install Mule as a Service.
-
Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.
-
In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.
-
Manage certificates in a keystore file.
-
Use a separate property file to store usernames and passwords, and secure it using file system permissions.
Run as a Non-Root User
Run on-premises Mule runtime engine as a non-root OS user. Root is not required except to bind ports below 1024. The runtime user must own $MULE_HOME and have write permission to the logs directory.
On Linux and Unix, you can run Mule as any user with the following caveats:
-
You need write permissions to logs directory
-
Without root you cannot use ports below 1024
On Windows, you need to be in admin user’s group to run Mule.
Harden in Layers
By its nature, you can situate Mule in a variety of configurations. The suggested approach to hardening involves hardening in layers beginning with the operating system, then working up the stack. The Center for Internet Security (CIS) publishes configuration benchmarks that are widely used in whole or in part as system hardening guides.
Commercial configuration management and integrity management tools can help you automate management to the CIS benchmarks. Also, Mule documentation includes a good deal of information on configuring security. If your application deals in sensitive data, consider using SSL Transport (HTTPS) to protect it.
On the network security side, security experts recommend using a good stateful inspection network firewall with a default-deny rule set and exceptions only for justified business needs. Also, any internet facing server belongs in a DMZ with strong default-deny egress rules on the firewall to prevent data exfiltration. Furthermore, you can use a network IDS/IPS to monitor and prevent known attacks. Putting the database on an internal network - not the DMZ - also helps to harden your installation.
Be sure your software developers are familiar with secure web application coding techniques. At the very least, they should be familiar with best practices to avoid common web app pitfalls, such as those listed in OWASP’s top 10 Project.