Traffic Blocked by Geo-Policy Showing Up in FWLog on IPS Blade

[Terri_Hawkins]

We are running R80.30 take 111. We upgraded from R77.30.

In my GeoPolicy I have several countries blocked. I followed the steps in Timothy Hall's Max Power book to make sure I have everything set up correctly and it looks like I do. I know that in 77.30 GeoPolicy was coupled with IPS, but from my reading on here it looks like in 80.30 traffic hits the GeoPolicy log before it gets to the rulebase. 

I am seeing a lot of traffic on the IPS blade from countries that should be blocked by the geo-policy. I don't see the countries on any other blade (even the traffic which is just "detected" by IPS).

Is this normal? I would expect to see nothing in the logs from these countries (I have it set to drop and not log). 

Is my understanding incorrect? Should I be seeing this traffic? I am worried that in the upgrade process I may have done something incorrectly.

Any assistance is appreciated.

[PhoneBoy · Accepted solution]

The traditional GeoPolicy is still enforced prior to the Access Rulebase as was the case prior to R80.x.
However, you can now use Updatable Objects for all the same countries directly in the Access policy.
This allows you to be more granular with blocking (for example, allow all countries to access a specific server but block all other traffic from these countries).
Both GeoPolicy and the Updatable Objects should have the same data, though it is delivered to the gateway differently.

Possible that the update mechanism for Geo Policy is not working properly and you might need the TAC to assist here.
You can also try implementing your Geo Policy in the Access Policy in the meantime.
You should probably do this anyway as Geo Policy will not be further improved, given you can now do it (and more) in the Access Policy.

[Terri_Hawkins]

Thank you so much! I was not aware of these objects, I am changing over to them ASAP. May I ask, it seems like this should be the very first rule in the rulebase, is that correct? To keep down on the traffic?

Thanks again! 🙂

[Timothy_Hall]

Yes if you are using Geo Updatable Objects and looking to drop traffic it should happen very early in your Access Control policy, even before the Stealth Rule.  The third edition of my book released in early 2020 still covers the old Geo Policy, but strongly recommends moving to Geo Updatable Objects if using R80.20+ due to the enhanced flexibility, and covers exactly how to set it up.

[Mike_Jensen]

By using Geo Updatable Objects do we still get the same performance increase of blocking countries the traditional way?

[Timothy_Hall]

As mentioned in the third edition of my book, the legacy Geo Policy is enforced very early by the gateway in the F2F path, right after the antispoofing check in fact.  Geo Updatable Objects are not referenced until later when the Network policy is being checked in F2F, but with the advent of Column-based Matching in R80.10, rulebase lookup overhead has been significantly reduced.  So while there is a very slight performance edge for the legacy Geo Policy, the Geo Updatable Objects are far more flexible, easier to understand, and more than make up for it.  Assuming you are using R80.20+ on your gateways, Geo Updatable objects are highly recommended over Geo Policy, at least in my opinion.

[Mike_Jensen]

I have been experiencing the same issue with countries I have GEO blocked showing up in IPS logs.  

Take a look at sk164916 - Geo Protection does not block countries

It appears that IPS core exceptions are also applied to GEO policy.

[Timothy_Hall]

Code version?

[Mike_Jensen]

I am using R80.10 with Jumbo Hotfix Accumulator GA Take 259 both on my management server and gateways.

[Timothy_Hall]

Please provide a redacted screenshot of the log card showing this.  Geo Policy is part of the Access Control policy starting in R80.10, it should not be the IPS blade blocking it.

[Mike_Jensen]

Here is a screen shot of a IP from Panama that made it through.  I have Panama set "Drop" and track "None" in the GEO policy for this security gateway.  I was watching these logs in real time so I quickly opened a terminal session to the gateway and did a "fw ctl zdebug drop | grep 141.98.80.204" and what I saw is below.  It appears the IP from Panama was indeed being blocked by GEO but also made it past in at least this instance.

[Expert@:0]# fw ctl zdebug drop | grep 141.98.80.204

;[cpu_4];[fw4_7];fw_log_drop_ex: Packet proto=6 141.98.80.204:44490 -> 165.x.x.x57 dropped by fw_handle_first_packet Reason: Geo Protection;

;[cpu_2];[fw4_11];fw_log_drop_ex: Packet proto=6 141.98.80.204:44490 -> 50.x.x.x                                                             5.238:16957 dropped by fw_handle_first_packet Reason: Geo Protection;

;[cpu_7];[fw4_1];fw_log_drop_ex: Packet proto=6 141.98.80.204:44490 -> 50.x.x.x                                                             .245:16957 dropped by fw_handle_first_packet Reason: Geo Protection;

;[cpu_3];[fw4_9];fw_log_drop_ex: Packet proto=6 141.98.80.204:44490 -> 50.x.x.x

[Timothy_Hall · Accepted solution]

That log card does not show traffic that "made it through".  What happened is this:

1)  There were a bunch of drops for traffic sourced from a Panama IP address, these drops were performed by Geo Policy which is part of the Access Control policy

2) There were more than 100 Geo Policy drops from the same source IP address in Panama to the same destination port within 30 seconds (default settings), this triggered the "Sweep Scan" IPS signature which is looking for large numbers of IP addresses being raked for the same destination port number (port 22 is a popular target)

3) The Detect log card was created showing the Sweep Scan was triggered based on all the Geo Policy drops; it is just an additive alert saying "hey there have been a bunch of drops all against the same destination port (sweep scan), take a look at this unusual activity". 

The Sweep Scan signature itself does not actually block or allow anything, it is just a threshold that when reached triggers an extra logging alert.

[Mike_Jensen]

Thank you Tim! That makes sense.  I wasn't aware that the sweep scan would be based off of GEO policy like that.  It makes perfect sense now.  

[Timothy_Hall]

I'll admit the use of "Detect" as an action for a Sweep Scan is a bit misleading, and implies that something was Detected but not Prevented which is not the case.  But Sweep Scan is one of those dastardly 39 IPS "Core Protections" that walk proudly in "no-man's land" so I'm not surprised. 🙂

[Terri_Hawkins]

I hate to keep beating the subject to death, and I am guessing my answer to this is the same as the port sweep. I have traffic coming in from a blocked country on non http traffdic on http port, which is also one of the inspection settings. So it is actually being blocked right? just showing as detect for the same reason as the port scan?

[Timothy_Hall]

The Core Protections that create additive alerts with a "Detect" action are:

Sweep Scan

Host Port Scan

These alerts are triggered by drops that have already occurred over a certain threshold, these protections do not directly drop or block anything.  There may be other additive alerts like these but I can't think of any.

[Terri_Hawkins]

ok, thanks. I'll try and figure out why this traffic was getting through then.