waf fw-rules

The waf fw-rules command manages the path rules of a host group. Every rule meets a request path and determines with which methods, at what length and at what depth the request coming to that path can be. The detailed inspection parts of the rule are kept in a separate command.

Command Summary

TR7 WEB-CLI · waf fw-rules

# Tab after the command

admin@TR7LBWAF01> waf fw-rules

add add-arg-headers delete list show update

 

admin@TR7LBWAF01> waf fw-rules list poolId <vservice> hostGroupId <group>

admin@TR7LBWAF01> waf fw-rules add poolId <vservice> hostGroupId <group> …

admin@TR7LBWAF01> waf fw-rules update poolId <vservice> hostGroupId <group> id <id> …

admin@TR7LBWAF01> waf fw-rules delete poolId <vservice> hostGroupId <group> <id>

admin@TR7LBWAF01>  

Required Fields

In every command the CLI asks for the place of the rule in the following order, one by one; it does not show the next one before one is written. The fields are written with the field name and its value together.

Order	Field	Status	Value
1	poolId	Required	The vService record the rule is bound to
2	hostGroupId	Required	The host group record the rule is bound to; the groups of the selected vService are listed
3	path.input	Conditionally required	Only in the add command; the request path to be met. Since the --path.type default is exact, in practice it is always asked for
3	id	Required	Only in the update command; the rule to be edited

When a -- field is added to the line, path.input is written in the --path.input form as well; Tab shows the correct writing at every step.

The add, list, show and delete commands ask for the first two fields; in the show and delete commands the identifier of the rule is then written without the field name. In the add-arg-headers command, on the other hand, the name of neither field is written (see the section below). The rules do not have a name: they appear in the selection list with the path they match, and the built-in general rule as default rule.

The Request Path

Field	What it does	What is written after it
--path.type	Determines whether the rule meets a certain path or all the paths	exact a certain path (the default) · any all the paths; any belongs only to the built-in default rule
--path.input	Determines the path to be met	The request path that starts with /, for example /api/v1/login. The glob pattern (/api/*) is detected by itself. It is required while --path.type exact (see order 3)

The server calculates the type of the rule: the exact paths are marked as exact, the paths with a glob pattern as regex and the built-in general rule as default.

The Allowed HTTP Methods

Field	What it does	What is written after it
--allowedMethods.type	Selects how the method restriction will be applied	any allows every method (the default) · multiple allows only the selected methods · none allows no method
--allowedMethods.input.N	Determines which methods will be allowed when multiple is selected	GET · HEAD · OPTIONS · POST · PUT · PATCH · DELETE · TRACE · CONNECT; every method with its own index. It opens only while --allowedMethods.type multiple

The Path Restrictions

Both restrictions consist of the same three fields: the comparison operator, the value and the end of the range.

Field	What it does	What is written after it
--pathSize.op	Selects how the path length will be compared	none no restriction (the default) · <= · = · >= · - range
--pathSize.val	Determines the length to be compared	A number; while the operator is -, the beginning of the range
--pathSize.val2	Determines the end of the range	A number; it is used only while the operator is -
--pathDepth.op	Selects how the path depth will be compared	none no restriction (the default) · <= · = · >= · - range
--pathDepth.val	Determines the depth to be compared	A number; while the operator is -, the beginning of the range
--pathDepth.val2	Determines the end of the range	A number; it is used only while the operator is -

If the operator is not none, the value is required

The restriction in the schema requires, when the operator takes a value other than none, that the val field be a number, and while the operator is -, additionally that the val2 field be a number too.

The OWASP Inspection

Field	What it does	What is written after it
--argOwasp	Turns on the OWASP inspections being applied to the request path	true · false (the default is false)
--argOwaspExclusions.N	Determines the OWASP rule keys that will not be applied in this rule	The rule key; every key with its own index, the same key cannot be written twice

add-arg-headers — Adding the Recommended Header Rules

It adds the ready header-argument inspection set (cookie, user-agent, content-type and the like) to the default rule of the host group; it refreshes the existing entries of the set. A request body is not needed.

Order	Field	Status	Value
1	poolId	Required	The vService to be worked on. The field name is not written, the value is written directly
2	hostGroupId	Required	The host group to whose default rule the adding will be made. The field name is not written, the value is written directly

Applying the same operation to more than one host group at once is done from the waf host-groups command, with add-arg-headers.

Examples

TR7 WEB-CLI · path rules

# only POST to the login path, at most 128 characters

admin@TR7LBWAF01> waf fw-rules add poolId <vservice> hostGroupId <group> \

--path.type exact --path.input /api/v1/login \

--allowedMethods.type multiple --allowedMethods.input.0 POST \

--pathSize.op "<=" --pathSize.val 128 --argOwasp true

 

# a path with a glob pattern, a depth range

admin@TR7LBWAF01> waf fw-rules add poolId <vservice> hostGroupId <group> \

--path.input "/api/*" --pathDepth.op "-" --pathDepth.val 2 --pathDepth.val2 6

 

# leaving an OWASP rule out on this path

admin@TR7LBWAF01> waf fw-rules update poolId <vservice> hostGroupId <group> id <id> \

--argOwaspExclusions.0 <rule-key>

 

# adding the ready header inspections to the default rule

admin@TR7LBWAF01> waf fw-rules add-arg-headers <vservice> <group>

admin@TR7LBWAF01>  

Things to Know

• A rule belongs to a host group. In every command it is stated with poolId and hostGroupId on the rules of which group it is worked; the groups are in the waf host-groups command.
• The required fields do not take --. poolId and hostGroupId are written with the field name and its value side by side; the optional fields are in the --field value form. The detail is on the API Commands page.
• The rule does not have a name. The records are referred to with the path they match; the built-in general rule appears in the list as default rule.
• The any path type is not selected manually. According to the explanation in the schema, this type belongs only to the built-in default rule.
• The comparison operators require quotes. The values such as <=, >= and - are written inside double quotes so that they are not counted as a redirection by the shell.
• The detailed inspections are in a separate command. The key and value inspections in the regions such as the query, the header and the body are managed with the waf rule-parts command; they appear as read-only in the rule responses.
• A deleted rule does not come back. The delete command removes the rule and the inspection parts under it.