Properly defining the Internet within a security policy

[Danny]

Let's discuss!

There are various methods of defining the Internet within your firewall security policy.

I've showcased the five most common methods in the screen shot below.

The proper firewall definition of the Internet depends on your needs!

This discussion shall raise your awareness that it's required to evaluate your specific demand to avoid using * Any or All_Internet by default.

Method 1: Using the default * Any definition

   Pro: Allows for proper Security Policy verification checks.

   Con: Any is not the Internet. In an ideal security world, you shouldn't use * Any in any of your firewall rules.

Method 2: Using the default IP Address range: All_Internet (0.0.0.0-255.255.255.255)

   Pro: While Hide-NAT on "Any" source doesn't work, using All_Internet as the source will do the job.

   Con: The Internet consists of various networks, public, private and other ones. In a security environment you operate all kind of corporate networks, DMZs, VPNs, Remote Users, Office Modes and many more entities using IP addresses. From a firewall security point of view the Internet definition means everything that is not internally, branch office, Site-to-Site or Remote Access VPN connected. For a firewall the Internet is everything else, public, untrusted, external. A simple IP Address range object with the name All_Internet provokes many misunderstandings. A security reviewer, like me, would be happy that * Any was replaced with an object someone hopefully took care of properly defining what the Internet for that specific firewall implementation is. Only when looking deeper into the object it gets clear that this definition is even more worse than * Any because it might supersede the automatic validation checks Check Point does. Please see the Global Properties for Non Unique IP Adresses shown below.

Method 3: Using a Group with Exclusion (Any except all corp. networks, branch office networks, VPN encryption domains, office mode networks, RFC 1918 networks and so on)

   Pro: Easy to use and understandable for humans within normal firewall administration.

   Con: Groups with Exclusion are very complex for automatic firewall validation checks, hard to troubleshoot for humans, known to sometimes cause issues when used in VPN encryption domains and therefore have many limitations (sk97246, sk101506, sk107543, sk107417, ..). Also, what is * Any from a firewalls perspective? How does a firewall define * Any? Are there exclusions from * Any? For Services everyone knows that Check Point per default excludes X11 from Any. How about Networks?

Method 4: Using the Application and URL Filtering object 'Internet'

   Pro: Only applies to traffic heading outside the corporate network - to the DMZ and external interfaces. The object distinguishes between internal and external addresses.

   Con: This is only the default destination for Application and URL Filtering rules so you can only use this object in the destination column of Application and URL Filtering enabled rules and layers.

Method 5: Negating a group that contains all your networks (similar to Method 3 without using a Group without Exclusion)

   Pro: Perfect definition of the Internet for the firewall and all of its automatic verification and validation mechanisms. Simple negation of all networks that your firewall 'knows' not to be part of the public, untrusted, external Internet.

   Con: Harder to understand for humans, especially in security policies with advanced complexity.

Appendix:

Menu > Global Properties > Non Unique IP Addresses

In the above window you can see the non-unique IPv4 and IPv6 address ranges.

Security Management considers addresses that are routable on the Internet as unique, and private, non-routable addresses as being non-unique (duplicated). It is possible to add address ranges to the default list. There is normally no need to change the default addresses.

This list is used by SmartDashboard to perform automatic validity checks on addresses.

IPv4 Addresses

RFC 1918 documents private address spaces which may be used on internal networks that will not have hosts directly connected to the Internet. The Internet assigned Numbers authority (IANA) has set aside the following three blocks of IP addresses for internal (private) network use:

• Class A network numbers: 10.0.0.0–10.255.255.255
• Class B network numbers: 172.16.0.0–172.31.255.255
• Class C network numbers: 192.168.0.0–192.168.255.255

In an intranet that uses private addresses, a Check Point Security Gateway NAT gateway is put in place to connect the intranet to the Internet and translate the private addresses, to routable addresses. The default list of non-unique addresses are the three ranges specified in RFC 1918.

IPv6 Addresses

There are so many IPv6 public addresses that is not usually necessary to assign private IPv6 addresses for an internal network. There is a "Unique Unicast" IP range of fc00::/7 that can be used for private IPv6 addresses as specified in RFC4193.

[Marco_Valenti]

for me most of the time negating group is one of the most reliable ad easy way to define internet , I personally dislike group with exclusion for maaaany reason , by the way ther's a chance that we can use the defined internet (any exeternal and dmz ) in the firewall policy in the future?

Nice post btw

[Gaurav_Pandya]

These are the small things but can impact a lot.

Good Information.

[Dor_Marcovitch]

I am just negating a group with all "private" ipv4 ranges.

[Daniel_Taney]

This is always how I've done it, as well!

[Tomer_Sole]

Hi guys, what are your thoughts about Check Point's out-of-the-box "Internet" object?

[Ilmo_Anttonen]

Hi Tomer Sole

I just found this thread when searching for information about the All_Internet object.

What you are asking about is the App control object 'Internet', yes? I like it and would like to be able to use it for the access control policy instead of using the negate option like I am currently doing. Luckily this seems to be the least bad option from the list in the OP. Reading the answers here it seems many others would like to have the Internet object available for access control as well.

[grandpafirewall]

I'd like to add one more method

Method 6:  Using Security Zones

(Ref:  SmartConsole R80.10 Help)

Security Zones let you to create a strong Access Control Policy that controls the traffic between parts of the network.

A Security Zone object represents a part of the network (for example, the internal network or the external network). You assign a network interface of a Security Gateway to a Security Zone. You can then use the Security Zone objects in the Source and Destination columns of the Rule Base.

Use Security Zones to:

• Simplify the Policy. Apply the same rule to many Gateways.
• Add networks to Gateways interfaces without changing the Rule Base.

Workflow

1. Define Security Zone objects. Or, use predefined security zones (ie. ExternalZone, InternalZone, DMZZone, WirelessZone)
   

2. Assign Gateway interfaces to Security Zones
3. Use the Security Zone objects in the Source and Destination of a rule. For example:

   Source	Destination	VPN	Service	Action
   InternalZone	ExternalZone	Any Traffic	Any	Accept

Below are screenshots from SmartConsole topology settings and an example of a policy

And can be defined in the rule base.

[Gaurav_Pandya]

Nice Information. I think This applies to R80 only as lower than R80 version don't have zone concept.

This is good feature in R80

[Pedro_Espindola]

Also available in SMB appliances running R77.20.XX.

[Timothy_Hall]

Security Zones are definitely helpful, and their use does not appear to impact SecureXL acceleration, templating, or the new Column-based/Early Drop rule matching based on my research so far.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Danny]

Unfortunately Check Point seems to have issues with Security Zones in R80.x.

[Vladimir]

Danny,

Is it really an issue if all you have to do is create a single rule with "External Zone" object and label it in a separate section "Do not delete, will cause policy installation failures!"?

[Kristof_Vermael]

Security zones cannot be used in NAT rules, so when you wan't to do a HIDE nat for all internet traffic, it is useless. 

[Richard_Amos]

I found an interesting bug(?) with this.  When setting the zone "According to topology" in topology settings, policy validation fails with "Rule X has security zone objects that are not attached to any interface used in (gateway) : (zone).".  Performing a "where used" on the zone object does not show the relevant gateway until I manually define the zone.  For example, I selected "According to topology" which set my external interface to "ExternalZone".  Validation failed until I manually forced it to "ExternalZone", and gateway didn't show up as "used" by the zone until then either.  I am on R80.20 with JHFA Take 118.

I'm backing off of using Zones in my Policies for now.  I am using the method with all of my networks in a group and then negating the cell.  It works, but I feel it can be error prone in a larger environment.  Topologies have to be correct for our various VPN's, so tagging a zone to this seems like it would scale better.  I'll check back on this later when NAT is also supported like others seem to be doing.

[Danny]

Addendum - Services & Applications

How To Describe "Any Application"

Matching unknown traffic

[Hugo_vd_Kooij]

Actually IPv6 makes it much simpler. 2000::/3 is a good starting point for Internet. If you want it more accurate you can exclude your local Public IPv6 range(s). Nothing much to it.

[Danny]

According to Marc Lampo this is not working since R80.20 anymore.

[Marc_Lampo]

To be precise : one cannot enter a route for 2000::/3, anymore.

I now have 32 routes, each a /8.  (2000::/8, 2100::/8, 2200::/8, ... 3F00::/8)

Thanks R80.20 ;-(

[A_H]

Method 7:  Using Public IP Network Ranges

Create 6 network address ranges listed below, these should cover all the routable IPv4 public space:

1.0.0.0 - 9.255.255.255

11.0.0.0 - 126.255.255.255

128.0.0.0 - 169.253.255.255

169.255.0.0 - 172.15.255.255

172.32.0.0 - 192.167.255.255

192.169.0.0 - 223.255.255.255

Create a network group called Internet_IPv4 to include all of them.

Use Internet_IPv4 instead of any for internet rules.

The ranges that have been excluded are listed below in red:

10.0.0.0 - 10.255.255.255 Private-Use Networks

127.0.0.0 - 127.255.255.255 Loopback

169.254.0.0 - 169.254.255.255 Link Local

172.16.0.0 - 172.31.255.255 Private-Use Networks

192.168.0.0 - 192.168.255.255 Private-Use Networks

Note: There are several reserved IP subnets in the 192.0.0.0 and 198.0.0.0 address blocks that are included in the ranges above, to simplify the ranges a bit. I'm not too worried about including them. If the IPs are not forward-able the ISP will drop them.

IANA IPv4 Special-Purpose Address Registry 

[Ilmo_Anttonen]

At first glance this was my favorit way of defining Internet. But, when comparing adding 6 address ranges to a group vs. negating RFC1918 networks in a group the latter feels like the better choice from a performance perspective.

Considerations:

• 3 networks is less than 6 address ranges. But which one has the smaller performance impact?
• Does negating have any impact on performance?
• You cannot negate a src/dst cell in NAT rules.
• Negating doesn't feel as natural as allowing.

I'm currently sticking with the negated RFC1918. But if using address ranges can be proved not causing a large performance impact I'll consider using it just because it looks cleaner and is usable in NAT rules.

/ Ilmo

[Shannon_Diotte]

I'm surprised at all the ways you're trying to mask 'ANY'.  Depending on your topology, infrastructure, security posture (layered defense), and active blades, most of these solutions are still effectively 'ANY'.  Embrace it, accept it, secure it, and document it.  BTW, I'm only talking about 'ANY' as a source or destination, when related to the Internet.

[Vladimir]

Hmm... "ANY" should be avoided whenever possible.

Please see this comment by Timothy Hall‌:

https://community.checkpoint.com/message/18334-re-securexl-is-enabled-but-the-traffic-is-not-acceler... 

[Shannon_Diotte]

In most all cases, I agree the use of ANY is prohibited.  In these "Internet" cases, I'll agree if you can show me the value of replacing ANY with a negated or excluded internal networks object.  Or replacing ANY with all applicable IP ranges that represent the Internet.  In most common topologies that have a dedicated "Internet" firewall, you would never see your internal networks as an Internet source or destination.  You can mask ANY with some of these methods, and it can be debated that you've provided additional security by explicitly defining the Internet as a whole, but the effective outcome is still ANY.  To me, the danger is in providing a false sense of security to those that don't fully understand this concept. 

Personally, I accept ANY in these instances (related to Internet only), and ensure that there's a documented process to manage and mitigate the associated risk with using ANY.  This includes, but isn't limited to, periodic reviews for continued use of ANY, requirements for additional security measures when using ANY, and management understanding and approval to use ANY.

[Vladimir]

If it would only affected security aspects of access control, I'd agree with you. The problem with "Any" is the impact on performance of the gateways, as per post referenced earlier as well as inclusion of RFC 1918 ranges in it.

I have seen too many environments with Anti-Spoofing disabled to be comfortable with it.

My personal preference is to use "All Internet" object available with URLF and Application Control blades or the "External" zone object.

If you do use "Any" extensively, I'd check the SecureXL status on the gateways to see how the acceleration is being affected. Your environment may very well perform nominally, if hardware specks are way higher than could've been otherwise.

[A_H]

On other firewall brands I have used in the past, using "Any" was not affecting the performance. I know "Any" sounds bad, but there are things one want to be accessible from any IP, for example a web public server located in DMZ, behind the firewall. You want all the Internet IPs and private internal IPs to reach that Web server.

Another example is cloud services that cannot be properly handled by a DNS rule, due to the fact that the IPs change all the time and when the firewall checks, the IP is already different.

Even the Stealth and Cleanup rule has "Any" in it. As bad as it sounds "Any" might be a necessary evil.

For performance reasons I try to avoid "Any" and I was able to replace it with Internet_IPv4 when I have no choice like inbound traffic to a public web server.

[Daniel_Taney]

If you are concerned about cleaning up as many *ANY* rules as possible, you could have a group containing all your private address space (or all RFC-1918 LANS) and negate that group for rules granting inbound access from the Public Internet. 

[Timothy_Hall]

As mentioned earlier in this thread, from a functional perspective using "Any" in your policies works fine.  However avoiding "Any" helps optimize the new Column-based matching function which is described here:

Unified Policy Column-based Rule Matching 

This feature causes much more efficient matching of policy rules in the PXL/F2F paths.  It is not part of SecureXL and using various SecureXL commands like "fwaccel stat" will not show the potential impact of using "Any" in your policies.  As mentioned in my book the "throwing out" of rules by Column-based matching that cannot possibly match the connection happens for the Destination column first, so trying to avoid use of "Any" in that one column can be the most beneficial, because if almost all rules can be "thrown out" during the first pass through the Destination column there are very few rules left when going through the Source and Service columns.  Once all non-matching rules have been thrown out, a traditional "top-down, first-fit" evaluation of the surviving rules commences.

There do not appear to be any commands that allow you to measure how efficiently Column-based matching is operating on the firewall, other than a full-blown kernel debug of the policy evaluation.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Vladimir]

Thanks for the reminder about column-based matching!

The only caveat is that it has to be an R80.X environment and I cannot deduce that it is from Shannon's posts.

Cheers,

Vladimir

[Network_Anderso]

This is confusing. So, for allowing your internal network out to the Internet, what is the best method to only specify the Internet and nothing extra.

Thanks