R81 Geo policy updatable objects with exceptions

[erann]

Hi,

In order to "move" from using the legacy geo protection to Security policy updatable objects, am I supposed to set the Geo Policy Profile activation mode to "Inactive" and then load the list of countries in a new rule in access policy? or better yet, DELETE the geo profile under "Shared Policies" ?

also, if I have exceptions of network objects defined under Geo Policy > Exceptions , when I "move" to Geo policy updatable objects, will these exceptions be ignored? meaning I will need to create the exceptions as a higher rule in the security policy above the geo policy blocking rule?

Thanks!

[PhoneBoy · Accepted solution]

The legacy Geo Policy applies prior to the Access Policy.
Which means, assuming you have created Access Policy rules that incorporate geo-based updatable objects, you would also need rules to account for those exceptions in your rules.
Whether you delete the Geo Profile or set it to Inactive is a matter of personal preference, I suspect. 

[erann]

Just wanted to share that so far - it seems really uncomfortable to move away from the legacy geo policy to updatable objects managed in security policy.

Using the legacy method, you manage the geo policy and the security rules policy separate, thus allowing you to order and tidy up the security policy anyway you want.

Using the updatable objects for geo policy as part of the security policy masses/breaks that logic/order.

For example, I am using inline layers like this:

Inside the WAN -> Internal layer, I have some rules like these:

So now I need to place the Geo blocking rules above this layer rule obviously and that's fine, but if I want to allow a domain object or other updatable object such as Azure, Office365, Amazon, etc` , I have no way of knowing if some of the addresses behind these objects are located in geo locations blocked by the Geo blocking rule above, so now I need to place these domain objects/updatable rules above the geo blocking rules and outside the WAN -> Internal layer which now breaks my logic/comfort.

Same goes for regular network objects with a public IP address, if the country behind the IP address (host object) is a geo blocked country, I can't place it inside my WAN -> Internal / Internal -> WAN inline layer, it would need to be placed in the Geo Exceptions section.

It is much more convenient when the geo policy is not part of the main security rule base, since it allows you to create exceptions which are not dependent on the security rules location.

Just felt like sharing this feedback.

[the_rock]

I really get where you are coming from, agree 100%.

[PhoneBoy · Accepted solution]

You can use ordered layers to achieve the same result as the legacy Geo Protection.
Make your first layer only countries that you block or allow, with any exceptions defined here.
Note that traffic you wish to allow must be accepted by a rule in each ordered layer.

[erann]

Hmm..  so if I want to allow a certain public IP host which belongs to a blocked country in the Geo Protection layer (which is above the Network layer) , how would I achieve that in your scenario? 

I would create a rule in the Geo Protection layer which allows that certain public IP host  access to my internal host, this rule (exception basically) would be placed above the Geo Drop rule (still inside the Geo Protection layer). 

Then, I would create the exact same rule in the Network layer, wherever I want. 

Meaning, it wont be enough to create the rule ONLY in the Geo Protection layer, it must exist also in the Network layer, otherwise access will not be granted? 

[PhoneBoy]

Traffic must hit an accept rule in all ordered layers to be accepted.
This means that you could leave your existing rules as is and put all Geo-specific stuff in this Geo layer, which should be first, and will be enforced first similar to the legacy Geo Policy.
Some examples of rules you can add to this layer:

• Allow only X country and block all others
• Allow all but specific countries
• Allow all countries to access a specific server on a specific protocol (allowed by your other layer) but block all other access from specific countries.

You don’t need to exactly duplicate the rules between the layers, but there should be a rule in each layer that will permit the desired traffic.

[the_rock]

@PhoneBoy ...I need your opinion and expertise with this. I know its slightly off topic, but same subject though. So, I recall once, I was helping customer and they asked me best way to configure ordered layers, since they wanted 2nd ordered layer to be just app control and urlf. So, issue was, CP TAC suggested sk (cant recall number now) where it states that rather than doing white list in that layer and then have any any block rule, you should do blacklist and then have any any allow at the bottom!!??

To me, logically, that makes no sense at all. If you think about it, doesnt that defeat the purpose of having ANY block rules at all in network layer, if bottom rule at 2nd ordered layer is any any allow, then would not all traffic be accepted to begin with? We even tested it with TAC on the phone and saw that exact behavior. So, my question is this...is there a good way to have ordered layer like this? Would it not make sense to have 1st ordered layer as app control + urlf and even if you have any any allow rule at the bottom of that layer, then I guess if 2nd ordered layer is network layer, it would still look through all those rules?

Hope I explained that right 🙂

[PhoneBoy]

If you go back to pre-R80 days, this is precisely how App Control/URLF was implemented:

• A “firewall” layer that handled layer 3/4 rules with some basic Layer 7 (stuff implemented in the firewall).
• An “Application” layer that handled Layer 7 (web applications, etc).

These layers were effectively fixed.
And if you are managing App Control from R80.x for an R77.x gateway, you must construct the policy in exactly this manner to emulate the way it actually operates on these releases.

The downside to this approach is that not all traffic you might want to allow could be expressed using Application Control rules (ie the precise traffic may not match one of our definitions).
Therefore the recommendation to take a “blacklist” approach versus a “whitelist” approach when handling applications.

Once your gateways are R8x, this doesn’t apply because you can mix functions (Firewall, App Control) in the same layer and implement as a whitelist.
That said, the basic premise is the traffic must be accepted in each ordered layer still applies. 

Hope that explains it.

[erann]

These are good news, tomorrow im gonna tidy up all layers and policy rules until my OCD is satisfied 🙂 

[the_rock]

Yes, makes sense...so what I usually do now with customers is either we end up creating section on top of the rulebase for app control and urlf OR we may end up create another ordered layer ONLY for app control + urlf, but we place that layer as first ordered layer, so that way, access control fw layer would not be affected if we follow "blacklist" approach with any any allow rule at the bottom of app control urlf ordered layer.

[PhoneBoy]

If you want to leverage full SecureXL acceleration, you may not want to put the App Control layer first.
You may want to employ an inline layer for App Control instead.
Yes, lots of ways to do this 🙂

[the_rock]

Yea, inline layer for app control was what I wanted to do for one customer, but TAC could not come up with good way for parent rule, so we just ended up doing section with few rules and that works well!

[erann]

So the  Accept ANY rule as the cleanup rule on the geo layer is mandatory, any "unmatched traffic" will be forwarded to the network layer whether it's supposed to be accepted or not.   the same goes for any other type of traffic, including internal traffic between vlans, otherwise i will start getting dropped connections all around.     So for allowed traffic, I will see x2 accepts in the logs, 1 for geo layer and 1 for network layer and for not traffic which is not allowed (but also not blocked by geo), will show up as 1 accept (geo layer) 1 drop (network layer) in the logs.

I think I still prefer the legacy method.. 

For non-allowed traffic, I will see 1 accept (geo layer, cleanup rule)

[erann]

Also, making all firewall traffic (WAN/LAN, internal external) pass through the Geo cleanup Allow rule with services set to ANY could raise some issues with protocols, one will have to make sure all required/special protocols are either checked or unchecked with the option "Match for Any" according to the need.   I had issues with this in the past regarding VOIP communication via VPN tunnel.

[the_rock]

phoneboy is 100% correct...I will say, from personal experience, I find setting policy with updatable objects for countries you wish to block seems to work much better and it is recommended by Check Point. Or, if you prefer, what you can do is say create access rule that says you want to allow certain countries and then block the rest in rule below by simply putting object called "geo location" I believe (or something like that). Same method would apply if you wish to block specific countries...you can do it that way and then you dont even need to have a rule to allow the rest of geo locations. Either way definitely works.