Secure your Azure IaaS environment
In this entry I will show you how to create a secure IaaS environment. We will achieve this by filtering IP addresses using network security groups. Meaning that only certain IPs or address ranges will be allow to connect to the virtual machines using for example RDP or SSH or even Http(s).
Note: As already mentioned this method of securing your IaaS environment will filter IPs. Therefore you or your company needs to have at least one static IPv4 address if not a range.
So let’s have a look at the architecture and lay some basics:
I strongly recommend using a load balancer in front of your virtual machines regardless if the servers are internal reachable only or public reachable. The Azure load balancer can be either internal or public and support any application protocols other than for example Application Gateways (http/s only). Also is this load balancer is operating on Transport level (Layer 4) which is important for the setup, because the LB doesn’t change the source IP address while load balancing.
Network Security Group (NSG)
Network security groups can be seen as firewalls that are either bound to the subnet and/or a network card (nic). This allows to control the network traffic flow to the machines at a granular level. For most administrators or engineers it’s very uncommon to see that you can’t bound a NSG to a public IP address or a load balancer. While this is possible in AWS using security groups it is a little bit different to understand how Azure works.
Putting it together
In Azure everybody can browse the PaaS-based load balancer and the load balancer will send the traffic to the subnet respectively the virtual machine. The NSG behind the load balancer can either accept the requests or not using security rules since the source IP address does not change!
If we have a look at the created inbound security rule the following is visible:
The rule with the priority 100 means, that we only allow a certain public IP address to browse the subnet and only port 80 is allowed.
You might notice that there is a button called “default rules” next to the “Add” button this is very imported to see, because here you can see the default rules that are already in place and act:
Here you can see that there is already a “DenyAllInBound” rule. Before this rule acts there are is a rule allowing all Vnet traffic and another which allows all traffic from the load balancer.
This means as already mentioned only the possibility for the load balancer to contact the network security group and forward the request. This request will be then declined if the client has a different IP address as the one we defined in the first rule. The last rule is responsible for this behavior.
Hope I could help you guys and try to build secure IaaS environments by using network security groups.
Until next time,
- Erstellt am .