Security Policy Best Practices for Check Point Firewalls

Start with network design

A good starting point for good firewall policy is good network design. The ability to use network objects instead of many node objects will result in a more supportable policy. Establish an architecture to your network. Allocate blocks for each part of your network. Use a different IP block for your DMZ than you use for your Internal users, and a different block for Internal servers. Think about potential usage 10 years out. Allocate more IP space for each need than you believe you'll ever use in a decade. A nice roomy network design will allow for flexibility and easier management over time. This will not only help you make efficient, supportable firewall policy, but also nice small summarized and human recognizable routing tables.

Scope and assumptions

This methodology is for the Access Control policy of CheckPoint Security Gateways. It was first written for releases before R80 and has been revised against the R80 and R81 documentation. Threat Prevention policy and IPv6 are not covered.

• The first rule that matches a connection decides it. The order of the sections is the design.
• Implied rules are at their defaults.
• Anti-spoofing is configured on every interface. It is the partner of the Internet group: the group says what is yours, anti-spoofing checks that it arrives where it should.
• Rules are matched on the original, untranslated addresses. Translation is covered in NAT Architecture for Check Point Firewalls.

Guidelines

1. Don't use 'Any' in the Source, Destination, or Service fields for Accept rules. There may be good reasons, but they are few and far between.
2. Create a group object that represents either the DMZ subnets, or a network object for the larger network block from which DMZ subnets are allocated.
3. Create a group object that represents either the Internal subnets, or a network object for the larger network block from which Internal subnets are allocated.
4. Create a group object that contains the Internal and DMZ subnets/blocks. Use this group in its negated form to represent the Internet. A group with exclusion will work as well. Many people don't realize that when they use 'Any' for source or destination, they are including their Internal and DMZ subnets. Do you really need some DMZ server to http/ftp to all Internal servers and workstations? Do you really mean all other DMZ servers can http/ftp/etc. to the publicly accessible DMZ server?
5. Keep that group complete. It should hold every private range and every public block you own. A network left out of it silently becomes part of the Internet, and every rule written for the Internet then applies to it.
6. Utilize a naming convention. It will make finding/using/reading/supporting objects and policy easier. Start the name with the type of object, then the address, then the purpose, and name a group for what it contains.
7. Use those section titles and description fields. Even you will forget why, and for whom, you wrote that rule 18 months from now.
8. Log every rule. The only rules that are not logged are ones that drop named noise, such as NetBIOS broadcasts in the clean up section.
9. End each section by dropping what the section did not allow. A broader rule further down then cannot reopen something the section was meant to restrict.
10. Give a temporary rule an expiry and an owner. Use a time object, and put the date and the requester in the comment.
11. In a policy package installed on more than one gateway, set Install On for every rule.

Firewall policy: major sections

Presented in the intended order.

1. 01Firewall Management
2. 02Stealth Rule
3. 03Remote Access VPN Rules
4. 04Site-to-Site VPN Rules
5. 05High Traffic Rules
6. 06Network Management
7. 07DMZ Rules (Part 1 of 3, Inter-DMZ)
8. 08DMZ Rules (Part 2 of 3, Internet to/from DMZs)
9. 09DMZ Rules (Part 3 of 3, Drop all DMZ traffic)
10. 10Internal Out - Specific
11. 11Internal Out - General
12. 12Clean up

Reading the examples

The bar at the left of each rule, and the Action, show whether it accepts or drops. The Internet is written as not Internal-and-DMZ, the negated group from the guidelines. Every rule is logged unless Track says otherwise.

• Accept
• Drop

01Firewall Management

Allow the firewall(s) to be managed. Allow only the services each management platform needs. Depending on your environment, you may want to allow the firewalls to connect to each other.

CheckPoint control connections, and traffic the firewall itself starts such as DNS, NTP and updates, are allowed by the implied rules at their defaults. If you disable implied rules, the equivalent rules go here.

02Stealth Rule

• Any to Firewall, Drop

A staple in the firewall community. Protect the firewalls. Anything that has to reach the firewall itself must be in the section above.

03Remote Access VPN Rules

I've found that putting the user vpn rules directly following the stealth prevents so many future problems. If you plan to manage the firewalls via a VPN, then you'll need to place a specific rule in Firewall Management section of the policy.

Here, we want to be specific about the source IPs a VPN will use. That is the Office Mode pool. Identify the users with an Access Role; the legacy user@location objects are not supported in a unified policy.

At the end of this section, drop everything else to and from the pool.

04Site-to-Site VPN Rules

• Specific hosts/networks within Encryption Domains to other hosts/network in Encryption Domains, Accept
• VPN Encryption Domains to VPN Encryption Domains, Drop
• Any to Remote VPN Encryption Domains, Drop
• Remote VPN Encryption Domains to Any, Drop

With more than a few communities, put every remote encryption domain in one group and write the three drop rules once, at the end of the section.

05High Traffic Rules

A small number of rules that carry a large share of the connections, placed early.

Use the hit count to decide what belongs here, not a guess. A rule moved up to this section is matched before every drop below it, so only move a rule that could never conflict with one.

From R80.10 the position of a rule has little effect on how fast it is found, so this section matters less than it did. Rule order can still affect SecureXL templates; check before moving rules for performance.

06Network Management

• Network Admins to Management subnets, Accept
• Network Management server to Internal/DMZ subnets, Accept

07DMZ Rules (Part 1 of 3, Inter-DMZ)

• DMZ to DMZ Rules, Accept
• Inside to DMZs, Accept
• DMZs to Inside, Accept

There are many schools of thought on creation of DMZ rules. Your preference should be influenced by the supportability and scalability within your environment. Smaller environments may combine the first two DMZ sections together. Larger environments will likely further divide by Application, DMZ, Application components, DMZ purpose, among other criteria. Below, I'll give basic examples for both small and large environments.

08DMZ Rules (Part 2 of 3, Internet to/from DMZs)

• DMZ Hosts/Subnets to Internet (Negated Group of Internal/DMZ subnets), Accept
• Internet (Negated Group of Internal/DMZ subnets) to DMZ Hosts/Subnets, Accept

09DMZ Rules (Part 3 of 3, Drop all DMZ traffic)

• DMZ subnets to Any, Drop
• Any to DMZ subnets, Drop

This closes the DMZ sections. No rule below this point can allow traffic into or out of a DMZ.

10Internal Out - Specific

• Internal Hosts/Subnet to Specific Internet Hosts, Accept

When access is for named users only, follow the Accept with a Drop for everyone else to the same destination, so the general rules below cannot allow it.

Identify users with an Access Role. Client Authentication is a legacy feature. For a vendor's published address ranges, use an updatable object in place of a group you maintain by hand.

11Internal Out - General

• Internal Hosts/Subnet to Internet (Negated Group of Internal/DMZ subnets), Accept

In a unified policy this is where applications and URL categories are used. Keep them in this section, or in a layer under it, so the sections above stay simple address and port rules.

12Clean up

• Any to Any, Drop

Drop and log everything that reached the end. Drop known noise without logging first, so the log shows only what matters.

Layers

From R80.10 the major sections can be built as inline layers. Each section becomes one parent rule that says what the section is about, with the section's own rules in a layer beneath it.

• The parent rule matches the traffic the section owns, for example anything to or from the DMZ subnets.
• The layer ends with its own explicit clean up rule, logged. That is the "drop what the section did not allow" guideline, enforced by structure.
• A layer can be given to another team to manage without giving them the rest of the policy.
• Keep the order of the parent rules the same as the order of the sections here.

Review and upkeep

• Review the hit count on a schedule. A rule with no hits over a long period is either no longer needed or is hidden by a rule above it. Check that hit count is enabled on every gateway first; a zero from a gateway that is not counting means nothing.
• Remove disabled rules once the change that disabled them is confirmed. A rulebase is not an archive.
• Find expired temporary rules by their time objects and remove them.
• Check every Accept rule for 'Any'. Each one should have a comment that explains why.
• Check the Internet group against the routing table whenever a network is added.

Version notes

R80 and later

Legacy user access (user@location) and Client Authentication are legacy features. Use Access Roles with Identity Awareness. SecuRemote and SecureClient have been replaced by the current remote access clients with Office Mode.

R80.10 and later

Ordered and inline layers, security zones in Source and Destination, and applications and URL categories in the same rulebase. Security zones are an alternative to the negated group for the Internet and the DMZs.

R80.20 and later

Updatable objects for services such as Microsoft 365, kept current by CheckPoint.