Database Management
DPA Secure Configuration Guide: Best Practices and Recommendations
This article provides recommendations and best practices to ensure the security of your DPA deployment. It includes environmental best practices, enabling AES 256, disabling HTTP connector, disabling less secure protocols, using a CA server certificate, securing connections to monitored instances and the DPA repository, upgrading Tomcat or Java, mitigating a Slow HTTP DOS attack, preventing a Host Header attack, trusted certificate management, securing integration with external systems such as the mail server and the SolarWinds Platform, and securing user management and user sessions.
First published date
Last published date
Overview
Note: Also see the SolarWinds Security Statement.
This document is a guide to assist you in securing your deployment of Database Performance Analyzer (DPA) by providing environmental considerations, specific configurations, as well as information on some of the libraries DPA relies on as well as certificate management.
If you are also taking advantage of the DPA Integration Module for the SolarWinds Platform (self-hosted), please refer to the Secure Configuration for the SolarWinds Platform for further guidance.
Product section
Resolution
See the following sections:
- Environmental best practices
- Secure configuration options
- Enable AES 256 with custom passphrase
- Disable HTTP connector
- Disable less secure protocols
- Use a CA server certificate instead of the default one (self-signed)
- Configure password protection for DPA features that allow custom SQL
- CyberArk integration
- Encrypt the keystore password in the Tomcat server configuration file
- Secure connections to databases
- Configure Tomcat to minimize the risk of slow HTTP and Host header attacks
- Trusted certificate management
- Secure integration with external systems
- Secure user management and user sessions
Environmental best practices
-
Ensure you have installed the latest version of the SolarWinds® Database Performance Analyzer, including hotfixes and service releases.
Updates can be found at https://customerportal.solarwinds.com.
-
Maintain the latest host operating system, application, and network security updates.
-
SolarWinds recommends keeping DPA from being exposed to an untrusted network. If possible, protect remote access using VPN or SSH tunnel rather than placing the DPA server in a publicly accessible zone.
-
Disable unnecessary ports, protocols, and services on your host operating system and on applications, like databases. See port requirements at https://documentation.solarwinds.com/en/Success_Center/orionplatform/Content/core-solarwinds-port-requirements.htm#DPA.
-
Implement strict access control and auditing in your environment at operating system and network layers. Limit access to the Database Performance Analyzer servers to only those authorized persons who require access as part of their duties.
-
Make sure you restrict access to the DPA installation directory as much as possible. DPA servers store cached data and indexes locally on the file system under the installation directory. Configuration files, logs, and memory dump files should also be protected.
-
Also consider local disk encryption because DPA stores sensitive information about the databases it is monitoring.
-
Where possible, deploy DPA on its own server or VM. This assists in resource management.
-
Strongly consider integration with AD or LDAP for DPA authentication. See below for further information.
Secure configuration options
Enable AES 256 with custom passphrase
DPA uses these cryptographic options to control how it encrypts passwords. In order to achieve stronger security, the admin must input a custom passphrase and choose AES 256 encryption option.
These include passwords for the repository user, logins to monitored DB instances, logins to monitored VMware vCenter Servers and ESX Hosts, DPA custom users, as well as DPA alert and custom metric security.
To access these settings, choose Options > Administration > Password Encryption Settings. For more information, see DPA password encryption settings.
Disable the HTTP connector
In DPA 2023.2 and later, HTTP traffic is disabled by default, and HTTPS connections are required.
In earlier versions of DPA, to disable all insecure communication from clients, you need to disable the connector as described in Turn off HTTP traffic in DPA (Port 8123).
Disable less secure protocols
For some existing instances of DPA, older protocols can remain active for compatibility reasons. Plan a regular review of allowed protocols and adjust the configuration as described in Disable weak TLS 1.2 cipher suites in DPA
New installations of DPA 2021.1.1 and later have TLSv1.0 and TLSv1.1 disabled by default.
Server.xml: sslEnabledProtocols="TLSv1.2+TLSv1.3"
Use a CA server certificate instead of the default one (self-signed)
Generate your own certificate for the DPA server, or use one from a certificate authority and set it up in Tomcat (see Configure DPA to use a custom certificate for SSL/TLS). Make sure you follow any internal polices regarding certificate rotation.
Configure password protection for DPA features that allow custom SQL
DPA provides the functionality that allows users with administrator permission to insert custom SQL statements into metrics and alerts. Additionally, it provides database query tool that can be used by administrators to execute queries against the repository and monitored databases. In order to enable extra protection for these features and prevent unauthorized use, you can enable additional password protection. See Configure password protection for DPA features that allow custom SQL.
CyberArk integration
If your company uses CyberArk to store login credentials, you can configure DPA to authenticate using credentials stored in CyberArk.
Encrypt the keystore password in the Tomcat server configuration file
By default, the keystore password is stored as plain text in the Tomcat server configuration file used by DPA (DPA-install-dir/iwc/tomcat/conf/server.xml). This article describes how to store an encrypted keystore password that Tomcat can understand and decrypt when you start the DPA server in HTTPS mode. See Encrypt the keystore password for SSL/TLS in the Tomcat server configuration file used by DPA.
Secure connections to databases
Secure connections to monitored instances
-
Oracle
-
PostgreSQL
Choose Verify-full mode during instance registration to force the use of SSL and to verify the certificate provided by the instance (both chain and hostname check). For more information, see Register a PostgreSQL database instance and prepare for monitoring.
-
SQL Server
-
When using a JTDS driver, see SSL connections from DPA to SQL Server monitored instance.
List of available SSL values (http://jtds.sourceforge.net/faq.html):
request - SSL is requested; if the server does not support it then a plain connection is used.
require - SSL is requested; if the server does not support it then an exception is thrown.
authenticate - same as require except the server's certificate must be signed by a trusted CA. -
When using Microsoft JDBC driver, perform the same steps as above, but for Advanced Connection Properties > JDBC URL Properties, set:
"encrypt=true;trustServerCertificate=false"
-
-
Azure SQL Database and Azure Managed Instance
Perform the same steps as in the SQL Server article (SSL connections from DPA to SQL Server monitored instance), but for Advanced Connection Properties > JDBC URL Properties set:
"encrypt=true;trustServerCertificate=false "
-
Sybase
To encrypt the password when monitoring a Sybase instance, follow the instructions in SSL connections from DPA to SQL Server monitored instance.
-
MySQL
When you register the instance, specify the following in Advanced Connection Properties > JDBC URL Properties:
trustServerCertificate=true;useSSL=true
Note: With these settings, attempts to connect to the server can result in the following error if the certificate uses only the common name (CN) field:
tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead
To resolve this issue, see Add a subject alternative name to a MySQL server SSL certificate.
Secure a connection to the Repository
To secure a repository connection, to a MySQL repository server, complete the following steps:
- When you create the repository database, specify the following properties in Advanced Connection Properties > JDBC URL Properties. Or, if you have already created the repository database, edit the repo.properties file and add it to the repo.jdbcDriverProperties setting:
trustServerCertificate=true;useSSL=true - Edit the repo.properties file and add or update the following setting:
repo.clientSocketTimeout=180 - Restart DPA for the change to take effect.
To secure a repository connection, to other database types you can follow the same steps above for the monitored instance of the same type. To update, specify connection properties for repo.jdbcDriverProperties in the repo.properties file.
Configure Tomcat to minimize the risk of slow HTTP and Host header attacks
The following recommendations require editing the server.xml file and then rebuilding the Windows services or restarting DPA on Linux. If you plan to implement both recommendations, make all changes to the server.xml file before rebuilding or restarting.
Mitigating a slow HTTP denial of service attack
A slow HTTP attack is a type of denial of service (DoS) attack. The attacker opens HTTP connections on the web server and attempts to hold them for long periods by sending data very slowly. If an attacker occupies all available HTTP connections and holds them, the server cannot process legitimate connections.
To minimize the impact of a slow HTTP attack, complete the following steps:
-
Open the server.xml file in a text editor. By default, this file is in the following location:
<DPA installation>/iwc/tomcat/conf/server.xml
-
To reduce the amount of time that connections will wait before timing out, add the following parameters to each Connector element:
connectionTimeout="10000" connectionUploadTimeout="40000" disableUploadTimeout="false"
See “Timeout parameter descriptions” below for more information.
-
You can also set the following parameter to specify the maximum number of connections the server will accept and process at once:
maxConnections="600"
Note: You cannot use the server.xml file to specify the maximum number of connections the server will accept from the same IP address. Configure this in the firewall.
-
Do one of the following to cause the changes to take effect:
-
On Windows, recreate the Ignite PI Server service by running two batch files:
- C:\Program Files\SolarWinds\DPA\removeWindowsService.bat
- C:\Program Files\SolarWinds\DPA\createWindowsService.bat
-
On Linux, restart DPA.
-
Timeout parameter descriptions
-
connectionTimeout: After a Connector accepts a connection, this value specifies the number of milliseconds the Connector will wait to receive the first line of the message. A value of 10000 sets the connection timeout to 10 seconds.
-
connectionUploadTimeout: This value specifies the number of milliseconds a Connector will wait for a data upload to complete. A value of 40000 sets the upload timeout to 40 seconds.
Note: This value is used only if disableUploadTimeout is set to false. If disableUploadTimeout is set to true, the connectionTimeout value is used as the upload timeout value.
-
disableUploadTimeout: Setting this value to false allows you to specify a longer connection timeout for data uploads.
Preventing a Host header attack
Web servers can host multiple web sites or web applications on the same IP address. The purpose of the HTTP Host header is to identify which of these virtual hosts the client wants to communicate with. However, attackers can edit the Host header value and use it to inject harmful code.
When the Host header contains an unrecognized value, Tomcat routes the request to the default virtual host. To prevent requests with malicious content in the Host header from being routed to your DPA server, configure Tomcat to ignore all requests that are routed to the default virtual host. Only traffic with a legitimate value in the Host header will be routed to the DPA server. To do this:
-
Open the server.xml file in a text editor. By default, this file is in the following location:
<DPA installation>/iwc/tomcat/conf/server.xml
In the Engine element, define the default host and the DPA host, and add an Alias to specify each additional host name or IP address that can be used to identify this host. Requests will be routed to DPA only if the Host header contains a value from the Host name or Alias attributes.
In the following example, 10.10.10.10 is the IP address of the DPA server, and MyDPAServer is the host name of the DPA server.
<Engine name="Catalina" defaultHost="default">
<Host name="default" appBase="ignored" />
<Host name="127.0.0.1" appBase="webapps">
<Alias>localhost</Alias>
<Alias>10.140.66.235</Alias>
<Alias>WIN-BMI4I1HL4F7</Alias>
</Host>
</Engine>
-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.
-
Do one of the following to cause the changes to take effect:
-
On Windows, recreate the Ignite PI Server service by running two batch files:
- C:\Program Files\SolarWinds\DPA\removeWindowsService.bat
- C:\Program Files\SolarWinds\DPA\createWindowsService.bat
-
On Linux, restart DPA.
-
Trusted certificate management
Audit your trusted certificates
DPA stores trusted certificates used to connect to monitored database instances or LDAP Servers. There are two trust stores:
-
Java trust store cacert located under your Java folder structure <JDK_HOME>/lib/security/cacerts
-
DPA custom trust store located in <DPA_HOME>/iwc/tomcat/ignite_config/security/dpa-truststore.jks
Certificates Management is available through Options > Trusted Certificate Management. For more information, see View and manage trusted certificates.
Audit your certificate exceptions
During registration of a PostgreSQL database instance, if the database supplied a non-trusted certificate, you could accept the supplied certificate and store it as a database exception. You can review your DB exceptions in Options > Trusted Certificate Management > DB certificates.
For each PostgreSQL database, you can see assigned certificate as exception.
If you want to remove certificate exception (e.g., your database certificate is already signed by trusted certificate authority), make sure your trust store holds certification authority certificate.
Audit your DPA trust store settings
By default, DPA uses two trust stores – the Java trust store and the DPA trust store where LDAP and database certificates are imported.
It is possible to disable this additional trust store by pointing it to the Java trust store using the option listed below (more about the Java trust store and its location in the next section). After doing so, DPA will trust only certificates from the Java trust store.
If you want to keep using the DPA trust store but make it more secure, you can change its type, password, and location by specifying following properties in system.properties:
-
Location: com.confio.security.trustStore
-
Type: com.confio.security.trustStoreType
(The default is jks. To use pkcs12 set com.confio.security.trustStoreType =pkcs12.) -
Password: com.confio.security.trustStorePassword
Audit your Java trust store settings
The location of the Java trust store depends on the version of Java being used, but usually the default path is <JAVA_DIR>/lib/security/cacerts.
The location, type, and password of the Java trust store can be changed by specifying following properties in system.properties:
-
Location: javax.net.ssl.trustStore
-
Type: javax.net.ssl.trustStoreType
(The default is jks. To use pkcs12 set javax.net.ssl.trustStoreType=pkcs12.) -
Password: com.confio.security.trustStorePassword
Secure integration with external systems
Secure outgoing mail server
Follow the instructions in this document to set up a custom email server and avoid using the default one (owned by SolarWinds): SMTP mail server for outgoing email. During the setup, make sure you choose the port that supports encryption.
SNMP traps
DPA sends SNMP updates to SNMP traps. It is configured through Options > Contact Management > SNMP Contacts. (See Send SNMP traps from DPA alerts.) Make sure you use safe connection using community string. (See Enable SNMP Monitoring in SCOM.)
Secure connection to AD/LDAP
Follow the steps in Configure DPA to use Active Directory or LDAP and make sure you choose the port that provides a secure connection. When importing the trusted certificates, validate the information provided by the AD/LDAP server. For ports, follow the vendor recommendations.
For older DPA installations it is possible that hostname verification of LDAP certificates is disabled. To enable the hostname verification of LDAP certificates, specify the following in system.properties:
com.sun.jndi.ldap.object.disableEndpointIdentification=false
Orion or SolarWinds Platform integration
Communications between the Orion or SolarWinds Platform server and the DPA server use the HTTPS protocol. For further security improvements, see the Tomcat section.
Collecting anonymized product usage data
To help SolarWinds improve DPA, by default DPA collects anonymized data about how the product is used. DPA provides usage information to the SolarWinds Improvement Program (SWIP). DPA 2023.1 and later versions also collect usage information through the product analysis tool Pendo.
If your policy does not allow participation in improvement programs, follow these steps to disable participation in SWIP and disable data collection by Pendo:
-
Open Advanced Options. (See Set advanced DPA configuration options.)
-
On the System Options tab, set one of the following options to FALSE:
- In DPA 2022.4 and earlier: SWIP_OPT_IN
- In DPA 2023.1 and later: PRODUCT_BEHAVIOR_OPT_IN
Secure the login screen
By default, DPA provides additional information on the login screen. This is mainly to avoid issues during the initial use of the product. Advanced users who require stronger security can disable the display of this information on the login screen.
Hide login name, repository name, and DPA version on the login screen
-
Open Advanced Options. (See Set advanced DPA configuration options.)
-
On the System Options tab:
-
Set LOGIN_FILL_REPO_USER to FALSE.
-
Set LOGIN_SHOW_REPO_NAME to FALSE.
-
Set LOGIN_SHOW_DPA_VERSION to FALSE.
-
For information about recent changes to login screen defaults, see the DPA 2020.2 Release Notes.
Hide domain information (AD/LDAP only)
-
Open Advanced Options. (See Set advanced DPA configuration options.)
-
On the System Options tab, set LOGIN_SHOW_DOMAIN_NAME to FALSE.
Secure user management and user sessions
Delegate user management and authentication to integrated AD/LDAP
See Configure DPA to use Active Directory or LDAP.
SSO setup
The article Configure DPA for Single Sign-On (SSO) describes how to configure DPA for Single Sign-On in your domain environment. AD setup is the prerequisite for this configuration.
Access cards (CAC)
You can use a Common Access Card (CAC) to log in to Windows and DPA. Before using a CAC, configure DPA for AD, and then for SSO as described in the sections above. For more information, see DPA user authentication options.
Audit user logins to DPA
DPA user logins will now be logged to the dpa_access_log.log file in the <DPA_home>/iwc/tomcat/logs directory. For more information, see Log DPA user activity.
Ensure a limited number of users with admin role
DPA offers different roles (ReadOnly, CustomUser, UserManager, Admin) which limit users’ ability to view and edit DPA configuration and access to features (for example, Alerts and Reports). For more information, see DPA roles and privileges.
API token management
DPA has a public API that helps to automate your processes. In Options > API Refresh Token Management, you can generate tokens for access without your credentials. Set token expiration to a limited time based on your internal policy.
You can limit the default expiration period for refresh/access token in Advanced Options:
-
Set API_REFRESH_TOKEN_EXPIRATION. (The default is 90 days.)
-
Set API_ACCESS_TOKEN_EXPIRATION. (The default is 900 seconds.)
For more information, see Manage tokens used for authentication to the DPA API.
SameSite attribute settings
By default, the SameSite attribute is not set on the authentication cookie. To set the attribute, open <DPA_HOME>\iwc\tomcat\conf\context.xml and add the following inside the <context> element:
<CookieProcessor sameSiteCookies="lax"/>
Be aware that if DPA is integrated with Orion, you will have to manually authenticate to DPA when navigating from Orion.
Secure cookie attribute
The secure cookie attribute is enabled by default. DPA will protect the session cookie (JSESSIONID) and userName cookie with the Secure attribute. Additionally, the session cookie has the HttpOnly attribute set.
CSRF token
This is enabled by default. A valid CSRF token is required for each POST request to DPA.
Security headers
DPA sets the following headers to increase the security of each user session:
-
CSP: Content-Security-Policy
-
HSTS: Strict-Transport-Security with expiration set to one year (HTTPS only)
-
X-Frame-Options: DENY
-
X-Content-Type-Options: nosniff
-
X-XSS-Protection: 1; mode-block
Session expiration
By default, the DPA session expiration is set to 12 hours. To specify a shorter period for inactive user sessions to expire, adjust the com.confio.tomcat.session.timeout option in system.properties and restart DPA. The value is minutes of inactivity.