cOS Core security policies are configured by the administrator to regulate the way in which traffic can flow through the Clavister Security Gateway. Such policies are described by the contents of
different cOS Core rule sets. These rule sets share a uniform means of specifying filtering criteria which determine the type of traffic to which they will apply. The possible filtering criteria are Source/Destination interface and network, Service.

Rule sets can be:

• IP Rules set – here you specify which traffic is permitted to pass through as well as determining the network translation.
• IP Polices set – this is alternative to IP rule object. They are designed to simplify the creation of policies and make it easier to define NAT rules
• Pipe Rules set – used for traffic shaping
• Policy-based Routing Rules – used for PBR
• IDP Rules set
  
• Authentication rules set
  

IP Rule Actions

• Allow – The packet is allowed to pass. As the rule is applied to only the opening of a connection, an entry in the „state table“ is made to record that a connection is open. The remaining packets related to this connection will pass through the cOS Core „stateful engine“.
• FwdFast – Let the packet pass through the Clavister Security Gateway without setting up a state for it in the state table. This means that the stateful inspection process is bypassed and is therefore less secure than Allow or NAT rules. Packet processing time is also slower than Allow rules since every packet is checked against the entire rule set. FwdFast action guarantees that the TCP sequence number is unaltered. Other IP rule actions, such as Allow and NAT change the TCP sequence number as traffic flows through cOS Core.In some situations with certain types of network equipment, the TCP sequence number needs to remain the same as data traffic traverses the security gateway.
• NAT – This functions like an Allow rule, but with dynamic address translation (NAT) enabled
• SAT – This tells cOS Core to perform static address translation. A SAT rule always requires a matching Allow, NAT or FwdFast IP rule further down the rule set.
• Drop – This tells cOS Core to immediately discard the packet. This is an „impolite“ version of Reject in that no reply is sent back to the sender. It is often preferable since it gives a potential attacker no clues about what happened to their packets.
• Reject – This acts like Drop but will return a TCP RST or ICMP Unreachable message, informing the sending computer that the packet was dropped. This is a „polite“ version of the Drop IP rule action. Reject is useful where applications that send traffic wait for a timeout to occur before realizing that the traffic was dropped. If an explicit reply is sent indicating that the traffic was dropped, the application need not wait for the timeout.

Logging – When an IP Rule or IP Policy object is created the default is that logging is enabled. This means that a log message is generated whenever either is triggered. This behavior can be altered by disabling logging on the individual rule or policy object.

Multiple IP Rule Sets

cOS Core allows the administrator to define multiple IP rule sets which can both simplify and provide greater flexibility when defining security policies. The default IP rule set is known as main
and is always present in cOS Core. Additional rule sets can be defined as needed and are given a name by the administrator. Multiple IP rule sets offer many advantages, among them:

• The administrator can break a single large IP rule set into multiple, smaller and more manageable rule sets.
• A single named IP rule set can be associated with a routing table. This makes implementing Virtual Routing much simpler since each router can have a dedicated IP Rules-set associated
  with it.
• IP rule lookup speed can be increased for large numbers of rules by breaking one large rule set down into several smaller ones.

When multiple rule sets are defined, the way they are processed for a new connection is as follows:

• The primary main IP rule set is always searched first for matches of source/destination interface/network.
• User-defined rule sets are used in a rule look-up only when the action specified for a matching rule in main is Goto. The Goto action must have a named, administrator defined IP
  rule set associated with it and if the traffic matches the Goto rule then the rule look-up continues from the beginning of that named rule set. A Goto may never use the main rule set as its target.
• If the search in the named rule set finds no match then the connection is dropped.
• If a match is found in the named rule set then the action is executed. The action might be another Goto in which case the rule scanning jumps to the beginning of another named rule set.
• If the action is Return then the rule scanning resumes at the rule which follows the last Goto action

Below are two simple IP Rule set tables which illustrate how multiple rule sets might be used. The main rule set contains a first rule which has a Goto action which references the named
administrator defined table called ExtraRules. The administrator defined rule set ExtraRules contains a NAT and SAT rule. If neither are triggered then the final rule has a Return action which will cause the scanning process to go back to the rule in main which follows the Goto rule. In this case it will be the second rule in main.

When the main rule set starts to contain many thousands of rules, the speed of IP rule lookup can become impaired and this can degrade the overall throughput of the security gateway. Typical
symptoms of this can be:

• Consistently high CPU loads in the security gateway.
• Unusually long loading times for Web Interface pages (which is a result of high CPU loads).

The solution is to break the large table up and place the rules into several new rule sets, each containing the rules related to a generalized aspect of traffic throughput. A small number of IP rules with a Goto action are then added to the main rule set, and these point to the rule set that contains the individual rules that related to the traffic that triggers the Goto. For example, the main IP rule set may contain many thousands of rules where the Destination Network might be one of number of networks such as dmz_net, lan_net or wan_net. It can be much more efficient to divide these rules based on Destination Network and place each group in new rule sets which might be called dmz_rules, lan_rules and wan_rules.

When a new connection is opened with dmz_net as the destination, cOS Core first performs a lookup in the main table. The Goto rule triggers and the rule search continues in the rule set called dmz_ip_rules. This example uses the destination network as the method of dividing up the rules but another factor, such as an interface, could have been used. The diagram below illustrates the example.

IP Rule Set Folders

In order to help organize large numbers of entries in IP rule sets, it is possible to create IP rule set folders. These folders are just like a folder in a computer’s file system. They are created with a given name and can then be used to contain all the IP rules that are related together as a group. Using folders is simply a way for the administrator to conveniently divide up IP rule set entries and no special properties are given to entries in different folders. cOS Core continues to see all entries as though they were in a single set of IP rules. The folder concept is also used by cOS Core in the address book, where related IP address objects can be grouped together in administrator created folders.

Object Groups

The concept of folders can be used to organize groups of cOS Core objects into related collections. These work much like the folders concept found in a computer’s file system. Folders are described in relation to the address book and can also be used when organizing IP rules. A compliment and alternative to folders for organizing objects is using configuration object groups.

Object groups allows the administrator to gather together and color code configuration objects under a specified title text so their relationships are more easily understood when they are displayed in a cOS Core graphical user interface. Unlike folders, they do not require each folder to be opened for individual objects to become visible. Instead, all objects in all groupings are visible at once. Object groups can be used not only for address book objects but in most cases where cOS Core objects are displayed as tables and each line represents an object instance. The most common usage of this feature is likely to be for either the cOS Core Address Book to arrange IP addresses or for organizing rules in IP rule sets.

IP Policies

The IP Rule objects described previously provide very finely grained control over how arriving traffic is handled by cOS Core. The IP Policy object provides the ability to achieve the same results
as IP rules but in a more intuitive way so that simple policies can be quickly defined. The aim with an IP policy is to hide some of the potential complexities of IP rules. For example, a NAT policy might require several IP rules but may be achievable with a single IP policy. The several IP rules are still created in the background but the administrator is only aware of the IP policy object.
It is up to the administrator to decide if they will use an IP rule or an IP policy to describe what is required from cOS Core. Where there is a choice, using an IP policy is recommended.