DAS is a collection of services provided by different processes. Each process is a container responsible for different types of database operations. These processes are:
DAS Core: DAS Core is responsible for the following:
Performs general Sentinel Service operations including Login and Historical Query.
Provides the server-side functionality for Active Views.
Calculates event data summaries that are used in reports.
Provides the server-side functionality for the Sentinel iTRAC functionality.
Provides a command line interface to certain DAS services. Used primarily for third-party integration.
Provides the server-side of the SSL proxy connection to Sentinel Server.
DAS Binary: Performs event database insertion.
DAS Proxy is not directly part of the DAS collection of services. It is part of the Communication Server and does not directly connect to the database.
The primary settings in the configuration files can be configured using the dbconfig utility and are related to the database connection, including:
username
password
hostname
port number
database (database name)
If any of these database connection settings need to be changed, they must be changed in every das_*.xml file using the dbconfig utility. Using the –a argument, this utility can update all files at the same time (For example, update all files in the <Install_directory>\config or <Install_directory>/config directory). Alternately, using the –n argument, this utility can update a single file’s contents if only one file need to be updated. Typically, all files should be updated at the same time.
WARNING:Do not manually edit the database connection properties. Use the dbconfig utility to change any database connection values within these files.
Login to the machine where DAS is installed as the admin user.
Go to:
<Install_directory>/bin
Run the following command:
dbconfig –a <Install_directory>/config [-u username] [-p password] [-h hostname] [-t portnum] [-d database] [-s server] [-help] [‑version]
Other settings in the files can be adjusted manually (without using dbconfig):
maxConnections
batchSize
loadSize
Changing these settings might affect database performance and should be done with caution
The following files are used to configure logging of the DAS process. These files are typically changed when troubleshooting the DAS processes.
das_core_log.prop
das_binary_log.prop
They are located at:
<Install_directory>/config
These files contain the configuration that determines how the DAS processes will log messages. The most important part of the configuration is the logging levels, which indicate how verbose the log messages should be. The section of the file to configure these settings is:
###### Configure the logging levels # Logging level rules are read from the top down. # Start with the most general, then get more specific. # # Defaults all loggers to INFO (enabled by default) .level=INFO # # < Set level of specific loggers here > # # Turns off all logging (disabled by default) #.level=OFF ######
NOTE:The logger .level is a wildcard logger name that refers to all loggers. Setting this logger’s level will affect all loggers.
The available logging levels are:
OFF: disables all logging
SEVERE (highest value): indication that a component has malfunctioned or there is a loss/corruption of critical data
WARNING: if an action can cause a component to malfunction in the future or if there is non-critical data loss/corruption
INFO: audit information
CONFIG: for debugging
FINE: for debugging
FINER: for debugging
FINEST: (lowest value) – for debugging
ALL: will log all levels
When one specifies a logging level, all log messages of that level and higher (in the above list) will actually be logged. For example, if one specifies the INFO level, then all INFO, WARNING and SEVERE messages will be logged.
NOTE:At 10 second intervals, the logging properties file will be checked to see if any changes have occurred since it was last read. If the file has changed, the LogManagerRefreshService will re-read the logging properties file. Therefore, it is not necessary to restart the processes to begin using the updated logging levels.
Log messages are written to <Install_Directory>/log in the following files:
das_binary_0.*.log
das_core_0.*.log
The 0 indicates the unique number to resolve conflicts and the * indicates a generation number to distinguish rotated logs. For example, das_core0.0.log is the log with index 0 (latest) file in a rotated set of log files for the DAS Core process.
Log messages are also written to the process’s console (standard output). However, since the processes are running as services, users do not have access to the console output. It is possible, however, to capture the console output in the sentinel0.*.log file. This is useful, for example, if the process is producing an error that is not printed to the process’s own log file. This can be enabled by adding the following line to the sentinel_log.prop file:
esecurity.base.process.MonitorableProcess.level=FINEST
The Sentinel 6.1 Rapid Deployment server uses an asymmetric key pair, consisting of a certificate (or public key) and a private key, to encrypt communications. When the Sentinel Communication Server is started for the first time, it automatically creates a self-signed certificate which is used by the Server.
You can replace the self-signed certificate with a certificate signed by a major Certificate Authority (CA), such as Verisign, Thawte, or Entrust. You can also replace the self-signed certificate with a certificate signed by a less common CA, such as a CA within your company or organization.
This section describes several certificate management tasks that you can perform in Sentinel:
Replace the default certificate with a certificate signed by a Certificate Authority (CA)
Change default keystore and keyEntry passwords. This is recommended on all Sentinel systems.
Change the location of the .proxyServerKeystore file
Change the default keyEntry alias to avoid potential conflicts with other keys in the keystore or for simplicity
Novell provides a self-signed certificate for the server to use. To improve security, you can replace the default, self-signed certificate that gets installed with a certificate signed by a Certificate Authority (CA). The CA may be a major CA, such as Verisign, Thawte, or Entrust, or it may be a less widely-known CA, such as one that is within your organization.
The basic steps are to get a CA to sign your certificate and then import that certificate into the keystore for server to use. To import the certificate, the CA that signed the certificate must be known to the keytool utility. Keytool usually recognizes the major certificate authorities, but for other CA’s you may need to import a certificate or chain of certificates for the certificate authority before you can successfully import the certificate that DAS_Core uses.
NOTE:These instructions are based on the user guide for keytool. For more information, see http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
Execute the following command in the console:
<Install_directory>/jre/bin/keytool -list -keystore <Install_directory>/config/.proxyServerKeystore
Provide the keystore password (star1111 by default). The contents of the keystore file display:
Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry 10.0.0.1, Jan 8, 2008, keyEntry, Certificate fingerprint (MD5): 22:B4:19:63:AC:2D:F9:C0:66:7F:7C:64:85:68:89:AB
The keyEntry alias, which is used in the following step, is the IP address in the example above. By default, the keyEntry alias can be the IP address or the host name of the local machine.
Execute the following command in the console using the keyEntry alias from .proxyServerKeystore:
<Install_directory>/jre/bin/keytool -certreq -alias <keyEntry alias> -keystore <Install_directory>/config/.proxyServerKeystore -file <csr_filename.csr>
The .csr file is saved in the specified location.
Provide the .csr file to the CA. The CA will return a signed .cer file. (These exact steps varies based on the Certificate Authority.)
If the CA is not well known, you must add the CA's certificate to the cacerts keystore :
Open a command prompt and go to <Install_directory>/jre/lib/security. There should be a cacerts file in this directory.
Run the following command to import:
<Install_directory>/jre/bin/keytool -import -trustcacerts -alias <a_ca_cert_alias_of_your_choosing> -keystore <Install_directory>/jre/lib/security/cacerts -file <ca_cert_filename>
NOTE:The default password for this keystore file is changeit.
Execute Step 5.a through Step 5.b on the Sentinel Server machine, all Collector Manager systems that are connecting to the Sentinel Server through the SSL Proxy, and all Sentinel Control Center systems.
To enable the use of CA signed certificate, edit das_proxy.xml file available on the Sentinel Server. Change the property value to true:
<property name="usecacerts">true</property>
Edit the configuration.xml file on all system with Sentinel Control Center and add the following attribute to the ssl element of the proxied_client and proxied_trusted_client strategies:
usecacerts="true"
For example:
<strategy active="yes" id="proxied_client" location="com.esecurity.common.communication.strategy.proxystrategy.ProxiedClientStrategyFactory"> <transport type="ssl"> <ssl host="hostname" keystore=”Path of .proxyClientKeystore” port="10013" usecacerts="true"/> </transport> </strategy> <strategy active="yes" id="proxied_trusted_client" location="com.esecurity.common.communication.strategy.proxystrategy.ProxiedClientStrategyFactory"> <transport type="ssl"> <ssl host="hostname" keystore=”Path of .proxyClientKeystore” port="10014" usecacerts="true"/> </transport> </strategy>
NOTE:The default property of usecacerts is false. You must change the property of usecacerts to true.
Import the .cer file into keystore file by executing the following command:
<Install_directory>/jre/bin/keytool -import -trustcacerts -alias <keyEntry alias> -keystore <Install_directory>/config/.proxyServerKeystore -file <cer_filename.cer>
This will replace the self-signed certificate installed with Sentinel.
Restart Sentinel Server.
Ensure that you change the keystore and keyEntry passwords after replacing the certificate.
By default, the passwords used for keystore and the keyEntry are both set to star1111. It is a good practice to change these to something new.
NOTE:DAS_Proxy requires that the keystore and keyEntry passwords to be identical.
To change the keystore and the keyEntry password:
Execute the following command in the console to change the keystore password:
<Install_directory>/jre/bin/keytool -storepasswd -keystore <Install_directory>/config/.proxyServerKeystore
Enter the old keystore password (star1111 by default) and a new keystore password. The following example depicts this:
Enter keystore password: <old_pass> New keystore password: <new_pass> Re-enter new keystore password: <new_pass>
Verify the keyEntry alias using the following command:
<Install_directory>/jre/bin/keytool -list -keystore <Install_directory>/config/.proxyServerKeystore
Provide the current keystore password. The contents of the keystore file display:
Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry 10.0.0.1, Jan 8, 2008, keyEntry, Certificate fingerprint (MD5): 22:B4:19:63:AC:2D:F9:C0:66:7F:7C:64:85:68:89:AB
The keyEntry alias is the IP address in the example above. By default, the keyEntry alias is either set to the IP address or the hostname of the local machine.
Execute the following command in the console to change the keyEntry password to the same password as the new keystore password:
<Install_directory>/jre/bin/keytool -keypasswd -alias <keyEntry alias> -keystore <Install_directory>/config/.proxyServerKeystore
Enter the existing password and the new password. The following example depicts this:
Enter keystore password: <new_pass> Enter key password for <keyEntry alias> <old_pass> New key password for <keyEntry alias>: <new_pass> Re-enter new key password for <keyEntry alias>: <new_pass>
NOTE:Remember that the keyEntry password and keystore password must be identical.
Get the encrypted, Base64 value of the new password using the following steps:
Copy <Install_directory>/config/das_rt.xml to a file named temp.xml:
Execute the following command to add an encrypted, Base 64 form of the password to temp.xml file:
<Install_directory>/bin/dbconfig -n <Install_directory>/config/temp.xml -p <new password for keystore and keyEntry>
Open temp.xml file.
Copy the value of password from the following section of the file: <property name="password">BSEU8ew2JYsxtOt4hYcYNA==</property>
Delete the temp.xml file when you are confident that you have successfully copied the encrypted password.
Open the das_core.xml file.
Paste the copied value of the new password to the keystorePassword property in the ProxyService component property as shown below:
<obj-component id="ProxyService">
<class>esecurity.ccs.comp.clientproxy.ClientProxyService</class>
<property name="clientports">ssl:10013</property>
<property name="certclientports">ssl:10014</property>
<property name="keystore"> ../config/.proxyServerKeystore</property>
<property name="keystorePassword"> BSEU8ew2JYsxtOt4hYcYNA==</property>
</obj-component>
Save the das_core.xml file.
Restart Sentinel Server.
By default the certificate and private key are stored in the file .proxyServerKeystore located at <Install_directory>/config. To change the location of .proxyServerKeystore file, you can edit the value of the property “keystore” in the file $/<Install_directory>/config/das_core.xml.
You must restart Sentinel Server after making changes.
The default keyEntry alias is either the IP address or the hostname of the local machine. To use a different keyEntry alias, open the das_core.xml file and set the value of certificateAlias in the component ProxyService to the new value.
You must restart Sentinel Server after making changes.