New Nessus Configuration Auditing Features for Windows Servers

Tenable has added several new types of configuration and security audits that can be performed by Nessus 3 against Windows servers. This blog post explains the new items.

New Auditing Options

There are four new types of audit types available for Windows:

• GROUP_MEMBERS_POLICY
• FILE_AUDIT
• REGISTRY AUDIT
• SERVICE_AUDIT

The new types allow for close analysis of file, registry and service audit policies as well as which specific users are members of of a group.

GROUP_MEMBERS_POLICY

If you would like to perform audits of a Windows server and make sure that there is a specific list of users present in one or more groups, it is now very trivial to accomplish. The template for this type of audit is as follows:

<custom_item>
type: GROUP_MEMBERS_POLICY
description: ["description"]
value_type: [value type]
value_data: [value] | ([value2] | (...))
group_name: ["group name"]
</item>

When using this type of audit, the following items should be considered. The "value_type" variable must always be "POLICY_TEXT".  The "value_data" variable is a list of user accounts in quotes, separated by a pipe character. User accounts can also refer to their domain prefix such as "MYDOMAIN\John Smith". Lastly, the "group_name" specifies a single group for auditing.

A single Nessus .audit file can specify multiple different customer items, so it is very easy to audit lists of users in multiple groups. Here is an example .audit policy which looks for the "Administrators"
group to only contain the "Administrator" and "TENABLE\Domain admins" user:

<check_type: "Windows">
<group_policy: "Audit Administrators group">
<custom_item>
type: GROUP_MEMBERS_POLICY
description: "Checks Administrators members"
value_type: POLICY_TEXT
value_data: "Administrator" | "TENABLE\Domain admins"
group_name: "Administrators"
</item>
</check_type>

When scanning a Windows 2003 server that was not on the Tenable domain, the results under Nessus 3 look like this:

FILE_AUDIT

On Windows server systems, any file or directory can have auditing enabled. This can create logs when authorized or unauthorized users attempt to access or delete content.  The new type requires the specification of a Windows access control list someplace else in your .audit file. The template for this check looks like:

<custom_item>
type: FILE_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
file: ["filename"]
(optional) acl_option: [acl_option]
</item>

The "value_type" feild must always contain a FILE_ACL. The "value_data" field should name an Access Control List defined elsewhere in your .audit file.  The "file:" keyword should indicate either the full path to the file or directory of interest, or make use of one of the following supported PATH keywords:

• %allusersprofile%
• %windir%
• %systemroot%
• %commonfiles%
• %programfiles%
• %systemdrive%

When using this audit, please consider the following. The "file" field must include the full path to the file or folder name (ie: C:\WINDOWS\SYSTEM32) or make use of the above PATH keywords. The "value_data"  field is the name of an access control list defined in the policy file. The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success/error if the file does not exist. Also, the "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events.

Here is an example .audit file that implements the FILE_AUDIT function, including an example access control list rule named "ACL1".

<check_type: "Windows">
<group_policy: "Audits SYSTEM32 directory for correct auditing permissions">

<file_acl: "ACL1">
<user: "Everyone">
acl_inheritance: "not inherited"
acl_apply: "This folder, subfolders and files"
acl_deny: "full control"
acl_allow: "full control"
</user>
</acl>

<custom_item>
type: FILE_AUDIT
description: "Audit for C:\WINDOWS\SYSTEM32"
value_type: FILE_ACL
value_data: "ACL1"
file: "%SystemRoot%\SYSTEM32"
</item>

</group_policy>
</check_type>

REGISTRY_AUDIT

Similar to FILE_AUDIT, registry settings can have auditing enabled to log when attempts to add, change, delete or modify them occur by specific users or groups. The prototype for this type of audit is this:

<custom_item>
type: REGISTRY_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
reg_key: ["regkeyname"]
(optional) acl_option: [acl_option]
</item>

When using this type of audit, please keep the following items in mind:

• The only supported value for "value_type" is REG_ACL
• The "value_data" field specifies the access control list name
• The "reg_key" field specifies the registry key name for auditing
• The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success or error if the key does not exist
• The "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events

Also, the "reg_key" value can also make use of a predefined registry path value of :

• HKLM (HKEY_LOCAL_MACHINE)
• HKU (HKEY_USERS)
• HKCR (HKEY_CLASS_ROOT)

Here is an example portion of a .audit file which audits the registry key of "HKLM\SOFTWARE\Microsoft" against an access control list named "ACL2" which is not shown:

<custom_item>
type: REGISTRY_AUDIT
description: "Audit for HKLM\SOFTWARE\Microsoft"
value_type: REG_ACL
value_data: "ACL2"
reg_key: "HKLM\SOFTWARE\Microsoft"
</item>

SERVICE_AUDIT

Similar to auditing files and registry settings, Windows also has the ability to audit when authorized or unauthorized users attempt to start, stop or restart a process. The prototype for this is as follows:

<custom_item>
type: SERVICE_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
service: ["servicename"]
(optional) acl_option: [acl_option]
</item>

When using this audit, please keep the following items in mind:

• The "value_type" field is always SERVICE_ACL
• The "value_data" field contains the name of the access control list to test against
• The "service" field identifies the service to be audited.
• The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success or error if the service does not exist
• The "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events

Here is an example portion of a .audit file for auditing the "Alerter" service.

<custom_item>
type: SERVICE_AUDIT
description: "Audit for Alerter Service"
value_type: SERVICE_ACL
value_data: "ACL3"
service: "Alerter"
</item>

Version 1.0.8 of the "inf to audit" (i2a) tool

Tenable has also released version 1.0.8 of the i2a tool to take advantage of these new features. The i2a tool converts Microsoft .inf policy files directly to a Nessus 3 .audit file. If you have previously generated a .audit file with the i2a tool, and it had audit policies for these new settings, you can rerun the i2a tool on your .inf policy file to get an updated audit policy.

Obtaining The New Audits

Nessus 3 Direct Feed or Security Center users should update their plugins. If daily plugin updates are normally performed, you will already have these new audits available to you.

At the time of this blog writing, the latest version of the compliance_check.nbin file was 1.20. On UNIX, you can test this by invoking the nasl binary test tool.

[root@megalon bin]# ./nasl -V /opt/nessus/lib/nessus/plugins/compliance_check.nbin
Script ID : 21156
Script Name : Windows Compliance Checks
Script Version : $Revision: 1.20 $
Copyright : This script is Copyright (C) 2006 Tenable Network Security
Family : Policy Compliance