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.

[A_H]

Method7 listed below works for us.

Adrian

[Network_Anderso]

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

[Ilmo_Anttonen]

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!

[Network_Anderso]

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.

[Ilmo_Anttonen]

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

[Hugo_vd_Kooij]

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 😉

[Network_Anderso]

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

[Kristof_Vermael]

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.

[Ilmo_Anttonen]

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 

[Tomer_Sole]

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.

[Ilmo_Anttonen]

That was news for me. Thank you Tomer!

[Petr_Hantak]

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.

[SChalhoub]

Great explanation.

[MKIT_NMG]

Great Explanation... Thanks...

[Jeroen_Demets]

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

[Danny]

Yes, this is still true even for R80.20 and higher versions. The Internet object is used by App Control only. You can verify this by creating a separate security policy without Application Control, you'll notice that you are unable then to select the Internet object anymore.

[Jeroen_Demets]

I see. I thought you could only use it if an app object was used instead of an old school service in a rule itself. But apparently you can already use the internet object if  application control is part of the policy package, so in practice we can use it almost always.

[bpik]

Since now R81 also supports using Security Zones in NAT rules, i think this could be the solution to go and use the External Zone object. What could be cons? If you are used to negate the "all known networks" group the difference obviously is just the other RFC1918 networks, not covered by the groupd and different to internal interface definitions. The question would be: Is the External Zone object just an object with all networks, not covered by your internal Interfaces (and hopefully their "Leads to" configuration which would make sense) ? - I think so.

Are there any performance thoughts on using the negated "all known networks" group or the External Zone object?

[K_montalvo]

Danny,

Thanks for all the clarification on this topic!

[Tobias_Moritz]

Just found out, that method 5 is not working reliable with IPv6 addresses.

Example:

Rule-ID	Source	Destination	Service	Action
1	Negated Cell Network Object (1.0.0.0/24, 2003:a::/64)	5.5.5.5	any	drop
2	Host Object (1.0.0.1, 2003:a::1)	5.5.5.5	any	allow
3	5.5.5.5	Negated Cell Network Object (1.0.0.0/24, 2003:a::/64)	any	drop
4	5.5.5.5	Host Object (1.0.0.1, 2003:a::1)	any	allow

Rulebase verification fails.

Error:

Layer Network: Rule 2 Conflicts with Rule 1 for Services & Applications any

Layer Network: Rule 4 Conflicts with Rule 3 for Services & Applications any

When you split the Host object up in two objects (one with only IPv4 and one with only IPv6), the rulebase verification succeeds:

Rule-ID	Source	Destination	Service	Action
1	Negated Cell Network Object (1.0.0.0/24, 2003:a::/64)	5.5.5.5	any	drop
2	Host Object (1.0.0.1) Host Object (2003:a::1)	5.5.5.5	any	allow
3	5.5.5.5	Negated Cell Network Object (1.0.0.0/24, 2003:a::/64)	any	drop
4	5.5.5.5	Host Object (1.0.0.1) Host Object (2003:a::1)	any	allow

Tested with R80.40 JHF T120 and R81.10 Build 220 (no JHF in CheckMates Labs)

Anyone aware of that? I may open a TAC case for that, because it looks like a bug to me.

[RamGuy239]

TAC pointed me to this thread to get a better understanding of how to best define "Internet" in a security policy. We don't consider "ExternalZone" on R80.20+ ideal in all scenarios because sometimes you don't want to have private addresses from external encryption domains etc. To be included when designing rules and layers.

My goto has always been a network group with exclusions, and this has been "best practice" according to TAC in the past. And funny enough when you utilise IoT Protect from Check Point it will create a network object named "IoT Internet" which is a network group with exclusions that says src:any, expect:group containing rfc1918 networks. This object is being used in automatically created rules within the IoT Policy. Doesn't seem like Check Point themselves are opposed to the idea of network groups with exclusions?

But as soon as IPv6 is involved I'm running into a lot of issues. I just continued with my previous logic of using network group with exclusions. I simply added an object containing our /56 global IPv6 prefix and created a network group with exclusion that said src:any, expect:our /56 prefix.

This wasn't working at all. It's working in the context of IPv6. But for some reason, this network object is also picking up traffic with 10.0.0.0/8 as its destination which doesn't make much sense to me. I figured it had to be something with the network groups with exclusion logic that doesn't separate IPv4 and IPv6 correctly so by saying src:any, except: XXXX::/56 it will count IPv4 addresses as well as those that are not within this /56 IPv6 prefix or something like that. Doesn't make any sense, but I don't know how the code works and how it behaves when you have IPv6 in a network group with exclusions.

So then I went ahead and tried a rule where I simply put an IPv6-only network object that contains our /56 prefix and use it as negate in the destination field in our network policy. This one is also picking up traffic with 10.0.0.0/8 addresses as its destination. I've replicated this behaviour on both R81.10 and R81.20. What is going on here? Is this expected behaviour?

If I follow the recommendation in this thread and instead of depending on network group with exclusions, and instead create Internet-IPv4 containing the six network ranges defined earlier in the thread, and a network group containing all global IPv6 addresses and use both of these in a group I call "Internet-IPv4-IPv6" it seems to be working. This group will pick up all traffic heading towards public IPv4 and global IPv6 addresses. And it won't mistake traffic going towards 10.0.0.0/8.

But this isn't ideal either, as I want a way for us to exclude our own global IPv6 prefix from the rule. How am I supposed to make this work when both negating an IPv6 network object directly, or using one in a network group with exclusions is not working? Will I have to manually create an object containing all global IPv6 addresses in such a why that I leave out our specific /56 prefix? If so, that sounds rather silly.

It surely has to be a bug that the policy matching is behaving in such a way when IPv6 is in play.

I managed to work around this by creating a nework group with exclusions saying src:internet-ipv6 (my group containing all global ipv6 addresses), expect:our /56 prefix. This makes it so that the object does not pickup 10.0.0.0/8 anymore.

But still, especially the fact that when negating ipv6 network objects in the dst field results in 10.0.0.0/8 matching the rule is very bizarre behaviour to me.

[Danny]

The previous comment by @Tobias_Moritz also mentions issues with IPv6.
Hopefully Check Point adresses these issues in R81.20+.

---

This is the second time today that I'm aware of TAC referencing my community threads and tools. This makes my very proud. 😊

[Tobias_Moritz]

@RamGuy239 : I think in your case, the root cause may be that "any" is not limited to any address-family. So it matches both IPv4 and IPv6. When subtracting a /56 IPv6 network, there is still the complete IPv4 address space included. Same logic seems to apply for cell negation. For IPv6-Internet, you could use an object with exclusion: 2000::/3 except your internal global unicast IPv6 networks. For IPv4-Internet, create a separate object, like you used to do. Then put both objects in the rule field. And avoid dual stack objects, unfortunately.

Regarding my simple example from the post above with the rulebase verification error: We opened a TAC case for that and the answer was (in short): We won't fix that. We call it a known limitation. Just don't use that feature and go for zones...

[RamGuy239]

@Tobias_Moritz This is what I ended up doing. I just find it strange that negating IPv6-only objects to include IPv4, while negating IPv4-only objects does not include IPv6. Surely this has to be a mistake in the code? The same goes for network groups with exclusions. You don't see the groups considering IPv6 addresses as a part of "any" when using IPv4-only objects as the exception.

Can't really expect admins to wrap their heads around this. The only reason why we noticed the behaviour was because a lot of internal traffic stopped working as it was getting tossed into the wrong layers making me have to dig deeper into what is going on.

It would actually be better for this to cause a policy verification error or at least a noticeable warning. I can't see many scenarios where this kind of IPv4+IPv6 behaviour is desirable or expected behaviour from admins when creating rules and objects. And having it working one way for IPv4-only which differs from when using IPv6-only just ads to the confusion.

I've tested using R81.10 JHF Take 55 (slightly behind GA), and R81.20 JHF Take 52 (EA) so doesn't seem like we should expect any difference on R81.20 at least.

[RamGuy239]

@Tobias_Moritz As you say regarding how TAC reacted to this in your scenario I suppose the best option unless one wants to work against the stream and against the internal logic from Check Point is to utilise zones and just drill various firewall admins on how "ExternalZone" will include IPsec VPN encryption domains so when utilising layers they need to create applicable encryption domain rules within relevant layers that utilise ExternalZone, or by having more specified rules for encryption domains above the layers utilising "ExternalZone".

[RamGuy239]

While digging myself further into this rabbit hole. How would this work in terms of VTI? With VTI you are able to add sones directly on VTI interfaces, just like you can on Palo Alto. So in a perfect world, you use VTI-only so you can add all your IPsec VPN traffic into an "IPsec VPN" sone and then your "ExternalZone" is no longer going to pick up IPsec VPN traffic?

Going this route will be more confusing in the short term as you then end up with domain-based VPN matching under "ExternalZone", while all your policy-based/VTI VPN is matching using whatever sone you put on the applicable VTI interface. If this is how sones on VTI works in the first place. Haven't tested that before, but I'm going to test tomorrow just to verify the behaviour.

[AlexandruD]

From the IP layer perspective, you can define sensible ISP provided IPv4 Internet as a group wih exclusion network object:

INCLUDE:

All IPv4 prefix:
"All_Internet" predefined network range object (0.0.0.0 - 255.255.255.255)

EXCLUDE:

IPv4 private prefixes:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

IPv4 bogon prefixes:
0.0.0.0/8
100.64.0.0/10
127.0.0.0/8
169.254.0.0/16
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
240.0.0.0/4

IPv4 multicast prefix:
224.0.0.0/4

I find all other definitions to be confusing or too permissive. If you allow Internet access using such a network object, then looking through the cleanup DENY rule logs will give information about weird behavior of internal resources.