Loop Prevention in Exchange Online Demystified

by Contributed | May 3, 2021 | Technology

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

We often get questions regarding mail forwarding in Exchange Online. As you already know, Exchange Online is a shared service. We must take care that users cannot take the service down by creating mail loops. It is sometimes a little confusing for our customers that we handle this somewhat differently than in Exchange on-premises organizations. With this blog post we will give you an overview of how we handle possible mail loop scenarios and how this affects your mail flow. If you are the kind of a person that loves digging into the details, this post is for you!

Mail loop insight in the Security & Compliance Center

You may have ended up here because you ran into a possible mail loop scenario. This blog post should help you to get a better understanding about how we handle possible mail loop scenarios, how they can occur and what to do to prevent them. I recommend checking the Fix possible mail loop insight in the Recommended for you area of the Mail flow dashboard in the Security & Compliance Center (protection.office.com) or the converged security portal (security.microsoft.com). It notifies you when a mail loop is detected in your organization.

Read on now if you want to get deeper insights about our loop prevention mechanisms.

Currently stamped and preserved X-headers

It’s important to know that there are some headers which get preserved across Exchange organizational boundaries and most of them will not be removed during transport (neither by Exchange Header Firewall nor using transport rules). These headers are:

• X-MS-Exchange-Inbox-Rules-Loop


• X-MS-Exchange-Transport-Rules-Loop


• X-MS-Gcc-Journal-Report


• X-MS-Exchange-Moderation-Loop


• X-MS-Exchange-Generated-Message-Source


• X-LD-Processed


• X-MS-Exchange-ForwardingLoop


• X-EOPAttributedMessage


• X-EOPTenantAttributedMessage

Please keep in mind that we might change these headers without notice. The purpose of this list is only to provide an overview of different headers we use to prevent loops in the service. Please do not rely on them if you construct business-critical workflows.

To get a better understanding of how loop prevention in Exchange Online works, we will have a look at most of these headers.

X-MS-Exchange-Inbox-Rules-Loop header

First things first: in the cloud, the number of times a message can be redirected, forwarded, or replied to automatically is limited to 1. On-premises Exchange servers are limited to 3 (as documented here).

We set this header for example in the following scenarios:

• User created an inbox rule which forwards the message to another recipient


• User created an inbox rule which redirects the message to another recipient

The value of this header denotes the original recipient of the mail (one which has a mailbox rule to forward to the new recipient in To: header). It looks like this:

X-MS-Exchange-Inbox-Rules-Loop: john.doe@contoso.com

If you run an extended message trace:

Start-HistoricalSearch -ReportType MessageTraceDetail -ReportTitle Inbox-Rules-Loop -MessageID “<1234567890123456789012345678901@AM0PR04MB6531.eurprd04.prod.outlook.com>” -NotifyAddress john.doe@contoso.com -StartDate 05/09/2020 -EndDate 05/10/2020

And you find something like this:

Source: MAILBOXRULE
event_id: THROTTLE
reference: XLoopHeaderCount:1/1

It means that the message got silently dropped because it has reached datacenters X-MS-Exchange-Inbox-Rules-Loop limit which is (as described above) 1.

Mostly important for Exchange Online customers who run an on-premises Exchange organization in a Hybrid configuration: we also check if current recipient mail address is already present within an X-MS-Exchange-Inbox-Rules-Loop header for incoming messages. If that is the case, then we silently drop the message as well (not yet relevant in Exchange Online because the X-MS-Exchange-Inbox-Rules-Loop limit is currently 1 which means we drop the message if any X-MS-Exchange-Inbox-Rules-Loop header exists when the message arrives, regardless of which address the header contains).

X-MS-Exchange-Transport-Rules-Loop header

We set this header in the following scenario:

Mail gets redirected or recipients are added (To, Cc, Bcc) by an Exchange transport rule (ETR)

If the value of this header exceeds its thresholds (in the cloud, the number of times a message can be redirected or forwarded automatically by using a transport rule is limited to 1 – please have a look at Scenario 2 in the Real-life examples – what is the impact on email? how this can happen), we then stop processing, drop the message, log the event, and finally send out an NDR to the original sender like this:

550 5.7.128 TRANSPORT.RULES.RejectMessage; Transport rules loop count exceeded and message rejected

Note: We do not send an NDR to the original sender for any recipient added to Bcc by an Exchange transport rule during the mail flow (we only NDR for To and Cc type recipients).

X-MS-Exchange-Moderation-Loop header

Example scenario when we set this header:

• When a message is forwarded for approval, we stamp this header into the approval message followed by arbitration mailbox SMTP address:

X-MS-Exchange-Moderation-Loop: SPO_Arbitration_fa627f00-12d2-4d68-bd5d-75cd62ead0ee@M365x777241.onmicrosoft.com

• We allow at maximum 1 header. If there are more headers in place, we are going to silently drop the approval message.

You will find the following smtp status logged when running a message trace:

550 5.2.0 Resolver.MT.ModerationLoop; Loop in approval process

X-LD-Processed header

We use this header to track transport processing on a per tenant basis:

• To track potential loops due to mail contact ExternalEmailAddress (TargetAddress) redirection


• If forwarding is configured using the Set-Mailbox -ForwardingSMTPAddress or -ForwardingAddress parameter

If an action like this was detected from our service, we stamp the header followed by the ID of the tenant and a list of strings indicating the list of work that is being tracked.

This may be:

• ExtAddr if we are doing an external redirection by using ExternalEmailAddress


• ExtFwd if we are doing external forwarding by using ForwardingSMTPAddress or ForwardingAddress

If the message is redirected or forwarded to another tenant, we add another X-LD-Processed header containing the tenants ID (we do not replace any existing X-LD-Processed header). If the message comes from an external address and is redirected to another external address, we also stamp the Resent-From header to indicate that Exchange has touched it.

We allow a maximum of 3 loops per tenant for ExternalEmailAddress (TargetAddress) or ForwardingAddress/ForwardingSmtpAddress.

If we exceed the number of forwards, we track the following smtp event (you can find the event by running a message trace). We do not send out an NDR to prevent further loops:

550 5.4.142 RESOLVER.FWD.LoopingTarget; forwarding to a looping external address

We also detect if there is a loop within the directory. You normally should not run into this kind of loop. It can occur, for example, when a mailbox has forwarding configured and ForwardingAddress refers to itself. This job is done while the message is processed. If we detect a loop here, the message will be dropped and we NDR the sender with:

550 5.4.6 RESOLVER.FWD.Loop; there is a forwarding loop configured in the directory

X-MS-Exchange-ForwardingLoop header

This header is added when forwarding happens due to ForwardingSmtpAddress or ForwardingAddress properties set on a mailbox. In the case where the mailbox also has DeliverToMailboxAndForward:$true, when recipient A forwards a message to recipient B, there will be two copies of the message. One to the original recipient A and the other to the forwarded recipient B. The value of the header in the message to the forwarded recipient B will contain <SmtpAddressOfOriginalRecipient>;<TenantGuidOfOriginalRecipient>. The header looks like this:

X-MS-Exchange-ForwardingLoop: JDoe@contoso.com;53bb1ab7-edea-4e35-8c3f-e395807764bf

The purpose of this header is to detect forwarding loops like A forwards to B and B forwards to A.  If B attempts to forward to A, the message will be dropped with the smtp response:

550 5.4.142 RESOLVER.FWD.LoopingTarget; forwarding to a looping external address

The message copy to the original recipient A will also have this header added with the value ForwardingHandled;< TenantGuidOfOriginalRecipient>. It looks like this one:

X-MS-Exchange-ForwardingLoop: ForwardingHandled;53bb1ab7-edea-4e35-8c3f-e395807764bf

The purpose of this header with ForwardingHandled value is to prevent forwarding message multiple times in scenarios like Centralized Mail Transport (aka CMT or CMC), where the message to the original recipient is routed out of the service and then back to the service. In a CMC scenario the message will be forwarded first when the message enters the service. When the message gets routed out and sent back to the service, duplicate forwarding will be prevented by looking at this header in the message. Please have a look at Scenario 5 at the end of this post to get a better understanding of the workflow in CMC scenario.

Note: Customers sometimes make use of the X-MS-Exchange-Inbox-Rules-Loop header to check if a message was forwarded to forwarding address or forwarding SMTP address of the mailbox. If you are doing so, you should now use the new X-MS-Exchange-ForwardingLoop header instead.

X-MS-Exchange-Generated-Message-Source header

This header is used to check for loops in Exchange agent-generated messages. In Exchange Online, we do this while they are in submission and smtp process. We make use of this header for example if an automatic reply via inbox rule is in place. We then stamp the following headers:

X-Auto-Response-Suppress: All
X-MS-Exchange-Inbox-Rules-Loop: john.doe@contoso.com
auto-submitted: auto-generated
X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent

Let us have a closer look at these X-headers:

• X-Auto-Response-Suppress
  
  
  
  • Specifies whether a client or server application will forego sending automated replies in response to this message. There are different values available. In case of an automatic reply, Exchange sets the value to All.
  
  
  
  


• X-MS-Exchange-Inbox-Rules-Loop
  
  
  
  • Please have a look at 1) X-MS-Exchange-Inbox-Rules-Loop
  
  
  
  


• auto-submitted
  
  
  
  • Defined in RFC 3834. Let me quote from there:
  
  
  
  

“The purpose of the Auto-Submitted header field is to indicate that the message was originated by an automatic process, or an automatic responder, rather than by a human; and to facilitate automatic filtering of messages from signal paths for which automatically generated messages and automatic responses are not desirable.”

• X-MS-Exchange-Generated-Message-Source
  
  
  
  • Short: This X-header is used to prevent mail loops caused by agent-generated messages.
  
  
  • Long: If this header is present, it means that the mail you see is an agent-generated message. We check if it does not exceed our limits. We do these checks while the message is processed in submission and smtp. There are different limits in place. If the message is an inter-tenant one (means no intra-tenant organization header exists), we limit this to 3 agents, and they may be the same (for example three times DLP Policy Agent).
  
  
  
  

You will see multiple agents for example if you have DLP in place and an inbox rule which redirects every message to another mailbox. If your DLP policy matches and you receive a mail notification that gets redirected to another mailbox, you will see something like this:

X-MS-Exchange-Generated-Message-Source: DLP Policy Agent,Mailbox Rules Agent.

If the message is an intra-tenant one, we limit this to a maximum of 2 Exchange agents. Side effect messages are, for example, intra-tenant messages. This kind of messages are generated after a message has been delivered to the mailbox. For example, a message delivered to a mailbox triggers an auto reply or inbox rule that redirects the message to another recipient. In this case, a side effect message is generated. We drop the message if the Exchange agent is the same (for example two times DLP Policy Agent). While in progress, side effect messages are stamped with the following header which is replaced after the message has been delivered.

X-MS-Exchange-Organization-Generated-Message-Source: Mailbox Rules Agent

Some more loop protection insights

We also detect incoming messages that are looping when they pass Exchange Online Protection (EOP). We count every time a message passes through EOP frontdoor and we reject every message that reaches our thresholds. Let me explain this in a little more detail.

To do this, we need some more headers. As this is EOP related work, the headers are named like this:

• X-EOPAttributedMessage


• X-EOPTenantAttributedMessage


• Some more internal loop prevention headers for routing to quarantine and ATP

We increase the X-EOPAttributedMessage header every time the message is processed by EOP frontdoor. It looks like this:

X-EOPAttributedMessage: 1

We also stamp the X-EOPTenantAttributedMessage header with tenant guid and a number which shows how often the message was processed through this tenants EOP. A valid header of a messages that passes EOP for the first time looks like this:

X-EOPTenantAttributedMessage: 543b1ab7-eeea-4a35-8c3f-e396007764bf:0

If the message is re-routed through another tenant (for example, an ETR in Tenant A automatically forwards the message to Tenant B), the X-EOPTenantAttributedMessage header is reset. Anyway, the X-EOPAttributedMessage count is kept and increased. We drop the message if it goes several times through the same tenant (X-EOPTenantAttributedMessage) or when it exceeds a threshold of several more message being routed between different tenants).

If we exceed the number of total hops (which is currently 7 but it but can be changed in the future without being separate announced), you can find the following smtp response logged:

554 5.4.14 Hop count exceeded – possible mail loop ATTR1

If we exceed the hop count within the same tenant (which is currently 3 but can be changed in the future without separate announcement), we then NDR this one out:

554 5.4.14 Hop count exceeded – possible mail loop ATTR34

If you see any of the following smtp responses logged, you then should be open a support case for further investigation. We protocol these if a threshold associated with quarantine or ATP has been reached and a message has been dropped by the service:

454 4.4.15 Hop count exceeded – possible mail loop ATTR39

454 4.4.15 Hop count exceeded – possible mail loop ATTR40

Real-life examples – what is the impact on email?

Here are some examples of how all of this may affect your mail flow:

Scenario 1:

John Doe (Contoso Ltd.) creates an inbox rule to redirect every message to Mike Meyer (TailSpin Toys). Mike in turn has another inbox rule in place to redirect every incoming message to Anna Smith (Fabrikam, Inc.).

Result:

In this case, Exchange stamps the X-MS-Exchange-Inbox-Rules-Loop: John.Doe@contoso.com header after the first redirect is processed. Exchange at TailSpin Toys detects that header (message tracking reference will log XLoopHeaderCount:1/1) and does not redirect the message again. In this case Mike Meyer will not get an NDR. As an administrator you will find this event by running a message trace.

This scenario is one of the most seen and we must be very restrictive because customers can easily build a loop here. Therefore, we restrict this to only 1 redirect/forward by using inbox rules. This limit is hardcoded and cannot be changed. If you make use of Exchange on-premises, it is possible to have up to 3 redirects by inbox rules in place. As an administrator it is your task to protect your users from building loops. 

Scenario 2:

In this scenario we make use of two transport rules. The first one, located at Contoso’s Exchange organization, redirects every message addressed to John.Doe@contoso.com and coming from outside the organization, to Mike Meyer at TailSpin Toys company:

At TailSpin Toys there is also a transport rule in place, to Bcc incoming messages to Anna Smith at Fabrikam:

Result:

In this case the message is stamped at transport within Contoso organization. We see the X-MS-Exchange-Transport-Rules-Loop: 1 header. At TailSpin Toys the message is dropped due to X-MS-Exchange-Transport-Rules-Loop: 1 header. If you run a message trace, you will find the following event logged:

550 5.7.128 TRANSPORT.RULES.RejectMessage; Transport rules loop count exceeded and message rejected

Remember: We do not send out an NDR to the original sender. This is because of the second transport rule which is configured to add an additional recipient as BCC into the message. If the second transport rule is configured to add an CC-Recipient or simply redirects the message instead of an additional recipient as BCC, an NDR will be send out to the original sender.

Scenario 3:

In this scenario we are going to have a look at the moderation loop protection. We have a transport rule (2) that forwards every message, send from outside the organization to shared@fabrikam.com, to Anna Smith for approval (3). Anna is going to holiday and so she has created an inbox rule to redirect every message to the marketing team (4). Unfortunately, the marketing distribution list is also moderated.

Result:

In this case, the moderation message is stamped with the X-MS-Exchange-Moderation-Loop header, followed by the smtp address of the arbitration mailbox:

X-MS-Exchange-Moderation-Loop: SPO_Arbitration_fa627f00-12d2-4d68-bd5d-75cd62ead0ee@M365x777241.onmicrosoft.com

The approval request which is forwarded via inbox rule from Anna’s mailbox to the marketing distribution list is dropped and no NDR is send out to the original sender. If you run a message trace, you will find the following smtp response stamped:

550 5.2.0 Resolver.MT.ModerationLoop; Loop in approval process

Scenario 4:

In this scenario we are going to have a look at the X-LD-Processed header and how it works. Assumed we have the following setup: We have two companies – TailSpin Toys and Fabrikam. Both have marketing departments working together. To make this workflow easier, they decide to create mail users for each other company department (Marketing-Fabrikam and Marketing-TailSpin). Unfortunately, someone added the mail users to the local marketing distribution list – and the loop begins.

Result:

What happens here? Someone sends a mail to one of the distribution lists. Exchange expands the list and starts processing the item. For the first time the mail gets processed, we check on transport if any X-LD-Processed header followed by tenants guid is present. If this is not the case, we stamp a header like this:

X-LD-Processed: 6249f43a-676b-4124-a13a-50205140b751,ExtAddr

We do this also for the other tenant. So one more X-LD-Processed header is added:

X-LD-Processed: 53bb1ab7-edea-4e35-8c3f-e395807764bf,ExtAddr

We keep doing this every time the message is processed and at the end (after the message was processed for the 3^rd time), the header looks like this:

X-LD-Processed: 6249f43a-676b-4124-a13a-50205140b751,ExtAddr,ExtAddr,ExtAddr

X-LD-Processed: 53bb1ab7-edea-4e35-8c3f-e395807764bf,ExtAddr,ExtAddr,ExtAddr

If the message enters transport again, it will be dropped and NDR is send out to the original sender:

554 5.4.14 Hop count exceeded – possible mail loop ATTR1 [HE1EUR04FT048.eop-eur04.prod.protection.outlook.com]

And so, the loop ends.

Scenario 5:

In this scenario we are going to have a look at the X-MS-Exchange-ForwardingLoop header and how it works. Assumed we have the following setup: Fabrikam has a Hybrid configuration and have also enabled Centralized Mail Transport (CMT; also known as CMC, RouteAllMessagesViaOnPremises enabled on the outbound connector). MX points to the Exchange Online service to make use of our malware and spam protection features. They need to route all outgoing messages through Exchange on-premises because of their mail signature and DLP solution which has not been migrated to cloud yet. Anna Smith of Fabrikam has set ForwardingSmtpAddress to John.Doe@contoso.com as well as DeliverToMailboxAndForward set to $true.

Result:

A message addressed to Anna.Smith@fabrikam.com enters the service (1). We notice that ForwardingSmtpAddress is set to John.Doe@contoso.com as well as DeliverToMailboxAndForward is set to $true. Now message bifurcation kicks in and creates another copy of the message. The message which goes to John.Doe@contoso.com gets stamped (2a) with following header:

X-MS-Exchange-ForwardingLoop: Anna.Smith@fabrikam.com;53bb1ab7-edea-4e35-8c3f-e395807764bf

And is routed through Exchange on-premises to John.Doe@contoso.com. Unfortunately, there is also ForwardingSmtpAddress set on John Doe’s mailbox which points to Anna.Smith@fabrikam.com. The message is now routed to the Exchange Online service again (3a). Here we detect that X-MS-Exchange-ForwardingLoop has already been set with that recipient and tenant guid. Result of this is that we drop the message with smtp response:

550 5.4.142 RESOLVER.FWD.LoopingTarget; forwarding to a looping external address

The original message copy to Anna Smith’s mailbox is also on its way. This message also makes an extra round through Exchange on-premises due to requirement imposed by having CMC enabled and it’s coming from Internet (i.e. not having passed through on-premises yet). Before being sent to on-premises, however, this copy was stamped with a header (2b). It looks a little different to the header mentioned before:

X-MS-Exchange-ForwardingLoop: ForwardingHandled;53bb1ab7-edea-4e35-8c3f-e395807764bf

As you can see, it contains ForwardingHandled instead of the recipient’s e-mail address. We need to do this in order to remember that Forwarding was already applied in cases when the message then has a routing requirement out of the EXO service such as Centralized Mail Transport. When on-premises sends it back to Exchange Online (3b), we now figure out that the X-MS-Exchange-ForwardingLoop header has already been stamped with ForwardingHandled flag. Result of this is that we don’t forward the message again (no RESOLVER REDIRECT event in Message Tracking Log/Message Trace Details Report). The message is finally delivered to Anna Smith’s mailbox (4b).

What if I need to do multiple forwards or redirects for handling business processes?

Glad you asked! Basically, there are 3 ways to go:

• Keep these mailboxes on-premises (which is not a real option if you want to use the awesome features available in Exchange Online). Remember: Some limits are different when using Exchange on-premises.


• Configure redirect via Set-Mailbox -ForwardingSMTPAddress or -ForwardingAddress parameter. As described above, we make use of the X-LD-Processed header in this scenario which allows up to 3 redirects per tenant.


• Make use of Microsoft Power Automate. With Power Automate you can create automated workflows between your favorite apps and services in a centralized way. This includes many email actions when using the Microsoft 365 Outlook Connector. I encourage you to check out the documentation, give it a try and see the power of this Microsoft Power Platform application.

I hope all these insights help you to get a better overview and understanding of how we handle possible loop situations in Exchange Online. It is sometimes a little confusing and may look complicated, but keeping the service running for our customers is a must.

Special thanks to all contributors: Especially to Stan Aleksiev for taking care of the technical review, Arindam Thokder, Dan Li, Guru Prasad, Arnold Kermer and Dmitry Starostin!

Lukas Sassl

Log Analytics pinned parts now works with Azure Dashboard filters

by Contributed | May 3, 2021 | Technology

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

Intro:

As we continue to improve our Log Analytics pinned parts experience to Azure Dashboards, we are happy to announce integration with dashboard filters.

Integration with Dashboard filters:

Log Analytics pinned parts are now integrated with dashboard filters – you can now add a filter to your
dashboard and it will apply to pinned Log Analytics parts:

Use the new filtering experience to achieve more with Azure dashboards.

Feedback:

We appreciate your feedback! comment on this blog post and let us know what you think of the this
feature.
You may also use our in app feedback feature to provide us with additional feedbacks:

Log Analytics UI – New experience for Custom Logs

by Contributed | May 3, 2021 | Technology

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

Intro

We continue to improve our experiences!
The Custom Logs and custom fields screens get a new, dedicated experience in your log Analytics workspace.  

The new Custom Logs Blade:

Reach your custom logs blade from the left hand navigation bar in your Log Analytics workspace:

The new experience was updated with a cleaner look and feel, for custom logs:

And custom fields:

The new experience also allows filtering of the custom logs or custom fields for easier management:

Feedback

We value your feedback, please let us know what you think by commenting on this blog post or by clicking the ‘feedback’ button right in Log Analytics:

Understanding Microsoft Azure Virtual Machine sizes

by Contributed | May 3, 2021 | Technology

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

Having an on-premises infrastructure background, I’m used to scoping hardware by defining the specifications (CPU, memory etc) we’ll need to run the applications and expected concurrent users and allowing for some growth. Then we’d often buy a box that would give us room to upgrade further, so for example we’re not putting the maximum amount of RAM in that server today. But when it comes to creating a virtual machine in Microsoft Azure, you’re now faced with unfamiliar choices – Burstable, D series, F series etc. and a mix of vCPU, RAM and temporary storage combinations. How do you know which 8 vCPU 32GB size to choose?

T-shirt sizes!

A great way to think of the different combinations of specifications is to relate it to clothing. If I’m buying a t-shirt, I can choose from small, medium, large, extra large etc. Each size has specifications for the body length, sleeve circumference, neck circumference etc. I also have to decide how I like my t-shirts to fit – do I want a tighter, slimmer fit or a baggier, relaxed fit? A small size in a slim but range will be different to a small size in a relaxed cut. And what style do I want – am I going for short sleeves, no sleeves, long sleeves, round neck, or v neck? There are a lot of decisions we make when we’re buying clothing, but these choices are familiar.

Microsoft uses the terms category, series and instance when talking about virtual machine sizes. Lets start with our VM “t-shirt” style!

Category

You’ll find the high level categories mentioned in some of the Azure VM documentation, include the pricing information. This is a great place to start to narrow down which machines would be the most suited to the workloads you want to run. Pick your style!
General purpose: Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.
Compute optimized: High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes and application servers.
Memory optimized: High memory-to-core ratio. Great for relational database servers, medium to large caches and in-memory analytics.
Storage optimized: High disk throughput and IO. Ideal for Big Data SQL, and NoSQL databases.
GPU: Specialised virtual machines targeted for heavy graphic rendering and video editing available with single or multiple GPUs.
High performance compute: Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).

Series

Next, you’ll choose your t-shirt fit, by examining the different series of virtual machines. A series is a group of virtual machine sizes based on the same host hardware configuration. For compute optimized, that’s CPU focussed. For storage optimized, that might be local SSD disks or directly mapped local NVMe storage.

In the Compute optimised category for example, lets compare two different series:
Fsv2 series: 2GB RAM and 8GB local temporary storage per vCPU, hyperthreaded and based on the Intel Xeon Platinum 8272CL (second generation Intel Xeon Scalable processors or the Intel Xeon Platinum 8168 (Skylake) processor.

F series: 2GB RAM and 16GB local temporary storage per CPU core, based on the Intel Xeon Platinum 8272CL (second generation Intel Xeon Scalable processors, Intel® Xeon® 8171M 2.1GHz (Skylake), Intel® Xeon® E5-2673 v4 2.3 GHz (Broadwell) or the Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) processor.

Instance

Now we’re down to the specific t-shirt size for your virtual machine, it’s own combination of CPU, RAM and temporary storage. Looking again at computer optimized machines, we’ll see the Fsv2 series offers vCPUs in combinations like:

While the F series offers physical CPU cores in combinations like:

Note: Temporary storage is a non-persistent disk that disappears & is recreated new if the VM is shut down, resized, moved to a different physical host or if the host is updated or upgraded. It’s the default location for the pagefile.sys for Windows and can also be used for SQL’s TempDB. You need to provision additional storage for your applications and data, which is not included in the instance sizes.

Where to find sizing information

As sizing is a consideration when estimating or creating a virtual machine, you can find a direct link to detailed sizing information from the Azure Pricing Calculator when you add a virtual machine to your estimate. After adding a virtual machine, click the i symbol then choose Pricing details:

Azure Pricing Calculator link to VM sizing information

And from the Azure portal when you create a new virtual machine, click the i symbol next to Size, then choose Learn more about Virtual Machine sizes:
Azure portal VM size information

B-series burstable virtual machines

The B-series VMs are unique in that they will build up credits when they are operating under their baseline CPU performance, but they can use more than that baseline when your application needs it, up to the maximum provided by the instance size you have selected. For example, the Standard_B2ms instance has 2 vCPUs and a baseline of 60% CPU performance of the VM. When the VM is operating at less than 60% of the CPU performance, you’ll accumulate credits. When needed, the Standard_B2ms can burst up to 200% max CPU performance. This is great for applications that have regular, short periods of high demand and long periods of low or no demand, like outside of office hours.

In the Azure Pricing Calculator, there’s a switch you can toggle to not show B-series VMs in the size selector. For more information on burstable VMs, maximum credits and how they are applied, visit B-series burstable virtual machines sizes.

Restricting certain VM sizes

Azure Policy lets you control which VM sizes are allowed to de deployed in your environment, and by omission, which sizes are not allowed. The instance sizes are referred to as SKUs (stock keeping units) and this Deny policy will stop VMs being created with or resized to any instance that is not listed in your policy. This is an effective way of putting a cost control measure in place to ensure that the more expensive sizes are not deployed without your knowledge. For more information see Azure Policy built-in definitions for Azure Virtual Machines and the json policy definition on GitHub. 

Getting your sizing right

If you are still unsure, the Azure Portal will recommend sizes related to the Image you have selected for your VM. When an operating system image is added to the gallery, the publisher can recommend a list of instance sizes that are appropriate for that image:

Azure portal showing recommended sizes for the selected image

Note: Note all instance sizes are available in all Azure regions due to capacity of the data centers and demand. As you need to choose a region first when you create a VM in the Azure portal, you’ll received a warning in red if the selected size is not available in that region. Instance sizes can also be restricted depending on your subscription type. For example, an Azure free account is limited to 750 hours of Azure B1S virtual machines for the first 12 months. Also, as per the previous section, you’ll receive an error if an administrator has prevented the creation of (and resizing to) certain instance sizes.

List your VMs and their sizes

You can use the Azure Resource Graph Explorer to return a list of all your VMs and their current sizes, with the following KQL query:

| where type =~ 'Microsoft.Compute/virtualMachines'
| project vmName = name, vmSize=tostring(properties.hardwareProfile.vmSize), vmId = id

Resizing

If you find that your virtual machine is not performing as well as you need it to, you may have undersized it. Azure Advisor will also notify you if your VM is consistently under utilised and could be down sized, saving you money. Fortunately, resizing a VM is a simple process using the Azure portal or PowerShell, but it does require your VM to be shut down and restarted. Also, if your VM is part of an availability set and the new size is not available in it’s current physical host hardware cluster, all of the VMs in that availability set need to be deallocated and moved, which may require updating the size of the other VMs too. For detailed information on resizing a virtual machine, visit Resize a Windows VM in Azure. 

Learn more:

Docs – Sizes for virtual machines in Azure (including a great video)

MS Learn – Introduction to Azure virtual machines

How to Quick Start with Defender for IoT Sensor onboarding and integration into Azure Sentinel

by Contributed | May 3, 2021 | Technology

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

Azure Defender for IoT is a unified security solution for identifying IoT/OT devices, vulnerabilities, and threats. It enables organizations to secure entire IoT/OT environments, whether there is a need to protect existing IoT/OT devices or build security into new IoT innovations.

Azure Defender for IoT offers agentless network monitoring that can be deployed on physical hardware or virtualized environment and a lightweight micro agent that supports standard IoT operating systems. OT (Operational Technology) is used to monitor Industrial equipment rather than traditional Network IT resources.

Azure Sentinel can be used to integrate with Defender for Security Orchestration, Automation, and Response (SOAR) capabilities enables automated response and prevention using built-in OT-optimized playbooks.

This Blogpost presents two topics to support enterprises and enable a quick start with IoT/OT:

• Onboard an agentless Defender for IoT sensor for PoC/Evaluation purpose.


• Integration of Defender for IoT with Azure Sentinel for unified security management across IoT/OT landscape.

Prerequisites and Requirements

This capture describes the requirements to set up the environment.

• Hardware appliance for the sensor.

The supported hardware for Defender IoT is listed here: Identify required appliances – Azure Defender for IoT | Microsoft Docs

• A network switch that supports traffic monitoring via SPAN port.


• Create or use an existing Azure IoT Hub service. IoT Hub is required to manage IoT devices and security.


• An existing Azure Sentinel deployment for unified security management experience for Defender for IoT alerts.

Install the Defender for IoT Sensor

The installation takes a while and requires several reboots during the installation.

Before you can start the installation, there is a need to download the installation software. The ISO for the installation can be found in Azure Portal > Azure Defender for IoT > Set up a sensor > Purchase an appliance and install software > Download.

For my lab environment, I decided to use a Vmware ESXI server. I created a guest VM with 4 CPU cores, 8 GB of RAM, 128 GB of hard drive, and 2 virtual network cards for the sensor. One virtual card will be later used for the management interface, and the second one for the SPAN port. I prepared the environment for my lab as follow:

For installing the sensor, I attached the downloaded ISO to the sensor guest VM to kick off the installation.

For the initial configuration, select a language.

Select SENSOR-RELEASE-version Office.

Configure the architecture and the network properties.

Use eth0 for the management network (interface) and eth1 for the input interface (SPAN port) and click “y” to accept the configuration.

After few minutes, CyberX and support credentials appear. Copy the passwords for later usage.

• Support: The administrative user for user management.


• CyberX: The equivalent of root for accessing the appliance.

Select Enter to continue.

Once the installation is finished, you can access the management console via the configured IP address during the installation.

                https://ipaddress

Onboard the agentless Sensor in Event Hub

Once the sensor is installed, now it’s time to prepare the sensor as a cloud-connected sensor. In this mode, the sensor would send the alerts to Event Hub to share them with Azure services such as Azure Sentinel.

For the next step, there a need for an activation file. The Activation files contain the instructions for the management mode of the sensor.

To get the activation file, perform the following steps.

From the Azure Portal, navigate to Defender for IoT > Start discovering your network / Onboard sensor.

Define a name for the sensor, choose the subscription, select On the cloud, select an IoT Hub or create one, use a Display name and click to Register.

Now the Activation file is generated and can be downloaded for the next step. Download the file and save it for the next step to activate the sensor in cloud-connected mode.

Activate the agentless Sensor

The following steps are required to activate the sensor and to perform the initial setup.

Log on to the management console from your browser and the CyberX credential, which was pre-defined, including password during the installation.

After sign in from the Activation page, upload the Activation File, which was saved in preview steps, approve the Terms and Conditions and click Activate.

After activation, I would recommend some best practices to follow:

• Create a new Admin account for management and only use the CyberX and support account if there is a need for it.


• Change the sensor’s name and, if required, the network settings in the network configuration settings.

Validate the Sensor

After logging in to the management console, the sensor can be validated.

I see the SPAN input is functional, and data is streamed from the mirror port.

The sensor also discovered the asset as well as built a network map based on the discovery.

Integrate with Azure Sentinel

As the sensor is operated in a cloud-connected mode, the integration into Azure Sentinel is a one-click experience.

To enable the data connector in Azure Sentinel, open the Azure Portal and navigate to Azure Sentinel > Data connectors and search for the Azure Defender for IoT connector, then click to Open connector page.

And click to connect your Subscription to stream IoT Hub alerts into Azure Sentinel.

In the Next Steps selection, you can enable the Create incidents based on Azure Security Center for IoT alerts analytics rule to create incidents that Azure Sentinel can manage.

Additionally, use the Azure Defender for IoT Alerts workbook to gain insights into your IoT data workloads from Azure IoT Hub managed deployments, monitor alerts across all your IoT Hub deployments, and detect devices at risk act upon potential threats.

With the enabled data connector, you can manage the Defender for IoT incidents in Azure Sentinel. Please check the SecurtityAlert table for all the alert data from Defender for IoT. 

SecurityAlert | where ProductName == “Azure Security Center for IoT”

| sort by TimeGenerated

Or from the Azure Sentinel Incident dashboard.

Summary

In this blog post, I covered the deployment of an agentless Defender for IoT sensors and the integration with Azure Sentinel to manage the security incidents.

Stay tuned for other IoT-related content in this channel.

Additional Resources

Azure Defender for IoT Landing Page

https://azure.microsoft.com/en-us/services/azure-defender-for-iot/

Agentless IoT/OT Security with Azure Defender for IoT

https://www.youtube.com/watch?v=8spIfxewaeM&feature=youtu.be

Thank you for

Additionally, many thanks to Paul Roberts and Clive Watson for brainstorming and ideas for the content.