Creating a Strong Firewall Security Policy

Using the Firewall Rule Base

The firewall is the core of a well-defined network security policy. The goal of the Check Point Firewall Rule Base is to create rules that only allow the specified connections.

Managing the Firewall Rule Base

Use SmartDashboard to easily create and configure Firewall rules for a strong security policy.

These are the fields that manage the rules for the Firewall security policy.

Explicit and Implied Rules

These are the types of rules in the Rule Base:

• Explicit rules - Rules that you create to configure which connections the Firewall allows
• Implied rules - Rules that are based on settings in the Global Properties menu

Implied rules allow connections for different services that the Security Gateway uses. For example, the Accept Control Connections option allows packets that control these services:

• Installing the security policy on a Security Gateway
• Sending logs from a Security Gateway to the Security Management server
• Connecting to third party applications, such as RADIUS and TACACS authentication servers

To show the implied rules in the Policy window:

1. Make sure there is at least one rule in the Rule Base.
2. Click View > Implied Rules.

   The Policy window in the Firewall tab shows the Rule Base with the explicit and implied rules.

To configure the implied rules:

1. Click Policy > Global Properties.
2. From the navigation tree, click Firewall.
3. Select a rule to enable it, or clear a rule to disable it.
4. For the enabled rules, select the position of the rules in the Rule Base.
5. Click OK and install the policy.

Order of Rule Enforcement

The Firewall inspects connections and enforces the Rule Base in a sequential manner. The Firewall inspects each connection that comes to the network and compares the data (source, destination, service, etc.) to the first rule. If the connection matches the rule, the Firewall applies the action of that rule. If the connection does not match the rule, the Firewall continues with the next rule in the Rule Base.

Make sure that you understand the importance of the order of rule enforcement to maximize the security of the Firewall. The Firewall always enforces the first rule that matches a connection. It does not enforce later rules that can be more applicable.

This is the order that rules are enforced:

1. First Implied Rule: You cannot edit or delete this rule and no explicit rules can be placed before it.
2. Explicit Rules: These are rules that you create.
3. Before Last Implied Rules: These implied rules are applied before the last explicit rule.
4. Last Explicit Rule: We recommend that you use the Cleanup rule as the last explicit rule.
5. Last Implied Rules: Implied rules that are configured as Last in Global Properties.
6. Implied Drop Rule: Drops all packets without logging.

   Note - If you use the Cleanup rule as the last explicit rule, these rules are not enforced: Last implied rule Implied drop rule

Creating a Secure Firewall Rule Base

Basic Rules

These are basic access control rules we recommend for all Rule Bases:

• Stealth rule that prevents direct access to the Security Gateway.
• Cleanup rule that drops all traffic that is not allowed by the earlier rules.

  There is also an implied rule that drops all traffic, but you can use the Cleanup rule to log the traffic.

Sample Firewall Rule Base

This table shows a sample Firewall Rule Base for a typical security policy. (The Hits and VPN columns are not shown.)

1. Stealth - All traffic that is NOT from the internal company network to one of the Security Gateways is dropped. When a connection matches the Stealth rule, an alert window opens in SmartView Monitor.
2. Critical subnet - Traffic from the internal network to the specified resources is logged. This rule defines three subnets as critical resources: Finance, HR, and RnD.
3. Tech support - Allows the Technical Support server to access the Remote-1 web server which is behind the Remote-1 Security Gateway. Only HTTP traffic is allowed. When a packet matches the Tech support rule, the Alert action is done.
4. DNS server - Allows UDP traffic to the external DNS server. This traffic is not logged.
5. Mail and Web servers - Allows incoming traffic to the mail and web servers that are located in the DMZ. HTTP, HTTPS, and SMTP traffic is allowed.
6. SMTP - Allows outgoing SMTP connections to the mail server. Does not allow SMTP connections to the internal network, to protect against a compromised mail server.
7. DMZ and Internet - Allows traffic from the internal network to the DMZ and Internet.
8. Clean up rule - Drops all traffic. All traffic that is allowed matched one of the earlier rules.

Defining Security Zones

Networks use different security zones to protect very important resources and to defend against malware. Create rules that allow only the applicable traffic in and out of a security zone. Make sure that there are different rules in the Firewall Rule Base that define traffic to and from the security zones. These are the key elements that define security zones:

• External network - Insecure data, such as the Internet
• Internal network - Company data that is only used by trusted and authenticated users
• Perimeter - The border between the internal and external networks.
• DMZ - Company servers that can be accessed from insecure sources, such as the Internet

Perimeter

The Firewall on the perimeter of the network is responsible for all the incoming and outgoing traffic. These are some of the connections that are usually allowed by a Firewall on the perimeter:

• Outgoing connections to the Internet
• Connections to the DNS server
• Specified external connections
• Connections to servers in the DMZ
• Connections from the internal network to the internal network
• VPN connections

DMZ

Servers that are accessed by the Internet are usually located in a DMZ (demilitarized zone). The DMZ makes sure that these servers cannot connect to the internal network. Make sure that the Rule Base contains rules for DMZ traffic. For example, these are rules for a web server in the DMZ:

• A rule that allows HTTP and HTTPs traffic to the DMZ network object
• A rule that allows traffic from the internal network group object to any destination (the destination includes the DMZ)

Preventing IP Spoofing

Firewall rules can be based on Source and Destination IP addresses. Attackers use IP spoofing to change a packet's IP address and make a packet look like it is from a trusted source. If your network is not protected against IP spoofing, attackers can exploit the vulnerability in the Firewall rules and gain access to the network.

Anti-spoofing protection makes sure that the source IP address is the same as the Security Gateway interface. The Firewall blocks a packet that comes to an external interface with a spoofed internal IP address. Check Point Anti-spoofing makes sure that packets go to the correct interface according to the destination IP address.

For the Alaska_GW, the Firewall makes sure that:

• All incoming packets to IF1 come from the Internet.
• All incoming packets to IF2 come from Alaska_LAN or, Alaska_RND_LAN or Florida_LAN.

For the Alaska_RND_GW, the Firewall makes sure that:

• All incoming packets to IF3 come from Alaska_LAN, Florida_LAN or the Internet.
• All incoming packets to IF4 come from Alaka_RND_LAN.

When you configure Anti-spoofing for a Security Gateway, specify if the interfaces go to the Internet (External) or an internal network (Internal).

Configuring Anti-Spoofing

Use the Topology page to configure Anti-spoofing for the external and internal interfaces on the Security Gateway. Configure Anti-spoofing protection on all the interfaces of the Security Gateway, including internal interfaces.

SmartDashboard attempts to automatically retrieve the topology from the Security Gateway. If it cannot retrieve the topology information, make sure that:

• The details in the Security Gateway General Properties window are correct.
• The Security Gateway, the Security Management server, and the SmartDashboard can communicate with each other.

When you configure an internal interface, select the option for the IP addresses that are connected to the interface. These are the network options:

• Not Defined - All IP addresses are considered as part of the internal network that connects to this internal interface.
• Network defined by the interface IP and Net Mask - There is only one network that connects to this internal interface.
• Specific - There is more than one network that connects to this internal interface. Select the group network object that contains all the appropriate networks.

To configure Anti-Spoofing for an interface:

1. In SmartDashboard, from the Network Objects tree, double-click the Security Gateway.

   The General Properties window opens.

2. From the navigation tree, click Topology.
3. Click Get > Interfaces.
4. Click Accept.

5. Select the interface that connects to the Internet and click Edit.

   The Interface Properties window opens.

6. Click the Topology tab.

   

7. Select External or Internal.
8. For Internal interfaces, do these steps:
   1. Select the option for the network IP Addresses behind this interface.
   2. If the internal interface connects to a DMZ, select Interface leads to DMZ.
9. Select Perform Anti-Spoofing based on interface topology.
10. Select an Anti-Spoofing action.
    • Prevent - Drops spoofed packets.
    • Detect - Allows spoofed packets.

      We recommend that you use the Detect option to monitor traffic. You can use it with a Spoof Tracking option to learn about the network topology without rejecting packets.

11. Optional for External Interfaces: Configure the IP addresses that are not included in Anti-spoofing.
    1. Select Don't check packets from.
    2. Click the field, and select the Group or Network object that you are not including in Anti-spoofing.

       You can click New to create a new Group or Network object.

12. From Spoof Tracking, select the tracking action that is done when Anti-Spoofing is detected.
13. Click OK and configure Anti-spoofing for all the interfaces on the Security Gateway.
14. Click OK and install the policy.

Excluding Specific Internal Addresses

In some configurations, the Firewall must allow connections with an internal IP address from an external source. For example, an external application can assign internal IP addresses to external clients. You can configure the Anti-spoofing protection on the external interfaces to ignore connections from these IP addresses. The Firewall allows these connections and does not inspect them.

Analyzing the Rule Base (Hit Count)

Use the Hit Count feature to track the number of connections that each rule matches. You can show Hit Count for the rules in these options:

• The percentage of the rule's hits from total hits
• The indicator level (very high, high, medium, low, or zero)

These options are configured in the Firewall Rule Base and also changes how Hit Count is shown in other supported Software Blades.

When you enable Hit Count, the Security Management server collects the data from supported Security Gateways (from version R75.40 and up). Hit Count works independently from logging and tracks the hits even if the Track option is None.

You can use the Hit Count data to:

• Analyze a Rule Base - You can delete rules that have no matching connections

  Note - If you see a rule with a zero hit count it only means that in the Security Gateways enabled with Hit Count there were no matching connections. There can be matching connections on other Security Gateways.

• Better Firewall performance - You can move a rule that has a high hit count to a higher position in the Rule Base
• Better understand the behavior of the security policy

Enabling or Disabling Hit Count

By default, Hit Count is globally enabled for all supported Security Gateways (from R75.40). The timeframe setting that defines the data collection time range is configured globally. If necessary, you can disable Hit Count for one or more Security Gateways.

After you enable or disable Hit Count you must install the policy for the Security Gateway to start or stop collecting data.

To enable or disable Hit Count globally:

1. From the Policy menu, select Global Properties.
2. Select Hit Count from the tree.
3. Select the options:
   • Enable Hit Count - Select to enable or clear to disable all Security Gateways to monitor the number of connections each rule matches.
   • Keep Hit Count data up to - Select one of the time range options. The default is 6 months. Data is kept in the Security Management Server database for this period and is shown in the Hits column.
4. Click OK and then install the policy.

To enable or disable Hit Count on each Security Gateway:

1. From the Gateway Properties of the Security Gateway, select Hit Count from the navigation tree.
2. Select Enable Hit Count to enable the feature or clear it to disable Hit Count.
3. Click OK and then install the policy.

Configuring the Hit Count Display

These are the options you can configure for how matched connection data is shown in the Hits column:

• Value - Shows the number of matched hits for the rule from supported Security Gateways. Connection hits are not accumulated in the total hit count for:
  • Security Gateways that are not supported (versions before R75.40)
  • Security Gateways that have disabled the hit count feature

  The values are shown with these letter abbreviations:

  • K = 1,000
  • M = 1,000,000
  • G = 1,000,000,000
  • T = 1,000,000,000,000

  For example, 259K represents 259 thousand connections and 2M represents 2 million connections.

• Percentage - Shows the percentage of the number of matched hits for the rule from the total number of matched connections. The percentage is rounded to a tenth of a percent.
• Level - The hit count level is a label for the range of hits according to the table.

  The hit count range = Maximum hit value - Minimum hit value (does not include zero hits)

To configure the Hit Count display:

1. Right-click the Hits column header or the rule number in the row.
2. From the menu, select Display.
3. Select one or more options:
   • Percentage
   • Value
   • Level