0 Replies Latest reply: Nov 12, 2012 8:59 AM by Mehul RSS

Auditing Check Point GAiA Configuration Compliance

Mehul Guru

Today we released a new compliance checks plugin for auditing Check Point GAiA devices in the general Nessus plugin feed.

This post is intended to provide details about the plugin, and help users understand its capabilities.

 

Introduction:

 

Check Point GAiA is the latest and greatest platform offered by Check Point. It combines the best features from IPSO and

SecurePlatform into a single unified OS. The GAiA OS runs Check Point Appliances, open servers, VPN-1, FireWall-1, and

virtualized gateways. The GAiA OS is also provided as virtual image which can be installed on VMware ESX.


Scan Requirements :


If you have used Nessus compliance checks before, then you will find yourself in familiar territory while running the scan.

The process is similar to running Unix compliance checks.


Here's what is required :


- SSH should be enabled on the GAiA device.

- Admin credentials for the GAiA Device.

- Audit policy specifically designed for GAiA.

   - A Best practice audit for GAiA devices is available for download on the Tenable portal.

- Plugin #62679 (Check Point GAiA Compliance Checks)

 

Setting Up the Scan :

 

- Create a new scan policy

- Enter SSH credentials

 

ssh.png

 

- Select Plugin #62679 (Check Point GAiA Compliance Checks)


policy.png

- Apply .audit policy

audit_file.png

 

- Save the policy and run the scan.


 

Check Point .audit syntax

 

As with any .audit file, the Check Point .audit file should also adhere to a strict predefined syntax.

 

List of supported keywords :

 

type :

 

This  keyword describes the type of check that is being performed by a given  item in an  audit file. All Check Point checks are performed

by CONFIG_CHECK .audit check. Internally this check runs the "show configuration" to audit the config.  The CONFIG_CHECK check

consists of 2 or more keywords. Keywords type, description are mandatory which are followed by one or more keywords.

 

e.g.

type: CONFIG_CHECK

 

description :

 

This keyword gives a brief description of the check that is being performed. It is required that description field be unique and no two checks

should have the same description field. This is required because Security Center uses this field to auto generate a plugin ID number based

on the description field.

 

e.g.

description: "1.0 Require strong Password Controls - 'min-password-length >= 8'"

 

info:

 

This keyword allows users to add a more detailed description to the check that is being performed. Multiple info fields

are allowed with no preset limit. The info content should be enclosed in double-quotes.

 

e.g.

info          : "Enable palindrome-check on passwords"

 

severity:

 

This keyword allows users to set the severity of the check.

 

e.g.

severity : MEDIUM

 

The severity can be set to HIGH, MEDIUM or LOW.

 

regex:

 

This keyword allows searching config items that match a particular regex expression.

 

e.g

regex: "set snmp .+"

 

If a check has 'regex' keyword set, but no 'expect' or 'not_expect' keyword is set, then the check simply reports

all lines matching the regex. This is of great value while manually reviewing the settings.

 

For e.g. in the above case, the check will list all the SNMP settings.

 

Compliance Testing Keywords

 

The compliance of a check can be determined by comparing the output of the check to either 'expect' or 'not_expect' keyword.

There cannot be more than one compliance testing keywords i.e either 'expect' or 'not_expect' can exist but not both.


expect :

 

This keyword allows auditing the config item matched by the 'regex' tag. The check passes as long as the config line found by 'regex' matches the 'expect' string.

 

e.g.

regex          : "set password-controls complexity"

expect        : "set password-controls complexity [1-4]"

 

In the above case, the 'expect' tag ensures that the complexity is set to a value between 1 and 4.

 

not_expect:

 

This  keyword allows searching the configuration items that should not be in  the configuration. It acts as the opposite of 'expect'. The check passes  as long as

the config line found by 'regex' does not match the 'not_expect' string.

 

e.g

regex             : "set password-controls password-expiration"

not_expect    : "set password-controls password-expiration never"


Examples :

<custom_item>

  type           : CONFIG_CHECK

  description   : "1.0 Require strong Password Controls - 'min-password-length >= 8'"

  regex         : "set password-controls min-password-length"

  expect        : "set password-controls min-password-length ([8-9]|[0-9][0-9]+)"

  info          : "Require Password Lengths greater than or equal to 8."

</custom_item>

 

<custom_item>

  type          : CONFIG_CHECK

  description   : "1.0 Require strong Password Controls - 'password-expiration != never'"

  regex         : "set password-controls password-expiration"

  not_expect    : "set password-controls password-expiration never"

  info          : "Allow passwords to expire"

</custom_item>

 

<custom_item>

  type          : CONFIG_CHECK

  description   : "2.13 Secure SNMP"

  regex         : "set snmp .+"

  severity      : MEDIUM

  info          : "Manually review SNMP settings."

</custom_item>

 

Sample Result :


fail.png

pass.png

 

Conditions:

 

It  is possible to define an if/then/else logic in a Check Point .audit  policy. This allows the end-user to use a single file which is able to  handle multiple configurations.

 

The syntax to perform conditions is the following :

<if>

  <condition type:"or">

      < Insert your audit here >

  </condition>

<then>

     < Insert your audit here >

</then>

<else>

     < Insert your audit here >

</else>

</if>


Example:


<if>

<condition type: "OR">

<custom_item>

  type           : CONFIG_CHECK

  description   : "2.6 Install and configure Encrypted Connections to devices - 'telnet'"

  regex         : "set net-access telnet"

  expect        : "set net-access telnet off"

  info          : "Do not use plain-text protocols."

</custom_item>

</condition>

<then>

  <report type: "PASSED">

   description    : "Telnet is disabled"

  </report>

</then>

<else>

  <custom_item>

  type           : CONFIG_CHECK

  description   : "2.6 Install and configure Encrypted Connections to devices - 'telnet'"

  regex         : "set net-access telnet"

  expect        : "set net-access telnet off"

  info          : "Do not use plain-text protocols."

</custom_item>

</else>

</if>

 

The condition never shows up in the report - that is, whether it fails or passes it won't show up (it's a 'silent' check).

 

Conditions can be of type "and" or "or".

 

Reporting:

 

Support for simple report checks has also been added. Report checks can be of the type PASSED,FAILED or WARNING

 

Example :


<if>

<condition type: "OR">

<custom_item>

  type           : CONFIG_CHECK

  description   : "2.6 Install and configure Encrypted Connections to devices - 'telnet'"

  regex         : "set net-access telnet"

  expect        : "set net-access telnet off"

  info          : "Do not use plain-text protocols."

</custom_item>

</condition>

<then>

  <report type: "PASSED">

   description    : "Telnet is disabled"

  </report>

</then>

<else>

<report type: "FAILED">

   description    : "Telnet is disabled"

  </report>

</else>

</if>

 

That  wraps up our discussion on Check Point GAiA compliance checks. If you  have any questions, please feel free to contact Tenable Support or post a reply to this  post.

 

-Mehul