Express route
is a great way to get some private routing into your Azure space. Larger organizations may implement the peering themselves with a Cloud Exchange provider like Equinix. Smaller organizations may utilize a middle man who handles the peering on behalf of them. A good example is adding a Cloud Exchange to an existing MPLS network. The Cloud Exchange becomes just another possible node on the network and the customer only needs to point appropriate routes in the direction of the MPLS. The latter is what this quick write up is concerning.
Service Tags
Azure implemented Service Tags a while back. It’s great for quickly defining firewall rules with objects rather than specific networks/addresses.
“VirtualNetwork” For example automatically consist of all subnets within a Vnet. So it’s pretty normal to build NSG’s with Permit VirtualNetwork rules, so much so that it’s a default and non-removable rule on all NSG’s (but can be preceded with over-riding rules).
The Issue…
These two things together, when a 3rd party is handling the peering is an issue. Express Route receives it’s routing from it’s BGP peering. The 3rd party provider chooses (at the customer’s discretion) what to advertise, in effect giving Azure routing to on-prem networks. The problem with this is that all networks received by the Express Route become absorbed into the VirtualNetwork Service Tag.
This means that if Azure network security is built using the VirtualNetwork Service Tag and Express Route peering is handled by 3rd party, It’s possible for an actor within the 3rd party to advertise a new route to Azure and in the same action, permit the traffic from that new route to any Virtual Machines allowing traffic from the tag, VirtualNetwork.
There’s only one way to fix this, build firewall rules the hard way by defining the source/destination addresses explicitly and forgo the use of the VirtualNetwork Service Tag.
Pulling the route list from the express route peering is one way to identify what’s being advertised, but I recommend using a slightly obfuscated tool to get an idea of where routes are actually coming from. Navigate to VM within the Vnet in question and head to Diagnose and solve problems > I can’t connect to my Linux VM > and look for the effective routes hyperlink.
Everything here labeled with a Source of Virtual network gateway is considered part of Service Tag VirtualNetwork. This is the only way I’ve found to identify what VirtualNetwork really consist of. If you know a better way, please please let me know.
Azure does have Route Filters, however that’s only for Azure services. There is no way to explicitly state what routes we would like the Express Route to accept. This has to be addressed at the NSG level if security is really a priority.