deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 05:17:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Intitial porting from spec docs

Browse Source
This commit is contained in:
Paolo Matarazzo 2024-01-12 12:06:31 -05:00
parent 01bcf42c66
commit 82014fdecb
5 changed files with 508 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
windows/security/identity-protection/key-protection-with-vbs/how-it-works.md Normal file
View File

@ -0,0 +1,103 @@
---
title: How Key protection with VBS works
description: Learn how Key protection with VBS works ...
ms.date: 01/11/2024
ms.topic: overview
appliesto:
- "✅ <a href=\"https://learn.microsoft.com/windows-insider/\" target=\"_blank\">Windows Insider Preview builds</a>"
---
# How Key protection with VBS works
[!INCLUDE [insider-note](../../includes/insider-note.md)]
## Problem Statement
In today's landscape, with the growing number and complexity of OS and admin-level security threats, a secure key isolation solution on Windows is critical. Traditionally, Windows leverages LSA Memory to store keys - while this is more secure than storing keys in process memory as is done on Linux, it does not prevent admin-level attacks. Increasingly, cyber attackers exploit vulnerabilities in identity services to gain access to critical assets. Key exfiltration, when sensitive data is extracted off the network and continually used to authenticate resources from outside, is a major threat that can result in a range of consequences, from the exportation of high value secrets off the network, to rogue control of guest and Azure VMs, to major service outages. Therefore, protecting cryptographic keys is essential to the availability and security of all Azure first-party as well as third-party services.
Traditionally, Windows leverages software isolation with LSA Memory to store keys, which does not prevent admin-level attacks. Another option is hardware-based isolation, where keys are stored directly on a TPM, but this is less ideal for high-volume signing and encryption scenarios.
## Solution Design
KeyGuard is a Windows key isolation solution that provides a strong security guarantee against rogue admin and key exfiltration attacks. KeyGuard leverages VBS to store keys in VSM (Virtual Secure Mode), an isolated boundary within the OS backed by an on-device TPM (Trusted Platform Module). The following sections explain this in further detail.
### Key Isolation through Virtualization Based Security (VBS)
KeyGuard isolates private key material with Virtualization Based Security (VBS). VBS uses the virtualization extension capability of the CPU to enable a security boundary between two different Virtual Trust Levels (VTLs):
- The first virtual trust level, **VTL0**, consists of normal user mode and kernel mode. This is where the client process is running. In the case of KeyGuard, *LsaSs.exe*, the normal mode secure process, runs here.
- The second and more privileged virtual trust level, **VTL1**, consists of an Isolated User Mode as well as the Secure Kernel (SK), which manages the operations of VTL1. In the case of KeyGuard, VTL1 is where the secure process, *LsaIso.exe* runs in a VBS trustlet. This is an isolated process that is separate from other applications running on the same machine.
The security boundary between VTL1 and VTL0 makes up what is known as [Virtual Secure Mode](https://learn.microsoft.com/virtualization/hyper-v-on-windows/tlfs/vsm) on Windows. Such separation ensures that malicious host kernel, user mode, and host admin level malware penetrates VTL0, it cannot access secrets in VTL1. Altogether, this design enables the isolation of secure regions of memory for private key material and significant containment malware and exploits.
### Data Encryption with a TPM
KeyGuard leverages a master key from the [Trusted Platform Module (TPM)](https://learn.microsoft.com/windows/security/hardware-security/tpm/trusted-platform-module-top-node) on the machine to encrypt its data, binding the contents of KeyGuard to the device.
A TPM chip is a secure crypto-processor that helps with actions such as generating, storing, and limiting the use of cryptographic keys, and to confirm that the operating system and firmware on your device are what they're supposed to be and have not been tampered with.
TPM version 2.0 is the current standard and a requirement for KeyGuard on bare-metal machines. vTPM is supported in VM environments.
> [!IMPORTANT]
> KeyGuard is not as secure as a sole TPM-based solution, since operations are not hardware isolated and VBS creates a larger attack surface than TPM. In fact, KeyGuard is only as secure as the TPM that its master key is provisioned from. Therefore, if TPM reliability or security is degraded, it will pass on to KeyGuard.
>
> This is still a significant improvement compared to the security posture/attack surface in standard OS.
## Security Properties
This section outlines some of KeyGuard's security promises and non-promises.
### Security Promises
- KeyGuard protects keys from **key exfiltration** and guarantees the non-exportability of keys in plain-text from a single machine. Admin and kernel level malware penetrating VTL0 cannot access keys in VTL1 because of the security boundary created through Virtual Secure Mode. This encompasses scenarios where attackers extract private keys and send it to the attacker machine and mount the attack from there.
- KeyGuard is compatible with attestation, meaning a service like Managed HSM can verify the integrity of the KeyGuard enclave and release keys encrypted to that enclave, so no clear-text copies of the keys ever exist outside of KeyGuard and the HSM.
- KeyGuard is also compatible with MAA (Microsoft Azure Attestation) as a back-end service to ensure a key is in KeyGuard.
### Non-Promises
- Even though KeyGuard protects against exfiltration attacks, an adversary with access to VTL0 will still be able to use Key Guard keys for any operation such as signing and decryption. This is referred to as "oracle-access" and is the same promise as other hardware based key isolation environments.
- KeyGuard's security is dependent on the TPM that its master key is provisioned from, and any degradation of TPM security and reliability will pass onto KeyGuard.
## Diagram
The following diagram details KeyGuard architecture.
:::image type="content" source="images/architecture.png" alt-text="Diagram of the Key guard architecture." lightbox="images/architecture.png" border="false":::
| Diagram Component | Description |
|-|-|
|VTL0: *Normal-mode* | The memory space where NTOS, drivers and regular processes run|
|VTL1: *Secure-mode*| The memory space where the Secure Kernel and isolated user mode processes run|
| *Client.exe* | Sample client process, runs in VTL0<br>- *NCrypt.dll*: Linked by Client.exe<br>- *NCryptProv.dll*: Loaded at run time by NCrypt.dll. Forwards calls to LsaSs.exe|
|*LsaSs.exe*|System process where our VTL0 Key Guard component runs<br>- *NCrypt.dll*: Linked by LsaSs.exe<br>- *NCryptProv.dll*: Loaded at run time by NCrypt.dll<br>- *BCryptIso.lib*: VTL0 client interface to Key Guard, linked by NCryptProv.dll. Forwards calls to LsaIso.exe|
|*LsaIso.exe*| Secure process where our VTL1 Key Guard component runs<br>-*BCryptIum.lib*: VTL1 server part of Key Guard, linked by LsaIso|
|Hypervisor| Hyper-V or Windows Hypervisor, establishes the security boundary between VTL0 and VTL1 by introducing a Second Layer Address Translation (SLAT)|
|TPM|Trusted platform module, encrypts key material at rest|
## Terminology and Concepts
This page provides short descriptions of terms you may encounter while learning about or using KeyGuard. It does not provide detailed documentation about the features. Use the provided links to learn more.
| Term | Definition |
|-----------|-----------|
| **Attestation** | A process used to verify the integrity of a system, component, or key, such as the KeyGuard enclave. |
| ***BCryptIso*** | normal-mode client library that interfaces with the trustlet via RPC |
| ***BCryptIum*** | secure-mode Key Guard library that runs in VTL1 |
| **CNG (Cryptography API: Next Generation)** | The public pluggable cryptographic library supported on Windows. CNG is designed to be extensible at many levels and is cryptography-agnostic in behavior |
| **Enclave** | Code that is running in an isolated/secure space |
| **IUM (Isolated User Mode)** | security feature to protect against kernel driver exploits, provides an execution environment for trustlets to run in an isolated process |
| **Key exfiltration** | When sensitive data is extracted off the device and continually used to authenticate resources from outside |
| **Key isolation** | hosting and performing crypto operations on key material in a separate high security environment so that the key material is never exposed to the calling app or other apps on the same system |
| ***LsaSs*** | Normal-mode secure process in VTL0 that hosts KeyGuard's KeyIso service and NCryptProv with BCryptIso client library |
| ***LsaIso*** | Secure-mode trustlet in VTL1 that hosts BCryptIum library |
| **MHSM (Managed Hardware Security Module)** | An Azure Key Vault resource type that act as single-tenant, fully managed, highly available, load balanced instances backed by 3 HSMs isolated to one single tenant |
| **RPC (Remote Procedure Call)** | Standard that enables one process to make calls to functions executed in another process on the same or different computer, can be used in all client/server applications based in Windows OS |
| **SK (Secure Kernel)** | Manages the operations of VTL1 |
| **TPM (Trusted Platform Module)** | A hardware chip on the device that provides a secure storage area for cryptographic keys and other sensitive data. |
| **Trustlet** | A program that runs as an IUM process |
| **VBS (Virtualization Based Security)** | A security feature in Windows that uses virtualization to create a secure region of memory to isolate critical system processes from the normal operating system. |
| **VSM (Virtual Secure Mode)** | Technology that sets up the security boundary between different Virtual Trust Levels (VTLs) created by VBS on Windows. Such separation ensures that malicious host kernel, user mode, and host admin level malware penetrates VTL0, it cannot access secrets in VTL1. A VSM-backed key is also known as a KeyGuard key. |
| **VTL (Virtual Trust Level)** | Security boundaries set up by VBS/VSM that act as CPU protection rings |

BIN
windows/security/identity-protection/key-protection-with-vbs/images/architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 548 KiB

69
windows/security/identity-protection/key-protection-with-vbs/index.md Normal file
View File

@ -0,0 +1,69 @@
---
title: Key protection with VBS
description: Learn about Key protection with VBS and how ...
ms.date: 01/11/2024
ms.topic: overview
appliesto:
- "✅ <a href=\"https://learn.microsoft.com/windows-insider/\" target=\"_blank\">Windows Insider Preview</a>"
---
# Key protection with VBS overview
[!INCLUDE [insider-note](../../includes/insider-note.md)]
## Overview
> "KeyGuard" is an internal name only. For all 3P services and public documentation and applications, this feature is referred to as "VBS Key Isolation."
VBS Key Isolation is a Windows security feature that isolates the private material of cryptographic keys from the normal operating system, enhancing protection against malware and malicious attacks. Across Azure, first party services can leverage this feature and migrate high value and high blast radius keys to prevent key exfiltration attacks.
KeyGuard leverages a master key from an on-device TPM (Trusted Platform Module) to encrypt its data, while also making use of [Virtualization Based Security (VBS)](https://www.osgwiki.com/wiki/Virtualization_Based_Security) to isolate keys and execute on the main CPU.
Through this combination, KeyGuard offers strong security against exfiltration attacks by admin and kernel-level malware, as well as strong performance and reliability by leveraging the power of the device's CPU. This makes KeyGuard an ideal solution for applications that have high performance, reliability, and security requirements.
## Supported Scenarios
- APPKI Certs: KeyGuard is available for self-service for 1P customers using APPKI-backed certs on Pilot Fish Control Plane (Windows Server 22+) and Azure Host 2023.
- See [Auto Pilot and Pilot Fish](https://eng.ms/docs/products/autopilot/autopilot/keyguard) for pre-requisites and onboarding instructions.
- Customers using non-APPKI backed certificates should check with their secret manager for support.
- eSTS and MSA: KeyGuard offers protection of eSTS and MSA token signing keys on EAP VMs (Windows Server 22+).
- KeyGuard supports PKCS11 unwrapping on EAP VMs (Windows Server 22+).
- KeyGuard supports attestation of KeyGuard keys on EAP VMs (Windows Server 22+).
## Upcoming Scenarios and Environments
- Generic support on Windows Server 22+
- Generic support on Windows Client 11+
- Azure Host 2024
## Hardware Requirements
Although you may have the appropriate OS installed on your machine, the following hardware requirements must be met to leverage KeyGuard:
- VBS enabled
- TPM enabled
- For bare-metal environments, TPM 2.0 is required.
- For VM environments, [vTPM](https://microsoft.sharepoint.com/sites/knowledgecenter/_layouts/15/TopicPagePreview.aspx?topicId=AL_nR48woHhIZkP7o9MB44Yvg&topicName=Virtual%20Trusted%20Platform%20Module&lang=en-us&ls=Ans_Bing) (Virtual TPM) is supported.
- BIOS should be upgraded to UEFI with SecureBoot profile
See also:
- VBS has several hardware requirements to run, including Hyper-V (Windows hypervisor), 64 bit architecture, and IOMMU support. The full list of VBS hardware requirements can be found [here](https://docs.microsoft.com/windows-hardware/design/device-experiences/oem-vbs
).
- Microsoft requirements for a highly secure device can be found [here]( https://docs.microsoft.com/windows-hardware/design/device-experiences/oem-highly-secure).
## FAQ
### What is KeyGuard?
KeyGuard is a key isolation feature based on Virtualization Based Security (VBS) that provides a strong guarantee that even kernel level malware or malicious admin users can't extract private key bits. KeyGuard stores and performs crypto operations on keys and secrets in a VBS trustlet, an isolated process that's separate from other applications running on the same machine. KeyGuard leverages a master key from the Trusted Platform Module (TPM) chip on the host to encrypt its data, binding the contents of KeyGuard to the device. 
Trusted Platform Modules (TPMs) can be used to combat security attacks that involve exporting keys or secrets from a device as well. However, TPMs have low performance. Key Guard on the other hand leverages VBS and executes on the main CPU which leads to much stronger performance & reliability metrics.
Leveraging KeyGuard offers the security of TPM by making keys resilient to admin level malware and exfiltration attacks, while simultaneously maintaining strong performance and reliability by leveraging the power of the device CPU. Key Guard protects the certificate private key using virtualization-based security so that administrative or kernel-mode code can interact with the certificate but not access the private key directly. This forces the intruder to remain on the server in order to use the certificate, giving us an extended period for detection and response. Using Key Guard is advantageous for applications with high performance, reliability, and security requirements. 
Disclaimer: KeyGuard is not as secure as the TPM because operations are not HW isolated and VBS offers a much larger attack surface than TPM. Furthermore, KeyGuard is only as secure as the TPM that its master key is provisioned from. Therefore, if TPM reliability or security is degraded, it will pass on to KeyGuard. This is still a significant improvement compared to the security posture/attack surface in standard OS. 
### What is Attestation? 
Host Attestation cryptographically verifies that a given machine is running a securely configured stack - HW root-of-trust, firmware, bootloaders, and OS. Today, attestation is enforced during node bootstrap when the node reaches out to APCA (Autopilot Cert. Authority) for a machine cert. Every node requires a machine cert (AP PKI cert) to talk to other Azure services and to eventually host customer workloads and the provisioning of this cert by APCA is gated by whether the machine passed Host Attestation service checks. In the near future, HAS will switch to periodic enforcement - entire fleet will be re-attested every 24-48 hours and each node will receive a host health token that can serve as its evidence of being trusted and healthy.

334
windows/security/operating-system-security/network-security/windows-firewall/dynamic-keywords.md Normal file
View File

@ -0,0 +1,334 @@
---
title: Windows Firewall dynamic keywords
description: Learn about Windows Firewall dynamic keywords and how to configure it.
ms.topic: how-to
ms.date: 01/12/2024
---
# Windows Firewall dynamic keywords
Windows Firewall includes a functionality called *dynamic keywords*, which simplifies the configuration and management of Windows Firewall.
You can use dynamic keywords to create a set of IP addresses, or fully qualified domain names (FQDNs), to which one or more Firewall rules can refer.
## Configure dynamic keywords
To configure dynamic keywords, you can use:
- [Firewall CSP](/windows/client-management/mdm/firewall-csp)
- Microsoft Intune, through a simplified experience called [reusable settings groups](/mem/intune/protect/reusable-settings-groups)
- Windows PowerShell
### Microsoft Intune reusable settings groups
Microsoft Intune offers a functionality called *reusable settings groups*, which can be used to configure Windows Firewall dynamic keywords.
Reusable groups simplify the configuration and management of Windows Firewall rules, offering controls to configure and reuse settings across rules.
Reusable settings groups contain properties that can be reused across Firewall rules, like remote IP address ranges, Fully Qualified Domain Name (FQDN) definitions, and auto-resolution.
When a device is added or removed, each policy does not need to touched individually, instead the reusable group is be updated.
For more information, see [Use reusable groups of settings with Intune policies](/intune/protect/endpoint-security-firewall-policy#add-reusable-settings-groups-to-profiles-for-firewall-rules).
## Fully Qualified Domain Names (FQDN)
Dynamic keywords can be set up with IP addresses or FQDNs. FQDNs are auto-resolved by the client.
Here are important things to consider when using FQDNs in dynamic keywords:
- FQDN support is for reducing the overhead of managing IP rules where IP addresses are dynamic and change frequently
- FQDNs are not a replacement for IP addresses in all scenarios. IP addresses should be used when possible, for security and performance reasons
- FQDN rules have a performance impact on the endpoint
- FQDN is not a secure DNS service. The FQDN resolution uses the default DNS configuration of the endpoint
- DNS latency can impact endpoint performance
- An FQDN rule requires a DNS query to happen for that FQDN to be resolved to an IP address. Traffic to IP addresses must generate a DNS query for FQDN rules
- Limitations may include: websites accessed via proxy, secure DNS services, certain VPN tunnel configurations, cached IPs on the endpoint
- Fully Qualified Domain Names (FQDNs) are the best option, but Partially Qualified Domain Names (PQDNs) are allowed. Wildcards `*` are supported for hosts, for example `*.contoso.com`
Further information on the API structure can be found in https://learn.microsoft.com/windows/win32/ics/firewall-dynamic-keywords.
### Functions and known limitations
The Windows Firewall FQDN feature uses the Network Protection external callout driver, to inspect DNS responses where the DNS query matches FQDN rules.
- The Network Protection component doesn't periodically execute DNS queries. It requires an application to execute a DNS query
- Windows Firewall flushes all stored resolved IP addresses on device restart
- Network protection doesn't synchronously inspect the DNS response, meaning it currently doesn't hold the UDP packet during inspection. It is an asynchronous function
- This can create a condition where an application, after receiving the DNS response, may attempt to connect to an IP address but gets initially blocked if it is faster than the FW rule update.
- This is in the order of milliseconds
- Generally, applications have retry logic for an initial failed connection and as a result the issue is transparent to the end user
- On occasion a component may not have retry logic on initial connection fail. Which is generally solved in two ways
- The end user can hit "refresh" in the application they are using, and it should connect successfully at that time
- Customers can use the pre-hydration scripts tactfully where this condition is occurring in their environment
- MDE keywords in the FQDN feature are case sensitive.
- If local policy merge is disabled, then all rules must be recreated via Intune. For more information, see [Local policy merge and application rules](rules.md#local-policy-merge-and-application-rules).
### Order of operations
1. Firewall publishes the list of FQDNs to Network Protection
1. Network Protection listens for DNS queries where FQDNs match the definition from Windows Firewall
1. Network Protection listens for the DNS response. Once UDP packets are received, Network Protection parses the packets and sends the information to Windows Firewall
1. Windows firewall updates the corresponding firewall rules with the resolved IP(s)
### Key Configuration Points for FQDN Feature
- Microsoft Defender Antivirus must be turned on and running platform version 4.18.2209.7 or later.
- To verify, open [Windows Security](windowsdefender://) and select **Settings** > **About**
- Network Protection must be in *block* or *audit* mode. For more information, see [Check if network protection is enabled](/microsoft-365/security/defender-endpoint/enable-network-protection?view=o365-worldwide#check-if-network-protection-is-enabled).
- DNS over HTTPS (DoH) must be disabled. To configure your preferred browser, you can use the following settings:
- [Edge](/deployedge/microsoft-edge-policies#control-the-mode-of-dns-over-https)
- [Chrome](https://chromeenterprise.google/policies?policy=DnsOverHttpsMode)
- [Firefox](https://support.mozilla.org/kb/firefox-dns-over-https)
- The device's default DNS resolution settings apply. This feature does not provide any additional DNS security or functionality changes
- For Edge version 109 and later, configure the browser to use the default system DNS through [this policy](/deployedge/microsoft-edge-policies#builtindnsclientenabled). For more information, see [Configure Microsoft Edge policy settings on Windows devices](/deployedge/configure-microsoft-edge)
> [!TIP]
> You can also download the ADMX file from there, follow the directions, and configure it via gpedit.msc for local testing.
### Example configurations for the two primary postures for FQDN
- Block all outbound and inbound by default and allow specific outbound traffic
- Block all inbound by default and block some specific outbound traffic
- Inbound FQDN rules are not natively supported. However, it is possible to use Sample_hydration_scripts to generate inbound IP entries for the rules.
Here are a few general guidelines for configuring outbound rules. https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/checklist-creating-outbound-firewall-rules
> [!CAUTION]
> The default configuration of *Blocked for Outbound* rules can be considered for certain highly secure environments. However, the *Inbound* rule configuration should never be changed in a way that allows traffic by default.
In high security environments, an inventory of all enterprise-spanning apps must be taken and logged by the administrator or administrators. Records must include whether an app used requires network connectivity. Administrators will need to create new rules specific to each app that needs network connectivity and push those rules centrally, via group policy (GP), Mobile Device Management (MDM), or both (for hybrid or co-management environments). E.g., Edge https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-endpoints
## Manage dynamic keywords with Windows PowerShell
The following hydration scripts read the current Firewall configuration, extract FQDN based rules and perform DNS resolution on each domain, so that IP addresses for those rules get populated.
### Hydrate FQDN rule IPs using Resolve-DNSName
```PowerShell
Get-NetFirewallDynamicKeywordAddress -AllAutoResolve |`
ForEach-Object {
if(!$_.Keyword.Contains("*")) {
Write-Host "Getting" $_.Keyword
resolve-dnsname -Name $_.Keyword -DNSOnly | out-null
}
}
```
Silent:
```PowerShell
Get-NetFirewallDynamicKeywordAddress -AllAutoResolve |`
ForEach-Object {
if(!$_.Keyword.Contains("*")) {
resolve-dnsname -Name $_.Keyword -DNSOnly | out-null
}
}
```
Hydrate FQDN rule IPs using NSLookup
```PowerShell
Get-NetFirewallDynamicKeywordAddress -AllAutoResolve |`
ForEach-Object {
if(!$_.Keyword.Contains("*")) {
Write-Host "Getting" $_.Keyword
nslookup $_.Keyword
}
}
```
If using `nslookup.exe`, you must create an outbound firewall rule when using the *block all outbound* posture. Here's the command to create the outbound rule for `nslookup.exe`:
```PowerShell
$appName = 'nslookup'
$appPath = 'C:\Windows\System32\nslookup.exe'
New-NetFirewallRule -DisplayName "allow $appName" -Program $appPath -Action Allow -Direction Outbound -Protocol UDP -RemotePort 53
```
### Additional PowerShell and Firewall Commands
#### Enable Network Protection
Block Mode:
`Set-MpPreference -EnableNetworkProtection Enable`
Audit Mode:
`Set-MpPreference -EnableNetworkProtection AuditMode`
#### Display Auto resolve rules and associated resolved IP addresses
> [!NOTE]
> IP addresses will not populate until DNS query is observed.
`Get-NetFirewallDynamicKeywordAddress -AllAutoResolve`
### Block Outbound
Here is an example script to block a site from PowerShell (replace somedomain.com below with the domain you wish to block):
```PowerShell
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'somedomain.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "block $fqdn" -Action Block -Direction Outbound -RemoteDynamicKeywordAddresses $id
```
### Allow Outbound
Here is an example script to allow a site from PowerShell. Replace the `$fqdn` variable value with the FQDN you wish to block (line #1):
```PowerShell
$fqdn = 'google.com'
$id = '{' + (new-guid).ToString() + '}'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
```
## Example rules for block all outbound and allow some FQDNs
### Chrome Config
This is a sample list of application FQDN evaluation. These were observed when inspecting traffic on Chrome first launch. This is not a complete list and not a recommendation. It is an example of how an application should be evaluated to ensure proper connectivity and function, as https://microsoft.sharepoint.com/teams/windowsdefender/Shared%20Documents/WiAD%20PM/Boost%20-%20Data%20and%20Web%20Protection/Firewall/General%20FQDN%20Firewall%20Rule%20Considerations.docx#_Configuring_block_all.
```PowerShell
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.google.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'http://www.google.com/'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'google.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.googleapis.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.googleusercontent.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'http://www.gstatic.com/'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'ipv6.msftconnecttest.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'client.wns.windows.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'dns.msftncsi.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.microsoft.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'http://www.microsoft.com/'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'microsoft.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.gfx.ms.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
```
### Edge Rules
This is a sample list of application FQDN evaluation. These were observed when inspecting traffic on Edge first launch.
> [!NOTE]
> This is not a complete list and not a recommendation. It is an example of how an application should be evaluated to ensure proper connectivity and function, as described above.
[Edge](deployedge/microsoft-edge-security-endpoints)
```PowerShell
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'ctldl.windowsupdate.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'config.edge.skype.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'ntp.msn.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'edge.microsoft.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.events.data.microsoft.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'login.live.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.smartscreen.microsoft.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.msftconnecttest.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'assets.msn.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'client.wns.windows.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'dns.msftncsi.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = '*.microsoft.com'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
$id = '{' + (new-guid).ToString() + '}'
$fqdn = 'http://www.microsoft.com/'
New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true
New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id
```

2
windows/security/operating-system-security/network-security/windows-firewall/toc.yml
View File

@ -13,6 +13,8 @@ items:
href: configure.md
- name: Configure with command line tools
href: configure-with-command-line.md
- name: Dynamic keywords
href: dynamic-keywords.md
- name: Hyper-V firewall
href: hyper-v-firewall.md
- name: Troubleshoot