Encrypting Manager to DB Communication

Communication between the Vulnerability ProtectionDeep Security Manager and the database is not encrypted by default. This is for performance reasons and because the channel between the Manager and the database may already be secure (either they are running on the same computer or they are connected by crossover cable, a private network segment, or tunneling via IPSec).

However, if the communication channel between the Vulnerability ProtectionDeep Security Manager and the database is not secure, you should encrypt the communications between them. Do this by editing the dsm.properties file located in \Vulnerability ProtectionDeep Security Manager\webclient\webapps\ROOT\WEB-INF\

If you are running the Deep Security Manager in multi-node mode, these changes must be made on each node.

Microsoft SQL Server (Linux)

To encrypt communication between the Deep Security Manager and a Microsoft SQL Server database:

  1. Stop the Vulnerability ProtectionDeep Security Manager service:
    # service dsm_s stop
  2. Edit /opt/dsm/webclient/webapps/ROOT/WEB-INF/dsm.properties to add the following line:
    database.SqlServer.ssl=require
  3. Under /opt/dsm, create a file named dsm_s.vmoptions that contains the following line:
    -Djsse.enableCBCProtection=false
  4. In the SQL Server Configuration Manager, enable "Force Encryption" in the protocol properties for the instance:

  5. Start the Vulnerability ProtectionDeep Security Manager service:
    # service dsm_s start

For additional information, see Enable Encrypted Connections to the Database Engine on the Microsoft MSDN site.

Microsoft SQL Server (Windows)

To encrypt communication between the Vulnerability ProtectionDeep Security Manager and a Microsoft SQL Server database:

  1. Stop the Vulnerability ProtectionDeep Security Manager service.
  2. Edit \Program Files\Trend Micro\Vulnerability ProtectionDeep Security Manager\webclient\webapps\ROOT\WEB-INF\dsm.properties to add the following line:
    database.SqlServer.ssl=require
  3. Under \Program Files\Trend Micro\Vulnerability ProtectionDeep Security Manager, create a file named Vulnerability ProtectionDeep Security Manager.vmoptions that contains the following line:
    -Djsse.enableCBCProtection=false
  4. In the SQL Server Configuration Manager, enable "Force Encryption" in the protocol properties for the instance:

  5. Start the Vulnerability ProtectionDeep Security Manager service.

For additional information, see Enable Encrypted Connections to the Database Engine on the Microsoft MSDN site.

Oracle Database

To encrypt communication between the Vulnerability ProtectionDeep Security Manager and an Oracle database:

  1. Add the following lines to dsm.properties (example):

    database.Oracle.oracle.net.encryption_types_client=(AES256)
    database.Oracle.oracle.net.encryption_client=REQUIRED
    database.Oracle.oracle.net.crypto_checksum_types_client=(SHA1)
    database.Oracle.oracle.net.crypto_checksum_client=REQUIRED

  2. Save and close the file. Stop and restart the Vulnerability ProtectionDeep Security Manager service.

(All parameters prefixed with database.Oracle. will be passed to the Oracle driver.)

Possible values for the encryption_types_client are:

Possible values for crypto_checksum_types_client are:

For additional options consult: http://docs.oracle.com/cd/B28359_01/java.111/b31224/clntsec.htm

Running an Agent on the Database Server

Encryption should be enabled if you are using an Agent to protect the database. When you perform a Security Update, the Vulnerability ProtectionDeep Security Manager stores new Intrusion Prevention Rules in the database. The rule names themselves will almost certainly generate false positives as they get parsed by the Agent if the data is not encrypted.