Geo Policy Blacklist

[Ashish_Shah2]

Hi,

I have Geo protection configured in my setup and we are blocking traffic to & from certain countries in policy. Still I can observe traffic from those countries are getting permitted (ingress or egress). I have observed this behavior mainly post R80 upgrade. 

Looking at Smart log it is mainly permitting for process fw_ica but some other traffic as well i.e. for Skype for business etc.

Can someone please guide what can be wrong here?

[Steve_Moran1]

fw_ica would be accepted by the implied rules, which I think would be processed before the geo-policy rules.  

Have you validated the country's IP is actually still assigned to the country your trying to block with RIPE/ARIN/APNIC etc?  Could have changed and not been updated.  

[Timothy_Hall]

As far as order of operations, in R80.10 and earlier Geo Policy enforcement is applied around the same time as antispoofing which is well before the implied or explicit rules are reached.  Control traffic can definitely get killed by antispoofing and Geo Policy.  This may have changed in R80.20+ but I don't think so.  Note that use of the new R80.20+ Geo Objects to block traffic should not affect control connections as Geo Objects are applied in the explicit policy after the implied rules have been evaluated.

So @Ashish_Shah2 I'd ensure that your IP Geo database is up to date.  Check out sk120261: Geo Protection logs show the wrong country flag

Finally you can always create a Geo Policy exception for the traffic being dropped if need be.

[Mike_Jensen]

I am having the same issue in R80.10 /  Jumbo Hotfix take 189 where countries that should be blocked are still getting through on many ports, most notably TCP 22.

Is there a way to verify my Geo database is actually out of date before updating per SK120261?

In addition, if I follow SK120261 and update my Geo database will I have to continually update this manually or is it supposed to update automatically after that?

[Mike_Jensen]

I followed SK120261 and updated my IP Geo database on my SMS and I have also verified the geo database on the actual gateways involved have dates of 4-22-19 telling me that database is updating daily as it should and I still see traffic being logged inbound from countries I have set to block and not log such as China, Russia, etc.

In another Geo Protection issue I had on R80.10 I permitted all traffic to and from the United States and blocked every other country.  Geo Protection started dropping legitimate United States traffic.  I worked with TAC on this and was told "I find out that Whitelist for R80.10 for Geo Policy does not work too well without a specific fix. It more on and off". 

The TAC engineer provided sk110683 to reference.  The hotfix mentioned in this SK would not import in CPUSE at first, then TAC got it to import but it wouldn't pass the verification test.  I have been waiting for TAC to create a hotfix that will work.

Apparently it doesn't work well with a blacklist approach either.

It's very disappointing that I can't make it work as intended in my environment as I was really looking forward to the performance boost. 

[Timothy_Hall]

Using Geo Policy in a blacklist configuration is supported starting in R80.20 gateway.

As far as countries being identified incorrectly, please see this content which has been copy/pasted from my CPX 2019 presentation:

Geo Policy IP-to-country mappings are kept up to date by a gateway process called in.geod (debug log file $FWDIR/log/geod.elg). It automatically updates these files:

$FWDIR/conf/IpToCountry.csv - IPv4 to Country Code Mappings
$FWDIR/conf/GeoIPv6.csv - IPv6 to Country Code Mappings
$FWDIR/conf/GeoIPASNum2.csv - IPv4 to BGP ASN mappings
$FWDIR/conf/GeoIPASNum2v6.csv - IPv6 to BGP ASN mappings

Notice the two files mapping IP addresses to BGP Autonomous System Numbers (ASNs). BGP ASNs can be used to block or rate-limit traffic via the fw samp command – see sk112454: How to configure Rate Limiting rules for DoS Mitigation.

If planning to deploy Geo Policy for the first time, it is a great idea to check the modification time of these four files on your gateway, especially on gateways older than R77.30. If these files are not reasonably recent, consult sk108425: IPS Geo Protection does not perform daily update to get them updated before attempting to deploy Geo Policy enforcement.

If you suspect that your gateway has assigned the wrong country to a certain IP address, you can look inside the files mentioned on the last slide. (make sure they are up to date!) You may need to consult sk94364: How to determine which country an IP address is associated with for Geo Protections to help make sense of how IP addresses are represented in those files.

A much easier way is to just look up the country code via MaxMind which is who populates those files: https://www.maxmind.com/en/geoip-demo

Geo Policy drops will show up in the output of the fw ctl zdebug drop command with a stated reason of “Geo Protection”

Also be aware of the following situation that can cause the Source country to display an unexpected value: sk105019: Geo Protection logs show incorrect Source Country
 
Finally, Yuri Slobodyanyuk wrote a fascinating CheckMates article about the way various bad actors try to deliberately subvert Geo classification of IP addresses here: https://community.checkpoint.com/message/18178#comment-18322

[Mike_Jensen]

Hi Tim,

Thank you very much for all of this detailed information.  Basically what I was trying to do is block the top 20 countries or so mentioned in your book to achieve the mentioned performance increase.

I will read through all of this documentation and give it another shot.

Thanks again!

[phlrnnr]

Another good article for making sure geo protections are up to date is sk92823: Geo Protection fails to update

This doesn't require creating a scheduler job to update the defs.  It also explains that the update files are in $FWDIR/tmp/geo_location_tmp/updates folder on a GW.  The files there are loaded into the kernel.  The files in $FWDIR/conf/ are only used if it cannot load the files from the geo_location_tmp/updates folder.

Hope that helps!