Home  Prev  cOS Stream 4.00.03 Administration Guide  Next

Chapter 7: IP Rules

7.1. Security Policies

Before examining the main IP rule set in detail, it is useful to first look at the general concept of security policies.

Security Policy Characteristics

Security policies are configured by the administrator to regulate the way in which traffic can flow through the Clavister NetShield Firewall. Such policies are described by the rules defined in the main IP rule set. Security policies created within this rule set share a uniform means of specifying filtering criteria which determine the type of traffic to which they will apply. Usually, the filtering criteria consist of the following rule properties:

Source Interface
An Interface where the packet is received on the Clavister NetShield Firewall. This could also be a physical Ethernet interface but might be a configuration object that acts as an interface such as a VPN tunnel.
Source Network
The network that contains the source IP address of the packet. This is usually an IP address object which defines a single IP address, a range of addresses or a network.
Destination Interface
An Interface from which the packet would leave the Clavister NetShield Firewall. This could also be a physical Ethernet interface but might be a configuration object that acts as an interface such as a VPN tunnel.
Destination Network
The network to which the destination IP address of the packet belongs. This is usually an IP address object which defines a single IP address, a range of addresses or a network.
Service

The protocol type to which the packet belongs. Service objects define different protocols. Examples are HTTP and ICMP communication.

A number of predefined service objects exist but administrator defined custom services can also be created. Existing service objects can also be collected together into Service Groups so that a group can be specified in a policy rule instead of a single service.

IP Rules and the Main Rule Set

IP rules created within the main rule set determine the critical packet filtering function of cOS Stream, regulating what is allowed or not allowed to pass between different interfaces and between interfaces and cOS Stream.

One IP rule set exists, and this rule set is named main. The object type IPRuleSet exists in the category RuleSet so the CLI command to change the context to main is: 

System:/> cc RuleSet IPRuleSet main

If tab completion is not being used, this can be shortened to 

System:/> cc IPRuleSet main

Examples in this guide will assume tab completion is used with the longer form.

[Note] Note: There Is Only One Rule Set

In cOS Stream there is only one IP rule set and that rule set is called main. It is not possible to create additional rule sets.

There are two possible approaches to how traffic traversing the Clavister NetShield Firewall could be dealt with:

  • Everything is denied unless specifically permitted.

  • Or everything is permitted unless specifically denied.

To provide optimal security from the outset, cOS Stream uses the first of these approaches. This means that when started for the first time, cOS Stream has no IP rules defined in the main IP rule set and all traffic arriving at all interfaces is therefore dropped. In order to permit any traffic to traverse the Clavister NetShield Firewall (as well as allowing cOS Stream to respond to ICMP Ping requests), some initial IP rules must be added to the configuration.

Each IP rule that is added by the administrator will define the following basic filtering criteria:

  • From what interface to what interface traffic flows (the Source Interface and Destination Interface).

  • From what network to what network the traffic flows (the Source Network and Destination Network).

  • What kind of protocol is affected (the Service).

  • What action the rule will take when a match on all the criteria is triggered (the Action).

IPv4 and IPv6 addresses for the network properties can coexist in the main IP rule set as well as in the same IP rule.

Specifying Any Interface or Network

When specifying the filtering criteria in any of the rule sets specified above there are a number of useful predefined filtering parameters that can be used:

  • For a Source or Destination Network, the all-nets-ip4 address object is equivalent to the IPv4 address 0.0.0.0/0 which will mean that any IPv4 address is acceptable.

    Similarly, the all-nets-ip6 address object is equivalent to any IPv6 address. The address object all-nets includes both all-nets-ip4 and all-nets-ip6.

  • For Source or Destination Interface, the any option can be used so that cOS Stream will not care about the interface which the traffic is going to or coming from.

  • The Destination Interface can be specified as core. This means that traffic, such as an ICMP Ping, is destined for the Clavister NetShield Firewall itself and cOS Stream will respond to it.

    New flows that are initiated by cOS Stream itself do not need an explicit IP rule as they are allowed by default. For this reason, the interface core is not used as the source interface.

  • The Service can be specified as all_services which includes all possible protocols.

Traffic Flow Needs an IP Rule and a Route

As stated above, when cOS Stream is started for the first time, all traffic is dropped so at least one IP rule must be added to allow the traffic to flow. In fact, the following conditions need to be satisfied:

  • A route must exist in a routing table which specifies on which interface packets should leave in order to reach their destination.

    A second route must also exist that indicates the source of the traffic is found on the interface where the packets enter. This satisfies the reverse route lookup check performed by cOS Stream when a new flow is established.

  • An IP rule in the main IP rule set which specifies the security policy that allows the packets from the source interface and network bound for the destination network to leave the Clavister NetShield Firewall on the interface decided by the route.

    If the IP rule used is an Allow rule then this is bi-directional by default.

The ordering of these steps is important. The route lookup occurs first to determine the exiting interface and then cOS Stream looks for an IP rule that allows the traffic to leave on that interface. If a rule does not exist allowing the traffic then it is dropped.

Simplified Traffic Flow

Figure 7.1. Simplified Traffic Flow

Before the route lookup is done, cOS Stream first checks that traffic from the source network should, in fact, be arriving on the interface where it was received. This is done by cOS Stream performing a reverse route lookup which means that the relevant routing table is searched for a route that indicates the network should be found on that interface.

This second route should logically exist if a flow is bi-directional and it must have a pair of routes associated with it, one for each direction.

Changing Multiple IPRule Objects Together

Because IP rules are indexed objects (each rule has a unique number in its rule set) it is possible to either apply the set or delete commands to multiple rules at the same time by using the -Range option.

For example, to change the LogEnabled property for all IP rules from index number 65 to 80 (inclusive), the command would be the following: 

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> set IPRule -Range=65-80 LogEnabled=No

A general discussion of the -Range option can be found in Section 2.1.3, The CLI.

IP Rule Snooping

A helpful troubleshooting command that can be used to see which IP rules are triggering in real-time is rulesnoop. However, this command is only available when the advanced command view is first enabled using the following command: 
System:/> cmdview advanced
The rulesnoop command allows the administrator to receive messages on the console when IPRule objects trigger. Filters can be added to the command to specify which types of rules are of interest. The basic form of the command should specify the receive interface (in other words the SourceInterface of the IP rule). The value ALL can be used to specify all interfaces: 
System:/> rulesnoop all
If the administrator is only interested in turning on rule snooping for the if1 interface then the command would be: 
System:/> rulesnoop if1
In addition, a destination network and/or a source network can be specified as filters for the command. The destination network filter must always be specified first and can be the special value all-nets. For example, to apply a destination network filter for 203.0.113.0/24, the command would be the following: 
System:/> rulesnoop if1 203.0.113.0/24
The -verbosity parameter can be used to increase the amount of detail provided. The default value for this parameter is BASIC but this can be increased to INFORMATIVE and then increased further to EXTREME. For example: 
System:/> rulesnoop if1 -verbosity=informative

Rule snooping will continue until either CTRL-C is typed by the administrator or the following command is entered: 

System:/> rulesnoop none

A complete list of rulesnoop options can be found in the separate CLI Reference Guide.

Home  Prev   Next