Database Configuration Command Line Examples

This section provides some examples of common audits used for database compliance checks. The nasl command line binary is used as a quick means of testing audits on the fly. Each of the .audit files demonstrated below can easily be dropped into your scan policies. For quick audits of one system, however, command-line tests are more efficient. The command will be executed each time from the /opt/nessus/bin directory as follows:

# ./nasl -t <IP> /opt/nessus/lib/nessus/plugins/database_compliance_check.nbin

The <IP> is the IP address of the system to be audited.

Depending on the type of database being audited you may be prompted for other parameters beyond the audit file to be used. For example, Oracle audits will prompt for the database SID and the Oracle login type:

Which file contains your security policy : oracle.audit

login : admin

Password :

Database type: ORACLE(0), SQL Server(1), MySQL(2), DB2(3), Informix/DRDA(4), PostgreSQL(5)

type : 0

sid: oracle

Oracle login type: NORMAL (0), SYSOPER (1), SYSDBA (2)

type: 2

Consult with your database administrator for the correct database login parameters.

Following is a simple .audit file that looks for any SQL Server logins with no expiration date. If any are found, the audit will display a failure message along with the offending login(s).

<check_type: "Database" db_type:"SQLServer" version:"1">

<group_policy: "Login expiration check">

<custom_item>

type: SQL_POLICY

description: "Login expiration check"

info: "Database logins with no expiration date pose a security threat. "

sql_request: "select name from sys.sql_logins where type = 'S' and is_expiration_checked = 0"

sql_types: POLICY_VARCHAR

sql_expect: NULL

</custom_item>

</group_policy>

</check_type>

When running this command, the following output is expected from a compliant system:

"Login expiration check": [PASSED]

Compliance requirements usually mandate that database logins have an expiration date.

A failed audit would return the following output:

"Login expiration check": [FAILED]

 

Database logins with no expiration date pose a security threat.

 

Remote value:

 

"distributor_admin"

 

Policy value:

 

NULL

This output indicates that the “distributor_admin” account has no configured expiration date and needs to be checked against the system security policy.

This audit checks if the stored procedure “SQL Mail XPs” is enabled. External stored procedures can constitute a security threat for some systems and are often required to be disabled.

<check_type: "Database" db_type:"SQLServer" version:"1">

<group_policy: "Unauthorized stored procedure check">

<custom_item>

type: SQL_POLICY

description: "SQL Mail XPs external stored procedure check"

info: "Checking whether SQL Mail XPs is disabled."

sql_request: "select value_in_use from sys.configurations where name = 'SQL Mail XPs'"

sql_types: POLICY_INTEGER

sql_expect: 0

</custom_item>

</group_policy>

</check_type>

The check above will return a “passed” result if the “SQL Mail XPs” stored procedure is disabled (value_in_use = 0). Otherwise, it will return a “failed” result.

In some cases, compliance database queries require multiple data requests with multiple data type results. The example audit below mixes data types and demonstrates how the output can be parsed.

<check_type: "Database" db_type:"SQLServer" version:"1">

<group_policy: "Mixed result type check">

<custom_item>

type: SQL_POLICY

description: "Mixed result type check"

info: "Checking values for the master database."

sql_request: " select database_id,user_access_desc,is_read_only from sys.databases where is_trustworthy_on=0 and name = 'master'"

sql_types: POLICY_INTEGER,POLICY_VARCHAR,POLICY_INTEGER

sql_expect: 1,MULTI_USER,0

</custom_item>

</group_policy>

</check_type>

Note that the sql_request, sql_types, and sql_expect values all contain comma-separated values.