This section includes the following topics:This section includes the following topics:
The Rules configuration section represents the ruleset, the "heart" of the firewall. The ruleset is the primary filter which is configured to allow or disallow certain types of network traffic through the firewall. The ruleset also regulates how address translation and bandwidth management, traffic shaping, is applied to traffic flowing through the firewall.
When a new connection is being established through the firewall, the rules are evaluated, top to bottom, until a rule that matches the new connection is found. The Action of the rule is then carried out. If the action is Allow, the connection will be established and a state representing the connection is added to the firewall's internal state table. If the action is Drop, the new connection will be refused. The sections below will explain the meanings of the various action types available.
Consecutive packets belonging to an existing connection will not need to be evaluated by the ruleset. Instead, a highly optimized state-lookup algorithm will search the internal state table for an existing state representing the connection. This methodology is applied not only on TCP connections, but on UDP and ICMP traffic as well. Thus, the size of the firewall ruleset does not affect the throughput of the firewall.
The default action is drop, meaning that traffic that has not been explicitly allowed, will be dropped. The default drop is accomplished without a visible rule in the ruleset. However, for logging purposes, rulesets commonly have a DropAll rule at the bottom of the ruleset with logging enabled.
Name – Specifies a symbolic name for the rule. This name is used mainly as a rule reference in log data and statistics.
Action – Reject, Drop, FwdFast, Allow, NAT or SAT. See below for a more detailed explanation of each action.
Packets matching Drop rules will immediately be dropped. Such packets will be logged if logging has been enabled in the Log Settings page.
Reject works in basically the same way as Drop. In addition to this, the firewall sends an ICMP UNREACHABLE message back to the sender or, if the rejected packet was a TCP packet, a TCP RST message.
Packets matching FwdFast rules are allowed through immediately. In the case of these rules, the firewall does not remember open connections; it does not statefully inspect traffic passed through it under FwdFast rules. This means that a corresponding rule must be in place to allow return traffic to pass through if so required. If logging has been enabled in the Log Settings page, all packets passing through under FwdFast rules are logged.
FwdFast rules are also affected by static address translation specified under SAT rules. However, remember that in this case, SAT rules for return traffic must also be in place if return traffic is required.
In spite of its name, "FwdFast" is normally not faster than state-tracked connections. Looking up an open connection is faster than finding a rule a few lines down in the ruleset, not to mention a rule dozens of lines down in the ruleset. The name refers to the packet taking a "fast path" in the firewall, bypassing the state engine. For one single packet, it is indeed faster than first having to open a state-tracked connection and then passing the packet to it. But when several packets pass over the same connection, state tracking is faster.
The only time when FwdFast rules make real sense is when the firewall only sees one half of a connection, e.g. when traffic in one direction bounces on the inside of the firewall, but the other end knows how to get to the originator directly without bouncing on the firewall. In such a case, a state-tracked connection would not work, and FwdFast rules would have to be used.
Packets matching Allow rules are passed to the stateful inspection engine, which will remember that a connection has been opened. Therefore, rules for return traffic will not be required as traffic belonging to open connections is automatically dealt with before it reaches the ruleset.
Logging is carried out if it has been enabled in the Log Settings page. Log events will be generated when the connection opens, and when it closes.
NAT rules are basically like Allow rules. These rules also perform dynamic address translation, "NAT hide", of the sender address.
The most common area of use for NAT hide is in getting all machines on a protected network to appear to the outside world as if they use a single IP address. This can be used for reasons of security, concealing the internal network structure, or for practical reasons, i.e. to enable machines with private addresses to communicate with public networks.
When a packet matches a SAT rule, nothing happens to begin with. Instead, the firewall will remember that a static address translation will be performed at a later stage and continue to look for a matching rule that will allow the packet to pass. If the packet then matches a FwdFast, Allow or NAT rule, it is allowed to pass. However, if the packet matches a Drop or Reject rule, it is discarded.
The reason for this is that if, for example, a SAT rule is used to allow traffic to a server in a demilitarized zone with a private address, you will still need to differentiate between internally and externally originated connections. Externally originated connections are usually allowed by an Allow rule, whilst internally originated connections are often allowed by NAT rules in order to conceal the internal network structure to the servers in the DMZ.
SAT rule logging is only carried out if logging has been enabled in the final FwdFast, Allow or NAT rule.
Source Interface – Specifies the name of the receiving interface to be compared to the received packet.
Source Network – Specifies the sender span of IP addresses to be compared to the received packet.
Destination Interface – Specifies the name of the interface to be compared to the destination interface for the destination IP in the received packet. Note that the destination interface is a filter, computed by doing a route lookup on the destination IP address in the packet. Also note that, as of v8.5, the route lookup is performed according to policy-based routing rules.
Destination Network
– Specifies the span of IP addresses to be compared to the destination
IP of the received packet.
Note: The destination interface and network is those of the received packet. They are not affected by address rewriting rules. Address rewriting takes places after the rule lookup is completed.
As of v8.5 or above, the secure flag is removed from Clavister Security Gateway, for more information please see knowledge base article #10072.
The Service page is used to specify a service that will be used as a filter parameter when matching traffic with this rule.
|
Pre-defined - Specifies a pre-defined service, see the Services section. Custom - Specifies that a custom service definition should be used for this rule. For more information on how to write a custom service see the Services section. |
|
By adding a schedule to a rule, Clavister Security Gateway will only allow that rule to trigger at those designated times. Any activities outside of the scheduled time slot will not be allowed by that rule and will therefore likely not be permitted to pass through the firewall due to other more restrictive rules.
|
Custom - Specifies that a custom schedule definition should be used for this rule. For more information on how to write a custom schedule see section Schedules.
|
Use the Address Translation page to specify address translation parameters. This page is only available if NAT or SAT has been chosen as Action type for the rule.
For NAT, two address translation options are available; Specify Sender Address and Use Interface Address. Please note that, if Specify Sender Address is chosen, a corresponding ARP publish entry needs to be added in order for the firewall to receive the return traffic.
If SAT is chosen as Action type, the translation can apply to either source or destination IP address and port. See Address Translation of Address or Port Ranges on how to write these kind of rules.
For more information about how to implement address translation, please see the section Using Address Translation.
See also: Log Settings and Server Load Balancing (SLB) .
Pre-defined