Category: Networking

Microsoft AZ-700: Exercise – Restrict Network Access to PaaS Resources with Virtual Network Service Endpoints Using the Azure Portal

Reading Time: 3 minutes

Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 5: Exercise – Restrict Network Access to PaaS Resources with Virtual Network Service Endpoints Using the Azure Portal

Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

  • Task 1: Create a virtual network.
    • Search and select Virtual Networks in portal
    • Click Create
      • Select or Create New Resource group (create new in this example)
        • Enter unique name in dialog and click OK
      • Enter Instance Name
      • Choose Region from dropdown
      • Click Next : IP Addresses >
      • Click link for default
        • In right panel change name to Public
        • Click Save
      • Click Next : Security >
      • Verify all security settings toggled to Disable
      • Click Review + create
      • Once validated click Create
  • Task 2: Enable a service endpoint.
    • Click Go to resource on deployment complete page from task above
    • Click Subnets in left panel
    • Click Subnet in menu bar to create a new subnet
      • In right panel
        • Enter unique name for subnet
        • Under Service Endpoints choose Microsoft.Storage from services dropdown
        • Click Save
    • Note 2 subnets created: Public and Private
  • Task 3: Restrict network access for a subnet.
    • Search and click Network security groups in portal
    • Click Create in menu bar
      • Choose Resource group from dropdown
      • Enter unique name under Instance details
    • Click Review + create
    • Once validated click Create
    • Once deployment complete choose Go to resource
    • Under Settings choose Outbound security rules
      • Click Add in menu bar
      • In right panel
        • Choose Service Tag in Source dropdown
        • Choose Virtual Network in Source service tag dropdown
        • Choose Service Tag in Destination dropdown
        • Choose Storage in Destination Service Tag dropdown
        • Enter wildcard (*) in Destination port ranges box
        • Enter unique name in Name box
        • Click Add
      • Click Refresh to verify rule created with Priority 100
  • Task 4: Add other outbound rules.
    • Follow MS Learn steps similar to above to Deny Internet All
    • Change Priority to 110
    • Click Add
    • Refresh page to verify rule with priority 110 created
  • Task 5: Allow access for RDP connections.
    • Under settings in left panel click Inbound Security Rules
    • Click Add in menu bar
      • In right panel
        • Select Service Tag in Destination dropdown
        • Select Virtual Network in Destination Service Tag dropdown
        • Change port in Destination port ranges box to 3389
        • Add unique name for rule in Name box
        • Click Add
    • Click Refresh to verify new rule created
    • Click Subnets in left panel
      • Click Associate in menu bar
      • In right panel
        • Select Private subnet from subnet dropdown
        • Click OK
  • Task 6: Restrict network access to a resource.
    • This is really just a task to create the storage account but Task 6: Title is as from MS Learn
    • Search and click Storage Accounts in portal
    • Click Create
      • Choose resource group from dropdown
      • Enter unique storage account name
      • Choose Locally-redundant storage (LRS): from Redundancy dropdown
      • Click Review
      • Click Create
  • Task 7: Create a file share in the storage account.
    • Click Go to resource from deployment completion page from Task 6 steps
    • Choose File Shares under data storage in left panel
    • Click File Share in menu bar
      • In right panel
        • Enter Marketing in Name box
        • Click Create
  • Task 8: Restrict network access to a subnet.
    • In left panel under Security + networking choose Networking
    • Toggle Public Network Access to “Enabled from selected virtual networks and IP addresses
    • Click Add existing virtual network
      • In right panel
        • Select VNet under Virtual networks dropdown
        • Select subnet under Subnets dropdown (Private)
        • Click Add
    • Click Save in menu bar
    • In left panel under Security + Networking choose Access Keys
      • Click Show button for Key under key1
      • Click Copy to clipboard button
  • Task 9: Create virtual machines.
    • Open PowerShell in cloudshell pane (button next to portal search bar)
    • Upload Template and Parameter file as we’ve done in previous exercises
    • Verify Subscription
      • (az account show –output table)
    • Set account
      • (az account set –subscription “Name from output above”)
    • Set resource group name variable

($RGName = “myResourceGroup”)

  • Deploy VM
    • (New-AzResourceGroupDeployment -ResourceGroupeName $RGName -TemplateFile filename.json -TemplateParameterFile filename.parameters.json)
  • Close cloud PowerShell
  • Search Virtual Machines and verify new VMs created
  • Task 10: Confirm access to storage account.
    • Choose Private VM
    • Select Connect > RDP from menu bar
    • Click Download RDP File
    • Click Open file link
    • Click Connect on dialog
    • Enter creds and click OK
    • Search for PowerShell in RDP session
      • ($acctKey = ConvertTo-SecureString -String “previouslycopiedkey” -AsPlainText -Force)
      • (credential = New-Object System.Management.Automation.PSCredential -ArgumentList “Azure\contosostorage755238”, $acctKey)
      • (New-PSDrive -Name Z -PSProvider FileSystem -Root “\\contosostorage755238.file.core.windows.net\marketing” -Credential $credential)
      • Ping bing.com
        • Should fail
      • Close RDP Session and ContosoPrivate VM page in portal
    • Choose ContosoPublic VM
    • Click Connect > RDP from menu bar
    • Click Download RDP File
    • Click Open file link
    • Click Connect on dialog
    • Enter creds and click OK
    • Open PowerShell in RDP session
      • ($acctKey = ConvertTo-SecureString -String “previouslycopiedkey” -AsPlainText -Force)
      • (credential = New-Object System.Management.Automation.PSCredential -ArgumentList “Azure\contosostorage755238”, $acctKey)
      • (New-PSDrive -Name Z -PSProvider FileSystem -Root “\\contosostorage755238.file.core.windows.net\marketing” -Credential $credential)
        • Output should list Access is denied
      • Ping bing.com
        • Should be successful
    • Close RDP session
    • Search Storage accounts in portal
      • Choose the new contosostorage account created earlier
      • Choose File share in left panel under Data Storage
      • Choose marketing
        • Access is denied due to PC not in private subnet
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-restrict-network-access-to-paas-resources-with-virtual-network-service-endpoints-using-the-azure-portal/

Microsoft AZ-700: Integrate Private Endpoint with Domain Name Service

Reading Time: 2 minutes

Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 4: Integrate Private Endpoint with Domain Name Service

Private DNS zones typically hosted in same subscription where hub VNet deployed. Central hosting practice is recommended for cross-premises DNS resolution. Most cases – only networking and identity admins have permissions to manage DNS records

  • Azure Private Endpoint DNS Configuration
    • Below diagram show typical high-level architecture for enterprise env with central DNS.
    • Name resolution for Private Link resources done via Azure Private DNS
    • (Image taken from MS Learn)
    • Highlights of diagram
      • On-prem DNS servers have conditional forwarders configured for each Private Endpoint
      • DNS servers in hub VNet use Azure DNS resolver as forwarder
      • All VNets have DNS forwarders configured as primary/secondary DNS servers
      • DNS records follow lifecycle of Private Endpoint
    • Significance of IP Addr 168.63.129.16
      • VIP (public) that facilitates communication channel to Azure platform resources
        • Enables VM Agent to communicate with Azure platform to signal that it is in a “Ready” state
        • Enables communication with DNS virtual server providing filtered name resolution – Filtering ensures customers can resolve only hostnames to their resources
        • Enables health probes from load balancer to determine health state of VMs
        • Enables VMs to obtain dynamic IP addr from DHCP service in Azure
        • Enables heartbeat messages for PaaS role
    • On-prem workloads using DNS forwarder
      • For on-prem workloads to resolve FQDN of Private Endpoint use DNS forwarder to resolve Azure service public DNS zone
      • A DNS forwarder is VM running on VNet linked to Private DNS Zone
      • Query must be originated from VNet to Azure DNS
      • Proxy options include
        • Windows DNS
        • Linux DNS
        • Azure FW
      • Diagram below illustrates DNS resolution sequence from on-prem
      • Configuration uses DNS forwarder in Azure
      • Resolution made by private DNS zone linked to VNet
      • (Image taken from MS Learn)
      • Configuration needs
        • On-prem network
        • VNet connected to on-prem
        • DNS forwarder in Azure
        • Private DNS zones privatelink.database.windows.net with A record
        • Private Endpoint info (FQDN record name with private IP)
    • Virtual Network and On-prem workloads using Azure DNS Private Resolver
      • When using DNS Private Resolver – you don’t need DNS forwarder VM.
      • Azure DNS is able to resolve on-prem domain names
      • Below diagram uses DNS Private Resolver in hub-spoke topo
      • Best practice: Azure landing zone design pattern recommends using this type of topo
      • Hybrid net connection established using Azure ExpressRoute and FW
      • Provides secure hybrid network
      • DNS Private Resolver is deployed in hub network
      • (Image taken from MS Learn)
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-integrate-private-endpoint-with-domain-name-service/

    Microsoft AZ-700: Define Private Link Service and Private Endpoint

    Reading Time: 2 minutes

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 3: Define Private Link Service and Private Endpoint

    • What is Azure Private Link
      • Azure Private Link enables access to Azure PaaS Services and Azure hosted customer-owned/partner services over Private Endpoint in VNet
    • Private Link is designed to remove public part of connection
    • Provides secure access to Azure Services achieved by replacing resource public endpoint with a private NIC
    • Key considerations for this architecture
      • Azure resource becomes part of your VNet
      • Connection to resource uses Microsoft Azure backbone instead of public INET
      • Can configure Azure resource to no longer expose its public IP
    • What is Azure Private Endpoint
      • Key technology behind Private Link
      • NIC that enables a private/secure connection between VNet and Azure service
      • NIC that replaces resources public endpoint
      • Provides secure access to Azure services
      • Replaces resource public endpoint with private NIC
    • How is Azure Private Endpoint different from service endpoint
      • Grants network access to specific resource behind given service providing granular segmentation
      • Traffic can reach service resource from on-prem without using public endpoints
      • Service endpoint remains publicly routable
      • Private endpoint is private IP in address space of VNet where configured
    • What is Azure Private Link Service
      • Gives private access from Azure VNet to PaaS services and MS Partner services in Azure. What is org has its own Azure services. Is it possible to offer those customer a private connection to orgs services
    • Yes with Private Link Service
    • Lets you offer Private Link connections to custom Azure services
    • Consumers of custom service can access them privately without going over INET from their own VNets
    • Private Link service is reference to own service powered by Private Link
    • Service is running behind Azure standard load balancer can be enable for Private Link access
    • Customers can create private endpoint inside their VNet and map to this service
    • Private Link service receives connections from multiple private endpoints.
    • Private endpoint connects to 1 Private Link services
    • Private Endpoint Properties
      • Considerations
        • Unique name with resource group
        • Subnet to deploy/allocate private IP addresses from VNet
        • Private Link resource to connect using resource ID/Alias from list of available types – A unique network identifier is generated for all traffic sent to resource
        • The subresource to connect – each private link resource type has diff options to select based on pref
        • Automatic or manual connection approval method – based on Azure role-based access control (RBAC) Private Endpoint can be approved automatically.
        • For manual method of above, owner of resource approves connections
        • Only Private Endpoints in approved state used to send traffic
      • Additional Considerations
        • Clients initiate net connections. Only established in single direction
        • Private Endpoint has read-only NIC. Interface assigned dynamically from subnet that maps to Private Link resource – remains unchanged for lifecycle of Private Endpoint
        • Must be deployed in same region and subscription of VNet
        • Private Link can be deployed in diff region than VNet of Private Endpoint
        • Multiple Private Endpoints can be created using same Private Link
        • Multiple Private Endpoints can be created on same or diff subnets within same VNet
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-define-private-link-service-and-private-endpoint/

    Microsoft AZ-700: Explain Virtual Network Service Endpoints

    Reading Time: 3 minutes

    Notes from MS Learn AZ-700 Module 7: Explain Virtual Network Service Endpoints

    Think your org migrates existing ERP app with DB server to Azure VMs. Now, you consider Azure platform as a service in Azure for cost/admin requirements. Storage services hold large file assets. These engineering diagrams have proprietary info and must remain secure from unauthorized access. Must be only accessible from specific systems

    • What is a virtual network service endpoint
      • VNet service endpoint provides secure and direct connectivity to Azure services. Service endpoints allow you to secure critical Azure service resources to only your VNets. Service Endpoints enables private IP addrs in the VNet to reach the endpoint of an Azure service without needing a public IP
      • By default, Azure services are designed for DIA. All Azure resources have public Ips including PaaS services such as Azure SQL and Storage. Since explosed to INET potential for anyone to access Azure services
      • Service endpoints can connect certain PaaS services directly to private address space in Azure
      • Service endpoints use private space to access PaaS services directly
      • Adding service endpoints doesn’t remove public endpoint but provides a redirect of traffic
    • Preparing to Implement Service Endpoints
      • Two required steps
        • Turn off public access to service
        • Add Service Endpoint to VNet
      • When enabling Service Endpoint traffic flow is restricted and Azure VMs are enabled directly from private addr space
      • Devices cannot access service from public network
      • VM vNIC Service Endpoint becomes Next Hop Type
      • Example route table before enabling Service Endpoint (Table below from MS Learn)
      • Example route table after adding 2 Service Endpoints to VNet (Table below from MS Learn)
      • All traffic for service now routed to VNet Service Endpoint and remains inside Azure
    • Create Service Endpoints
      • Planning to move sensitive diagram into Azure Storage. File must only be accessible from computers inside corp network. You want to create a VNet Service Endpoint for Azure Storage to secure connectivity to storage accounts
      • Steps
        • Enable service endpoint on a subnet
        • Use network rules to restrict access to Azure Storage
        • Create a virtual network service endpoint for Azure Storage
        • Verify access is denied appropriately
    • Configure service tags
      • Service tag represents group of IP prefixes from a given Azure service. MS manages prefixes encompassed by service tag automatically updating addrees minimizing complexity of frequent updates to network security rules
      • You can use service tags to define network access controls on network security groups or FW
      • Use service tags in place of specific IP’s when creating security rules
      • Specifying service tag name (e.g. API Management) in appropriate SRC/DST of rule allows or denies traffic for service
      • As of March 2021 Service Tags can be used in place of IP ranges in user defined routes. Currently in Public Preview
      • Use service tags to achieve network isolation and protect Azure resources from general Internet while accessing Azure services that have public endpoints
      • Create In/Out network security group rules for deny to/from INET and allow to/from AzureCloud or other specific Azure services
    • Available service tags
      • Follow this MS Table for all service tags available for use in NSG rules. Columns define whether tag
        • Is suitable for rules that cover in/outbound traffic
        • Supports regional scope
        • Is usable in FW rules
      • By default, service tags are for entire cloud
      • Some tags also allow more granular control via restricting IP ranges to specific region
      • Service tags of Azure services denote prefixes from specific cloud being used
      • If implementing VNet service endpoint Azure adds route to VNet subnet. Prefixes in route are same as prefixes for corresponding service tag
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-explain-virtual-network-service-endpoints/

    Microsoft AZ-700: Design and Implement Network Security Module Resources

    Reading Time: < 1 minute

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 11: Design and Implement Network Security Module Resources

    Resources are links taken from MS Learns summary page for this module

    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-design-and-implement-network-security-module-resources/

    Microsoft AZ-700: Implement a Web Application Firewall on Azure Front Door

    Reading Time: 2 minutes

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 10: Implement a Web Application Firewall on Azure Front Door

    Web Application Firewall (WAF) provides centralized protection of web apps from common exploits and vulnerabilities. SQL injection and Cross-site scripting are common.

    Attack prevention is challenging. Can require lots of maintenance/patching/monitoring of many layers to the app. Centralized WAF aids in this. Also gives app admins better assurance to protection.

    WAF can react to security threats faster by central patching instead of individual web app patching

    • Web Application Firewall Policy Modes
      • Two common modes
        • Detection
          • Default WAF policy mode
          • Doesn’t block requests but logs
        • Prevention
          • Matching requests blocked & logged
    • Web App. Firewall default rule set rule groups and rules
      • Azure Front Door WAF protects web apps from common vulns and exploits. Azure-managed rule sets provide easy deployment against common sec threats. Azure rule set updated as required to protect against new signatures
    • Managed Rules
      • Azure managed Default Rule Set includes common categories
        • Cross-site scripting
        • Java attacks
        • Local file inclusion
        • PHP injection attacks
        • Remote command execution
        • Remote file inclusion
        • Session fixation
        • SQL injection protection
        • Protocol attackers
      • Enabled by default
      • Disable individual rule by checkbox in front of rule and selecting Disable at top of page
      • Change action types by checkbox and select Change action at top of page
    • Custom Rules
      • WAF with Front Door allows access to web apps on defined conditions
      • Custom WAF rule consists of
        • Priority
        • Rule type
        • Match conditions
        • And action
      • Two types of customer rules
        • Match Rule
          • Determines access based on matching conditions
        • Rate Limit Rule
          • Access based on matching conditions and rates of inbound requests
      • When creating WAF policy, create custom rule selecting. Add Custom Rule under the Custom Rules section
    • Create a Web Application Firewall Policy on Azure Front Door
      • Key steps for basic WAF Policy and apply to Front Door
        • Create WAF policy
          • Create a basic WAF policy with managed Default Rule Set (DRS)
          • Associate WAF policy with Front Door profile
            • Done during WAF policy creation
            • Can also be done on previously created WAF policy
              • In association specify Front Door profile and domain to apply to
          • Configure WAF policy settings and rules
            • Optional step, can configure policy settings such as Mode (prevention/Detection and configure managed and custom rules
      • Detailed steps in MS Learn page Tutorial: Create a Web Application Firewall policy on Azure Front Door using the Azure portal
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-implement-a-web-application-firewall-on-azure-front-door/

    Microsoft AZ-700: Exercise – Secure Your Virtual Hub Using Azure Firewall Manager

    Reading Time: 3 minutes

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 9: Exercise – Secure Your Virtual Hub Using Azure Firewall Manager

    Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

    • Task 1: Create two spoke virtual networks and subnets.
      • Search and choose Virtual Networks in Azure Portal
      • Select Create
        • Create New Resource group
          • Enter unique name and click OK
        • Enter Unique Instance Name
        • Choose Region from dropdown
        • Choose Next : IP Addresses >
        • Choose the hyperlink for default under subnet name
          • Enter a unique subnet name
          • Change Subnet address range to appropriate CIDR range
          • Click Save
        • Click Review + create
        • Once validated click Create
      • Repeat for second Virtual Network
    • Task 2: Create the secured virtual hub.
      • Search and Click Firewall Manager in Azure Portal
      • Click Overview tab
      • Click View secured virtual hubs
      • Click Create new secured virtual hub
        • Select Resource Group from dropdown
        • Select Region from dropdown
        • Enter unique name for Secured virtual hub name
        • Enter appropriate CIDR for Hub address space
        • Enter Unique name for Virtual WAN Name
        • Click Next : Azure Firewall >
        • Click Next : Security Partner Provider >
        • Click Next : Review + create >
        • Once validation succeeds click Create
        • Search and return to Firewall Manager under Azure Portal
        • Choose Virtual Hubs in left panel
        • Choose Hub-01
        • Select Public IP configuration
        • Note Public IP Address for later
    • Task 3: Connect the hub and spoke virtual networks.
      • Search for and choose Virtual WANs in Azure Portal
      • Choose Vwan-01
      • Select Virtual network connections in left panel
      • Choose Add connection
        • Enter unique Connection name
        • Choose hub from dropdown
        • Choose resource group from dropdown
        • Choose VNet from dropdown
        • Select Create
      • Repeat for Spoke 2
    • Task 4: Deploy the servers.
      • Open PowerShell from Portal
      • Upload Template and Parameters files
      • Verify subscription
        • (az account show –output table)
      • Set subscription
        • (az account set –subscription “Name from output above”)
      • Set route group name variable
        • ($RGName = “fw-manager-rg”)
      • Deploy ARM template
        • (New-AzResourceGroupDeployment -ResourceGroupeName $RGName -TemplateFile filename.json -TemplateParameterFile filename.parameters.json)
      • Return to portal and navigate to Virtual Machines
        • Click first VM and note IP
        • Repeat for second VM
    • Task 5: Create a firewall policy and secure your hub.
      • Search and Select Firewall Manager in portal
      • Click Azure Firewall Policies in left panel
      • Select Create Azure Firewall Policy
        • Choose Resource group from dropdown
        • Enter a unique name
        • Choose Region from dropdown
        • Toggle tier to Standard
        • Click Next : DNS Settings >
        • Click Next : TLS inspection >
        • Click Next : Rules >
        • Click Add a rule collections
          • Enter Unique Name
          • Select Application from Rule collection type dropdown.
          • Enter Priority (100)
          • Enter Name under Rules
          • Enter source (wildcard in this case *)
          • Enter http,https as protocol
          • Enter *.microsoft.com as destination
          • Click Add
        • Repeat for a DNAT rule collection type
          • Select TCP under protocol
          • Set Dest Port as 3389
          • Set Public Ip for DST
          • Enter Translated Address or FQDN
          • Enter DST port
          • Click Add
        • Repeat for Network rulle collection type
        • Click Review + Create
        • Once validated click Create
    • Task 6: Associate the firewall policy.
      • In portal search and click Firewall Manager
      • Click Azure Firewall Policies
        • Check box next to Policy-01
        • Select Manage associations dropdown in menu bar
        • Select Associate hubs
          • Check box next to Hub-01
          • Select Add
        • Click Refresh
          • Should be listed now
    • Task 7: Route traffic to your hub.
      • Select Virtual Hubs under deployments in left panel
      • Choose Hub-01
      • Under settings select Security configuration
        • Internet traffic select Azure Firewall from dropdown
        • Private traffic dropdown select Send via Azure Firewall
      • Click Save
      • Click OK in dialog
      • Ensure for both spokes Internet Traffic and Private Traffic list “Secured by Azure Fireall”
    • Task 8: Test the application rule.
      • Launch Remote Desktop Connection
      • Enter IP in Computer Box
      • Click Connect
      • Click Connect again
      • Enter Creds
      • Click OK
      • In RDP open Internet Explorer
      • Browse to Microsoft Home Page
      • Okay in dialog
      • Browse to Google Home Page
      • Denied due to app rule
    • Task 9: Test the network rule.
      • In RDP search and launch Remote Desktop Connection
      • Enter Private IP of workload VM
      • Click connect
      • Enter Creds
      • Clock OK
      • RDP Launches
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-secure-your-virtual-hub-using-azure-firewall-manager/

    Microsoft AZ-700: Secure Your Networks with Azure Firewall Manager

    Reading Time: 3 minutes

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 8: Secure Your Networks with Azure Firewall Manager

    Azure FW Manager is a security management that provides central policy/route management for cloud-based sec perimeters.

    Azure FW Manager simplifies centrally defining network and app level rules for filtering across multiple Azure FWs. Span different Azure regions and subscriptions in hub/spoke architectures for governance and protection

    If managing multiple FWs it can be difficult to keep them in sync. Central IT needs a way to define base FW policies and enforce across multiple biz units. Also, DevOps want to create local derived FW policies implemented across orgs. Azure FW Manager can help solve these

    • FW Manager can provide sec mgmt for 2 network arch types
      • Secured Virtual Hub
        • Given to any Azure Virtual WAN Hub associated with security and routing policies
        • Azure Virtual WAN Hub is MS managed resource to easily create hub/spoke archs
      • Hub Virtual Network
        • Given to any standard Azure VNet with associated security policies
        • Standard VNet is a resource created and managed yourself
        • Can peer spoke VNets that contain workload servers/services
        • Also manage FWs in standalone VNets that arenn’t peered to a spoke
    • Azure FW Manager features
      • Key Features
        • Central Azure FW deployment and config
          • Centrally deploy/configure multiple FW instances even if they span regions and subscriptions
        • Hierarchical policies (global/local)
          • Use Azure FW Manager to centrally manage FW policies across multiple secure virtual hubs
          • Central IT teams can write global firewall policies to enforce org FW policy across teams
          • Local authored FW polocies allow DevOps self-service model
        • Integrated with third-party security-as-a-service for advanced security
          • In addition to Azure FW third party providers can integrate providing extra protection for VNet and branch Inet connections
          • Only available with secured virtual hub deployments
        • Centralized route management
          • Easily route traffic to secured hub for filtering/logging without need for User Defined Routes on spoke VNets
          • Available only with secured virtual hub deployments
        • Region availability
          • Use Azure FW Policies across regions
        • DDoS protection plan
          • Associate VNets with a DDoS protection plan within FW Manager
        • Manage Web App Firewall policies
          • Centrally create/associate WAF policies for app delivery platforms including Front Door and App Gateway
    • Azure Firewall Manager Policies
      • FW policy is Azure resource that contains
        • NAT
        • Network rule collections
        • App rule collections
        • Threat Intelligence settings
      • Global resource that can be used over multiple FW instances in Secured Virtual Hubs and Hub VNets
      • New policies can be created from scratch or inherited
      • Inheritance allows DevOps to create local FW policies on top of org mandated base policy
      • Work across regions and subscriptions
      • Create FW Policy and associations using FW Manager
      • Can also create/manage policy using
        • REST API
        • Templates
        • Azure PowerShell
        • Azure CLI
      • Once created, can associate with FW in a Virtual. WAN Hub making it a Secured Virtual Hub
      • And/Or associate with FW in a standard VNet making it a Hub Virtual Network
    • Deploying Azure FW Manager for Hub Virtual Networks
      • Recommended Process
        • Create FW Policy
          • Create new
          • Derived base policy and customize a local policy
          • Import rules from existing FW (Ensure to remove NAT rules from policies applied across multiple FWs)
        • Create hub & spoke architecture
          • Create Hub Virtual Network using FW Manager and peering spoke VNets to it
          • Or create VNet and add VNet connections/peering spoke VNet to peering
        • Select security providers and associate FW Policy
          • Currently, only Azure FW supported provider
          • Create a Hub VNet or convert existing VNet to Hub Virtual Network
          • Is possible to convert multiple VNets
        • Configured User Defined Route
          • For routing traffic to Hub VNet FW
    • Deploying Azure FW Manager for Secured Virtual Hubs
      • Recommended Process
        • Create hub/spoke architecture
          • Create Secured Virtual Hub using FW Manager and add VNet connections
          • Or create Virtual WAN Hub and add VNet connections
        • Select security providers
          • Create a Secured Virtual Hub
          • Or convert existing Virtual WAN Hub to Secure Virtual Hub
        • Create FW policy and associate it with hub
          • Only applicable if using Azure FW
          • Third-party security-as-a-service policies are configured via partners management
        • Configure route settings to route to Secured Virtual Hub
          • Route to secured hub for filtering/logging without User Defined Routes on spoke VNets using Secured Virtual Hub Route Setting page
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-secure-your-networks-with-azure-firewall-manager/

    Microsoft AZ-700: Exercise – Deploy and Configure Azure Firewall Using the Azure Portal

    Reading Time: 3 minutes

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 7: Exercise – Deploy and Configure Azure Firewall Using the Azure Portal

    Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

    • Task 1: Create a virtual network and subnets.
      • Search and Choose Virtual Networks in Azure Portal
      • Click Create
        • Choose a resource group from the dropdown or click create new (create new in this example)
        • Enter a unique name in the dialog box and click OK
        • Enter a unique name under Instance Details
        • Select a region from the dropdown
        • Click Next : IP Addresses >
        • Select (check box) and the link to the default subnet
          • In right panel enter a unique subnet name
          • Enter an appropriate Subnet address range
          • Click Save
        • Click Add subnet for later use
          • Repeat above settings as appropriate
          • Click Add
        • Click Review + create
        • Once Validation has passed click Create
    • Task 2: Create a virtual machine.
      • Open PowerShell in cloudshell (Shell button next to portal search bar)
      • Upload Template and Parameters files
      • View and specify subscription
        • “az account show –output table”
        • “az account set –subscription “NAME from output above””
    • Set resource group variable
      • “$RGName = Test-FW-RG”
    • Return to Azure Portal to verify VM created
    • Select new VM and note IP Address
    • Task 3: Deploy the firewall and firewall policy.
      • Deploy template
        • “New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile filename.json -TemplateParameterFile filename.parameters.json”
      • In Azure Portal Search and Click Firewalls
      • Select Create
        • Choose Resource group from dropdown
        • Enter Instance Name
        • Choose region from dropdown
        • Choose FW SKU (Standard in this example)
        • Choose Add New under Firewall Policy
          • Enter Unique Policy Name in dialog
          • Choose Region from dropdown
          • Select OK
        • Under Choose a virtual network toggle to Use existing
        • Choose VNet under dropdown
        • Choose Add new under Public IP address
          • Enter Unique Name in dialog
          • Click OK
        • Click Review + Create
        • Once validation passed click Create
        • When complete click Go to resource
        • On overview page copy Firewall private IP
        • In left panel click Public IP configuration under Settings
        • Note public IP address
    • Task 4: Create a default route.
      • Search and click Route Tables in Azure Portal
      • Click Create
        • Choose Resource group from dropdown
        • Choose Region from dropdown
        • Enter unique name
        • Click Review + create
        • Once validation complete click Create
        • Once complete click Go to resource
        • Under settings select Subnets
        • Click Associate
          • Verify Virtual network and Subnet are as expected
          • Select OK
        • Under settings choose Routes
        • Click Add
          • Enter a unique route name
          • In Address prefix destination dropdown choose IP Address
          • Enter Destination IP addresses/CIDR ranges
          • In Next hop type dropdown choose Virtual Appliance
          • Enter Next Hop address
          • Select Add
    • Task 5: Configure an application rule.
      • In Azure Portal navigate to FW policy created earlier
      • Click Application rules
      • Select Add a rule collection
        • Enter Unique name
        • Enter a priority (200 in this example)
        • Enter a name in the Name box
        • Enter Source IP (CIDR)
        • Enter Protocol (http,https)
        • Enter Destination (www.google.com)
        • Click Add
    • Task 6: Configure a network rule.
      • Choose Network Rules under settings
      • Choose Add a rule collection
        • Enter a unique name for collection
        • Enter priority value (200)
        • Choose Rule Collection Group from dropdown
        • Enter unique name for rule under Name box
        • Enter Source (CIDR)
        • Choose Protocol from dropdown
        • Enter Destination Port(s)
        • Enter Destination
        • Click Add
    • Task 7: Configure a Destination NAT (DNAT) rule.
      • Choose DNAT rules under settings
      • Select Add a rule collection
        • Enter unique name for rule collection
        • Enter priority value (200)
        • Choose Rule collection group from dropdown
        • Enter unique name for rule
        • Enter Source IP as wildcare (*)
        • Choose protocol from dropdown
        • Enter Destination Port
        • Enter Destination IP
        • Enter IP addr in Translated address or FQDN box
        • Enter Translated Port
        • Click Add
    • Task 8: Change the primary and secondary DNS address for the server’s network interface.
      • Navigate to created VM earlier in Azure Portal
      • Click Networking under settings
      • Click the Network Interface for the VM
      • Click DNS servers under settings
        • Toggle to Custom
        • Add Primary and Secondary DNS Server
        • Click Save
      • Restart VM
        • Overview
        • Restart
        • Yes
    • Task 9: Test the firewall.
      • Launch Remote Desktop Connection
      • Enter FW Public IP:3389
      • Connect
      • Connect
      • Enter Credentials for VM and click OK
      • Open Internet Explorer and Browse to Google
      • In dialog select OK
      • Browse to microsoft.com – blocked due to FW
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-deploy-and-configure-azure-firewall-using-the-azure-portal/

    Microsoft AZ-700: Design and Implement Azure Firewall

    Reading Time: 3 minutes

    Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 6: Design and Implement Azure Firewall

    Azure. FW is managed, cloud based security service protecting VNet resources. Fully stateful FWaaS with build-in HA and unrestricted cloud scalability.

    • Azure Firewall Features
      • Built-in HA
        • HA so no extra load balancers required or configuration needed
      • Unrestricted cloud scalability
        • Azure FW can scale out as much as needed. No need to budget for peak traffic
      • App FQDN filtering rules
        • Limit outbound HTTP/S or Azure SQL traffic to specific list of FQDNs including wildcard
        • Doesn’t require TLS term
      • Net traffic filtering rules
        • Centrally create allow/deny rules by
          • Source/Dest IP
          • Port
          • Protocol
        • Azure FW is fully stateful
        • Rules enforced and logged across multiple subscriptions and VNets
      • FQDN tags
        • Make it easy to allow well-known Azure service traffic through FW
        • Create an app rule and include Windows Update tag for example
      • Service tags
        • Represents group of IP address prefixes minimizing complexity for rule creation
        • Cannot create personal service tag or specify which IP addrs included in tag
        • MS manages prefixes by tag and auto updates as addrs change
      • Threat intelligence
        • Threat intelligence-based filtering (IDPS) possible to alert and deny traffic from/to known malicious IP/Domains
        • IP addrs/domains sources from MS Threat Intelligence feed
      • TLS inspection
        • FW can decrypt outbound traffic, process, reqncrypt and send to DST
      • Outbound SNAT support
        • All outbound VNet traffic Ips translate to Azure FW public IP (Source Network Address Translatioin (SNAT))
        • Identify and allow traffic originating from VNet to remote Inet DSTs
      • Inbound DNAT support
        • Inbound Inet traffic to FW public IP translated (Destination Network Addr Translation) filtered to. Private IP on VNet
      • Multiple public IP addrs
        • Associate multiple (up to 250) with FW for specific DNAT/SNAT scenarios
      • Azure Monitor Logging
        • All events integrated to Azure Monitor
        • Allows archival of logs to storage account
        • Stream events to Event Hubs
        • Send to Azure Monitor Logs
      • Forced tunneling
        • Configure Azure FW to route all Inet bound traffic to a next hop instead of direct to Inet
        • Example to send to on-prem FW or NVA to process
      • Web categories
        • Allow or deny user access to web site categories
        • Categories included in Azure FW Standard
        • Categories more fine-tuned in Premium Preview
        • Standard matches FQDN, in Prekmium match on entire URL for HTTP or HTTP/S
      • Certs
        • Azure FW is PCI, SOC, ISO, and ICSA Labs compliant
    • Rule processing in Azure Firewall
      • In Azure FW, Possible to configure NAT rules, network rules, app rules. FW denies all traffic by default until manual rules configured to allow
    • Rule processing with classic rules
      • Rule collections are processed according to type in priority order
        • Lower numbers to higher from 100 – 65000
      • A rule collection name is only letters, numbers, underscores, period and hyphens
      • Must being with a letter or number
      • Must end with letter,number,underscore
      • Max name – 80 chars
      • Increments of 100 for priority allowing additional rules in between later
    • Rule processing with Firewall Policy
      • FW Policy, rules organized inside Rule Collections contained in Rule Collectioin Groups
      • Rule Collection types
        • DNAT
        • Network
        • Application
      • Define multiple types in single group
      • Can define zero+ rules in a collection
      • Rules in collection MUST be SAME type
      • FW Policy – rules processed on Rule Collection Group Priority
        • Number between 100 (highest) and 65000 (lowest)
        • Highest rule in group processed first
      • Application rules always processed after network rules which are always processed after DNAT rules
    • Deploying and configuring Azure FW
      • Consideration Factors
        • FW centrally create,enforce,log app/network connectivity policies across subscriptions and VNets
        • FW uses static, public IP for VNet resources
        • FW fully integrated with. Azure Monitor for log/analytics
      • Steps for deployment
        • Create resource group
        • Create VNet and subnets
        • Create workload VM in subnet
        • Deploy FW and Policy to VNet
        • Create default outbound route
        • Configure app rule
        • Configure network rule
        • Configure DNAT rule
        • Test
    Share this article:

    Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-design-and-implement-azure-firewall/

    Load more