topic Re: Properly defining the Internet within a security policy in Firewall and Security Management

Properly defining the Internet within a security policy

Danny — Fri, 10 Nov 2017 01:33:46 GMT

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.

Re: Properly defining the Internet within a security policy

Marco_Valenti — Fri, 10 Nov 2017 09:03:01 GMT

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

Re: Properly defining the Internet within a security policy

Gaurav_Pandya — Fri, 10 Nov 2017 10:08:59 GMT

These are the small things but can impact a lot.

Good Information.

Re: Properly defining the Internet within a security policy

Dor_Marcovitch — Fri, 10 Nov 2017 12:46:57 GMT

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

Re: Properly defining the Internet within a security policy

Daniel_Taney — Fri, 10 Nov 2017 18:04:34 GMT

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

Re: Properly defining the Internet within a security policy

Tomer_Sole — Sun, 12 Nov 2017 06:44:02 GMT

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

Re: Properly defining the Internet within a security policy

grandpafirewall — Sun, 12 Nov 2017 16:21:03 GMT

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

Define Security Zone objects. Or, use predefined security zones (ie. ExternalZone, InternalZone, DMZZone, WirelessZone)
Assign Gateway interfaces to Security Zones
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

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.

Re: Properly defining the Internet within a security policy

Gaurav_Pandya — Mon, 13 Nov 2017 11:10:58 GMT

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

Re: Properly defining the Internet within a security policy

Timothy_Hall — Mon, 13 Nov 2017 13:17:57 GMT

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.

Re: Properly defining the Internet within a security policy

Danny — Tue, 14 Nov 2017 01:35:13 GMT

Addendum - Services & Applications

How To Describe "Any Application"

Matching unknown traffic

Re: Properly defining the Internet within a security policy

Hugo_vd_Kooij — Wed, 15 Nov 2017 12:25:00 GMT

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.

Re: Properly defining the Internet within a security policy

Ilmo_Anttonen — Tue, 10 Apr 2018 06:23:34 GMT

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.

Re: Properly defining the Internet within a security policy

Danny — Tue, 24 Apr 2018 07:30:54 GMT

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

Re: Properly defining the Internet within a security policy

Vladimir — Tue, 24 Apr 2018 18:33:36 GMT

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!"?

Re: Properly defining the Internet within a security policy

A_H — Tue, 10 Jul 2018 13:49:17 GMT

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

Re: Properly defining the Internet within a security policy

Shannon_Diotte — Thu, 12 Jul 2018 17:53:36 GMT

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.

Re: Properly defining the Internet within a security policy

Vladimir — Fri, 13 Jul 2018 13:23:50 GMT

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-accelerated?commentID=18334…

Re: Properly defining the Internet within a security policy

Shannon_Diotte — Fri, 13 Jul 2018 14:00:05 GMT

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.

Re: Properly defining the Internet within a security policy

Vladimir — Fri, 13 Jul 2018 15:40:03 GMT

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.

Re: Properly defining the Internet within a security policy

A_H — Fri, 13 Jul 2018 16:01:42 GMT

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.