One of the key features of the newest firewalls and intrusion protection systems (IPS) has been the addition of something called GeoBlocking. This feature allows the administrator to shut down traffic to or from specific countries or regions of the world and your local network regardless of any other firewall permissions in place.
For example, you might have a rule in your firewall that grants inbound permission from anywhere to your web server on ports 80 and 443. This would be normal for a web server to function properly and to serve client requests. Now let’s say you have decided that there is no good reason for your network to communicate with (from or to) devices located in North Korea. The GeoBlocking rule will cause the firewall to drop web requests (port 80 or 443) from client devices located in North Korea, although the firewall rule has a source “any” in the permission rule to reach the web server.
Use of the feature can be a significant enhancement in our ability to protect our networks. Not only do we get to suppress inbound potentially malicious traffic from the outside, but we can also interrupt the outbound flow from potentially compromised machines inside the network. This can help prevent a malicious program or actor from gaining a proper foothold inside our internal networks after a malware infection thus blunting the scope of the damage that occurs.
For our clients, CSI has always traditionally entered eight countries into the default GeoBlocking table, including locations such as North Korea, Russia, and Iran.
Late last spring, US-CERT put out an advisory regarding malicious activity that they identified as being sourced from a fairly large number of networks (at the time about 90 of them) in 14 additional countries and encouraged firewall blocks on all these networks. What concerned us was that while the initial report showed 90 networks (which was large enough to have to deal with) the fear was next week there would be 10 more, and then 10 more after that, etc.
After some discussion and consultation with several of our clients, we decided to experiment and add all 14 new countries to the GeoBlocking table for those clients. And while truly nothing bad has come from this more aggressive GeoBlocking stance, we have had some interesting items come to light.
In one instance, we eventually had a tech support case opened because the business office of the district in question was having trouble getting secure communications from their bank. We eventually could determine that despite the bank in question being a large US-based bank, or so we thought, the secure mail server used by the service in question was in Argentina, and Argentina was one of the countries now on the GeoBlocking list. It was a bit of an eye-opener that some part of the communications from their “local bank” was, in fact, passing through Argentina. Who knew?
In another case, the district was installing a new security system that involved IP security cameras that communicated with a cloud-based platform for monitoring and control. The vendor involved was having difficulty making the connections between the cameras and the cloud platform. We eventually determined that the camera vendor in question, Axis, was a Swedish based company and the cloud platform in question was housed inside one of their own data centers in Sweden, again a country now on the GeoBlocking list.
In this case, it was easy enough for us to determine the IP range that belonged to the manufacturer so that we could add in an exception to the GeoBlocking table for this communication. But it opened a discussion about awareness of and whether they were comfortable with some part of their district’s security system’s data being housed and controlled by an application and servers located in Sweden.
Both instances highlighted a couple important items for all network administrators going forward:
1. For critical systems, particularly those involving security, finance or systems that involve data that contains personally identifiable information about your staff or students, if your using cloud services to hold or send this information you will want to query your vendors on where their systems really are that are holding that data. You might be surprised and in some cases a bit uncomfortable with the answer you get, and it just might influence your final choices for vendor solution providers.
2. If you are using one of the newer next-gen firewalls with GeoBlocking features enabled and you are scratching your head as to why a system is not working (or stopped working) you will want to give your IPS logs (this is where GeoBlocking occurs) a quick peek. Perhaps some part of your system is in fact located someplace in the world you did not expect.
The Internet is truly a global community and regardless of the fact you may be using a local vendor for a project if it involves sending data to the “cloud” you never know where that information might be ending up. And in some cases, you might not necessarily like that answer and choose to decide to make another choice in providers.
You must be logged in to post a comment.