10 comments

Azure Quick Tip: Block or Allow ICMP using Network Security Groups

Published on Tuesday, August 18, 2015 in ,

For a while now Azure allows administrators to restrict network communications between virtual machines in Azure. Restrictions can be configured through the use of Network Security Groups (NSGs). Those can be linked to both subnets or virtual machines. Check the following link if you want some more background information: https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-nsg/

A NSG always contains some default rules. By default all outbound traffic is allowed, and inbound from other subnets (not the internet) is also allowed. Typically if you ping between VM’s on different subnets (same VNET) you’ll see that the machines respond as expected.

Now what if you want to restrict traffic between subnets but still allow ICMP? ICMP is great for troubleshooting connectivity. Set-AzureNetworkSecurityRule allows you to provide the protocol parameter. In a typical firewall scenario this value would contain TCP, UDP, ICMP, … Ping uses ICMP which is neither TCP or UDP… Azure only seem to allow TCP, UDP and * for the protocol:

image

Now how can we block all traffic but allow ICMP? Simple, by explicitly denying UDP and TCP but allowing *. In this example I included the allow rule, but it should be covered by the default rules anyhow.

001
002
003
004
005
006

#allow ping, block UDP/TCP
Get-AzureNetworkSecurityGroup -name "NSG-1" | Set-AzureNetworkSecurityRule -Name BlockTCP -Type Inbound -Priority 40000 -Action Deny -SourceAddressPrefix "*"  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol "TCP"

Get-AzureNetworkSecurityGroup -name "NSG-1" | Set-AzureNetworkSecurityRule -Name BlockUDP -Type Inbound -Priority 40001 -Action Deny -SourceAddressPrefix "*"  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol "UDP"

Get-AzureNetworkSecurityGroup -name "NSG-1" | Set-AzureNetworkSecurityRule -Name AllowPing -Type Inbound -Priority 40002 -Action Allow -SourceAddressPrefix "*"  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol "*"

If we want to work the other way round: allow UDP/TCP but block ICMP we can turn the logic around:

001
002
003
004
005
006

#block ping, allow UDP/TCP
Get-AzureNetworkSecurityGroup -name "NSG-1" | Set-AzureNetworkSecurityRule -Name AllowTCP -Type Inbound -Priority 40000 -Action Allow -SourceAddressPrefix "*"  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol "TCP"

Get-AzureNetworkSecurityGroup -name "NSG-1" | Set-AzureNetworkSecurityRule -Name AllowUDP -Type Inbound -Priority 40001 -Action Allow -SourceAddressPrefix "*"  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol "UDP"

Get-AzureNetworkSecurityGroup -name "NSG-1" | Set-AzureNetworkSecurityRule -Name BlockPing -Type Inbound -Priority 40002 -Action Deny -SourceAddressPrefix "*"  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol "*"

The source/destination information is pretty open as I use * for those, but that’s just an example here. It’s up to you to decide for which ranges to apply this. And you might probably open up some additional ports for actual traffic to be allowed. The above logic is also mentioned in the information I linked at the beginning of the article:

The current NSG rules only allow for protocols ‘TCP’ or ‘UDP’. There is not a specific tag for ‘ICMP’. However, ICMP traffic is allowed within a Virtual Network by default through the Inbound VNet rules that allow traffic from/to any port and protocol ‘*’ within the VNet.

Kudos to my colleague Nichola (http://www.vnic.be) for taking the time to verify this.

Related Posts

10 Response to Azure Quick Tip: Block or Allow ICMP using Network Security Groups

26 February, 2016 04:10

Thanks, your post pointed me in the right direction. I just had to update to the ARM commands

10 November, 2016 18:38

Thanks Thomas, we are testing this next week for a setup in Azure as we never found these information in the Microsoft Official Azure documentation or from the Support Engineers.

14 February, 2017 03:08

Your logic is incomplete. There are many IP protocols other than ICMP, TCP, and UDP. For example, GRE and IPSEC (proto's AH and ESP). Azure's SG stinks for not allowing you to set the protocol by number like any basic network ACL would allow. So what you're rule ends up allowing is ICMP and every other IP protocols, http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml.

14 February, 2017 22:46

Agreed that the NSG could definately be improved by having the protocol number in there. And agree that my explanation is incomplete. When writing this I was aware of this in my reasoning. Maybe should have written it down. I'm not sure the underlaying stack does allow for those protocols to be used though.

27 June, 2018 15:54

You might also block traffic from Azure services like the load balancer with such a rule. You need to be very careful with such global rules.
Security groups in Azure still need a lot of improvements for better fine tuned rules.

22 August, 2018 19:56

FYI

"The 40002 argument is greater than the
maximum allowed range of 4096. Supply an argument that is less than or equal to 4096 and then try the command again."

30 August, 2018 15:08

Fair point :) using the real command makes it look like you can execute but indeed priority has to be below 4096

21 February, 2019 18:34

Nice Post!!!!

Anonymous
15 August, 2019 13:37

Looks like ICMP is now an option when creating NSG rules...

15 August, 2019 19:51

Yep, that's correct! Hah, as I look to this, almost posted 4 years to to this date :)

Add Your Comment