Firewall rule actions
Firewall rules can take the following actions:
-
Allow: Explicitly allows traffic that matches the rule to pass, and then implicitly denies everything else.
-
Bypass: Allows traffic to bypass both firewall and intrusion prevention analysis. Use this setting for media-intensive protocols or for traffic originating from trusted sources. A bypass rule can be based on IP, port, traffic direction, and protocol.
-
Deny: Explicitly blocks traffic that matches the rule.
-
Force Allow: Forcibly allows traffic that would otherwise be denied by other rules.
Note
Traffic permitted by a Force Allow rule will still be subject to analysis by the intrusion prevention module. -
Log only: Traffic will only be logged. No other action will be taken.
More about Allow rules
NoteTraffic that is not explicitly allowed by an Allow rule is dropped, and gets
recorded as an 'Out of "Allowed" Policy' firewall event.
|
Commonly applied Allow rules include:
Allow rules have two functions:
Procedure
- Permit traffic that is explicitly allowed.
- Implicitly deny all other traffic.
What to do next
- ARP: Permits incoming Address Resolution Protocol (ARP) traffic.
- Allow solicited TCP/UDP replies: Allow the computer to receive replies to its own TCP and UDP messages. This works in conjunction with TCP and UDP stateful configuration.
- Allow solicited ICMP replies: Allow the computer to receive replies to its own ICMP messages. This works in conjunction with ICMP stateful configuration.
More about Bypass rules
The Bypass rule is designed for media-intensive protocols or for traffic
originating from trusted sources where filtering by the firewall or intrusion
prevention modules is neither required nor desired.
A packet that matches the conditions of a Bypass rule:
- Is not subject to conditions of stateful configuration settings.
- Bypasses both firewall and Intrusion prevention analysis.
Since stateful inspection is not applied to bypassed traffic, bypassing traffic
in one direction does not automatically bypass the response in the other
direction. Bypass rules should always be created and applied in pairs, one rule
for incoming traffic and another for outgoing.
NoteBypass rule events are not recorded. This is not a configurable behavior.
|
Default Bypass rule for Server & Workload Protection traffic
Server & Workload Protection automatically implements a priority
4 Bypass rule that opens incoming TCP traffic on the agent's listening port for
heartbeats on computers running the agent. Priority 4 ensures that this rule is
applied before any Deny rules, and Bypass guarantees that the traffic is never
impaired. The Bypass rule is not explicitly shown in the firewall rule list
because the rule is created internally.
This rule, however, accepts traffic from any IP address and any MAC address. To
harden the agent's security on this port, you can create an alternative, more
restrictive bypass rule for this port. The agent will actually disable the
default Server & Workload Protection traffic rule in favor of
the new custom rule provided it has these characteristics:
- Priority: 4 - Highest
- Packet direction: Incoming
- Frame type: IP
- Protocol: TCP
- Packet Destination Port: agent's listening port number for heartbeats from Server & Workload Protection
The custom rule must use the above parameters to replace the default rule.
Ideally, the IP address or MAC address of Server & Workload Protection should be used as the packet source
for the rule.
More about Force Allow rules
The Force Allow option excludes a sub-set of traffic that could otherwise have
been covered by a Deny action. Its relationship to other actions is illustrated
below. Force Allow has the same effect as a Bypass rule. However, unlike Bypass,
traffic that passes the firewall because of this action is still subject to
inspection by the intrusion prevention module. The Force Allow action is
particularly useful for making sure that essential network services are able to
communicate with the DSA computer. Generally, Force Allow rules should only be
used in conjunction with Allow and rules to Allow a subset of traffic that has
been prohibited by the Allow and Deny rules. Force Allow rules are also required
to Allow unsolicited ICMP and UDP traffic when ICMP and UDP stateful are
enabled.
Firewall rule sequence
Packets arriving at a computer get processed first by firewall rules, then the
firewall stateful configuration conditions, and finally by the intrusion
prevention rules.
This is the order in which firewall rules are applied (incoming and
outgoing):
Procedure
- Firewall rules with priority 4 (highest)
- Bypass
- Log Only (Log Only rules can only be assigned a priority of 4 (highest))
- Force Allow
- Deny
- Firewall rules with priority 3 (high)
- Bypass
- Force Allow
- Deny
- Firewall rules with priority 2 (normal)
- Bypass
- Force Allow
- Deny
- Firewall rules with priority 1 (low)
- Bypass
- Force Allow
- Deny
- Firewall rules with priority 0 (lowest)
- Bypass
- Force Allow
- Deny
- Allow (Note that an Allow rule can only be assigned a priority of 0 (lowest))
What to do next
NoteIf you have no Allow rules in effect on a computer, all traffic is
permitted unless it is specifically blocked by a Deny rule. Once you create
a single Allow rule, all other traffic is blocked unless it meets the
conditions of the Allow rule. There is one exception to this: ICMPv6 traffic
is always permitted unless it is specifically blocked by a Deny rule.
|
Within the same priority context, a Deny rule will override an Allow rule, and a
Force Allow rule will override a Deny rule. By using the rule priorities system,
a higher priority Deny rule can be made to override a lower priority Force Allow
rule.
Consider the example of a DNS server policy that makes use of a Force Allow rule
to Allow all incoming DNS queries. Creating a Deny rule with a higher priority
than the Force Allow rule lets you specify a particular range of IP addresses
that must be prohibited from accessing the same public server.
Priority-based rule sets allow you set the order in which the rules are applied.
If a Deny rule is set with the highest priority, and there are no Force Allow
rules with the same priority, then any packet matching the Deny rule is
automatically dropped and the remaining rules are ignored. Conversely, if a
Force Allow rule with the highest priority flag set exists, any incoming packets
matching the Force Allow rule will be automatically allowed through without
being checked against any other rules.
A note on logging
Bypass rules will never generate an event. This is not configurable.
Log Only rules will only generate an event if the packet in question is not
subsequently stopped by either:
- a Deny rule, or
- an Allow rule that excludes it.
If the packet is stopped by one of those two rules, those rules will generate the
Event and not the Log Only rule. If no subsequent rules stop the packet, the Log
Only rule will generate an event.
How firewall rules work together
Server & Workload Protection firewall rules have both a rule
action and a rule priority. Used in conjunction, these two properties allow you
to create very flexible and powerful rule-sets. Unlike rule-sets used by other
firewalls, which may require that the rules be defined in the order in which
they should be run, Server & Workload Protection Firewall rules
are run in a deterministic order based on the rule action and the rule priority,
which is independent of the order in which they are defined or assigned.
Rule Action
Each rule can have one of four actions.
Procedure
- Bypass: if a packet matches a Bypass rule, it is passed through both the firewall and the Intrusion Prevention Engine regardless of any other rule (at the same priority level).
- Log Only: if a packet matches a Log Only rule it is passed and the event is logged.
- Force Allow: if a packet matches a Force Allow rule it is passed regardless of any other rules (at the same priority level).
- Deny: if a packet matches a Deny rule it is dropped.
- Allow: if a packet matches an Allow rule, it is passed. Any traffic not matching one of the Allow rules is denied.
What to do next
Implementing an Allow rule will cause all other traffic not specifically covered
by the Allow rule to be denied:
A Deny rule can be implemented over an Allow to block specific types of
traffic:
A Force Allow rule can be placed over the denied traffic to Allow certain
exceptions to pass through:
Rule priority
Rule actions of type Deny and Force Allow can be defined at any one of 5
priorities to allow further refinement of the permitted traffic defined by the
set of Allow rules. Rules are run in priority order from highest (Priority 4) to
lowest (Priority 0). Within a specific priority level the rules are processed in
order based on the rule action (Force Allow, Deny, Allow, log only).
The priority context Allows a User to successively refine traffic controls using
Deny and Force Allow rule combinations. Within the same priority context, an
Allow rule can be negated with a Deny rule, and a Deny rule can be negated by a
Force Allow rule.
NoteRule actions of type Allow run only at priority 0 while rule actions of
type Log Only run only at priority 4.
|
Putting rule action and priority together
Rules are run in priority order from highest (Priority 4) to lowest (Priority 0).
Within a specific priority level the rules are processed in order based on the
rule action. The order in which rules of equal priority are processed is as
follows:
- Bypass
- Log Only
- Force Allow
- Deny
- Allow
NoteRemember that rule actions of type Allow run only at priority 0 while rule
actions of type Log Only run only at priority 4.
|
NoteIt is important to remember that if you have a Force Allow rule and a Deny
rule at the same priority the Force Allow rule takes precedence over the
Deny rule and therefore traffic matching the Force Allow rule will be
permitted.
|