7 posts tagged with "security"

Azure DDoS Protection has always used machine learning to auto-tune detection thresholds per protected resource. That adaptive approach works well for most workloads — but it can be a poor fit if your traffic has known, predictable patterns that don't match what the model expects. The new custom policy feature, now in public preview, lets you override the automatic thresholds with your own fixed values for specific protocols.

Think of it like this: adaptive tuning is the thermostat that learns your home's routine and adjusts itself. A custom policy is the moment you decide the thermostat is wrong and set the temperature yourself. For most people the thermostat is fine. For the person who hosts a gaming event every Saturday night, knowing exactly what "normal" looks like makes a manual override worth it.

The feature works at the protocol level — TCP, UDP, and TCP SYN — and applies to inbound traffic on Standard Load Balancer frontend IPs. Protocols you don't tune continue using adaptive mitigation, so you only take over what you specifically need to control.

Azure WAF has long had exclusion lists — a way to tell the firewall to skip inspecting a specific part of a request, like a header or a cookie. Exceptions are different. They let you skip entire rules, rule groups, or managed rulesets for specific requests, based on attributes like the request URI, the caller's IP address, or a specific header value.

Both Azure Application Gateway and Azure Front Door now support this in public preview.

Think of it this way: an exclusion says "ignore this cookie when running all rules", but an exception says "don't run the SQL injection rule group at all when the request comes from 10.0.0.1". That's a meaningful difference in how precisely you can tune the WAF without weakening protection broadly.

Microsoft has made Network Security Perimeter (NSP) support for Azure Event Hubs generally available. If you've been waiting to use this in production, the wait is over.

NSP lets you draw a logical security boundary around your PaaS resources. Instead of managing individual service firewalls for every resource, you define access rules at the perimeter level and let Azure handle the rest. Event Hubs now joins the growing list of services that support it.

This matters because Event Hubs is often the front door for high-volume data pipelines — telemetry, logs, Kafka topics, IoT streams. Securing that front door without a tangle of per-namespace firewall rules is a real improvement.

Microsoft is retiring the Azure VPN Client for Linux (Preview) on 31 August 2026. If you still rely on the microsoft-azurevpnclient package for point-to-site access into Azure, you've now got a clear deadline to move.

The important detail is what isn't changing. Your VPN Gateway or Virtual WAN gateway isn't being retired, and neither are the Windows or macOS Azure VPN clients. This is only about the Linux preview client.

If you've got Linux users connecting with Microsoft Entra ID, this matters more than it first appears. The supported Linux replacements don't offer that same Entra ID path, so this isn't just a package swap. For some teams it's a small tidy-up. For others it's a design change.

Microsoft has made managed virtual network support for evaluations in Microsoft Foundry generally available. You can now keep evaluation workloads inside a Microsoft-managed private network boundary without having to build and run your own virtual network just to get started.

If you work in a regulated environment, or you simply want tighter control of outbound traffic, this is a useful step. It gives you a cleaner path to private connectivity for evaluation runs, while still letting you use Foundry's hosted evaluation features.

The nice part is that Microsoft handles most of the plumbing. You still choose the isolation mode and approve access to the services you need, but you don't have to manage the underlying network estate yourself.

Microsoft has raised the default Azure Virtual Network limits for both Network Security Groups (NSGs) and route tables. This is now generally available, so you get the new limits without opening a support request.

For teams running large hub-and-spoke estates, or anyone segmenting traffic with lots of explicit routes and rules, this removes a common scaling pain. You can keep cleaner designs with fewer workarounds.

The new defaults are 2,000 rules per NSG, up to 6,000 addresses or ports in an NSG rule, 1,000 routes per route table, and 600 route tables per subscription by default.

Microsoft has put summarized advertised gateway prefixes into public preview for Azure hybrid gateways. In plain terms, you can now tell Azure to advertise a smaller, cleaner set of CIDRs to on-prem instead of every hub and spoke prefix.

This matters when your hub-and-spoke estate gets large and your route table starts to look like a junk drawer. Fewer advertised prefixes can reduce operational noise and help you stay under ExpressRoute advertised prefix limits.

The update applies to Azure VPN Gateway and ExpressRoute Gateway scenarios where route advertisement scale and control are both pain points.