R81 geo policy

[the_rock]

Hey everyone,

I know that sk126172 says to use updatable objects and thats fine, but at the bottom if the article, it gives the procedure on how to unhide default geo policy tab in dashboard. Funny enough, customer has cloud instance, so we can do that, but, I thought based on reading the article that command is ran on gateway itself? Regardless, tried it and did not do anything...

By the way, I had 2 R81 labs (one standalone and one distributed) and when I ran the commands, it messed something up that I had to disable IPS blade to get policy working again. Just sounds too coincidental that issue would happen literally 15 mins after running the script from the sk.

Anyone experienced something similar? 

Andy

[PhoneBoy]

The mechanism is still there, we just hide it in the management UI in R81.

And yes the legacy method is tied to IPS.
Believe it operates similar to Core IPS protections (ie requires an Access Policy install to make changes).

[Danny]

It's hidden for a reason. I'm following Check Point's recommendation. No issues with updatable objects so far.

[the_rock]

Thanks for the responses guys, but that does not answer my question at all. I know I can use updatable objects, but had few customers where there was an issue...say specific country is blocked and just randomly, traffic is being allowed for no reason and TAC never found an explanation why. When we switched to default geo policy, worked fine. So again, seems like sk I indicated is not very useful, as it does not give the right procedure. Its highly unlikely commands are correct, considering I did it in 2 lab R81 setups and it failed in both...makes no sense.

Andy

[Danny]

That might just be a visual issue which tricks you to think that traffic is accepted for a blocked country because you probably din't update the ip2country.csv on your SmartCenter every night. I've created a One-liner that solves this.

[D_TK]

Danny  - off topic, but it looks like in your screenshot, rule 2, is the source a group of updatable objects?  Every time I've tried to group updatable geo objects, i receive a "field network object group members ...." error. so unfortunately i have ~100 objects in my geo rules.  R80.40

[the_rock]

Thats easy to fix...you say add countries to block via updatable objects and then allow all continents in the rule below. That actually works for the most part.

[D_TK]

right, but in my block rule i have about 100 updatable country objects listed (which looks messy) because smartconsole won't let me create a group with updatable objects.

[the_rock]

Tell me about it :). I still recall similar things even back in R55 lol

[the_rock]

But, in all seriousness, Im not joking now, you CAN do that. Here is how...super easy peasy. Highlight all those countries in the rule, then right click and select "group objects", give it a name, done. You are welcome : )

[D_TK]

Doesn't work for me with updatable objects.  receive this error every time.

[the_rock]

Yes, you are right...I know this worked for me in R80.10, but I see it fails now in R80.40. Ah, Check Point...man, always something : ). Ok, let me test this tomorrow morning and I will update you.

Happy weekend!

Andy

[Dorit_Dor]

1. The functionality is there. However the “legacy” ui was so front end in the ui, the product actually mis-guided the user to use the wrong thing. So we hidden the ui by default if you dont use it. 

2. If you are fresh user, you will now be directed to use the right way and if you used the legacy, and dont want to migrate, we dont force you

3. Please use the new way if you can because its the right way. In addition,  updateable objects are necessary for good use of the  product in modern scenarios. If updateable objects dont work in good way, we are not aware and we need to fix it. So please assume that we expect them to work and if there are issues, open TAC case so that we can handle them 

[the_rock]

I never quite logically understand why Check Point does things like that. Arent customers entitled to know if a feature is broken or something could be wrong with it? I asked TAC person the other night specifically, point blank, what would be the reason that you guys would remove default geo policy in R81? He took few minutes, came back and said that he found some internal notes, but is not allowed to share them with customers. Imagine how uncomfortable that must feel for an engineer...they know the reason, but are not allowed to share it. I dont personally see how is that a good business practise.

Anyway, all Im trying to figure out is why the sk I attempted fails and no one in TAC seems to know or is willing to test. The best answer I got is "Well, it is a new product"...to which I respond "Well, you are making money off people selling it to them, so it would be honest thing to try and make it work"

[Dorit_Dor]

Thank you for the feedback

The change was not supposed to be secret or hidden and it was not supposed to be hard to get answers on “why”

Therefore, we appreciate the report and will use it to learn what went wrong, improve documentation and improve the process going forward

Dorit

[the_rock]

Hi Dorit,

Im happy to give you my honest feedback offline, if you really care to know about it (you are more than welcome to message me privately offline). All I will say is this...there is RIGHT way of doing this and there is WRONG way of doing thigs. Sadly, my experience with lots of SKs and procedures in them, as well as way TAC does things, has not been a positive one and I can assure you, I am not the only one that says that.

Cheers,

Andy

[the_rock]

Sorry to say this, but I dont think its possible...maybe if someone from escalations or R&D sees this thread, they can confirm, but I tried everything I can think of and no dice, apologies.

Andy

[Dorit_Dor]

1. sk126172  stated that Starting from R81, Geo Policy is hidden from the navigation pane if no rules are configured in that window. Geo Policy is now supported through Updatable Objects in the Access Control Policy. Geo Policy rules can still be configured in Updatable Objects as described above.

We are having offline discussion to learn why the communication went wrong and we will improve it 

2. The other point here is that grouping (needed to manage large number of geographies) does not work. There is indeed issue w specific grouping of updateable objects (UI validation on grouping that is too strong). The issue was already raised by others and grouping is supported in R81.10  (join the EA soon). Until then you can continue to use the old geo policy 

We appreciate the product feedback. 

[Vladimir]

FYI: the sk126172 to unset Geo in R81 392 (had to enable it temporary to remove Geo logging) results in:

"Failed to reload Env variables to CPM. Check /opt/CPsuite-R81/fw1/log/cpm.elg for errors."
The error is:
invalid format in line [unset disableHiddenGeoPolicy=1] in file [/opt/CPsuite-R81/fw1/conf/dynamic_system_env]

[CPIshai]

Hi @Vladimir, thanks for bringing the issue to our attention, of course you are right and in the SK instead of:

 ./reload_env_vars.sh -u "disableHiddenGeoPolicy=1"

It should have been  

./reload_env_vars.sh -u "disableHiddenGeoPolicy"

I'll make sure to fix the SK as well. 

[Vladimir]

@CPIshai , you are quite welcome and thank you for the prompt response and correction.

[Vladimir]

Apologies fro removing your reply from being a solution, as it does not address the original post's concerns.

It was a solution to a different, but related issue.

[the_rock]

Thats great it will be corrected, because I suspected something was wrong with that command in the sk.

[CPIshai]

@Vladimir @the_rock the SK commands seem to be fine now. 

[5wheelcycle]

I built a ruleset on a freshly installed R81 gateway doing updatable objects in the Access Control Policy window.

It didn't work.

So after a bit of digging, I enabled the old view. Turned the setting from Monitor only to Active. Check that I had a geod process running, which it now was. And voila, the country I was trying to block, is now blocked. Whilst with the modern way of doing it in the access policy, it didn't work or partially worked and simultaneously, had no geod process running on the gateway.

I guess, the obvious bit is, why didn't it work.

But the bigger question for me, is, is there supposed to be a geod process running without having enabled the legacy stuff?

[5wheelcycle]

These rules do not work. The DROP_TABLE contains almost the entire world. But the target I was testing with is Brazil.

The above however, works.

[Danny]

The geod process is not supposed to run with the new method. This process is just for the legacy IPS based geo protection as described in sk97638. I also verified this on a R81 system which has the new geo policy method in use (preceding ordered layer in access control policy).

What made you think it doesn't work?
Did you update your ip2country.csv as described here?

[5wheelcycle]

I was using Geopeeker.com for testing sites on there. Using the legacy view. The Australian and Brazilian sections don't even get a ping time from my end. Using it in the Access policy, they are still able to reach me.

Now the rule itself in the new way, does log stuff. But it seems like it's partially blocking the country. I'm not 100% sure here.

The results are seemingly different between the 2, that I can tell.

I did not explicitly update the csv on the management server in the one-liner you posted. I'll give that a go.

[Danny]

Thanks for explaining. As Check Point relies on MaxMind, check which IP from, let's say Brazil, tries to reach you and look up if MaxMind correctly identifies that to come from Brazil.

[5wheelcycle]

I don't have any great ways to verify and test. The logs are populating after making a rule like the top one here:

I ran out of free attempts on geopeeker. But free proxies that are supposedly located in the US, are still able to fetch the site. Which should not happen. I'll have to find out a way to test this better.

The above rule should ideally block everyone and anyone from seeing my domain. osur.ee

I'll leave this up for now, it's a lab environment. If you can get to it, then know that you're not blocked by that rule, which then implies that maxmind doesn't have my IP listed under EE. 80.235.76.204 (didn't explicitly confirm if it is under EE, but it should be, it's a static address and they don't move around much)

I did calculate a 4G IP earlier though and it matched the EE column in the IpToCountry.csv file (was tagged Aug 2012. Assuming the newer is good too but not confirmed). I tried testing that with a rule that was without the country network object inverted. Tried reaching my site over the phone, and that worked IIRC, but it was around 2 hours ago. It shouldn't have. Implies that the file is, not used??

I'm off to bed for tonight. Thank you for the replies. Will probably continue the investigation on my end tomorrow as we're currently interested with employing geoblocking at the office.

Even though it isn't perfect, seemingly, according to logs. it does report that it's blocking something and for starters that's probably good enough.

EDIT: After reverting the env variable on the management, installing the policies and rebooting the gateway, the in.geod process is still running on the gateway. Legacy view in the management disappeared.