FirePOWER Geo Blocking Not Working

[moody]

We have a server that runs a script to block traffic from certain non-US countries.  Every night it emails a list of the connections it had to block. 

We purchased FirePOWER - and configured GeoBlocking - to Block/Reset connections from those same countries - however we're still seeing the server log connections that it had to drop. 

Has anyone seen issues w/ GeoBlocking not working? 

What exactly happens when the firewall does a Block/Reset? 

This was a rather expensive purchase for something like this not to work as expected.

[Marvin Rhoads]

It works in my experience.

What happens with a block depends on whether you are running a dedicated FirePOWER appliance or a FirePOWER module in an ASA. The former will send a tcp reset directly to the client for the session at hand. The latter will send a message to the parent ASA directing it to do the same.

[Lucas Phelps]

I think I found out that I had to put the GeoLocation blocking in a rule all by it's own.   So make sure your rule doesnt have other tabs of configured stuff, just geo. Then I put that rule at the top of my list to block them right away with reset.

[dan.letkeman]

This goes for all of the rules.  It's not obvious, but there is a logical "and" for each of the tabs.  So you cannot combine for example, applications and url filtering into one rule because you have a logical "and" between them, which in most cases will never match.  Because of this I have to have a lot of rules in the access control policy.  I really which there was an option to set the rule to "and" or "or" like some other vendors have.

Dan.

[Mark Combs]

I know this is an old thread but if you add the rule to the very top thats great.  But then the issue occurs if you want to add a specific IP address to allow you must insert it above that rule and then your rule is no longer at the top.

Example, you GEO block the country of China and place that rule at the top.  There is a specific IP address in China that you need to allow in.  You must then place that rule above your GEO blocking rule.

If my GEO blocking rule is further down the list then the logs states that the country is blocked.  However, I run packet captures and I know 100% that the traffic is getting through from these countries to my server even though the FMC states otherwise.  

- Mark

[mmcnetsupport]

I was having the same issue. I found that you cannot add the region (ie. Asia, Africa) as the source network or you will still have traffic allowed through.  I had to make rules and add the sub entries of each region to get my block/resets to work right.  I also had to make several rules because there is a limit of 50 entries for Source networks when creating a rule.  Hopefully Cisco can get the regional blocks to work properly one day.

[khanhluu82]

Instead of making several rules, create a GEO object with all the countries that you wanted to block. Worked well for me.

[bbiandov]

Wait a minute guys, are you serious, is the following still true "I found that you cannot add the region (ie. Asia, Africa)" for FMC 6.2.0.4?

If yes then what was the point of having those Geo Regions pre-defined internally by FMC? I mean what was the use if the regions do not work when used in an access rule?

I hope the answer is no but that's wishful thinking on my part and if it turns out that I have to defined countries individually (or as suggested here by defining a geo object), well then thank you so much for pointing out this blunt defect!

And just to be clear around the way a geo object must be defined correctly - basically just put a check mark on all countries except for those which will be allowed (the object will be used with a block rule):

[mmcnetsupport]

I am still seeing the same issue.  I have a global Geo block using the regions and I have separate country block rules further down the ACL for testing.  The event logging in FMC shows a connection from Russia being "Block with Reset", yet I still see the connection hitting my SFTP server logs.  I have no idea how to make this work correctly.

[bbiandov]

@mmcnetsupport I know this isn't answering the core question but I am curious to find a way to easily test this - other than going into the whole VPN and tor stuff is there an easy web GUI way to initiate https or even better -- an arbitrary proto just as you said (tftp, ssh, etc) from a foreign IP? This would be a good tool that all of us can use to test this whole FMC nightmare?

Thanks

[bbiandov]

I maybe onto something - details to follow. I suspect the access rules apply AFTER NAT translation has taken place, that is a game changer...

FYI: for the purposes of testing I have fund this handy free public proxy list, it works like a charm and of course no binary clients, each browser can handle the proxy setup:

https://www.proxynova.com/proxy-server-list/

[mmcnetsupport]

I assumed the rules were being applied after NAT as well but since FMC events still show the foreign IP as "initiator" that our rules would work with Geo IP as source network.  In my case, it appears that only the "Responder IP" changes due to NAT translation.

I don't understand why the FMC can show the connection attempt was Blocked with Reset, yet the connection does actually make it to the servers and inside of our networks.  If we want a connection blocked, the ASA/SF should stop it in its tracks at the edge and not make it even to the inside interface of the ASA.  Might just be wishful thinking on my part!

[John Telford]

To me this sounds like:
Behavior:
The first packet(s) is being allowed through while the a GEO DB lookup is performed and then the flow is dropped if a match to banned nations is confirmed. Cisco would need to confirm this.
Likely this is for performance reasons and/or the default post-ack setting (see below)

You would have to test by performing a valid connection and seeing how far into a session you can get. Assumption is it should be dropped, hopefully before you get a response or login.

Other vendor Geo Blocking IPS also behave this way for performance reasons but have the policy option to hold the connection while the IP to Geo look-up is performed.

Possible Solution:
Enabling Inline Normalization Pre-Ack
You should review the links below and discuss with Cisco first to ensure you understand the implications of Pre-Ack Rules. Monitor performance and latency if you enable it. We saw a minimal increase but our units were oversized.

We enabled it for a similar reason where the first packet of an HTTP Apache Struts ID:41819 attack were hitting the server before the flow was dropped. Like you we didn't want this behavior and enabled Inline Normalization. We were too aggressive with the settings and found that Macintosh client connections would randomly break and had to disable the "TCP Stream Configuration Option: Statefull Inspection Anomalies" to resolve it for Macs.

Talk to Cisco and test in a lab box is my recommendation. I reserve the right to be wrong :)

Links to Inline Normalization:
https://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/117927-technote-firesight-00.html

https://tozyer.wordpress.com/2014/12/30/sourcefire-snort-inline-normalization/

Let us know how it goes.

John

[antonkolev]

having the same problem  -  we  blocked a country  when source traffic  and still seeing   connection from the same originated country hitting our servers  

devices awe have are SFR 8350 managed from FMC 

[albert_sze]

Has anyone been able to respond to you? I created 3 global geolocation objects and used those defined in my access policy. 

Access Policy, Networks - Geolocation - my 3 objects 

Block and reset all traffic from these locations going anywhere.

I still get FMC notifications that IPs in China are attempting connections. I have also updated my GEO DB