(bright music)
We've all heard of unwanted people getting access
to our cloud computing networks, virtual machines
and other assets.
One of the critical and foundational ways to protect
against this, are network security groups on Azure.
You can use an Azure network security group
to filter network traffic to and from Azure resources
in an Azure virtual network.
Alright, let me show you what I mean.
Imagine you have a standard Azure virtual network
that contains three subnets that are all receiving traffic
from the general internet.
It is common practice to not just let anything
access the networks.
Not only do attackers frequently scan IP addresses
for openings, but who wants to expose everything
on their networks?
To protect our Azure virtual network and devices
we can use NSGs in different ways.
You can chain NSGs together in the case of VM1.
NSG 1 is attached to Subnet 1 and evaluates all traffic
from the internet to that subnet.
NSG 2 is attached to VM1
and only evaluates the traffic allowed through by NSG 1.
For VM2, there's only NSG 1
as the VM doesn't have a network security group
attached specifically.
VM3 in Subnet 2 has NSG 2 associated with it
but at the subnet doesn't have any.
And finally, VM4 is left unprotected,
ast least when it comes to NSGs.
All traffic will reach VM4.
In short, NSGs protects networks and VMs in Azure
from unwanted internet traffic,
either by being associated with a subnet,
a virtual machine or both.
So how do network security groups then protect resources?
Rules, lots of rules, rules that come for free.
Rules you have to configure,
rules to keep you warm at night.
Well, almost.
Let me give you an example of a rule.
Priority: 1000, Name: MongoDB, Port: 27017,
Protocol: any, Source: 127.0.0.1, Destination: any
and Action: allow.
Now this rule is most likely attached
to a VM that runs MongoDB.
It specifies which Port is allowed to be used, 27017
and that only IP 127.0.0.1 can access that port.
If traffic matches this rule, it is triggered
and the NSG processing stops.
Rules are made up of eight,
eight, eight, eight properties.
Name: this is whatever name you like.
Not like Paul or Susan, but more descriptive
of what you're doing with the rule, like allow RDP.
Priority: this is a number between 100 and 4,096
because, bits and bytes.
The lower the number, the more important the rule.
In other words, a rule with priority 150
is processed before a rule with priority 200.
Once a rule is triggered, the processing stops.
Source: this is an IP address,
a block of IP addresses, everything (called 'Any'),
a Service Tag such as 'storage', or 'AzureActiveDirectory'.
Source Ports: a single port or range of ports.
Destination: that's the same as the source
in terms of how you've set it up.
Destination Ports: that's also the same as the Source Ports.
And Protocol: TCP, UDP, ICMP, ESP, AH, BBQ or Any.
Cheese wheel: would be delicious, but no, there isn't one.
And Action: this is either allow or deny.
Now rules are processed one after the other,
according to priority.
And when one matches the traffic, the processing stops.
You can create as many rules as you want up to a thousand,
but it can quickly get overwhelming.
Using groupings such as Azure service tags,
blocks of IP addresses and ranges of ports
can help manage it much better.
At this point, you might wonder how Azure NSGs are different
from Azure firewalls and when you should use each.
Simply put NSGs are meant for filtering traffic
within a single virtual network,
whereas firewalls protect networks across applications,
networks and even subscriptions.
Use NSGs for VNets and individual VMs.
Use firewalls for large infrastructure applications
and projects.
Okay, let me show you how to create NSG
in the Azure portal and set up a couple of rules.
While you can set up a network security group on its own,
the most common way to do it is actually
by creating a virtual machine.
So I'm going to do that now
and just show you how that works.
So if I have the virtual machines here,
I'll add a new virtual machine,
like so,
and then that opens up the wizard
for creating virtual machines in the portal.
I've already created a resource group called Fundamentals,
'cause that's what we're looking at for NSG.
We'll give the virtual machine a name, like so
and we will just leave everything as default.
I'm not going to change anything
'cause this is not a fundamentals episode
in creating a virtual machine.
We're creating a network security group.
Disks are fine.
The networking here is that we have a new virtual network,
NSG VNet, that's fine.
We have a subnet, we have a public IP
and then we have an NIC network security group
which is where it creates a network security group
while creating a virtual machine.
Because you normally have one attached to a virtual machine.
So we'll leave it as a basic.
That's fine.
And we're going to allow SSH publicly.
I'm aware that this is not what you would do normally
but just to have some rules that we can look at.
The Management, we're going to leave the Management
as it is.
The Advanced tab is about extension user data.
That's all fine.
We're just going to go straight to Review and Create.
And then we click Create.
Make sure you download private keys if they are created
because otherwise you will never be able
to retrieve them again.
And now everything's being deployed.
So let's look at the resource group
that we just created everything inside.
And we can now see that there are a number of things
that have been created.
One of them being a network security group.
So let's have a look at that.
In here, you can see there's a number of rules
that have been created already.
So the rules are down here,
Inbound and Outbound security rules.
You can see here that the SSH access on port 22
has any Source and any Destination allow,
which means anyone can access
this particular virtual machine
with the SSH key pair that we downloaded earlier.
Now, if we wanted to add a rule,
I can go on the left here to Inbound security rules.
As an example, I can add a rule
and I can choose the source.
IP Addresses, Service Tag.
So if we wanted to, for example, have a service tag
of Azure load balancer or virtual network or Azure monitor.
Any of these can then access this particular device
that this network security group is protecting.
And you just put in your port ranges.
Your Destination, the service, as an example,
could be one of these or a custom.
So if you choose some more of these services
it will automatically set the port for you,
such as if we set FTP,
you can see the port is automatically set for that
and the protocol.
And then we have an Action allow or deny
and they give it a priority.
So 310 will be after 300, which is the SSH rule.
And we can add that.
So it is that simple to add rules.
You can also do this in PowerShell or the CLI
or arm templates, but it is a very good idea
to have a standard around these rules, how you generate them
and create them and what they protect against for you
a particular company or project.
It can get really messy, really fast
and then you don't know which rule is being triggered when.
That's network security groups for you.
There's custom rules, there are default rules
and go forth and secure.
There you have it.
Network security groups,
they keep your VNets and VMs secure and warm at night.
If you enjoy this video,
give it a thumbs up and consider subscribing
to the channel for everything cloud computing.
So with that, keep being awesome Cloud Gurus.