Set up the Deep Security firewall
Deep Security Firewall is a highly flexible firewall that you can configure to be restrictive or permissive. Like the Intrusion Prevention
The configuration and administration of your firewall must be performed carefully and there is no one set of rules that fits all environments. Make sure you understand the firewall rule actions and rule priorities before creating your rules and proceed with extra caution when creating Allow rules because they implicitly deny everything else not defined.
In this article:
- Test in Tap mode before switching to Inline mode
- Turn on Firewall
- Default firewall rules
- Restrictive or permissive firewall design
- Firewall rule actions
- Firewall rule priorities
- Recommended firewall policy rules
- Reconnaissance scans
- Stateful inspection
- Important things to remember
The Firewall module (as well as the Intrusion Prevention and Web Reputation modules) uses the Deep Security Network Engine, which can operate in one of two modes:
- Inline mode: Packet streams pass directly through the Deep Security network engine. All rules are applied to the network traffic before they proceed up the protocol stack
- Tap mode: 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, Deep Security offers no protection beyond providing a record of events.
It is a good idea to test your Firewall rules in Tap mode. Once you are satisfied that the rules are working correctly, switch to Inline mode.
To switch between Inline and Tap mode, open a Policy or Computer Editor and go to Settings > Advanced > Network Engine Mode.
To enable Firewall functionality on a computer:
- In the Policy/Computer editor, go to Firewall > General.
- Select On and then click Save.
No outbound rules are assigned to the policies that come with Deep Security by default but several recommended inbound rules are. You can view the default inbound rules assigned to each policy by going to the Firewall tab in the relevant operating system policy. The example below shows the default assigned firewall rules for the Windows 8 Desktop policy. You can configure these firewall rules to meet the needs of your environment but we have pre-configured several for you to get you started.
To minimize the impact on system performance, try not to assign more than 300 firewall rules. It is also good practice to document all firewall rule changes in the Description field of the firewall rule. Make a note of when and why rules were created or deleted for easier firewall maintenance.
Default Bypass Rule for Deep Security Manager Traffic
The Deep Security Manager automatically implements a Priority 4 Bypass Rule that opens the agent's listening port number for heartbeats on computers running Deep 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 Deep Security Agent's listening ports, you can create an alternative, more restrictive, Bypass Rule for this port. The Agent will override the default Manager traffic rule with the new custom rule if it has these settings:
- Priority: 4 - Highest
- Packet direction: Incoming
- Frame type: IP
- Protocol: TCP
- Packet Destination Port: Agent's listening port for heartbeats from the Manager
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.
Typically, firewall policies are based on one of two design strategies. Either they permit any service unless it is expressly denied or they deny all services unless expressly allowed. It is best practice to decide what type of firewall you would like to implement. This helps reduce administrative overhead in terms of creating and maintaining the rules.
A restrictive firewall is the recommended best practice from a security perspective. All traffic is stopped by default and only traffic that has been explicitly allowed is permitted. If the primary goal of your planned firewall is to block unauthorized access, the emphasis needs to be on restricting rather than enabling connectivity. A restrictive firewall is easier to maintain and more secured. Allow rules are used only to permit certain traffic across the firewall and deny everything else.
As soon as you assign a single outgoing Allow rule, the outgoing firewall will operate in restrictive mode. This is also true for the inbound firewall: as soon as you assign a single incoming Allow rule, the inbound firewall will operate in restrictive mode.
A permissive firewall permits all traffic by default and only blocks traffic believed to be malicious based on signatures or other information. A permissive firewall is easy to implement but it provides minimal security and requires complex rules. Deny rules are used to explicitly block traffic.
You can configure the Deep Security Firewall to take the following actions:
If you assign only incoming rules, all outgoing traffic will be allowed. If you assign a single outgoing Allow rule, the outgoing firewall will operate in restrictive mode. There is one exception to this: ICMPv6 traffic is always permitted unless it is specifically blocked by a Deny rule.
|Allow|| Explicitly allows traffic that matches the rule to pass and then implicitly denies everything else.
Note: You should use Allow with caution because it implicitly denies everything else not defined. Be careful when creating Allow rules without defining the related rules correctly because doing so can cause all traffic to be blocked except for the traffic that the Allow rule is created for. Traffic that is not explicitly allowed by an Allow rule is dropped and gets recorded as a Out of "allowed" Policy Firewall event.
|Bypass||Allows traffic to bypass both firewall and intrusion prevention analysis. Bypass Rules should always be created in pairs (for both incoming and outgoing traffic). A Bypass Rule can be based on IP, port, traffic direction, and protocol.
The Bypass rule is designed for media-intensive protocols.
|Deny||Explicitly blocks traffic that matches the rule.|
|Force Allow|| If a packet matches a Force Allow rule, it is passed but still filtered by Intrusion Prevention. No events are logged.
This type of firewall rule action must be used for UDP and ICMP traffic.
|Log only||Traffic will only be logged. No other action will be taken.|
Rule priority determines the order in which filters are applied. This means that high priority rules get applied before low priority rules. When actions share the same priority, the orders of precedence for rules are: Bypass, Force Allow, and then Deny. However, a Deny action with a higher priority will take precedence over a Bypass action with a lower priority.
To simplify the administration of firewall rules, consider reserving certain priority levels for specific actions. For example, apply a default of Priority 3 to rules that use Bypass, Priority 2 for Force Allow rules, and Priority 1 for Deny rules. This reduces the potential for rule conflicts.
Allow rules can only have a priority of 0. This is to ensure it is processed after all Force Allow and Deny rules at higher priorities. Keep this in mind when using Allow rules to implicitly deny traffic (any traffic not matching the Allow rules are denied). This means that when a Deny rule is assigned, it will take precedence over all of the existing assigned Allow rules.
Force Allow rules
Force Allow rules are recommended for traffic that must always be allowed, such as Address Resolution Protocol (ARP). The Force Allow action only acts as a trump card to a deny rule at the same or higher priority. For example, if you have a Deny rule at priority 3 that prevents access to an allowed port number from the 10.0.0.0/8 subnet, and you want to allow host 10.102.12.56 to access that, you must create a Force Allow rule at priority 3 or 4 to trump the Deny rule at priority 3. Once a packet triggers this rule, it is immediately allowed and the lower priority rules will not process it anymore.
The Bypass Rule is a special type of rule that allows a packet to bypass both the firewall and Deep Packet Inspection (DPI) engines. This rule must be placed at priority 4 and must be created in pairs, one rule for each traffic direction.
We recommend that you make the following rules mandatory for all of your firewall policies:
- ARP: This rule allows incoming ARP requests for the host to reply to queries for its MAC address. If you do not assign this rule, no devices on the network can query the host for its MAC address and it will be inaccessible from the network.
- Allow solicited TCP/UDP replies: Ensures that the 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.
- DNS Server: Ensures that the DNS servers can receive inbound DNS requests.
- Remote Access RDP: Ensures that the computer can accept Remote Desktop connections.
- Remote Access SSH: Ensures that the computer can accept SSH connections.
You can configure the Deep Security Firewall to detect possible reconnaissance scans and help prevent attacks by blocking traffic from the source IPs for a period of time. Once an attack has been detected, you can instruct the Agents/Appliances to block traffic from the source IPs for a period of time. Use the Block Traffic lists on the on the Policy/Computer Editor > Firewall > Reconnaissancetab to set the number of minutes.
- Computer OS Fingerprint Probe: The Agents/Appliances will recognize and react to active TCP stack OS fingerprinting attempts
- Network or Port Scan: The Agents/Appliances will recognize and react to port scans.
- TCP Null Scan: The Agents/Appliances will refuse packets with no flags set.
- TCP SYNFIN Scan: The Agents/Appliances will refuse packets with only the SYN and FIN flags set.
- TCP Xmas Scan: The Agents/Appliances will refuse packets with only the FIN, URG, and PSH flags set or a value of 0xFF (every possible flag set).
For each type of attack, the Agent/Appliance can be instructed to send the information to the Deep Security Manager where an Alert will be triggered by selecting the option Notify DSM Immediately. For this option to work, the Agents/Appliances must be configured for Agent/Appliance initiated or bidirectional communication in Policy/Computer Editor > Settings > Computer.) If enabled, the Agent/Appliance will initiate a heartbeat to the Deep Security Manager immediately upon detecting the attack or probe.
If you want to enable reconnaissance protection, you must also enable the Firewall and Stateful Inspection on the Policy/Computer Editor > Firewall > General tab. You should also go to the Policy/Computer Editor > Firewall > Advanced tab and enable the Generate Firewall Events for packets that are 'Out of Allowed Policy' setting. This will generate Firewall events that are required for reconnaissance.
Deep Security Firewall Stateful Configuration mechanism should be enabled when the firewall is on. This mechanism analyzes each packet in the context of traffic history, correctness of TCP and IP header values, and TCP connection state transitions. In the case of stateless protocols like UDP and ICMP, a pseudo-stateful mechanism is implemented based on historical traffic analysis.
Packets are handled by the stateful mechanism as follows:
- A packet is passed to the stateful routine if it has been allowed through by the static Firewall Rule conditions.
- The packet is examined to determine whether it belongs to an existing connection.
- The TCP header is examined for correctness (for example, sequence numbers, flag combinations, and so on).
The Deep Security Firewall Stateful Configuration enables protection against attacks such as denial of service, provided that a default configuration with stateful TCP / ICMP / UDP is enabled and only solicited replies are allowed. If the UDP stateful option is enabled, Force Allow must be used when running UDP servers (for example, DHCP). If there is no DNS or WINS server configured for the Deep Security Agents, a Force Allow Incoming UDP Ports 137 rule might be required for NetBIOS.
Stateful logging should be disabled unless required for ICMP / UDP protocols.
This is an example of how a simple firewall policy can be created for a web server:
- First enable stateful inspection for TCP, UDP, and ICMP using a global Firewall Stateful Configuration with these options enabled.
- 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 check box 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).
- 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 check box. 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.
Add a Firewall Rule to allow incoming TCP traffic to port 80 and 443 with the Syn check box 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.
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.
- 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.
- 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 (Windows shares).