Locking down outbound internet in Azure

[JPC]

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

[Shannon]

---

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

[denbesten]

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.

[komalrai]

If you are experiencing limited access to the internet outside of your home (for instance, due to the firewall or proxy), read this article to find out which specific outbound destinations are required for you to be able to register for a CDP environment.
When the Cloud Provider network you wish to register the CDP environment is using a customized DNS server that doesn't permit name resolution for public domains, you need to include all parts listed in the table below in the DNS forwarder to resolve the name.

On Azure, It is possible to establish network security groups (NSGs) based on IP addresses but not on hostnames. However, the requirements for egress filtering described here include not just static IP addresses but also hostnames, as the IP address can change over time. This means it's impossible to implement Egress filtering with NSGs. If you'd prefer to allow outbound access to your permit list using hostnames, then using an Azure firewall that includes FQDN filtering in the network rules is recommended. To do this, you can choose the Azure-hosted DNS or an individual DNS according to the FQDN filtering feature within network rule-making. It is important to note that connections created via Azure Private Link do not need to use the proxy.

[sergeling]

There are also Azure Application Gateway can act as inbound proxy. Or use Azure Firewall Premium for NGFW functionality.