cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
JPC
Newcomer I

Locking down outbound internet in Azure

Hello ISC2 community,

 

I was looking for a steer from anyone using a cloud service provider (or more specifically Microsoft Azure) for IaaS components.

 

I would like to lock down inbound and outbound internet connectivity from some virtual machines, but the current firewall we are using only supports IP based source/destination/port rules. This makes management of the rule set overly complicated as we never sure if the IP ranges are entirely up to date. I'm also not overly happy with allowing a rule that includes thousands of IP addresses that we may/will not need to communicate with at all, but are part of the range a software provider has given us.


My current thought process is to 1)look at implementing a proxy service or 2)look at a Next Generation Firewall that can handle URL based firewall rules.

 

Has anyone encountered this issue and found either of the two options (or a 3rd) to be the best way forward?

 

J

2 Replies
Community Champion

Re: Locking down outbound internet in Azure

 


@JPC wrote:

 

Has anyone encountered this issue and found either of the two options (or a 3rd) to be the best way forward?


I have encountered something like that, though I'm not entirely sure it's exactly the same. Azure is used as an IaaS & the connection to it is via a perimeter firewall's site-to-site VPN --- but this caters to subnets and ports, rather than specific IP addresses. (Even if it did that, granular control isn't much of a luxury if policies can't based on accounts)

 

I would like to lock down inbound and outbound internet connectivity from some virtual machines, but the current firewall we are using only supports IP based source/destination/port rules. This makes management of the rule set overly complicated as we never sure if the IP ranges are entirely up to date. I'm also not overly happy with allowing a rule that includes thousands of IP addresses that we may/will not need to communicate with at all, but are part of the range a software provider has given us.

In our case the main firewall doesn't do much besides providing a secure tunnel so we have to depend on a proxy / additional firewalls behind the main one, for access control policies based on users / systems. The controls can be set at multiple layers. (For example, users are restricted from logging onto AD systems with login restrictions in AD itself, as well as by rules on the proxy)

 

My current thought process is to 1)look at implementing a proxy service or 2)look at a Next Generation Firewall that can handle URL based firewall rules.

Let's look at 3 options : -

 

  1. Using a proxy by itself
  2. Using a NGFW by itself
  3. Using a NGFW along with a proxy

Option 3 would be the best, but cost the most. If you find a NGFW solution that offers all the features you'd expect from a proxy, it would probably fall cheaper if used by itself.

 

 

 

Shannon D'Cruz,
CISM, CISSP

www.linkedin.com/in/shannondcruz
Community Champion

Re: Locking down outbound internet in Azure

I've used both and am equally happy with either.  

 

Their URL categorization databases are the key.  This is what allows you to "outsource" understanding the details about how each web site works and to outsource maintenance of the "known bad sites" list.  

 

Without categorization, you end up needing to know unnecessary details, such as youtube.com requiring account.google.com when logging in.  Chasing these down is about as much fun as the IP address mire you are stuck in today.

 

Public cloud proxies, such as Zscaler and Blue Coat update their database real-time, whereas advanced firewalls, such as Palo Alto and Checkpoint tend to download the database a few times a day.  Depending on your needs, either might be sufficient.

 

When you add Azure to the picture, you will need to start to think about new routing and contingency approaches.  In a normal on-premise scenario, this is well understood and no big deal -- just cable things inline and use VRRP.  Things get tougher in the cloud world.  I do recommend starting with careful study of reference architectures.  Palo Alto's can be found here: AWS Azure.  Note that their PA's Azure architecture currently 404's.  Likely, they are reworking it to address the fact that the Azure load balancer does not work exactly like they thought it did.