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:
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.
Fix
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
