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

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

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.

0 Kudos
2 Solutions

Accepted Solutions
PhoneBoy
Admin
Admin
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.

View solution in original post

Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

16 Replies
PhoneBoy
Admin
Admin
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
Collaborator

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! 🙂

0 Kudos
Timothy_Hall
Champion
Champion

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.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor
By using Geo Updatable Objects do we still get the same performance increase of blocking countries the traditional way?
0 Kudos
Timothy_Hall
Champion
Champion

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.

 

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor

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.

0 Kudos
Timothy_Hall
Champion
Champion

Code version?

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor

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

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor

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.

Panama log.png

[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

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Mike_Jensen
Advisor

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.  

0 Kudos
Timothy_Hall
Champion
Champion

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. 🙂

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Terri_Hawkins
Collaborator

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?

0 Kudos
Timothy_Hall
Champion
Champion

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.

 

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Terri_Hawkins
Collaborator

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events