Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Tips Database Forum Rss Feed

» Database Journal Home
» Database Articles
» Database Tutorials
MS Access
SQL Scripts & Samples
» Database Forum
» Slideshows
Free Newsletters:

News Via RSS Feed

Rss Feed

Database Journal |DBA Support |SQLCourse |SQLCourse2

Featured Database Articles

SQL etc

Posted Feb 4, 2011

Check Your Database Configurations

By DatabaseJournal.com Staff

By Alex Rothacker

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. Let’s 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. Let’s 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:


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.

Alex Rothacker is the Director of Security for Application Security, Inc.’s TeamSHATTER. Follow him on Twitter @arothackerasi and @TeamSHATTER

SQL etc Archives

Latest Forum Threads
SQL etc Forum
Topic By Replies Updated
MySQL rollback UAL225 0 August 21st, 09:56 PM
Complex Search Query Galway 0 May 20th, 10:04 PM
change collation at once supercain 2 May 15th, 06:18 AM
SQL Features, tools and utilities question Neomite 1 April 10th, 09:13 AM