G'day Cloud Gurus. Welcome to another episode of Azure Service Spotlight.
I'm James Lee, and it's great to have you with me for this episode.
We're going to shine the light on the Azure Firewall service.
Now we all know security is important.
There are stories of data leaks and website hacks every other week in the news.
So the important question becomes,
how can enterprises secure their network resources within Azure?
We could just take everything offline, no more online public access at all.
It's a very real option and it is actually one that several organizations like
defense and government might use for special applications,
but with more and more of the world's global workforce now working remotely,
it's becoming far less viable.
So many of the applications and services that enterprises host within Azure
are publicly available over the internet and network security is arguably more
important now than ever before.
So what's a really powerful tool we can use to protect those network resources
within Azure? You've guessed it. Azure Firewall.
Azure Firewall is a fully managed network security service.
It gives you centralized control over what goes in and out of your Azure
virtual networks.
It's another tool in the security toolbox to help protect you and your
organization from ending up on the front page of the mail.
So stick around for today's Azure Service Spotlight to learn more about the
Azure Firewall features and pricing,
and some important differences compared to network security groups and network
virtual appliances.
We'll also jump into the Azure portal and walk through a demonstration of
deploying and configuring the service before finally wrapping things up by
walking through my verdict on the pros and cons of the Azure Firewall service.
To understand the purpose of Azure Firewall,
it helps to briefly chat about where the service sits in relation to other
network security services.
Microsoft provide a range of tools to control network security for your
resources in Azure.
That can be virtual network security with network security groups or more
platform as a service focused security, for example,
web application firewalls for Azure web apps,
and there are so many more options. However, in the early days of Azure,
there was something missing from the network security toolbox.
Certainly for a lot of organizations I was working with who were migrating from
on premises into Azure.
A lot of these organizations needed advanced network security functionality
for resources within a virtual network and network security groups, or NSGs,
just didn't tick all the boxes. For this reason,
the Azure marketplace grew to include a range of virtual firewalls,
also known as network virtual appliances, or NVAs. I'm sorry,
for all the acronyms.
There are a lot of NVAs available from third party security vendors,
and that helped to fill those gaps. For example, Cisco, Fortinet, F5,
Palo Alto, and many more.
These all provided virtual firewalls within the marketplace.
And a lot of these NVAs typically provided more advanced functionality than it
was available with NSGs.
You could get features like fully qualified domain name filtering,
and there were other features like intelligent threat analysis,
advanced monitoring reporting, and much, much more. However,
it wasn't always that simple to license, deploy and configure NVAs within Azure,
especially when you wanted to run these NVAs at high scale or with high
availability and load balancing. Enter the Azure Firewall service.
Azure Firewall is a firewall as a service solution, which you can purchase,
deploy and configure all through Azure,
and you can use it to help protect your network resources within Azure,
both for simple network architecture through to more advanced hub and spoke for
hybrid deployments. With Azure being a fully managed firewall,
you don't need to manage the underlying infrastructure. Software, scaling,
and load balancing, and it provides familiar network security.
You can control inbound and outbound connectivity,
and you can also use service tags and application security groups like you can
with NSGs. It's also a stateful firewall. So for example,
it knows that the traffic, which is allowed to go out,
it should be allowing the reply traffic to come back in.
And it includes threat intelligence to alert or deny traffic from or to known
malicious IP addresses and domains using Microsoft threat intelligence.
Also it supports fully qualified domain name filtering.
So for those Minecraft servers you're hosting an Azure,
you can use DNS instead of trying to remember all the IP addresses.
Extending on top of this is something really cool, Azure Firewall Manager.
We can use Azure Firewall Manager to centrally manage multiple Azure Firewall
instances across subscriptions and virtual networks.
So whatever type of subscription hierarchy or network architecture you have,
Azure Firewall starts to look even more compelling. With all of these features,
you might be asking, what about the cost? For Azure Firewall,
when you compare it to NSGs, you certainly do have to pay more. However,
compared to the complexity and cost of deploying NVAs,
it is quite an appealing option. So let's have a chat about that pricing now.
With Azure Firewall,
you pay for each instance you have running on a per hour basis.
So if you have a geographically dispersed network,
perhaps you have a firewall in India and another one in Australia,
you'll pay for two instances for each hour they are running.
Then you're also going to pay for every gigabyte of data that is processed
through both of these firewall instances. The great thing about this pricing,
however, is there a no licensing fees,
unlike a lot of the NVA options which are available in the marketplace. Lastly,
I did just want to call out that Azure Firewall Manager is not included as part
of the Azure Firewall service.
It's technically a separate security management service,
and you do pay for it separately on a per policy, per region basis. Okay,
so we've got a great understanding.
Of what Azure Firewall has to offer and how much it can cost.
Why don't we jump on over to the Azure portal and see this.
In action.
Alrighty, here we are within the Azure portal.
So let's go ahead and get started with this demonstration.
To help understand what we want to do within this demonstration,
let's first browse into the all resources view of the Azure portal. Now,
what I want to do quickly is just mention a few resources that I've got here,
configured, ready to go. Azure Firewall, we don't yet have that.
That's something that we want to configure, but we do have some other resources.
We've got a virtual network vnet1, a virtual machine, vm1,
and a special thing called a route table.
This is what we're going to focus on within this demonstration.
The virtual network resources are what we are going to protect with our Azure
Firewall. Specifically,
we're going to protect virtual machine 1 using an Azure Firewall service.
If we quickly take a look at vm1,
you'll see that it exists within vnet1 one subnet one,
and it doesn't have any public IP address.
This VM has no inbound or outbound public accessibility.
If we have a look within virtual network 1,
you'll see that if we take a look at the subnets view, we have two subnets.
Subnet 1 and a special subnet we need to use for our firewall called Azure
Firewall subnet.
The last and most important thing to understand is this route table.
Through this demonstration,
what we're going to do is create an Azure Firewall service.
Let's say that we want to allow some inbound RDP access to vm1.
We also want to allow vm1 to have access to google.com.
We're going to create that Azure Firewall service, create those rules,
and then we need to use this route table to actually say that anything within
our virtual network should be using the firewall to go ahead and access other
resources. So first things first,
let's go ahead and get started with the creation of our firewall.
I'm going to type in firewall.
We're going to choose the first option here and go ahead and click on create.
Now,
what we want to do is we want to create our firewall within the same resource
group of our virtual network. So vnet1 which is this resource group here.
We're going to just call this firewall firewall1.
And I'm going to choose the region of Australia East,
which is the same region I have the virtual machine in that we're going to try
and protect. Now, you'll see straight away,
we get this option for availability zones.
So if I want to protect against data center failure,
I can actually do so by just ticking some boxes here. That's really simple.
When we compare that to actually having to deploy and manage NVAs ourself,
like we spoke of earlier,
we're just going to leave the availability zones as none for now.
And we'll choose an existing virtual network, which is vnet1.
For our public IP address, I've already created one.
So let's use firewall1-pubip. We're going to go ahead,
click on review and create, and then we'll click on, create and get started.
Now this can take a little bit of time.
So I'll pause the video until we're ready to go.
And then we can jump in and get started creating those inbound and outbound
rules. Awesome. That firewall's ready to go. Pretty simple so far, right?
We haven't had to deploy virtual machines, install any software,
configure licensing.
All the other sorts of things we'd have to do if we were using a network virtual
appliance.
Let's go ahead now and check this out and see how we can configure those rules
to allow inbound and outbound access for our virtual machine.
To understand how we can configure rules,
let's jump into the rules and the settings on the left hand side. Now, firstly,
what I want to just quickly show you is something called network rule
collection. If we click on add network rule collection,
what we're talking about here is the type of thing that you would be familiar
with. If you've used network security groups,
we've got the ability to control outbound connectivity using IP addresses,
ports, protocols, even service tags, and that sort of thing. However,
if we actually browse across to the application rule collection and click on add
application rule collection,
this is where we're talking about simplifying things using FQDN tags or
target FQDN. So let's say we wanted to allow access to Google. Okay,
we're going to give our rule a priority of 1000. For example,
we'll set the action to allow, and then we can go and actually say,
we want to allow Google access. Now for our source type,
we'll leave that as IP address, for the source we'll just say all.
So all machines behind our firewall can access Google for the protocols.
We can go ahead and type HTTP and HTTPS for web access.
And this is now where it's much simpler. If we want to access Google,
we might just say *.google.com.
So what we've actually done there is we've allowed computers behind our firewall
to have access to google.com.
And we haven't had to go off and find all the IP addresses for google.com.
That's something we would have to do if we were using network security groups.
The other cool thing about application rules is Microsoft provides some other
features called FQDN tags. So for example, these are Microsoft managed,
IP addresses and domains for things like Azure backup,
Windows diagnostic, and so on.
If you wanted to allow your virtual machines on your virtual network to have
access to Windows update, we can just tick a box and add the rule.
We're just going to delete that for now and we'll use the Google rule and go
ahead and click on add. Excellent, that rule has been added. So let's go ahead,
jump into nat rule collection.
And now we want to add an inbound rule to allow RDP access to virtual
machine 1. So let's say allow RDP.
We're going to give that a priority of 1000 once again,
and we're just going to add a new rule called allow RDP vm1.
For the protocol we'll choose TCP,
we'll leave the IP address as the source type, and for the source,
we're going to say that anyone can connect to RDP,
but normally you would actually secure this and lock this down to allowed IP
ranges, perhaps for your head office. So for the destination address,
what we actually to do is paste in the IP address of the firewall itself.
Remember this is the central egress and ingress point for our virtual network.
Everything that comes in and out is going to go via our firewall.
So for the inbound rule,
people are going to be connecting to our firewall IP address for the destination
port for 3389. That's going to be RDP.
Now the translated address is going to be 10.1.1.4,
which is the IP address of our virtual machine. And finally,
we're going to say 3389 for that as well. Let's go ahead and click on add,
and once that's ready to go,
there's just one final thing we need to do with the user defined route.
Okay, excellent. That rule is ready to go.
So now let's go ahead and quickly jump on across to the route table.
Subnet 1 route table. What we want to do is, you'll see,
we want to attach this rule,
which is going to force all traffic through the firewall that we just created.
We want to attach this route table to our subnet,
which is going to be vnet1 and subnet1.
This is just going to say that anything within subnet1 has to use the firewall.
Okay, excellent. So we've configured everything.
We need to be able to get inbound and outbound access to vm1.
Let's go ahead and give it a shot. To see this in action,
I'm going to move across to an RDP client that I have open on my computer.
And what we're going to do is we're going to RDP in and we're going to use the
IP address of the firewall. We're going to say, we want to connect on port 3389.
And if everything is working successfully, we should now connect, excellent,
to virtual machine 1. So if we're connected to virtual machine 1,
this is proving that we have inbound access via the firewall to vm1.
We've got that security through the firewall itself for a virtual network
resource.
What we want to do next is we just want to quickly confirm that we have access
to google.com. So if we open up Internet Explorer,
let's go ahead and see if this works. We're going to go to the URL.
We're going to type in www.google.com and press enter and
fantastic. We have access. So there you'll see it,
we've got our firewall working, it's protecting virtual machine 1.
If we tried to go to something like yahoo.com,
that's not going to work because we don't have the allowable.
So as you've seen folks,
it's really simple to get up and running with a firewall within Azure,
we don't have to deploy network virtual appliances.
We haven't had to configure licensing or any hardware. We click a few buttons.
We can have hyperscale,
we can have high availability and we get that familiar type of experience we
would come to expect for network security. So that's it for the demonstration.
Let's now have a chat about the pros and cons of the Azure Firewall service.
Azure Firewall is a great step forward by Microsoft to help those who require
the types of network security we've come to expect of a traditional firewall.
One of the greatest benefits right now is that it's firewall as a service.
And I've already said that,
but being as a service might sound obvious and not that important,
but I can tell you what,
being able to deploy a firewall and not having to worry about the underlying
infrastructure and software is a pretty big deal. For example,
as part of being fully managed, we have access to high availability and scale.
So you don't have to manage the backend nodes, scaling rules,
failover configuration synchronization, load balancing, and so on.
This and things like planned maintenance and failovers are largely managed for
you. All of this is manageable through the familiar Azure management interface.
You can use the portal or command line tools and so on.
You might even use the Azure Firewall service within an arm template as part of
a standardized configuration.
You can rapidly deploy out to Azure regions when your organization expands.
And when paired with Azure Firewall Manager,
we can implement network security for complex network hierarchies.
Now on the flip side,
Azure Firewall does lack some of the traditional firewall capabilities.
The gap is really closing, but vendors like Cisco,
Palo Alto and all the others I've mentioned have had a long time to create and
refine network security capabilities and some quality of life
administration features.
And whilst you can protect your web applications in Azure with the web
application firewall,
this feature is currently not available within the Azure Firewall service
itself. So you might end up having to run both.
Finally Azure Firewall is designed to protect resources within your virtual
networks. So you can't use it to protect against services,
which are not housed within virtual networks, for example, web apps,
container instances, and so on. At least not without performing some wizardry.
To wrap things up, should you invest, evaluate or revisit?
In my opinion, you should definitely evaluate the Azure Firewall service.
Azure Firewall has definitely come a long way.
And it certainly provides more functionality than NSDs.
And it's much more simple to deploy than an NVA from a third party vendor.
However,
you will definitely need to evaluate whether the Azure Firewall service provides
all of the features and capabilities that you require.
It may be that you only need features which are available from a third party NVA
solution. Another scenario to consider,
if the digital estate you have housed within your virtual networks is shrinking
by the day where you simply don't have much in virtual networks,
full stop,
maybe you're using other non virtual network services like Azure App service,
Azure Functions or something else. If that's the case,
then you should evaluate whether it makes sense to keep things simple.
Use NSGs for any network resources you do have within virtual networks
and rely on the other builtin network security features for the other services
you use. So that's a wrap for today, folks. Thanks for joining me.
And I look forward to seeing you again in the next Azure Service Spotlight.