7.2. IP Rule Evaluation

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

When a new flow, such as a TCP/IP connection, is being established through the Clavister NetShield Firewall, the list of IP rules are evaluated from top to bottom until a rule that matches the parameters of the new flow is found. The first matching rule's Action is then performed. For this reason, the ordering of the IP rules in the rule set is important.

If the action in the matching IP rule allows it then the establishment of the new flow will go ahead. A new entry representing the new flow will then be added to the internal list of active flows. This list allows monitoring of opened and active flows.

If the matching IP rule action is Deny or Reject then the flow is not set up.

	Tip: Rules in the wrong order can cause problems
It is important to remember the principle that cOS Stream searches the IP rules from top to bottom, looking for the first matching rule. If an IP rule seems to be ignored, check that some other rule above it is not being triggered first.

Tip: Rules in the wrong order can cause problems

It is important to remember the principle that cOS Stream searches the IP rules from top to bottom, looking for the first matching rule.

If an IP rule seems to be ignored, check that some other rule above it is not being triggered first.

Stateful Inspection

After initial rule evaluation of the opening flow, subsequent packets belonging to that flow will not need to be evaluated individually against the rule set. Instead, a highly efficient algorithm searches the flow table for each packet to determine if it belongs to an established flow.

This approach is known as stateful inspection and is applied not only to stateful protocols such as TCP but also by means of "pseudo-connections" to stateless protocols such as UDP and ICMP. This approach means that evaluation against the main IP rule set is only done in the initial opening phase of a flow. The size of the main IP rule set consequently has negligible effect on overall throughput.

Flows are unidirectional. This means that a typical traffic connection, for example between a web browsing client and a web server, will consist of two flows. This is not the case with the ESP flows used in IPsec where only a single flow is required for the connection.

Examining Flows

All current flows can be shown using the flow CLI command. Some typical output is shown below:

System:/> flow -show
			
Proto   Source                        Destination                   Timeout
------- ----------------------------- ----------------------------- -------
TCP     wan:10.6.58.2:2112            core:10.6.58.100:22           262142

If the -verbose option is used then the matching reverse flow for a connection is also shown. The command form is as follows:

System:/> flow -show -verbose

All options for the flow command can be found in the separate CLI Reference Guide. These include filtering parameters to only list certain flows. The use of this command with IPsec tunnels is discussed in Section 13.6, IPsec Troubleshooting.

The First Matching Principle

If several IP rules in the main IP rule set match the same filtering parameters, the first matching rule in a scan from top to bottom is the one that decides how the flow will be handled.

Non-matching Traffic and Adding a Deny All Rule

Traffic that does not match any rule in the main IP rule set is, by default, dropped by cOS Stream with an action of Deny and it is also logged. This denial is silent with no response sent to the source. Although not visible in the main IP rule set, this is the result of an implicit Deny All rule which is automatically encountered at the end of rule set scanning if there has been no previous match.

To override the default behavior of the implicit Deny All rule, an explicit IP rule must be created with a filter that triggers on all source/destination networks/interfaces and all services. This rule is then placed as the last entry in the main IP rule set. This explicit rule can then be used to change any of the following behaviors:

Changing the default silent action of Deny only to SendReject (this action is described in Section 7.3, IP Rule Actions).
Changing the default logging of dropped traffic to not logging it at all.
Making log identification easier if logging is enabled by having a specific rule name appear in the log message.

Example 7.1. Adding a Deny All IP Rule

This example shows how to create a Deny All rule that explicitly drops any IPv4 or IPv6 traffic not caught by any preceding rules in the main IP rule set. The action will be set to Deny but with the SendReject option enabled. Logging will not be enabled.

Command-Line Interface

First, change the current context to be the main IP rule set:

System:/> cc RuleSet IPRuleSet main

Now, create the IP rule:

System:/IPRuleSet/main> add IPRule Action=Deny
			Service=all_services
			SourceInterface=any
			SourceNetwork=all-nets
			DestinationInterface=any
			DestinationNetwork=all-nets
			OnDeny=SendReject
			LogEnabled=No
			Name=main_deny_all
Added IPRule/1.

After the rule is added to an empty rule set, it can be displayed by using its index number:

System:/IPRuleSet/main> show IPRule 1

              Property  Value
 ---------------------  ------------
                Index:  1
                 Name:  main_deny_all
      SourceInterface:  any
 DestinationInterface:  any
        SourceNetwork:  all-nets
   DestinationNetwork:  all-nets
              Service:  all_services
               Action:  Deny
               OnDeny:  SendReject (Send Reject)
           LogEnabled:  No
             Comments:  <empty>

Now, return to the default, root context:

System:/IPRuleSet/main> cc
System:/>

These configuration changes must now be saved by entering an activate followed by a commit command.