Today, there are a myriad of database configuration options many of which are either direct security settings, or that impact security. When a new database is installed, DBAs need to address many configuration options to enhance database security. Lets look at a few database configurations that should be followed.
Database Management Systems (DBMS) are complex. In the infancy of the DBMS, there were only a handful of configuration options, leaving little choices for the DBAs in charge of them and minimizing the potential for error. The simple configuration options they were allowed to change included what to name the database instance, and which storage location would be used for the data files.
Today, there are a myriad of configuration options many related to performance and enhanced feature sets such as replication, reporting and auditing. There are also many options that are either direct security settings, or that impact security. Having the correct configuration settings can determine whether or not your critical business information is secure and whether it could be compromised.
When a new database is installed, DBAs need to address many configuration options to enhance security. Lets look at a few database configurations that should be followed.
Sybase Current Audit Table
Sybase auditing records are written to a series of tables in the sybsecurity database. These table names are named sysaudits with a suffix of "_01" through "_08". For example, the first audit table is sysaudits_01, the next is sysaudits_02, etc.
Which table the auditing records are currently written to is determined by the 'current audit table' configuration option. The current audit table is set or read by using the sp_configure system stored procedure.
To effectively manage the audit trail, auditing should be configured to use at least two, but more is usually better, tables, each on a separate device.
Setting up less than two audit tables is strongly discouraged. If you use only a single audit table, a window of time exists while you are archiving audit data and truncating the audit table during which incoming audit records will be lost. There is no way to avoid this when using only a single audit table so ensure to create two audit tables or more.
Oracle Configuration Manager is Installed
Oracle Configuration Manager (OCM) is a function of the Oracle Software Configuration Manager (SCM). OCM collects system configuration data used for an automated upload to systems owned and managed by Oracle to assist in providing customer support. The configuration information about the server that the OCM collects includes IP addresses, hostname, database username, location of data files, etc.
If the configuration information is compromised and released to unauthorized persons the system configuration data may be used maliciously to gain additional unauthorized access to the database or other systems. This configuration issue affects versions of Oracle 10g and above.
To ensure that critical configuration information is secured from threats, make sure to remove Oracle Configuration Manager.
Details for removal of the OCM are provided in Oracle MetaLink Note 369111.1 or in MetaLink Note 728989.1 for a link to the OCM Installation and Administration Guide.
Microsoft SQL Server: DBMS network port, protocol, and services (PPS) configuration
By default, when TCP/IP Protocol is enabled, the default instance of Microsoft SQL Server listens on TCP port 1433. Because only one instance of SQL Server can use a port, Named Instances of SQL Server are configured to use dynamic ports. That means that an available port is selected when the SQL Server service is started.
The DAC (Dedicated Admin Connection) allows an administrator to access a running instance of SQL Server to troubleshoot problems. The default port used by DAC is TCP 1434. The connection is only allowed from a client running on the server, and no network connections are permitted.
By using non-standard network ports, protocol, or services configuration usage it could lead to bypassing of network perimeter security controls and protections. Any TCP ports used by SQL Server, except TCP 1433 and TCP 1434, should be reviewed.
To disable dynamic port usage from SQL Server Configuration Manager:
1) Expand SQL Server Network Configuration
2) Select Protocols for needed MSSQL Instance ("Protocols for <instance name>")
3) Right-click on "TCP/IP" and select "Properties"
4) Select "IP Addresses" tab
5) Clear any value listed in "TCP Dynamic Ports" for all IP addresses.
6) Set all "TCP Port" values for ports accessed across a network boundary to 1433, 1434, or both for all IP addresses.
IBM DB2: Trust All Clients
Sometimes it is required to perform DB2 authentication on the client side by setting the DBM AUTHENTICATION parameter to the non-default setting of CLIENT. In this case, the TRUST_ALLCLNTS configuration parameter is used to determine which clients are considered to be "trusted" clients.
With the TRUST_ALLCLNTS configuration parameter set to 'YES', all clients attempting to login are considered to be "trusted" clients and are allowed to attempt authentication. If all clients are trusted, an attacker is allowed to attempt authentication.
The default value for this parameter is 'YES'. This allows all clients to be treated as "trusted" clients. Considering a client to be "trusted" means that it is assumed that the client is considered to be "secure" and that all clients are validated on the client-side prior to attempting a login to the DB2 UDB database.
In order to change the TRUST_ALLCLNTS configuration parameter to 'NO', the AUTHENTICATION configuration parameter must be set to 'CLIENT'. By setting this configuration parameter to 'NO', clients considered to be "untrusted" must provide some form of authentication in the form of a login and password whenever they attempt to authenticate to the DB2 UDB database.
To view the database manager configuration perform the following steps from an IBM DB2 Console:
1) Attach to the instance whose authentication method is desired by executing:
ATTACH TO [instance alias] USER [login] USING [password]
If the local database manager configuration is desired, you can skip this step.
2) Get the list of configuration parameters by executing:
GET DATABASE MANAGER CONFIGURATION
3) Search the list of configuration parameters for the TRUST_ALLCLNTS parameter.
The parameter can also be set to the value 'DRDA only'. If so, all clients except DB2 hosts have their authentication checked at the server. This is not recommended since it opens the possibility of trusting a spoofed DRDA host.
To modify the TRUST_ALLCLNTS configuration parameter, perform the following steps:
1. Open up the DB2 Control Center.
2. Find the instance whose configuration is to be modified and select it.
3. Choose the "Selected/Configure" menu item.
4. Choose the "Administration" tab.
5. Select the "Trust all clients" value.
6. Under the "Value" section, set the value to NO.
7. Choose OK.
8. Restart the server.