Security Guidelines for Production Deployment¶

Given below are the common security guidelines for deploying a WSO2 Micro Integrator in a production environment.

In addition, see the production deployment checklist and any other product-specific guidelines in the documentation.

Runtime-level security
OS-level security
Network-level security

Runtime-level security¶

Given below are the security guidelines for the Micro Integrator runtimes. Note that some of these guidelines are common to both runtimes, whereas some guidelines are runtime-specific.

Micro Integrator runtime security¶

Given below are the security guidelines for the Micro Integrator runtime.

Guideline	Details
Apply security updates	Apply all the security patches relevant to your product version. Use WSO2 Updates to get the latest security patches. See WSO2 Updates for details. Note the following: WSO2 releases security patch notifications monthly via the Support Portal. However, WSO2 issues patches immediately to customers if there are highly critical issues. WSO2 does not issue patches publicly for older product versions. Community users are encouraged to use the latest product version to receive all the security issues resolved until that particular product release. WSO2 Docker repository releases docker images with security fixes. Users with a subscription can fetch these docker images.
Change default keystores	Change the default key stores and create new keys for all the cryptographic operations. WSO2 products, by default, come with a self-signed SSL key. Since these keys are public, it is recommended to configure your own keys for security purposes. Consider the following guidelines when creating the keystores: Select a key size of at least 2048 bits. Use an SHA256 certificate. Make sure that WSO2 default certificates do not exist in any of the keystores in your production environment. For example, be sure to delete the default public certificate in the default trust store that is shipped with the product. See Creating New Keystores for information on how to create and configure your own keys.
Encrypt passwords in configuration files	WSO2 products use a tool called Secure Vault to encrypt the plain-text passwords in configuration files. See Securing Passwords in Configuration Files for instructions.
Change default ports	For information on all the default ports used by WSO2 Micro Integrator, see Default Product Ports. For information on changing a default port, see Changing the Default Ports with Offset.
Enable read-only access to external user stores (LDAPs etc.)	If your product runtimes are connecting to an external user store for the purpose of reading and retrieving user information, be sure to enable read-only access to that user store. See Configuring a User Store for the Micro Integrator runtime.
Always communicate (with external user stores) over TLS	All connections from your server to external databases, userstores (LDAP), or other services, should be over TLS, to ensure adequate network-level protection. Therefore, be sure to use external systems (user stores, databases) that are TLS-enabled.
Connect to data stores using a less privileged user	When connecting the server to external databases or user stores (LDAP), be sure to go through a user who does not have permission to change the data store's schema. Be sure not to use the root user of the data store because all permissions are generally granted to the root user.
Configure strong HTTP(S) security	To have strong transport-level security, use TLS 1.2 and disable SSL, TLS 1.0 and 1.1. The TLS protocol and strong ciphers are configured for the passthrough transport in the `deployment.toml` file. See the following links for instructions: Configuring Transport-Level Security Note the following: When deciding on the TLS protocol and the ciphers, consider the compatibility with existing client applications. Imposing maximum security might cause functional problems with client applications. Apply ciphers with 256 bit key length if you have applied unlimited strength policy. Note that unlimited strength policy is recommended. Also, consider the following factors when deciding on the ciphers: DES/3DES are deprecated and should not be used. MD5 should not be used due to known collision attacks. RC4 should not be used due to crypto-analytical attacks. DSS is limited to a small 1024 bit key size. Cipher-suites that do not provide Perfect Forward Secrecy/ Forward Secrecy (PFS/FS). GCM based ciphers are recommended over CBC ciphers.
Remove weak ciphers for PassThrough transport	Remove any weak ciphers from the PassThrough transport and ensure that the server does not accept connections using those weak ciphers. The PassThrough transport is configured using the `deployement.toml` file. See Disabling Weak Ciphers for instructions.
Increase Ephemeral Diffie-Hellman Key size	Before starting the server, open the product startup script ( `micro-integrator.sh` in Linux and `micro-integrator.bat` in Windows) and enter the following with the other Java properties: `-Djdk.tls.ephemeralDHKeySize=2048 \`
Disable client-initiated renegotiation	Before starting the server, open the product startup script ( `micro-integrator.sh` in Linux and `micro-integrator.bat` in Windows) and enter the following with the other Java properties: `-Djdk.tls.rejectClientInitiatedRenegotiation=true \`
Enable HostName Verification	Make sure that hostname verification is enabled in the product startup script ( `micro-integrator.sh` in Linux and `micro-integrator.bat` in Windows) with the Strict mode. That is, you need to enable the following parameter: `-Dhttpclient.hostnameVerifier=Strict \`
Verify super admin credentials	The user name and password of the super administrator of your Micro Integrator (the first administrator) is created by adding the following configuration to the `deployment.toml` file. When you go into production, be sure to manually check your user store and ensure that unwanted super admin records are removed. `[super_admin] username = "admin" password = "admin" admin_role = "admin" create_admin_account = true` Note that you can easily use the management API to add, update, and delete admins and regular users in the user store. However, the super admin users created from the `deployment.toml` file should be managed manually. See the following topics for instructions to correctly create your administrators and other users in the Micro Integrator. Configuring a User Store for the Micro Integrator. Managing Users for the Micro Integrator.
Enable log rotation and monitoring	Ensure that you have a relevant log rotation scheme to manage logs. Log4J properties for Micro Integrator can be configured in the `<MI_HOME>/conf/log4j2.properties` file. To roll the wso2carbon.log based on size, this guide can be used. See Monitoring Logs for details on how to configure logging details in WSO2 products.
Prevent Log Forging	Log forging can be prevented by appending a UUID to the log message. Read about configuring logs in the Micro Integrator.
Set appropriate JVM parameters	The recommended JDK version is JDK 11. See the installation pre-requisites for more information. Tip: To run the JVM with 2 GB (-Xmx2048m), you should ideally have about 4GB of memory on the physical machine.

OS-level security¶

This section provides the list of OS-level security guidelines for your production environment.

Guideline	Details
Run WSO2 processes with a specific OS-level user	Use a separate OS-level user to run WSO2 products. Make sure that the user is only granted the permissions required for running the product for that particular user. Do not use the root/administrator user of your OS because the root/administrator is granted all privileges by default.
Minimize software to avoid vulnerability	Make sure that you only install the software/packages that are relevant to your WSO2 product's deployment. Also, continuously monitor the software that you install. For information on the minimum software that your WSO2 product will need, see Installation Prerequisites.
Enable the Firewall	Enable a firewall at the OS level (for example, iptables). This will provide protection for inbound and outbound connections of your WSO2 product. Make sure that you only open the required outbound and inbound ports from the OS-level firewall.
Restrict access to TCP ports used for clustering	Apply a firewall at the host-level to disallow access to TCP ports used for clustering (port 4000, 4001, … by default) from unrecognized hosts. These ports should be accessible only from other members of the WSO2 product cluster.
Use Secure Shell(SSH)	Use Secure Shell (SSH) when interacting with servers and executing commands. Adhere to the following best practices when you configure SSH: Change the default SSH port to a higher value. Disable the root or administrator. Enable login with user keys. Display a legal banner or a security banner with security warnings before SSH authentication.
Keep the system up-to-date	If there are security updates available for the packages installed in your OS (including the Java runtime), be sure to perform the necessary testing in a staging environment, and then proceed to install them for your OS.
Monitor user activities	Monitor the activities of your OS users. You can do this by enabling OS-level logs and by reviewing them regularly. You can also set up a centralized log monitoring system for this purpose.
Make regular backups	Make sure to back up important files and archive them continuously. For more information, see Backup and Recovery Recommendations.

Network-level security¶

This section provides a list of security guidelines for configuring the network.

Guideline	Details
Create a failover setup	In the cloud native deployment, high-availability should be achieved via the container orchestration system (e.g., Kubernetes ). In a VM deployment, there should be at least two nodes with the failover configuration. When your servers are clustered, you need to regularly monitor the health of your server instances. For example, you need to monitor resource-level factors such as the server's resource utilization, response time anomalies, and the number of incoming network connections. Server monitoring will help you identify when additional server instances (failover instances) are required. You can also make decisions about network routing changes that you need to do in order to avoid server downtime.
Maintain network-level logging	Be sure to maintain and monitor logs for your proxy servers, load balancers, and other network devices.
Check open ports and services	Periodically check for open ports using port scanning tools and make sure that only the necessary ports are open to both internal and external networks. Be sure that only the ports relevant to your WSO2 products are open for communication. If there are other ports started, be sure to monitor them. For the full list of ports in all WSO2 products, see Default Product Ports.
Configure device-level security	All your network devices should be periodically checked for anomalies. For example, you need to verify routing tables and firewall rules. Also, make sure that the default credentials are changed before the first use of those devices.
Apply firmware updates	Firmware updates for your network devices should be applied regularly.
Note:This security guideline is applicable to the MI runtime. Block the `/services` and `/carbon` contexts from the DMZ	Access to the "/services" and "/carbon" contexts should be blocked from the DMZ level (i.e., from the proxy server, load balancer and/or firewall). The "/services" context is used in WSO2 products to expose admin services. These admin services are used for performing administrative operations using SOAP requests. The "/carbon" context is used in WSO2 products to expose the management console (administration console) of the product. The management console is a user interface for performing some of the administrative operations of a product. In addition to the "/services" and "/carbon" contexts, be sure to expose only the required applications in your product to users beyond the DMZ level in your network. Note: It is recommended to use an allowlisting approach when allowing access to resources in your product from the DMZ level.