Understanding the Nessus Audit policy and its customization

The Nessus Audit files consist of custom XML-based rules which are needed to perform configuration audit for various platforms. These files allow the user to perform value and regex-based comparisons of the current configuration and determine the gaps present. In general, it is expected that these audit files are prepared in line with the industry standard baselines so that the actual compliance gaps are shown and the administration team can work on hardening and compliance at the same time. A custom audit file is to be saved with the extension .audit.

The following is a generic syntax of a check in the audit files:

<item>
 name                       : " "
 description            :  " "
 info                           : " "
 value                        : " "
</item>

We will look at some of the standard checks for windows so that we can learn about various generic and custom checks. All the default checks start with <item> and all the custom checks start with <custom_item>:

• Value data: The keywords in the audit file can be assigned data based on the value_data tag. This section describes the different keywords which can be defined in the audit file and the values they can hold. The datatype of value_data is DWORD. value_data can also be fed with complex expressions using arithmetic symbols such as ||, &&, and so on:
  • Check_type: This attribute is used to compare whether the value fetched from the remote host is the policy value and returns the result based on the attribute configured. Some of the versions of this attribute are as follows:
    • CHECK_EQUAL
    • CHECK_EQUAL_ANY
    • CHECK_NOT_EQUAL
    • CHECK_GREATER_THAN
    • CHECK_GREATER_THAN_OR_EQUAL
  • Info: This is an optional field which is used to add information about the check being performed. The syntax for this is as follows: 

info: "Password policy check"

• • Debug: This keyword can be used to obtain information to troubleshoot a check. This generates step-by-step data on the execution of the check, allowing the author to understand the errors.

• Access Control List Format (ACL): This section of the settings contains keywords which can hold values to detect whether the required ACL settings have been applied on the files. The ACL format supports six different types of access list keywords, as follows:
  • File access control checks (file_acl)
  • Registry access control checks (registry_acl)
  • Service access control checks (service_acl)
  • Launch permission control checks (launch_acl)
  • Access permission control checks (access_acl)

The preceding keywords can be used to define file permissions for a specific user in the following associated types. These categories of permissions might have different changes for different keywords:

• • • Acl_inheritance
    • Acl_apply
    • Acl_allow
    • Acl_deny

These keywords have different sets of permissions for folders. The following is the syntax in which file_acl can be used:

<file_acl: ["name"]>
<user: ["user_name"]>
acl_inheritance: ["value"]
acl_apply: ["value"]
</user>
</acl>

A similar syntax can be used for all the other keywords by just replacing file_acl with the respective keyword.

• Item: An item is of the check type, and can be used to perform predefined audit checks. This reduces the syntax as the policy is predefined and is called here using the attributes. The following is the structure of an item:

<item>
name: ["predefined_entry"]
value: [value]
</item>

The value can be defined by the user, but the name needs to match the name which is listed in the predefined policies. The following are a few of the keywords and tags we will use in this recipe to create a custom Windows and Unix audit file.

• • check_type: Each audit file begins with the check_type tag, where the operating system and the version can be defined. This tag needs to be closed once the audit file is complete to mark the end of the audit file:

<check_type:"Windows" version:" ">

• • name: The name attribute needs to be the same as in the predefined policies in order for the logic to be fetched from the predefined policies:

name: "max_password_age"

• • type: The type variable holds the name of the policy item which is used for a specific check:

type: PASSWORD_POLICY

• • description: This attribute holds the user-defined name for the check. This can be anything that is useful to identify the action that is going on in the check:

description: " Maximum password age"

• • info: This attribute is generally used to hold the logic in order for a user to understand the action being performed in the check:

info: "Maximum password age of 60 days is being checked."

• • Value: This attribute is of the DWORD type and consists of the policy value against which the remote value present on the host is to be compared with:

Value: "8"

• • cmd: This holds the command which is to be executed on the remote system in order to obtain the value of the item being checked:

cmd : "cat /etc/login.defs | grep -v ^# | grep PASS_WARN_AGE | awk {'print $2'}"

• • regex: This attribute can be used to perform regular expression-based comparisons for the remote value obtained. This can then be compared with the policy value to ensure that the check was successful, even if the configuration is stored in a different format:

regex: "^[\\s]*PASS_WARN_AGE\\s+"

• • expect: This policy item consists of the baseline policy value which is expected to be configured on the device. Otherwise, it is used to report the gap in the configuration:

expect: "14"

• • Custom_item: A custom audit check is something that is defined by the user using NASL and is parsed by the Nessus compliance parser as per the instructions provided in the checks. These custom items consist of custom attributes and custom data values, which will allow the user to define the required policy values and prepare the audit files accordingly.

• • value_type: This attribute consists of different types of the values which are allowed for the current check:

value_type: POLICY_TEXT

• • value_data: This attribute consists of the types of data that can be entered for the checks, such as:
    • value_data: 0
    • value_data: [0..20]
    • value_data: [0..MAX]

• • Powershell_args: This attribute consists of arguments which are to be passed and executed on powershell.exe for a windows system.

• • Ps_encoded_args: This attribute is used to allow PowerShell arguments or files as base 64 strings to PowerShell, for example, powershell_args:

'DQAKACIAMQAwACADFSIGHSAPFIUGHPSAIUFHVPSAIUVHAIPUVAPAUIVHAPIVdAA7AA0ACgA='
ps_encoded_args: YES

In this recipe, we will look at creating a windows audit file to check free disk space in the system partition.