Hardening your Mule Installation
As distinct from Security, hardening refers to the steps one must perform in order to bring an application from development into production. These are the hoops one must jump through in order to get something deployed in the IT space after development is completed.
Normally, an IT organization already has control of keeping open ports to a minimum, restricting access to administrative applications, minimizing the number of applications, and other housekeeping. Of course, the files used to configure Mule should be as secure as any configuration files.
Here is a list of simple steps you can take to begin harden the Mule installation itself:
Run Mule as a Non-privileged User
Install Mule as a Service
Make sure to configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files
In some situations, you will need to configure usernames, passwords and keystores on Mule. Usually, these settings are made available externally, so that dev/ops 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
On Xnix, you can run mule as any user with the following caveats:
You will need write perms to logs directory
Without root you will not be able to use ports below 1024
On Windows, you need to be in admin user’s group to run Mule
By its nature, Mule can be situated in a variety of configurations. That said, 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. Mule TCat Server also offers added security options.
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 (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. Furhermore, you can use a network IDS/IPS to monitor and prevent known attacks. Putting the database on an internal network - not the DMZ - will also help 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.