Ten Azure networking tips that may simplify your life

by Contributed | Aug 6, 2022 | Technology

This article is contributed. See the original author and article here.

Hi,

Azure networking can sometimes give headaches. Here are a few tips which may make your life easier.

1. Private link effect – episode 1 – route tables

When enabling Azure Private Link for a given resource, say a Storage Account, you may end up with the following configuration

where you have routed all traffic to Azure Firewall (or an NVA) and noticed that the VM (or anything else) is directly connecting to the private endpoint, bypassing the firewall…This might come as a surprise to you but this is due to the fact that whenever you enable private link for a given resource, a direct (more specific) route is propagated to the underlying NICs. In the above example, Azure will write the 10.1.5.4/32 route to the NIC(s) of the VM pointing directly to the InterfaceEndpoint of the resource. Because this route is more specific than 0.0.0.0/0, the firewall will be bypassed. To overcome this, you have to write a /32 route to the subnet’s route table to overwrite the one written by Azure, which can be itself challenging because of the 400 routes limit per route table. Microsoft wrote a good guidance on that topic.

2. Private link effect – episode 2 – route tables

Ok, now you think you understood private link routing, right? So what about this?

You thought Azure was pushing a route to underlying NICs but you realize that the VM in VNET 3 does not have such a route…Why is that? Well, it makes sense but you do not especially think about it. The reason why VNET 3’s VM does not get the route is because VNET 3 is not peered with VNET 1. Because peering is non-transitive, writing such a route would anyway lead to a dead-end. So, if you had a 0.0.0.0/0 UDR on VNET 3’s subnet, this would this time be correctly routed to the firewall…So as you guessed it, if you put a private endpoint in an intermediate VNET:

this time, the /32 route is propagated to all peered VNETs. Long story short, putting private endpoints into the hub, would propagate into every spoke, and thus, you’d better follow the guidance if you want to route that to the firewall.

3. Private link effect episode 3 – Network Security Groups

Ok great, that’s for routing but fortunately, we don’t have to worry about NSGs. Well…

How come VM2 is able to connect to my private endpoint??? My deny all rule should have kicked in..What’s going on here? Well, for the same reason as before, the InterfaceEndpoint is non-sensitive to NSGs. So, you must make sure to route things correctly to make sure, the InterfaceEndpoint is not used.

4. Private link effect episode 4 – forget the first 3 episodes?

Well, I’m sorry for you if you read the first 3 episodes because all of that is *almost* part of the past…but you will surely still likely see this for quite a while. Microsoft has revamped the way private link works, and there is a preview (UDR) and preview (NSG) available (not in all regions), which allows you to deal with private link traffic, like with any other type of traffic, but meanwhile, you’d better still understand how it currently works :).

5. Private link and outbound traffic

Repeat after me:

 – Private link is inbound traffic only

 – Private link is inbound traffic only

 – Private…(well you got it, right?)

I still see a huge confusion with many folks about private link, where people think that enabling private link for an app service, APIM, etc. will give them access to the resources sitting in a given VNET. That is wrong, to gain access to such resources, you have to focus on outbound traffic, not inbound!

6. Private link and public traffic

Remember one rule of thumb: private link does not automatically deny public traffic for all services. It does for some but not for all. So, remember to always double-check that public traffic is indeed correctly denied.

7. The propagate gateway routes effect

Whenever you establish private connectivity between your datacenter and Azure, you will use the hub vnet to bridge both worlds. You’re likely going to have (not mandatory) a VPN Gateway to establish a S2S and/or Expressroute connection. From there on, each spoke VNET should be able to connect to your on-premises systems and vice-versa. You, of course, want to make sure, traffic is routed through your firewall. If you encounter a different behavior (traffic directly flying from on-prem to spoke and vice versa), you’re likely forgot to deactivate the “propagate gateway routes” property of the route table.

So, make sure to turn it off :).

8. The Kubenet effect of NSGs

Many companies struggle to decide whether they want to implement Azure CNI (now BYO CNI is available) or Kubenet for their AKS clusters. The main reason is the shortage of IP addresses. Kubenet is IP-friendly because it only allocates IPs to nodes, while CNI allocates one IP per pod, which results in many more consumed IPs. You can use Kubenet if you’re willing to fully embrace a programmable network approach such as the use of Service Meshes and internet Network Policies (Calico for ex. which also works with Kubenet).  However, if you plan to rely on Azure networking capabilities, such as using NSGs and the likes, then you’d better switch to CNI. Consider the following scenario:

where you want to share the same cluster for multiple tenants but you want to isolate tenants in their own node pool. So, in the above scenario, you only want system to be able to connect to tenants but tenant 1 and tenant 2 cannot talk together. You do not trust logical isolation (K8s network policies & service meshes) and want to rule this with Network Security Groups instead, or even combine both. Easy, you simply add the following inbound rules to tenant 1 & tenant 2’s NSGs:

– Priority: 100 – source IP: 10.0.0.0/28 destination: * – ALLOW (let’s skip the ports for sake of simplicity)

– Priority: 110 – source IP: * destination: * – DENY 

So, that way, this should fly…Well, it appears that this won’t fly at all. Why is that? Because Kubenet makes use of network address translation (NAT) to allocate POD CIDRs dynamically, and what the NSGs see are not the subnet ranges but the POD CIDRs…, which can change at any time. Indeed, Azure constantly rewrites the route table associated to the subnets to map POD CIDRs with nodes, whenever the cluster restarts or whenever a node gets added/removed to/from a node pool. Therefore, you can’t predict how this allocation will be done, which defeats the use of NSGs to rule internal traffic. Of course, you could still use them to rule what comes from outside. 

9. Localhost in APIM policies

Did you know that you can use the keyword localhost in APIM policies? If you have a set of APIs and want APIM to let them call each other while never leaving the boundaries of APIM itself (not resolve again the IP through the DNS), you can use localhost…

10. The troubleshooting tool

Whenever you encounter a network issue in Azure, I recommend you to use Network Watcher and more specifically, its next hop feature. It helped me already a few times figure out what was misconfigured.

MTC Weekly Roundup – August 5

by Contributed | Aug 5, 2022 | Technology

This article is contributed. See the original author and article here.

Hello hello, MTC! The first week of August is in the books, so let’s see what went down in the Community.

MTC Moments of the Week

We had a great AMA in the Community this week that focused on Azure Deployments, featuring @Mark Gray, @adotfrank, @stephanieyen, and @stevenjma with @Eric Starker moderating. As a quick reminder, an AMA is a live text-based online event similar to a “YamJam” on Yammer or an “Ask Me Anything” on Reddit, and there is no audio or video component at this time.

Over on the blogs, @lucyhitz announced the general availability of Microsoft Viva Goals, “a goal-setting and management solution that aligns teams to your organization’s strategic priorities, driving results and a thriving business.” Head over to the post to watch an overview and learn more!

 We also want to give a shoutout this week to @ScottLamond, a new MTC’er, for providing several helpful responses in the Excel Community! Welcome and keep being awesome! :)

Unanswered Questions – Can you help them out?

Every week, users come to the MTC seeking guidance or technical support for their Microsoft solutions, and we want to help highlight a few of these each week in the hopes of getting these questions answered by our amazing community!

@Jenny_Bruce is seeking advice from the Community about compliance policies and document version history limits in SharePoint Online.

Meanwhile, @JohnHogan20224k is encountering an error in the Microsoft 365 admin center having to do with Teams for Organization, so maybe you can help figure out what’s causing it.

Next Week – Mark your calendars!

Lastly, we have no events next week, but check back soon for updates!

Have a great weekend, everyone!

Share data with Microsoft Purview for Azure storage with private endpoints or VNET restrictions

by Contributed | Aug 5, 2022 | Technology

This article is contributed. See the original author and article here.

This is a follow-up post on a recently published article on sharing data in near real-time with Microsoft Purview in-place data sharing for Azure Storage. I highly encourage you to read Share data near real-time with Microsoft Purview in-place data sharing for Azure Storage first before you pore over this article on how to share Azure storage solutions such as Azure Blob Storage and Azure Data Lake Gen2 with VNET traffic restrictions or even with no public endpoints i.e. private endpoints only.

Now, using Microsoft Purview in place data share you can also create shares that can connect to Azure storage PaaS such as blob storage and data lake storage with VNET restrictions and to further up the ante – even with storage accounts with no public endpoints.

This is a critical feature that has been made available only in Microsoft Purview data share and is not part of the standalone Azure data share services.

In this article, I will present a few quick pointers and considerations that you have to know before you get started with Purview data sharing using restricted Azure storage accounts.

Premise – Share data with Microsoft Purview for Azure storage with private endpoints or VNET restrictions.

Solution – In a nutshell, with Purview private endpoints i.e. account, ingestion, and portal (being optional) you can deliver new data shares while connecting to storage accounts with VNET restrictions and/or no public endpoint i.e. private endpoints only. This assumes that the private endpoint for the storage account and purview are created in the same VNET or, this is created in a networking landing zone in case you follow the learnings of the enterprise scale landing zone. 

Here’s a quick overview of key steps which will help you set up a data share with restricted storage accounts – 

Step 1 – Create purview private endpoints i.e. account, ingestion, and portal (being optional). This is required for private connectivity between Purview and target storage accounts. This is a required step regardless of how the storage account is configured i.e. with VNET restrictions or with no public endpoint.

You can create the private endpoints in the same VNET i.e. of storage account or in a dedicated VNET which may be part of your networking scaffold in the enterprise scale landing zone. Make sure the different networks i.e. Purview VNET and storage account VNET is peered if you were to follow this topology. 

You can also learn more about this configuration here – Connect to your Microsoft Purview to data sources privately and securely

Here’s a quick overview of a typical Purview deployment with private endpoints enabled.

Purview firewall settingsPurview account and portal private endpointsPurview ingestion private endpoint

Step 2 – Depending on the storage account networking configuration, let’s break this section into 2 sub parts – 

#1 Deliver data share from a storage account with VNET restrictions

Selected VNET’s only

This setup assumes that you have storage accounts with VNET restrictions and in-bound traffic from only selected VNET’s are permitted. In this case, you can create Purview endpoints in the same VNET as of storage account or in a separate VNET as long as both are peered. 

You can read more about this configuration here – Configure Azure Storage firewalls and virtual networks

#2 Deliver data share from a storage account with private endpoints only

No public endpoint

This setup assumes that you have storage accounts with no public endpoints and the only way an application can communicate is via private endpoints only. In this case, you will have to create private endpoints for the storage account in a VNET which is accessible by Purview via ingestion private endpoints. So, this can be done in the same VNET as Purview ingestion private endpoints or in a VNET that is accessible and peered to Purview private endpoints in case of enterprise scale landing zone.

If you create a private endpoint for the Data Lake Storage Gen2 storage resource, then you should also create one for the Blob storage resource. That’s because operations that target the Data Lake Storage Gen2 endpoint might be redirected to the Blob endpoint. By creating a private endpoint for both resources, you ensure that operations can complete successfully.

You can read more about this configuration here – Use private endpoints – Azure Storage

Step 3 (optional) – I always recommend running nslookup for querying the Domain Name System (DNS) records to obtain the mapping between domain name and IP address. The expectation here is that the name resolution for the storage account and Purview endpoints should return their respective private IP addresses.

If you have followed these steps, with appropriate permissions on the storage account via RBAC’s you can then deliver new data shares with your consumer groups with restricted storage accounts which earlier was not possible using Azure data share.

My objective for this post was to introduce you to how you can connect and deliver share with storage accounts that have network restrictions such as VNET restrictions and private endpoints only. Hence, I would not talk about the user journey or customer experience regarding how to create and manage a share. I encourage you to read our post on this subject at How to share data – Microsoft Purview.

Introducing the Azure Threat Research Matrix

by Contributed | Aug 3, 2022 | Technology

This article is contributed. See the original author and article here.

When performing an offensive security assessment, it’s common to find the assessment team attribute their actions to the MITRE ATT&CK knowledge base so that high-level stakeholders can visually see what techniques were successful and administrators & defenders can understand the techniques that were performed in order to remediate or defend against them in the future. However, the commonly utilized MITRE knowledge base lacks formal documentation of Azure or AzureAD-related tactics, techniques, or procedures (TTPs) that assessment teams can attribute to. Over the past year, Microsoft has worked with some of the top Azure security researchers to create the Azure Threat Research Matrix (ATRM), a matrix that provides details around the tactics & techniques a potential adversary may use to compromise an Azure Resource or Azure Active Directory.

The Azure Threat Research Matrix (ATRM), is a knowledge base built to document known TTPs within Azure and Azure AD. The goal of the ATRM is twofold:

1. To give security professionals an easily viewable framework to better visualize TTPs within Azure & Azure AD.


2. To educate professionals about the potential configuration risks that accompany Azure & Azure AD when not following best practices.

Scope & Intent

The ATRM is primarily focused on AzureAD and Azure Resource TTPs. Due to the nature of AzureAD being used by other products, such as M365, occasionally it is necessary to include techniques or technique details that also pertain to other products. An example is AZT303 – Managed Device Scripting, which documents abusing InTune, which is integrated with AzureAD, to execute scripts on devices. Additionally, there are some AzureAD techniques (specifically around hybrid-joined devices) that are not included due to that technique already being present in MITRE ATT&CK. The intent of the ATRM is not to replace MITRE ATT&CK, but to rather be an alternative for pure Azure Resource & AzureAD TTPs. However, we would like feedback on this decision from the community!

The additional purpose of the ATRM is to educate readers on the potential of Azure-based tactics, techniques, and procedures (TTPs). Commands that relate to a technique are added with the intention of defenders building alerts on those commands. While the commands are also listed to show how to abuse a given technique, certain parts are omitted or obfuscated to prevent malicious abuse.  

Walkthrough of the ATRM Structure

In order for security professionals to find ATRM helpful in understanding potential risks, it is important to first understand the layout and content within the matrix.

The top row designates the tactic, each sequentially having an ID starting with Reconnaissance at “AZT1”.

Figure 1: The top line represents the tactics and the columns represent the techniques that pertain to the tactic.

When clicking on a specific tactic, it will bring you to a list of techniques and sub-techniques associated with that tactic, with a short description.

Figure 2: Part of the page for the ‘Execution’ tactic.

Clicking on the specific ID associated with the technique will bring you to the page on that technique or sub-technique.

 Figure 3: The page for a sub-technique, AZT301.6 – Virtual Machine Scripting: Vmss Run Command.

The technique/sub-technique specific pages have several key topics of information.

• Resource: The resource(s) that the technique effects


• Actions: What resource provider operation actions are required to utilize the technique


• Examples of commands to utilize the technique, including using the portal


• Any potential detections


• Additional Resources

The Azure Threat Research Matrix is meant to be product-agnostic, meaning specific detection queries are for technologies within Azure by default and not an additional, paid solution.

Community Collaboration

Over the past several months, we’ve collaborated with some of the top researchers in the Azure security community to put together the TTPs within the matrix as it is released today. Their contributions have been extremely helpful and are on the list of acknowledgments here. One of the intended goals of the ATRM is to be as comprehensive as possible. With the hundreds of services and offerings within Azure, it’s difficult for one person to know every potential TTP within Azure and Azure AD. While internally at Microsoft we have dedicated research teams whose jobs are to research the potential abuse scenarios within Azure & Azure AD, we recognize that the community also has a large contribution to the security of our products. With this in mind, we openly invite feedback on the ATRM, from new techniques to additional data added, we would love to hear the greater security community’s input. The Azure Threat Research Matrix is being released under the MIT license and hosted on GitHub, which will openly welcome pull requests and issues.