Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Dr_Steve_Brule
Participant
Jump to solution

Geo-Updatable Objects

Hi I'm a new Check Point user with a recently deployed R80 gateway cluster.  I'm looking into implementing Geo-updatable objects instead of the traditional geo policy.  I work for a local municipality in the US so really, all traffic should be domestic.  I'd like to validate - Would I just need to apply a block rule from "any" to all countries except US and Canada and another corresponding block rule to any from all countries except US.  These rules would go just above my stealth rule, correct?

0 Kudos
2 Solutions

Accepted Solutions
PhoneBoy
Admin
Admin

That's the basic idea, yes:

Screen Shot 2020-12-02 at 11.02.01 AM.png

However, you can get even more granular and allow access to, say, your website from anywhere but block everything else.

View solution in original post

9 Replies
PhoneBoy
Admin
Admin

That's the basic idea, yes:

Screen Shot 2020-12-02 at 11.02.01 AM.png

However, you can get even more granular and allow access to, say, your website from anywhere but block everything else.

Pierre_Bienaime
Participant

Can I use A specific Access Control policy layer, place it first layer stack. After that Have Title for each Continent and place the Countries respectively that I want to blocked, and at the end instead of a cleanup rule, I add a *any -*any accept so that other traffic can go to the next or "Normal Access Control" policy layer? I am about to upgrade from R80.20 to R81.10 and I want to move away From IPS Countries Block list. Please advise .. Thank you  in advance CheckMates

0 Kudos
PhoneBoy
Admin
Admin
0 Kudos
the_rock
Legend
Legend

Just be careful if you create another ordered layer, because traffic has to be accepted on all ordered layers. You could create inline layer inside the ordered layer, but then might be tricky creating parent rule that way. So your approach makes sense, I would do it exactly like that. What I did with one customer in R81 is create few rules in separate section on top or rule base with 2 rules for Geo, one allowing few countries and rule below that that says source -> Geo Locations to any destination -> block. Happy to do remote and help you with this if you want.

Cheers!

0 Kudos
Timothy_Hall
Champion
Champion

In addition to the great advice you've received here, when going with an "allow list" approach for Geo enforcement as opposed to the more common "deny list", watch out for DNS traffic getting blocked which can cause some strange-looking effects. 

Also if you are based in the United States, I'd recommend allowing Canada and Mexico.  Probably will need to allow most of western Europe as well, or at least minimally the UK.  You'd be surprised how much Internet site access is geographically dispersed into these areas for access from the United States, which you will find out very quickly with your approach.

Here is an excerpt from my 2021 IPS/AV/ABOT Video Class discussing these very issues:

geo1.pnggeo2.png

Watch My 2023 CPX360 Speech Titled "Max Power
Reloaded: R81+ Gateway Performance Innovations"
Mikael
Contributor

As a comment to traditional vs. geo-updatable; as traditional is applied before the access policy (I remember someone saying it applies roughly on the same level as anti-spoofing) won't performance be much better using traditional geo policy? I believe it's mentioned in one of the SK's about mitigating DDoS-attacks...

0 Kudos
Pierre_Bienaime
Participant

A lot of great comments, recommendation and suggestion, I can't thank you all enough for everything. The reason why I am moving away from the GEO Policy using IPS  is because not too long ago I had one of the Checkpoint Support Engineer saying that Checkpoint will soon move away from Traditional GEO using IPS and Updatable Objects are the way moving forward, in order words, to future-proof my Eco-systems for future changes. Just Like Mobile Access Blade, I am still using legacy mode which launch the traditional R77.X interface which I have been told as well will go away and to use a Policy Layer for Mobile Access Blade within my R80.X soon to be R80.10 ecosystem. All  of this are part of an effort to future-proof the environment and to have a smoother transition using CPUSE for upgrade in place. I would like to ask do we confirm that Traditional IPS Geo will go away for the use of updatable objects ? also what are the best recommendations for a smoother upgrade from R80.20 to R81.10 using CPUSE ?

PhoneBoy
Admin
Admin

In R81 and above, we actually hide the traditional Geo Policy settings if nothing is configured there.
This is documented here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

There are still parts of MAB that require SmartDashboard even if you move away from the Legacy mode.

In terms of upgrading in place, I would consider doing an Advanced Upgrade for your management (at least) so you can leverage the faster XFS filesystem (versus ext3).
That requires new partitioning and thus can't be done in place. 
From R80.20, upgrading to R81.10 should be a single-step upgrade.

(1)
the_rock
Legend
Legend

Mr Phoneboy is correct, as always! I will tell you from my own experience...personally, I would NOT bother using traditional geo policy, updatable objects are so much better. I honestly had nightmare scenario when someone in TAC told us once to block certain countries (in their defense, it was the customer who approved it), but we never realized that one specific country we blocked was needed for cloud access, so we spent next 2 days trying to figure it out, worked with 3 escalation engineers, until something clicked in my head that was the issue and as soon as we unblocked it, all worked fine. Just keep in mind that traditional geo policy always takes place BEFORE regular rules, so it can definitely cause issues if you make a mistake. When you do regular rules, makes it much more intuitive to fix quickly if traffic is blocked. I would definitely read what @Timothy_Hall posted as well, because that absolutely makes 100% sense. To summarize, I believe everyone here is suggesting you use updatable objects : - )

0 Kudos
(1)