Juniper CONFIG_CHECK Keywords

The following table indicates how each keyword in the Juniper compliance checks can be used:

Keyword

Example Use and Supported Settings

type

CHECK_CONFIG and SHOW_CHECK_CONFIG

“CHECK_CONFIG” determines if the specified config item exists in the Juniper “show configuration” output in “set” format. In the same manner, “SHOW_CONFIG_CHECK” audits if the config item exists in the “show configuration” output in default format.

description

This keyword provides the ability to add a brief description of the check that is being performed. It is strongly recommended that the description field be unique and no distinct checks have the same description field. Tenable uses this field to automatically generate a unique plugin ID number based on the description field.

Example:

description: " 3.1 Disable Unused Interfaces"

info

The “info” keyword is used to add a more detailed description to the check that is being performed. Rationale for the check could be a regulation, URL with more information, corporate policy, and more. Multiple info fields can be added on separate lines to format the text as a paragraph. There is no preset limit to the number of info fields that can be used.

Note: Each “info” tag must be written on a separate line with no line breaks. If more than one line is required (e.g., formatting reasons), add additional “info” tags.

Example:

info: "Review the list of interfaces"

info: "Disable unused interfaces"

severity

The “severity” keyword specifies the severity of the check being performed.

Example:

severity: MEDIUM

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

regex

The “regex” keyword enables searching the configuration item setting to match for a particular regular expression.

Example:

regex: " set system syslog .+"

The following meta-characters require special treatment: + \ * ( ) ^

Escape these characters out twice with two backslashes “\\” or enclose them in square brackets “[]” if you wish for them to be interpreted literally. Other characters such as the following need only a single backslash to be interpreted literally: . ? " '

This has to do with the way that the compiler treats these characters.

If a check has “regex” tag set, but no “expect” or “not_expect” or “number_of_lines” tag is set, then the check simply reports all lines matching the regex.

expect

This keyword allows auditing the configuration item matched by the “regex” tag or if the “regex” tag is not used it looks for the “expect” string in the entire config.

Example:

expect: "syslog host 1.1.1.1"

The check passes as long as the config line found by “regex” matches the “expect” tag or in the case where “regex” is not set, it passes if the “expect” string is found in the config.

Example:

regex: "syslog host [0-9\.]+"

expect: "syslog host 1.1.1.1"

In the above case, the “expect” tag ensures that the syslog host is set to 1.1.1.1.

not_expect

This keyword allows searching the configuration items that should not be in the configuration.

Example:

not_expect: "syslog host 1.1.1.1"

It acts as the opposite of “expect”. The check passes as the config line found by “regex” does not match the “not_expect” tag or if the “regex” tag is not set, it passes as long as “not_expect” string is not found in the config.

Example:

regex: "syslog host [0-9\.]+"

not_expect: "syslog host 1.1.1.1"

In the above case, the “not_expect” tag ensures that the syslog host is not set to 1.1.1.1.

number_of_lines

This keyword allows testing compliance of an audit check based on the number of matching lines returned by the config.

<custom_item>

type: CONFIG_CHECK

description: "Syslog"

regex: "syslog host [0-9\.]+"

number_of_lines: "^1$"

</custom_item>

In the above case the check will pass as long as only one line is returned that matches the “regex”.