Design and implement network security AZ-700
[ Music ] LACHLAN MATHEW-DICKINSON: Hi and welcome. My name is Lachie. I'm a Microsoft Technical Trainer and I'm glad to have you here.
In this video series, we will be looking at network security from a range of different lenses. Whether it be from how you get recommendations through the Defender for Cloud Engine to how you implement Azure Firewall, different layers that we can add onto virtual machines to access them in an easier and more secure manner, or whether it is adding different layers of security to application workloads. There are many different aspects to network security which you can leverage, improve upon, and make better for your environment. In this upcoming section, we are going to talk about network security from the very specific lens of Defender for Cloud. Now, there are many different aspects to Defender for Cloud as an ecosystem, but we are going to focus on just a few of them. We're going to look at the Microsoft Cloud Security Benchmark recommendations within the network security control space, and how that will affect your day-to-day, what you need to implement, and how you can notify yourself about what's coming up with it.
We're also going to look at a regulatory compliance lens. Whether it be ISO 27001 or a NIST compliance stack, there are many different offerings out in the world. Depending on what your business is, you'll need to comply with something. So how do we find recommendations to build out your security specific to those control frameworks? We're also going to look at alerts within Defender for Cloud.
When you get an alert, as a network administrator, what do you need to do with it? How do you find out the right information and know what's next? Let's begin with those network security controls in the Cloud Security Benchmark. In front of you here are the network security controls from the Microsoft Cloud Security Benchmark. This benchmark is a combination of Microsoft's insights of how our platform runs, industry insights of how their platform runs, and combinations of other cloud provider frameworks to ensure that there is consistency across all environments. Now, the things that you are looking at here are general security controls that we can implement at a higher level at your network architectural stack.
If we look at some of the examples here, let's take NS5. Deploying direct denial of service or distributed denial of service attack mitigation, it's a no-brainer. If we are running a web application, there is always a chance that a threat actor is going to attempt to attack us.
So implementing it at a higher level, it just kind of makes sense. But if you go to the Microsoft Cloud Security Benchmark Framework documentation that is over on Microsoft Learn, you will see that there is actually some explicit recommendations and links to other documentation to help you implement this. Now, the Cloud Security Benchmark hasn't come out of nowhere. When I say industry, I mean we have taken explicit controls from CIS, NIST, and PCI DSS in combination with the security frameworks that we have developed in order to get this baseline in place. So the Cloud Security Benchmark as part of Defender for Cloud is a great spot for you to understand what the posture of your environment looks like from a technical level.
It is also good to know that control and baseline actually have really explicit meanings within Defender for Cloud. A control is what we've just seen. They are generic and typically sit at a higher level in your environment. Baselines are for specific products and offerings. So if you get a recommendation that is focused on a baseline, know that it is looking at something like SQL databases or storage accounts. It's particular pieces of configuration that either yourself or another administrator within the environment can put in place to uplift yourself, get your enterprise into a better state.
Now, not everybody is going to be looking at these generic frameworks. I specialize in high compliance. That is my big background. So regulatory compliance frameworks for different countries, for different industries, for different parts of different industries.
There is so many out there. I recommend looking at Defender for Cloud for your regulatory compliance offerings simply because many of the technical controls that are part of these different frameworks can be automatically assessed. Have you turned this on? Yes or no? Sometimes it's a really easy question. Getting some sort of baseline that looks across your environment and just does the check for you.
Checks your work and makes sure you are in a good stead and you're in good compliance with ISO 27001 or a NIST framework. This is what you want. So regardless of the industry you are in, check with your GRC team and check with your internal compliance teams about what frameworks you will need to implement. And make sure to go look at this dashboard and understand what controls will apply to you as a network administrator. Now, the other area that we look at within Defender for Cloud is the live monitoring space.
Alerting within Defender for Cloud, much like alerting in any SIEM or SOAR tool, is focused around different types of potential compromises. I say potential because not every alert will lead to a particular threat actor, but it is worth investigating them. If you receive an alert in Defender for Cloud or this is something your organization is using, just make sure you understand what particular alerts are built in for your network controls.
Note that many of the ones we're seeing here are focused around DDoS attacks. This is fairly common, but it is a really easy check to say, these are the times we actually saw an increase in traffic. Now I can go check my firewall logs or my application logs or the specific things to understand why that happened. Remember, the alerting system in Defender for Cloud, if this is the thing your organization is using, this is going to be the place to find out if there is a potential security incident in your environment with giving you specific ideas and specific controls that you can put in place to rectify and mitigate any attack.
In this section, we are going to be looking at DDoS protection. Direct denial of service attacks are one of the most impactful and simple attacks that can happen to an enterprise environment. The level of panic that someone can experience in a security operation center when one occurs, it's never great.
So what I want to look at is just a few different mitigation tactics that are available within Azure. Now we're going to start with some definitions. We're going to look at both what a DDoS attack is and also some of the different types of DDoS attacks that are available. That second one is going to be important because depending on the type of attack we're looking to protect against, we have different protection methods. And our focus today is on Azure DDoS protection, capital A, capital D, capital P, a very particular product. So let's begin with that definition.
A distributed denial of service attack means that we are getting multiple different inputs from different sources, bots, users, take your pick, that are targeting something in your environment. A public endpoint or an open port. The general purpose of a DDoS attack is chaos.
We're looking to take something down or we're looking to distract from some other type of attack. But the point is these large botnets, these large distributed locations that are sending this data to you, they have huge potential impact on your environment. Now, there are multiple types of DDoS attacks in the world, and I'm going to be looking at three specifically.
The first is the volumetric attack. This is the simple flood the lines idea, whether it be through an exploit or just through a sheer number of different endpoints hitting your particular location. The idea here is that we are going to see an impact on your environment.
So what can we do to mitigate this? Well, the nature of Azure's environment is that we will be able to mitigate most flooding attacks of this type. Volumetric attacks are typically handled by the multi-gigabyte scale of Azure's network global environment. But there is also DDoS protection standard to help mitigate these attacks more closely, something we'll look at in a moment. The second type is a protocol-based attack.
These are exploiting different weaknesses and flaws in layer three and layer four of the network stack. And we're looking at that OSI model to understand how that could potentially be coming through. These different flood or reflection attacks that can occur here, they reflect different types of malicious traffic coming through. Now, whether it be malicious or legitimate, we need to understand how the client is interfacing with this and what traffic represents malicious.
What is malicious and what's legitimate? We'll be looking at how we can handle these attacks as we go through. Now, the last type of attack is a resource layer attack. This is occurring at layer seven of the network stack. HTTPS attacks, different types of reflection attacks at that level.
And we would typically look at the different types of offerings within the web application firewall stack to protect here. Now, having said that, DDoS protection standard does provide a level of defense against this, but it depends on what you're looking for. There are many different firewall offerings that will also provide good protection against layer seven attacks because they're quite well known. SQL injection attacks can be a component of this as well. Now, Azure DDoS protection comes in two primary flavors. There is DDoS network protection.
This is something we enable on an environment as a whole. Target a virtual network, enable it for protection, and you have volumetric protection on that network. The other kind is DDoS IP protection.
This is where we are targeting a specific public IP in your environment, and we are protecting that one IP. There are a number of different reasons you would choose one or the other, but most of it comes down to pricing. Understanding the different levels of protection that you get from them, that can be very helpful. But ultimately, this will be a decision around what is important in your environment.
Is it that we need to protect an entire core network? Is it that we are looking to protect an entire DMZ that we have built out? Or are we just going to target key applications and protect the IP addresses of those apps? This is your call, and depending on your environment and your application structure, you're going to want something a little bit different. Okay, enough about what we're doing, what we're protecting against, what we can apply to. What do we actually get with Azure DDoS standard? This is what you get when you enable. Traffic monitoring, customization and fine tuning, metrics and alerting. These three things are stuff that a network admin is going to want straight away, as well as your security team to know when something is happening.
Turnkey protection, multilayer protection, these are all focusing on different types of protections that we can put in place, as well as that you're getting the mitigation scale of Azure itself. But this, this is the one that I want to focus on. Azure DDoS Protection Rapid Response is a team that will assist you around the sun if you are under a DDoS attack. If something gets through our environment and hits you, this is someone on the other end of the phone to help you through that process.
If you've never been in the room when a DDoS attack occurs, it's one of the more stressful types of basic security incident that can happen. Having someone with a clear head to be able to talk you through it and work through the mitigation process is extremely, extremely nice. So for me, this is the most valuable thing that we can get out of the DDoS protection plans. All right, how do we actually enable the things? It's as simple as clicking through and just creating something.
So that's what we're going to do. I'll be taking you across the portal and I'll just show you how you actually create your DDoS protection plan. I'm then going to actually just enable it on one of the various things that we can enable it on, which is a virtual network, just to show you what it looks like to actually put it in place. All right, let's jump into it. All right, DDoS protection plans.
Let's begin by just creating one. It's kind of the place to begin, right? Hit "Create" on the top left, choose your resource group, choose your location, all the standard stuff that we would expect for any Azure resource. Core networking, and we're going to go DDoS protection. Nice and simple. Note this here. You can create a single DDoS protection plan and apply it to all resources in one of your subscriptions.
DDoS protection plans typically are created at a per subscription level. So create one and then target different areas of your business, depending on what you need within that subscription structure. All right, I'm going to hit "Review and Create" here, and I'll join you back here when everything is done spinning up. Welcome back. So we now have our DDoS protection plan.
We're spun up in East US, and we're ready to go. Heading over into the top left, we'll open the blade, scroll on down, and protected resources in the settings is what we're looking for. Jumping into here, you will see an extensive list of different resources that can be protected by DDoS protection. There's even more down over here. The thing that I am interested in is just the virtual network.
We're going to enable it on a VNet as a whole. So to do this, simply hit "Add". All we need to do to get the protection, target the thing we're looking to protect, and we're done.
DDoS protection is designed as a turnkey solution. When I said that, I meant it. It truly is a one-, two-click process to actually get yourself up and running and get your resources protected. You only need one DDoS protection plan resource per subscription, somewhere we can store the metadata, and everything else can be done straight through the portal here. So if you're looking for the easiest way to begin mitigating DDoS attacks from day one in your environment, and you'd like the idea of that support if something goes wrong, look to DDoS protection plans and how you can get those set up. Nice and simple.
Up ahead, we're going to be looking at network security groups. No matter the size of your enterprise, the size of your architecture, whatever you are building, NSGs will make a huge difference in the baseline security of your environment. They are the simplest possible stateful way to check, allow or deny should this traffic be coming through. We're going to be focusing on how NSGs work, how you can create rules for them, way priority functions, a few different technical controls along that way. But there are some other things I will be talking about. Service tags and how you can utilize them to open up different resources to a range of Microsoft services.
And application security groups, which are really interesting way of implementing more tag-based controls around network traffic. Let's start at the top. What is a network security group? Where do we put it in place? How do we actually get it up and running? So the network security group or NSG is one of the most fundamental low-level pieces of network control that you have in an Azure environment. At any network interface card level or subnet level, you can apply an NSG with simple allow or deny rules to say what is allowed where. If you need to restrict traffic between subnets or even within a subnet, you can do that through the use of an NSG.
NSGs are also not necessarily one-to-one. You can have one NSG that can be applied to a range of different resources or have generic network security groups that reflect the security posture for multiple different subnets. Really, the only thing you need is a network security group per region, and then you can scale from there as different changes need to be made. Now, it is recommended at most scenarios to build out network security groups at the subnet level specifically. We'll get into why in just a moment, but for now, know that it is simplicity's sake. We are trying to keep things nice and easy for you.
Let's first focus on rules. NSG rules are key to keeping things up and running and also keeping things restricted or controlled in the way you're expecting. The way that NSG rules work is through a priority system. For users, you are able to configure priorities 100 through 4096 in both inbound and outbound traffic. We can see that someone has created a rather open RDP inbound to anything, anything is our first rule there.
I wouldn't recommend doing that, but it's nice for an example. But do note that there are a range of different rules available here, which are in the 65,000 range. These are extremely low priority rules that create a default posture for you. This is one of the reasons that NSGs get used so extensively, even in large architectures.
Because we have guaranteed control that on an inbound connection, virtual network traffic is allowed, load balancer traffic is allowed. This is something we use in the Azure ecosystem, so we need that open. But that all other inbound traffic will be explicitly denied.
That's a very good baseline security posture. And you can improve or override these rules simply by creating your own. Your priority starts at 4096, and that is a much higher priority than 65,000. So by creating any rule, you override these. Additionally, on the outbound side of things, we allow VNet outbound. So we can communicate between virtual networks.
We allow internet outbound. So virtual machines can go patch and communicate as they need to. But otherwise, we deny all other traffic. Again, if you wish to restrict this further, you absolutely can. Simply add a higher priority rule that contradicts it.
Yours will take precedence. So rules can get pretty complex pretty quickly. You've got a lot of different potential numbers to work with and quite a long priority list.
So this is where I get into why we recommend putting our network security groups only at the subnet level. Take this effective rule diagram as example. If I have a network security group, network security group 2, applied to the subnet, and a second NSG 1 applied directly to the network card for a virtual machine, what if I need to allow some traffic through? Let's say port 80, web traffic.
Beautiful. I allow it through at the subnet. That check is complete. We allow the traffic through.
And now I have to duplicate that rule on the inside. Inbound and outbound, you are going to be doing a lot of duplicate work anytime you have stacked NSGs in this way. So if you need it, this is an extremely useful thing because you can restrict individual virtual machines in a subnet and make them behave in a different way to the subnet on the whole.
But for the most part, try and keep it purely at the subnet level. It makes management easier and it'll just generally keep your life in an easier state. If you're not sure what's being applied to a particular virtual machine, head to Network Watcher. There is an effective rules check which you can apply to any NIC in an environment and find out all of the different rules that are being applied to a single network card. Now creating rules has a range of different things that you need to put in place.
But for the most part, we are focused on inbound port and IP, outbound port and IP, and then a priority, and if the traffic is allowed or denied. So there's some core things that we'll be doing. And as we go through each of the services when I demonstrate this in the portal, I'll show you how this can change depending on the type of service that you're looking to select. Now my general recommendation is that unless you are targeting a specific IP or range of IPs, try and utilize some of the service tags that we have available.
For example, here we have a number of different service tags that are targeting specific Microsoft services. Here we have an allow rule that is explicitly going that if data comes from a virtual network and is headed for any storage service, so storage accounts as the example here, we allow that traffic. If data is coming from virtual network and is heading to the East US region and is targeting a SQL database, we allow that traffic. Service tags mean you don't need to necessarily know the specific data center IP ranges that can change and be updated for individual services in Azure. All you need to do is apply the service tag and we'll maintain those in the backend. Now to answer the question which I'm sure many people will have, service tags are controlled by Microsoft.
So it is not something you can go through and add fresh service tags to an environment. But we do have a construct which works in a similar way, which you do have full control over. That is the application security group. Now, whether you are using virtual machines or private endpoints by the private link service, you can leverage application security groups to create more or less your own service tags.
Take for example here, I have one network security group applied across two different subnets with three different data pathways being controlled entirely via name. We create something called ASG web and I allow traffic from the internet to come into service that are tagged with ASG web. But if they're not, deny the traffic. I allow the logic box to communicate to the database in the backend, but no other service can follow that pathway.
Application security groups allow you to put role tags onto resources in Azure. Customers I find are in two minds about this. They either go all in on application security groups, make it a core part of their security principle, and it works fantastically. It is a super great way to reduce the number of network security groups you require in an environment.
The other thing that customers do is simply expand the network space, use subnets for subdivision and apply network security groups to each of the subnets to control it that way. There's no one right answer, but this is an incredibly useful tool to have up your sleeve if it matches the scenarios you're looking for. All right, we're going to dive into the portal now. I want to show you network security group creation in a bit more detail because it helps to really get an idea about how rules specifically get created.
Here we have a rather long named network security group. I got a naming convention. It's fine. And what we're going to do is add a custom rule to this. Now the rule that I wish to put in place is going to be using service tags, but I'm going to show you some of the other options along the way. On the left-hand side, we'll open the blade and then I simply select whether I'm creating an inbound or an outbound rule.
And in my case, inbound is what I'm looking for. I've already got a few rules in place to make sure I can access things, but let's add something fresh. I'll hit "Add" and the first thing we get to pick is a source.
Now, source can be a number of different things. A range of IP addresses or single IPs. Great if you need to open things up for someone who's a work from home user or you want to open up for your corporate IPs. Service tags, which allow us to look for a particular Microsoft service and open it up that way, or application security groups where we've tagged virtual machines or private endpoints with a particular purpose. I am going to stick to the service tag for now.
Because what I want to show you is that service tags are not necessarily just for Microsoft services. Note these first two, internet and virtual network. What we can allow is inter virtual network communication without necessarily knowing the IP address we wish to address here.
This is a really useful metric because it allows us to open it up to say, hey, it's not that I care what virtual network is accessing it. If I have already established a secure pathway between these virtual networks, that traffic should be allowed because it is originated from the Microsoft virtual network stack. A super great way to mark things in a more generic fashion.
We can then select our port ranges on both the inbound and also the destination. Take your pick on how you want to set these up. But do note this service tag here. If you know the exact port and protocol you wish to use, simply open it up.
But otherwise, select from the dropdown list. For my mind, I want to open up TCP, DNS, port 53, all being set up automatically. So simply by selecting that, I'm good to go. Put in your allow action, select a priority. It's already auto selected the next one along, but I can easily change this to something else.
Just make sure you give yourself a bit of the head room on either side. If you set something important priority 100, it's going to be the highest priority rule no matter what. So give yourself that breathing room. Auto name generation, but you can of course change this and add a description if you want.
But once you're done, we're done. Adding rules is extremely straightforward and there's really not too much else you need to do. Putting that in place, maybe rebooting something if you want to really test stuff out, you can. But it is applied immediately.
Heading over to my blade again, we can also look on the other side of things and where this is being applied, either on the network card level or in my case, at the subnet level. We can see exactly what subnets and what virtual networks this particular NSG is protecting. So if you need to get a summary of where protection is actually lying, it's nice and easy to do. Close things out.
Network security groups. Even if you have advanced firewall, even if you have the best architectures in the world, you are going to be utilizing them as a great baseline, simple, low-level mechanism to understand whether traffic should or should not be passing through your environment. Look to them anywhere you need that really low-level control and want that protection for your environment. We're going to start talking about Azure Bastion now.
Now Bastion is a really interesting service that's kind of there for one particular reason and gets used for a lot. Let me talk you through the scenario of how Bastion gets utilized, which is going to be the big part of it, and then I'll just show you how to actually use it. There's not a lot to demonstrate, but there is a lot to think about in terms of how this can affect the way your business interacts with virtual machines in the cloud. Let's dive straight in.
Here we have a diagram that represents how Azure Bastion will fit into an environment. Now Bastion can sit in the hub of a virtual network and can actually connect through to other spoke virtual networks, or you can have dedicated Bastions for individual things. There's only really a couple of things that we need to get set up to make Azure Bastion work. The first, Azure Bastion requires an Azure Bastion subnet, capital A, capital B, capital S. It needs to be named in that exact way and it needs to be a slash 26 CIDR block or larger. This is important because subnets with this name and that we have deployed the Azure Bastion service to have special navigation rules about how they can actually work within the Azure environment itself.
So what's the connection pathway if I need to remote into one of these virtual machines and access via either SSH or RDP? I start on the left-hand side. I am an administrator and I log into the Azure portal. And from here, everything else is handled directly via TLS over port 443, normal HTTPS.
Interact with the portal, click the Bastion button, and it will interface to the Azure Bastion host. This host will then, based on the ports you've opened with network security groups, interact with the target virtual machine, and you'll be able to input the credentials that will allow you access to said machine. And from here, you will be presented with a normal remote desktop session entirely within your browser. And that's kind of it. Bastion is designed to be a simple turnkey solution to give you remote access to virtual machines without having to expose a public IP to the internet, or worry about opening and closing ports on demand. Of course, we can add additional controls if we want to, but that's your environment and you can configure it how you need to.
Let's jump straight into the demo now. It's a fairly simple process to get things set up and to remote in, but it's important I show it to you so you know exactly what you need to do. Here we have a virtual machine that I've been using for testing purposes in my environment, and I want to be able to remote into this using SSH.
To do this, I have a couple of options. I can click the "Connect" button up here, and I can just do a normal SSH connection. As long as I'm able to access either a public IP attached to the virtual machine or a private IP via an express route or similar, I can remote in that way.
But I'm going to show you how to do this via Bastion, which means I don't necessarily need a private network connection to this machine, and we definitely don't need a public IP attached to the VM to make it work. Let's hit "Connect via Bastion". Now you'll note I don't have Azure Bastion installed.
This is not something that I have currently deployed in my environment, but because I am an administrator of the correct privileges, and we know where this is deployed in terms of the virtual network, all of that sort of stuff, we can simply hit "Deploy". Yes, there is a public IP address here. This public IP address is used as an interfacing point between the Azure ecosystem and the Azure portal, and is not publicly addressable into the broader internet.
This has heavy restrictions on it specific to the Azure Bastion service. So let's hit "Deploy on Bastion", and we'll come back once the deployment is complete, and I'll show you how to do a connection. And we're back.
So here we have the Bastion that I have deployed into my environment. This is now in the same subnet as the virtual machine I will be connecting to, but you could just as easily have the same Bastion service sitting in the hub, and then use different peering methodologies to connect those together. For this particular one, I've chosen to go with a virtual machine username and password combination, but you can actually store things like credentials within an Azure Key Vault, pulling the password from there, or using SSH keys.
Just depends on your connection methodology. And once you're ready, it is as simple as scrolling down, hitting the "Connect button", and in a new tab, your window will be open with a remote desktop session ready to go. Firewalls in our environment are one of the key network security components.
That's a fairly straightforward statement that I feel I can make. So what are we looking at in this module? Next-generation firewalls are something we can deploy as a third-party appliance, or we can look to a first-party offering from Microsoft. And that's the one we're focusing on, Azure Firewall.
Azure Firewall is fantastic for a whole range of reasons, whether it be because of the scalability that happens in a managed service, the fact that it can cover all of the different layers of the network stack to analyze different types of rules, and give you advanced threat protection. Whatever it is you need, Firewall provides those for you. We're going to run through a little bit about how Azure Firewall works, where it should sit within your network stack within a HubSpoke topology, and then I'm just going to show you a little bit of the portal about how Azure Firewall actually looks when you are accessing it. Let's dive in. So Azure Firewall, it is a stateful firewall as a service. As a service is important here.
When you are deploying a network virtual appliance-based firewall, or even a firewall in an on-premises virtualized environment, scaling is one of the big issues we face. Whether it be for licensing requirements or simply having enough vCPU cores to be able to meet the network demands that you're looking for, it's always a hassle from an administrative standpoint. Azure Firewall is a managed service. All you need to do is provide us a subnet space to land the firewall deployment, ability to scale up and down, which is done via picking the right SKU, and provide us the configuration. Do those, and you have a firewall that will be running that has a high SLA and will be in your environment ready to go.
It is designed to be high available by default. There is no extra architectural requirements to get it in a multi-deployment setup where you need multiple instances running. This is high availability cloud as a service offerings. Threat intelligence integration is native within Azure Firewall. The Microsoft threat intelligence feed is built in to Azure Firewall, and you can leverage this building out different rule sets to protect against known and emerging threat actors in the environment.
The fact that it also integrates so well with Azure Monitor, and therefore things like Microsoft Sentinel and other security systems is critical. So its deep integration with the Azure ecosystem as a whole is incredible. As a last point, I do want to call out this hybrid connectivity space here. It is actually possible using Azure Firewall to create forced tunneling scenarios where the firewall acts as a yay or nay point for how traffic is passed around your environment. Using it in a centralized hub model like this, we can actually force tunnel traffic back to on-premises after it has been evaluated for security purposes. I do want to call this one out because there are many customers where this is an explicit requirement.
So it's a nice one to know that it has. All right, features, all of that aside, let's dive into the nitty-gritty. We need to talk about the different types of rules that are available in Azure Firewall, because this makes a big difference to how your things are going to be processed. Azure Firewall has three different rule types. The first is a NAT rule. This is a network address translation rule collection.
So we will create a bundle of rules that represent something we wish to achieve in the environment. From there, we can create individual rules within that bundle that allow us to do destination network address translation. This is extremely useful if you just need to do a simple translation from one port and IP to another port and IP. But beyond this, we also have two other rule types. Network rule collections, these are similar to what you would get within a network security group, looking at port and IP combinations and allow or deny that traffic through. And application rule collections.
Application rules are the big thing that Firewall brings to the table at a baseline. This allows us to filter instead of by IP on fully qualified domain name or FQDN. Take the classic example of a virtual machine that needs to fetch updates.
If it is a Windows machine, it's going to reach out to update.microsoft.com or something similar. How do we know what IP that is? I mean, you don't. It depends on where you are in the world.
It depends on what servers are up and down. It depends on what services are currently available. There are so many different things that will route you to a different IP address.
But it's pretty clear what URL we're going to be reaching out to. So we can create an application rule that filters on this URL, filters on that FQDN that allows us to just target any traffic that is destined for update.microsoft.com. It is a significantly simplified way of collating our rules together.
And it's something we would expect of any good quality next-generation firewall. Now deploying Firewall is a fairly straightforward process. Like many things in Azure, it's a few clicks and a few pieces of configuration. But setup will be key. Making sure that you are prepared to deploy Azure Firewall is going to be a big part of actually deploying it.
When you go through the process of setting up Azure Firewall, there are a lot of different steps along the way. Of course, subscription, resource group, these are all key things. But we also need to pick region and availability zone. Are you going to have your firewall in multiple zones? Are you going to have one per zone? This depends on your broader network architecture. So design accordingly. How are you going to be bundling your policies? We need a set of initial policies to apply.
So what's going to go in there? How are we going to choose virtual network that we're going to land in? Are we going to be isolating this firewall away from the public internet? Or is it going to be acting as our ingress/egress point for all internet traffic? These are all huge decisions you need to make early on. So what I recommend is looking at the documentation in the Azure Architecture Center focused on hub spoke network topologies. Now why am I directing you there? A centralized firewall is a key component of any modern enterprise environment. Most enterprise environments that I have worked with in the customer world have switched to a model that represents roughly what we're seeing here.
Centralized shared resources like gateways, firewalls, Bastion services, remote desktop connections, sit within that shared bunker of the hub. Within the spokes, we see different workloads, different applications. So we're able to use shared resources in that one spot and then distribute those amongst the others as needed. But where this gets a key advantage is in the form of that centralized firewall.
Controlling traffic as it flows in and out and having one point that our traffic has to pass through. By doing this, we can ensure that only the right traffic gets to the right spot and anything else is either blocked, dropped or redirected to somewhere else. As a firewall is designed to sit within a hub spoke topology like this, this is one of its core design principles that will help you in terms of implementing a broader network strategy. So if this is firewall, there's one last thing I do want to call out. Often, I actually got a question in classes of how this differs from a network security group.
Now, of course, Azure Firewall has many, many more features than what a network security group offers. But at its core principal layer, it is allowing or denying traffic based on rules and requirements. The key thing to remember is that if that is all you are using firewall for, network security groups do not support the idea of an application style rule using FQDN tagging. If that is something you're looking for, you will absolutely want to look at one of the Azure Firewall SKUs. If you are looking for more advanced features, you will likely use these in combination in different parts of your environment. This is following the defense in depth network model.
So work with it. All right, I'm going to take you across to the portal now. I have an Azure Firewall deployed already and I want to show you just a couple of things about how it behaves within the portal ecosystem. Azure Firewall in the portal is nice and easy to work with. Depending on what it is you need to change or implement or add, we kind of do everything from the firewall manager here.
On the left-hand side within the blade, I have a lot of different options. Things like public IP configuration. This is actually extremely important.
Are you going to be using this firewall as your ingress/egress point? You'll want one or more public IPs associated with it. We also need to look at what monitoring components we have. Make sure you are understanding what metrics and what diagnostic components are actually going to be able to be brought out of the firewall.
One thing that you will not see here though, is the rules attached to this firewall. There's a good reason for that. If I scroll down and we take a look, you will see a firewall policy. This is designed so we can have one policy that can be applied across multiple firewalls if we so choose. Let's jump into my default premium policy here. That's something I've named it.
And take a look at some of the details that I've set up in terms of baseline policies. On the top left-hand corner, we'll open this blade once more. And now we're presented with things that are a little bit more familiar. DNAT rules, network rules, application rules.
These are the things that are going to allow or deny certain pieces of traffic. I think I want to leverage that specific example around Microsoft updating, the Windows update protocol. Let's head into application rules here. We'll take a look and actually add our first rule specifically focused around this.
The first thing we want to do is add a rule collection. The collection here is going to establish sort of a baseline of what we're looking for. It gives us an idea of the sorts of things that we're doing. So this is going to be for update rule set.
We have an application rule type here. And I'm going to set a priority here of 1,000. Priorities need to be set somewhere between 100 and 65,000. So take your pick. Then individually I can add rules.
And each one of these rules we can add however we so choose. So Windows update. If my source is a particular IP address or an IP group. IP groups can be useful if you create those in advance. This is good if you want to bundle certain virtual networks or maybe create something that reflects an on-premises IP range.
You can do that. We're going to do nice and simple and just wildcard all. We're going to go keep nice and simple here with HTTPS 443 request on the protocol. And then we can see destinations.
There is multiple different things here. FQDN, FQDN tag and web categories. Web categories depending on your SKU of Azure Firewall, allows you to well categorize the web. Are we looking for social media sites? Are we looking for different types of websites that may be harmful? You're able to put in those web categories and restrict that traffic or redirect it accordingly. I'm going to look at the FQDN tag here, because there are a number of things pre-populated. One of the ones that's really useful for me is Windows update.
It's already there. So make sure you check the FQDN tags to see if the service you're looking to filter for is already pre-populated. This just makes it a lot easier to manage en mass. All right. Now at this point, I'm ready to add.
I hit "Add." This will create the rule collection and set it at the priority that I have determined, and then it will go through and add the rules that I've set within it. I can always add more rules to a collection over time if I want to. So very straightforward to get everything up and running. Next step, run our traffic through it, get everything pointed at the firewall and the filtering begins. We're going to be looking at Azure Firewall Manager now.
This is a particular service designed to help you when you are running multiple instances of Azure Firewall. In an enterprise environment, you are likely to have one or more per region. So making sure that rules are unified, that we can have centralized rule sets and that we can kind of keep everything all in line is pretty important. Azure Firewall Manager is designed to assist you with this process, whether it be from the simple management of those rules and rule collections all the way through to deployments across both virtual WAN and also virtual network hubs.
I'm going to show you how Firewall Manager works, what some of the architectural principles look like for it and a little bit about administration as well. Let's dive into it. On the right-hand side of the slide, we have the core architecture that represents how Azure Firewall Manager is intended to be used. We are able to have a global administrator sitting at the top dictating centralized rules. This is important because these rules will have hierarchy precedents.
So we can have hierarchical policies that represent a core tenant of your business, your business structure, your security boundaries. And then based on the environment or the things that flow beyond each individual instance of a firewall, local administrators are able to make modifications and run those accordingly. On the right-hand side, we have a hub virtual network. So this is a hub-spoke style deployment.
Not a problem. You can run your Azure Firewall in there or in an Azure virtual WAN deployment. Take your pick. Whatever works, works for us. The key thing here is that across each deployment of your firewall, you'll be able to have consistency while still giving the flexibility for local administrators to make adjustments based on the environment requirements.
I want to dive into this just a little bit more. But before I dive away, don't forget about the security devices that can be deployed into virtual WAN. These have incredible integration with V-WAN on the whole and really work well side by side with something like Azure Firewall.
Azure Firewall's design practice around general rule administration works something like what you're seeing here. We have a prod and a staging hub. Both of these need to be reflective of our core policies that, well, they reflect production. We want to make sure that something in our staging environment is going to work the same in our prod environment no matter what. So we apply core policies that roll through into each of these. But like most environments, my environment here requires some adjustment for my dev space.
There's little things that need to be changed. Stuff that's not quite the same. IPs that are a little bit different. Not a problem. We can ensure that the global policies are still applied in that dev space and then we can make adjustments accordingly.
But it is isolated to just the firewall managing the dev environment. Think about how you can use this for cross region management, for multi environment management, even for just different levels of environments within your enterprise environment. Firewall Manager is designed to keep things as straightforward as possible and reduce the strain on administrators for making sure that everything's right. Regardless of whether you're using something in a virtual network hub or if you are going down the pathway of using virtual WAN, it doesn't really matter how we get there. The general process remains the same though. Create your policies, define your networks, and then look to Manager as a way of rolling those policies out on mass.
The specifics do vary, so make sure you check the documentation on learn.microsoft.com for specific details for your style of deployment. No matter which way you are going, the second you have more than one firewall in your environment, more than one instance of Azure Firewall, you want to be looking at Azure Firewall Manager for centralized deployments and ease of management. We're going to talk now about web application firewalls.
These are an interesting concept because they do often get confused with traditional or next generation firewalls, but they do operate in a very different space. Web application firewalls or WAFs are designed to assist with protecting against specific security threats. That's the key focus here. So we're not necessarily allowing or denying based on rules that you set or based on maybe individualized policies around port numbers or IPs. We are looking at generalized threat actions and also specific types of attacks in an environment and trying to restrict and prevent that traffic from reaching an application in the first place. Let's jump into the simplest implementation of it and we'll go through bit by bit about how the different policy modes work and what you can do to utilize the default rule set that we build out here at Microsoft.
Web application firewalls sit in front of your application and are designed to protect against specific threats. What we are looking at is layer seven of the OSI model. So we are looking at the request that is coming through from a user or a bot or anything that is attempting to be done in your environment and analyzing from a pattern matching perspective what is being requested. We're trying to stop SQL injection attacks well before they reach the SQL server. We're stopping different application workload exploits from happening before it hits the app server. The point here is to stop it in its earliest possible moment in your environment.
Prevent those relatively common attacks from actually ever reaching the workloads they could exploit. Now we based the rule set within the application gateway on the OWASP top 10, which are the top 10 threats that we're seeing in the web more broadly. Depending on where you implement a web application firewall in Azure, you will get slightly different coverage. So it's important to know where we can actually implement it.
Since this is going in front of an application and it is specifically focused on threats primarily in layer seven of the OSI model, there are two services that are key to deploying a WAF successfully -- Azure Application Gateway and Azure Front Door. Now these two services because of where they operate, it makes sense that we are able to add that layer of protection. Application Gateway because it is working at a regional level, we get extremely detailed monitoring details about how things are passing into your environment and what exactly an attack looks like. Life on Azure Front Door instead is running at the Microsoft secure edge.
So the goal there is to stop any threats before they even reach your network environment, before they even traverse to the region you are in. Between the two of them, different policy sets are available. So I recommend looking at learn.microsoft.com for more details about the exact specifics of what you can implement and protect against with each.
Depending on your particular scenario and which ones you're already using in an environment, you may choose to have a web application firewall on one or both of them. Now web application firewalls have a couple of different policy modes and it's good to remember which one to implement at the right time. Because there is potentially some large impact in your environment because the core goal of a web application firewall is to stop threats, you may wish to run it in a detection mode initially. This will go through and it will detect an attack has occurred or a potential attack has occurred, but it's not actually going to stop it.
Think of this like an alerting mode alone. By putting your web application firewall into a prevention mode that will actively stop things that match the rules that are defined in the rule set that you have either built out or the default rule set that we provide. Now the DRS or default rule set is a really important one to know. This is a very small screenshot for a reason.
There are hundreds of different potential attacks that have already been categorized as part of this default rule set. You can see a list on the side there, common things like cross scripting attacks or local file inclusions, even SQL injection attacks at the edge. The web application firewall is incredible in terms of how it is able to perform very fast pattern matching without major impact to your business systems and also be able to actually give you this level of protection. Now, of course, if you identify a threat that is not part of the default rule set and is not part of what we are currently covering or there is a specific threat actor you are looking to protect against, all we need is some sort of identifier. Now the identifier here of block me, I think that's a little obvious. I doubt many threat actors are going to put that in, but what we're looking for here is a pattern, something that you are seeing as a commonality.
We can either add a detection component there building into other learning systems that are available within Azure as the whole, or you can put it in a prevention setup. So if something matches your particular pattern, we can stop it in its tracks. But I do want to call out one other thing. At the top, rule types actually have two categorizations. They can either be put in a rate limiting mode or a matching mode.
Rate limiting is as it sounds. And it's a useful thing if you are confident that there is a DDoS attack from a certain source or something is coming through and you just want to restrict the amount of traffic that passes through. Think about where you can use these custom rules beyond just initial hardline blocks. Maybe what you want to do is just restrict the amount of traffic that flows through if it passes a certain threshold or matches a certain type.
There's many different ways we can use a web application firewall because we're doing that deeper analysis on the packets that are passing through and the information that a user is sending as part of their request. Now, the last thing I want to call out is how you implement web application firewalls within Azure Front Door because it is a little bit different to how we do it in an app gateway. What you need to do is actually go to your Front Door profile, get that created first and have everything stood up.
At this point, you are then able to associate a Front Door profile with a WAF policy. So, it is very much a process of building out your Front Door, building out your WAF, and then linking the two together. Because it is a little bit different in terms of how it gets set up, there's a bit more planning that goes into play. But, once you've done everything right, it's all ready to go, it's just as easy to turn on and you'll have that protection at the edge across the globe.
2025-05-17 05:36
