Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Champion
Champion

Properly defining the Internet within a security policy

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.

Labels (2)
44 Replies
Highlighted
Participant

Method7 listed below works for us.

Adrian

0 Kudos
Highlighted
Participant

I am interested in Method 5 but I don't fully understand it. I understand these are RFC 1918 and addresses can be added here but I am unsure how or when they are referenced. How are these network negated or when does the firewall observe addresses listed in this global property.

Thank you all

0 Kudos
Highlighted
Collaborator

Hi,

This method is not related to the "Non Unique IP Address Ranges" defined under global properties.

To use this method you define three network objects with the networks 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Then you either add them to a network group and call it for instance G_RFC1918. Now you place this group or the three networks to the rule source or destination columns and then right-click the object in the column and select "Negate Cell". 

That's all!

Highlighted
Participant

Thanks, so to be clear for my own understanding, if my outbound rule says source (internal network) destination RFC1918 group(negate), any service,  action accept

This will allow all IP traffic outbound from my LAN to the Internet except traffic to the negated group.

0 Kudos
Highlighted
Collaborator

Yes that would allow all traffic to the routable Internet, but would stop uninteded traffic from accessing your local networks..

If you want to allow the whole Internet access to your website I suppose that you would put the negated RFC1918 group in the source column and the website IP-address and relevant ports in destination and services columns.

/ Ilmo

Highlighted

Just for those brave enough, mehod 6:

And you might want to make it more complex if you want to exclude your Externe IP range for example.

Or if you have a need for Multicast traffic. (Which is a book by itself 😉

0 Kudos
Highlighted
Participant

This may be a foolish question but really wanted to know. If I have a rule inbound from the internet that is specifying source as (All_Internet) - to a DMZ web server, what happens when when a source address comes in from an IPV6 address? It seems like All_Internet pre-defined object only encompasses IPv4 address. How does the firewall address the IPV6 source address when my rule basically says only allow this 0.0.0.0 - 255.255.255.255.

Thanks again, really helpful stuff

0 Kudos
Highlighted
Contributor

In my opinion, option 5 is the best (and only option) you can/should use.

You often have site 2 site VPN's with public IP addresses in the encryption domain, and these need to be excluded from the 'internet' object as well.Creating a group 'all_customerX_networks' and negating this in the policy never fails.

The natting policy would then contain a rule 'all_customerX_networks' to 'all_customerX_networks' -> no nat.  Above, you can put all internal natting, below, you should put all Hide NAT rules to internet.

The moment security zones are permitted in the NAT rule, I will switch to this, but for now, I will stick to negating this object.

Highlighted
Collaborator

Exactly. Depending on the size of the network I usually create a G_RFC1918 or in case of larger networks with several S2S VPNs a G_NoNAT where I place all customer networks and network groups. I know it's probably not best practice to have groups in groups from a performance perspective but, if you have the juice, you can have fewer rows in the security policy and NAT policy Smiley Happy

0 Kudos
Highlighted

Ilmo Anttonen wrote:

I know it's probably not best practice to have groups in groups from a performance perspective

It's actually fine, there's no performance impact when using large groups or nested groups.

In case you make multiple nesting levels for a group, it might affect your ease of management at some point, with unexpected side effects when different users will reuse and edit the little groups that are used by the larger groups.

Highlighted
Collaborator

That was news for me. Thank you Tomer!

0 Kudos
Highlighted
Advisor

For me is still method 5 in top use. In some special cases we are using method 3 as well but groups with exclusion have many problems. It is not also suitable for NATs.

Method 6 is interesting way and I hope that once we'll be "brave enough" as Hugo van der Kooij‌ mentioned to make it real on some bigger rulebase/topology case.

Highlighted
Participant

Great explanation.
schalhoub
0 Kudos
Highlighted
Participant

Great Explanation... Thanks...
0 Kudos
Highlighted
Collaborator

for usage of the Internet object, is the "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."

still true in R80.20 and later?

I seem to be able to use it in rules which are using simple services

0 Kudos