Firewall

The Vulnerability ProtectionDeep Security firewall is a bidirectional, stateful firewall that is responsible for making sure that packets originating from unauthorized sources do not reach the applications on its host.

Basic configuration

To enable Firewall functionality on a computer:

1. In the Policy/Computer editor, go to Firewall > General
2. Select On , and then click Save

Inline vs. Tap Mode

The Firewall module uses the Vulnerability ProtectionDeep Security Network Engine which can operate in one of two modes:

• Inline: Live packet streams pass directly through the Vulnerability ProtectionDeep Security network engine. All rules, therefore are applied to the network traffic before they proceed up the protocol stack
• Tap Mode: Live packet streams are replicated and diverted from the main stream.

In Tap Mode, the live stream is not modified. All operations are performed on the replicated stream. When in Tap Mode, Vulnerability ProtectionDeep Security offers no protection beyond providing a record of Events.

To switch between Inline and Tap mode, open a Policy or Computer Editor and go to Settings > Network Engine > Network Engine Mode.

Firewall Rule Properties

Packet Source and Packet Destination

The Firewall can use the following criteria to determine traffic source and destination:

• IP address
• MAC address
• Port

IP Address

The following options are available for defining IP addresses:

• Any: No address is specified so any host can be either a source or destination
• Single IP: A specific machine is identified using its IP address.
• Masked IP: This applies the rule to all machines that share the same subnet mask
• Range: This applies the rule to all machines that fall within a specific range of IP addresses
• IP(s): Use this when applying a rule to several machines that do not have consecutive IP addresses.
• IP List: This uses a Component list, particularly one for IP addresses, to define hosts.

MAC Address

The following options are available for defining MAC addresses:

• Any: No MAC address was specified, so the rule applies to all addresses
• Single MAC: Rule applies to a specific MAC address
• MAC(s): Rule applies to the MAC addresses specified here
• MAC List: Rule applies to MAC addresses in a MAC list

Port

The following options are available for defining Port addresses:

• Any: Rule applies to all ports
• Port(s): Rule applies to multiple ports written here
• Port List: Rule applies to a port list

Transport Protocols

If the rule is meant for the Internet Protocol (IP) frame type, the protocol field is enabled, and administrators will be asked to specify the transport protocol that will be analyzed. The protocol options available are:

• Any (the Firewall will not discriminate based on protocol)
• ICMP
• ICMPV6
• IGMP
• GGP
• TCP
• PUP
• UDP
• IDP
• ND
• RAW
• TCP+UDP
• Other (for which you must provide a protocol number)

Direction

The Vulnerability ProtectionDeep Security firewall is a bidirectional firewall. Therefore it is able to enforce rules on traffic originating from the network to the Vulnerability ProtectionDeep Security host, referred to as incoming, and traffic from the host to the network, referred to as outgoing.

TCP Header Flags

When dealing with TCP traffic, administrators can choose the TCP flags to which rules apply. If the rule does not apply to all flags, administrators can choose from the following:

• Any Flags
• URG
• ACK
• PSH
• RST
• SYN
• FIN

There are a number of ways these flags can be used in different attacks. Only a selection will be discussed here.

The URG flag indicates that the packet is urgent and must be processed before all others, while the PSH flag sets the TCP stack to flush its buffers and send all information up to the application. Both flags can be used in a type port scan called the Xmas scan which is typically a FIN packet with the URG and PSH flags enabled. This scan gets its name from the alternating bits turned on and off in the flags byte (00101001), much like the lights of a Christmas tree.

When an unprotected machine receives packets related to a Xmas scan, the following happens:

Condition	Response
Closed Port	Returns an RST packet
Open Port	No response, exposing existence of the open port

The RST, or RESET, flag abruptly terminates TCP connections. As described above, among its legitimate uses is to terminate connects to closed ports indicating an impossible or disallowed connection. However, the RST flag can also be used as part of a RESET attack, designed to disrupt existing sessions. The following diagram illustrates a situation where an attack, Host C, was able to calculate the TCP sequence number that Host A expected from a packet from Host B, thereby spoofing Host A into believing that Host B had sent it a RST packet. The end result is a denial of service attack:

Frame Types

The term "frame" refers to Ethernet frames, and the available protocols specify the data that the frame carries.

Internet Protocol (IP), Address Resolution Protocol (ARP), and Reverse Address Resolution Protocol (REVARP) are the most commonly carried protocols on contemporary Ethernet networks but by selecting "Other" from the drop-down list you can specify any other frame type by its "frame number".

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 only for media-intensive protocols. 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.
  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

Allow rules have two functions:

1. Permit traffic that is explicitly allowed.
2. Implicitly deny all other traffic.

Commonly applied Allow rules include:

• ARP: Permits incoming Address Resolution Protocol (ARP) traffic .
• Allow solicited TCP/UDP replies: Ensures that the host computer is able to receive replies to its own TCP and UDP messages. This works in conjunction with TCP and UDP stateful configuration.
• Allow solicited ICMP replies: Ensures that the host computer is able 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 where filtering by the Firewall or Intrusion Prevention modules is neither required nor desired. Bypass rules have the following noteworthy characteristics:

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. Because of this, bypass rules should always be created and applied in pairs, one rule for incoming traffic and another for outgoing.

Default Bypass Rule for Vulnerability ProtectionDeep Security Manager Traffic

The Vulnerability ProtectionDeep Security Manager automatically implements a Priority 4 Bypass Rule that opens incoming TCP traffic at port 4118 on host computers running Vulnerability ProtectionDeep Security Agent. Priority 4 ensures that this Rule is applied before any Deny rule, 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 DSA at this port, you can create an alternative, more restrictive, Bypass Rule for this port. The Agent will actually disable the default Manager traffic rule in favor of the new custom rule provided it has the following characteristics:

• Priority: 4 - Highest
• Packet direction: Incoming
• Frame type: IP
• Protocol: TCP
• Packet Destination Port: 4118

The custom rule must use the above parameters to replace the default rule. Ideally, the IP address or MAC address of the actual Manager 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. These default Force allow rules are commonly enabled in real-life:

• Allow
• Deny
• Force Allow

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):

1. Firewall Rules with priority 4 (highest)
   1. Bypass
   2. Log Only (Log Only rules can only be assigned a priority of 4 (highest))
   3. Force Allow
   4. Deny
2. Firewall Rules with priority 3 (high)
   1. Bypass
   2. Force Allow
   3. Deny
3. Firewall Rules with priority 2 (normal)
   1. Bypass
   2. Force Allow
   3. Deny
4. Firewall Rules with priority 1 (low)
   1. Bypass
   2. Force Allow
   3. Deny
5. Firewall Rules with priority 0 (lowest)
   1. Bypass
   2. Force Allow
   3. Deny
   4. Allow (Note that an Allow rule can only be assigned a priority of 0 (lowest))

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 over TCP/UDP port 53. 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

Vulnerability ProtectionDeep Security 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, Vulnerability ProtectionDeep Security 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.

1. 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).
2. Log Only: if a packet matches a log only rule it is passed and the event is logged.
3. Force Allow: if a packet matches a force allow rule it is passed regardless of any other rules (at the same priority level).
4. Deny: if a packet matches a deny rule it is dropped.
5. Allow: if a packet matches an allow rule, it is passed. Any traffic not matching one of the allow rules is denied.

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/force allow combinations to achieve a greater flexibility. 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.

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

Stateful Filtering

When a Stateful Configuration is in effect on a computer, packets are analyzed within the context of traffic history, correctness of TCP and IP header values, and TCP connection state transitions. In the case of stateless protocols (e.g. UDP and ICMP) a pseudo-stateful mechanism is implemented based on historical traffic analysis.

A packet is passed through the stateful routine if it is explicitly allowed via static rules.

• The packet is examined if it belongs to an existing connection by checking the connection table
• The TCP header is examined for correctness (e.g. sequence numbers, flag combination)

Once enabled, the stateful engine is applied to all traffic traversing the interface.

UDP pseudo-stateful inspection, by default, rejects any incoming "unsolicited" UDP packets. If a computer is running a UDP server, a force allow rule must be included in the policy to permit access to that service. For example, if UDP stateful inspection is enabled on a DNS server, a force allow rule permitting UDP traffic to port 53 is required.

ICMP pseudo-stateful inspection, by default, rejects any incoming unsolicited ICMP request-reply and error type packets. A force allow must be explicitly defined for any unsolicited ICMP packet to be allowed. All other ICMP (non request-reply or error type) packets are dropped unless explicitly allowed with static rules.

Putting it all together to design a Firewall Policy

Generally speaking, there are two approaches when defining a firewall policy for a computer:

• Prohibitive: That which is not expressly allowed is prohibited. Prohibitive policies can be created by using a combination of allow rules to describe allowed traffic and deny rules to further restrict permitted traffic.
• Permissive: That which is not expressly prohibited is allowed. Permissive policies can be created through the exclusive use of deny rules to describe the traffic that should be dropped.

In general, prohibitive policies are preferred and permissive policies should be avoided.

Force allow rules should only be used in conjunction with allow and deny 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.

Example

Take the example of how a simple firewall policy can be created for a Web server.

1. First enable stateful inspection for TCP, UDP, and ICMP using a global Firewall Stateful Configuration with these options enabled.
2. Add a Firewall Rule to allow TCP and UDP replies to requests originated on the workstation. To do this create an incoming allow rule with the protocol set to "TCP + UDP" and select the Not checkbox and the Syn checkbox under Specific Flags. At this point the policy only allows TCP and UDP packets that are replies to requests initiated by a user on the workstation. For example, in conjunction with the stateful analysis options enabled in step 1, this rule allows a user on this computer to perform DNS lookups (via UDP) and to browse the Web via HTTP (TCP).
3. Add a Firewall Rule to allow ICMP replies to requests originated on the workstation. To do this, create an incoming allow rule with the protocol set to "ICMP" and select the Any Flags checkbox. This means that a user on this computer can ping other workstations and receive a reply but other users will not be able to ping this computer.
4. Add a Firewall Rule to allow incoming TCP traffic to port 80 and 443 with the Syn checkbox checked in the Specific Flags section. This means that external users can access a Web server on this computer.

At this point we have a basic firewall policy that allows solicited TCP, UDP and ICMP replies and external access to the Web server on this computer all other incoming traffic is denied.

For an example of how deny and force allow rule actions can be used to further refine this Policy consider how we may want to restrict traffic from other computers in the network. For example, we may want to allow access to the Web server on this computer to internal users but deny access from any computers that are in the DMZ. This can be done by adding a deny rule to prohibit access from servers in the DMZ IP range.

5. Next we add a deny rule for incoming TCP traffic with source IP 10.0.0.0/24 which is the IP range assigned to computers in the DMZ. This rule denies any traffic from computers in the DMZ to this computer.

We may, however, want to refine this policy further to allow incoming traffic from the mail server which resides in the DMZ.

6. To do this we use a force allow for incoming TCP traffic from source IP 10.0.0.100. This force allow overrides the deny rule we created in the previous step to permit traffic from this one computer in the DMZ.

Important things to remember

• All traffic is first checked against Firewall Rules before being analyzed by the stateful inspection engine. If the traffic clears the Firewall Rules, the traffic is then analyzed by the stateful inspection engine (provided stateful inspection is enabled in the Firewall Stateful Configuration).
• Allow rules are prohibitive. Anything not specified in the allow rules is automatically dropped. This includes traffic of other frame types so you need to remember to include rules to allow other types of required traffic. For example, don't forget to include a rule to allow ARP traffic if static ARP tables are not in use.
• If UDP stateful inspection is enabled a force allow rule must be used to allow unsolicited UDP traffic. For example, if UDP stateful inspection is enabled on a DNS server then a force allow for port 53 is required to allow the server to accept incoming DNS requests.
• If ICMP stateful inspection is enabled a force allow rule must be used to allow unsolicited ICMP traffic. For example, if you wish to allow outside ping requests a force allow rule for ICMP type 3 (Echo Request) is required.
• A force allow acts as a trump card only within the same priority context.
• If you do not have a DNS or WINS server configured (which is common in test environments) a force allow incoming UDP port 137 rule may be required for NetBios.