Selective use of Geo Policies

[Hugo_vd_Kooij]

I was trying to see if I can use Geo Policies more selectively in R80.10

For example:

1. I want only a few countries to start SSH to a server.
2. I want to block certain countries from starting a SMTP connection.

Has anyone figures out a way on how to do that?

[Daniel_Taney]

This may not be the most definitive answer, so anyone please feel free to correct me here! 

Unfortunately, since Geo Policy is listed under "Shared Policies", I don't believe you can have individual Geo Policies and apply them to your Threat Prevention policy. I wish this wasn't the case, because I would also like to be able to use Geo Policies in the way you outline in your question. Being able to selectively apply different Geo Policies based on Src / Dst / Service would greatly enhance the functionality of Geo Blocking. I was hoping this was something that would change between R77.30 and R80.10, but it looks like it hasn't. It would make for a good feature request, though!

[Vladimir]

I too would like to see more flexibility and logic in Geo protection.

In the absence of these features now, we may have to resort to exceptions.

I.e. US-to-US deny all; Exceptions: CPMI; HTTP; HTTPS; SSH; IKE; etc.

Would something like this work?

[Daniel_Taney]

Unfortunately, you can't specify countries in the Exception. You have to decide to exempt a whole SRC / DST / SVC from Geo Protections. You could set exceptions for the services you mentioned, but they wouldn't be inspected by Geo Policy at all. This would be another great feature request  

[Vladimir]

You are correct about inability to specify counties in exceptions, but what I am thinking about is applying exceptions to the policies for select countries:

Exceptions:

[Tomer_Sole]

Hi https://community.checkpoint.com/people/HUGO.532b93a9-c5ea-3035-ab17-ef7c02036f40‌, does that answer your question?

[Vladimir]

Hi Tomer,

I've given it some more thought and have experimented with Geo Policies a bit and have come to the conclusion that there is a problem wit their logic.

What Hugo trying to accomplish is, presently, not possible.

Consider these conditions:

You can only assign one Geo Policy to the gateway at the time.

Each Geo Policy is limited to accept or drop functions.

Policies can include multiple countries.

Exceptions are policy specific.

If you could have multiple Geo Policies assigned to the gateways (and processed sequentially), my suggestion would've worked.

As is, you can exempt particular traffic from All the Countries in the single policy, but you are still prevented from being granular enough to restrict access to particular services to a subset of countries.

[Timothy_Hall]

Agree with your assessment Valdimir, or it would be nice to just specify the countries directly in the various Access Policy layers rather than a separate Geo Policy as the "countries" are really just blocks of IP addresses.  Pretty sure that would provide the granularity needed.

Also just wanted to mention that Geo Policy on R80.10+ gateway has been broken out from the IPS blade and is just a part of the Access Policy now.  Updates to Geo Policy on R80.10+ gateway are applied by just reinstalling the Access Policy (not the Threat Prevention policy) and an IPS license/contract is no longer required to use Geo Policy in R80.10+ either.

Geo Policy drops are still performed in F2F, was hoping they would be done directly by SecureXL in R80.10 (perhaps as part of the direct antispoofing enforcement drops by SecureXL) but that does not appear to be the case from what I can tell.

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

[Daniel_Taney]

It would definitely be nice to see the Geo Policy incorporated into SecureXL someday!

[Tomer_Sole]

What about assigning a different Geo Policy per Gateway?

[Vladimir]

If you are trying to create a country or group specific exemptions in addition to "global" Geo Policy, presently you can do that only if you have multi-gateway chain. 

You can do this using VSX, but it is rather inelegant solution and a waste of resources and licenses.

[Tomer_Sole]

It is true that you will have to repeat yourself per geo policy as we don't have "global rules" for that right now.

Roadmap wise - yes, Access Control Policies will have the ability to select country dynamic objects.  

May I ask - at present - how big are your geo policy conditions? 

[Daniel_Taney]

We have made extensive use of Geo Policy Conditions to cut out large portions of Internet traffic we know we don't want. It has been very effective for us to reduce potentially bad traffic.

That said, having the ability to make granular decisions about geo controls in the access policy would be a huge improvement.

[Vladimir]

Depending on a client.

Some of them do not use geo policies at all and some do.

[Alex_Sazonov]

Hi Tomer,

Can you please say if this Country Dynamic Objects will be part of R80.20?

[Tomer_Sole]

it actually depends whether the R80.20 EA Program (which Alexander Sazonov is running) will give successful grades on that feature.

[PhoneBoy]

Worth pointing out this in the meantime as a workaround for not having it natively built in:

GEO Location Objects in Firewall Policy (with Dynamic Objects)‌

[VCL001]

Countries in access control policy with defined services i.e. all dynamic objects are here in R80.20. See this SK: Geo Location objects as network objects in R80.20

Sorry Hugo that it took nearly a year 🙂

[Mike_Jensen]

I have a "Branch Geo Policy" that blocks every country except the United States.  If I wanted to continue to do so but allow a certain service (smtp tcp/25 for example) from any country to my mail servers IP's I assume I would create that in the "Exceptions" area under Geo Policy.  

When I try to create a exception there I am able to apply it to my "Branch Geo Policy" but at the bottom in the "Installed On" portion, none of my branch gateways are listed as options to install this exception on.

The only reason I can think why this is, is my branch gateways don't have an IPS license, and maybe these exceptions only apply to gateways that are using IPS?

Does anyone have any ideas on how I could apply this exception to my branch gateways?

[Timothy_Hall]

If the gateway is a 1490 model or lower (embedded Gaia), Geo Policy is not supported and that may explain why you can't select that particular gateway.

If the gateway is running R77.30 or earlier, you need an IPS license and IPS enabled as Geo Protection was part of IPS in R77.30 and earlier.  For an R80.10+ gateway Geo Policy is just a regular part of the Access Policy and doesn't need anything other than a regular firewall license.

[Mike_Jensen]

The security gateways are 2200's running R80.10.  My Geo Policy is working on them great, it's just a matter of trying to install a exception on them.

[Timothy_Hall]

Hmm I just messed around with this in demo mode, and it looks like IPS needs to be enabled on the firewall object for it to be selectable in the Geo Policy exception.  Try enabling IPS on the gateway, publish, add the Geo Policy exception specifying that gateway, uncheck IPS and publish/install Access Policy to the gateway. 

I do not believe the user should be blocked from adding a Geo Policy exception on a R80.10+ gateway if the IPS checkbox is not enabled; this seems to be a GUI bug.  It is appropriate for this behavior to occur with an R77.30 or earlier gateway.