Category: Security
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/
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 7: Design and Implement Private Access to Azure Services – 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
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-define-private-link-service-and-private-endpoint/
Reading Time: 3 minutes
Notes from MS Learn AZ-700 Module 7: Design and Implement Private Access to Azure Services: Unit 2: 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
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-explain-virtual-network-service-endpoints/
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
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-design-and-implement-network-security-module-resources/
Permanent link to this article: https://www.packetpilot.com/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 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
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-secure-your-networks-with-azure-firewall-manager/
Permanent link to this article: https://www.packetpilot.com/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 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
- 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
Permanent link to this article: https://www.packetpilot.com/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 5: Deploy Network Security Groups by Using the Azure Portal
NSG in Azure allows filtering network traffic to/from Azure resources in a VNet. NSG contains security rules to allow/deny inbound traffic to, or outbound from several types of resources. Each rule specifies source/destination, port, protocol.
- NSG Security Rules
- NSG contains zero, or as many rules as you want, within subscription Limits
- Each rule has a series of properties
- Name
- Must be unique within NSG
- Priority
- Number between 100-4096
- Processed in order with lower number handled first
- Once traffic matches rule processing stops
- SRC or DST
- Can be set to
- Any
- Individual IP
- CIDR block
- Service tag
- App security group
- Protocol
- Direction
- Port Range
- Individual Port
- Range of Ports
- Action
- FW evaluates rules using source, source port, dest, dest port, protocol
- Default security rules
- (Table below from MS Learn)
- Deployment scenario examples based on diagram below (Diagram from MS Learn)
-

- For inbound traffic Azure processes rules in NSG associated to subnet first (if exists), and then rules in NSG associated to interface (if exists)
- VM1
- Subnet1 associated with NSG1
- Security rules are processed
- VM1 is in Subnet1
- Unless rule created that allows port 80 in, the DenyAllInbound default rule denies the traffic
- In this case never evaluated by NSG2 as it’s associated to network interface
- If NSG1 has rule allowing port 80, NSG2 then processes traffic
- To allow port 80 to VM both NSG1 and NSG2 must have rule that llows port 80 from inet
- VM2
- NSG1 rule processed because VM2 in Subnet 1
- Since VM2 has no NSG associated with interface all traffic received through NSG1 or denied all traffic by NSG1
- Traffic either allowed or denied to all resources in same subnet when NSG is associated with subnet
- VM3
- No NSG associated with Subnet2 – traffic allowed into subnet and processed by NSG2 as it’s associated to interface attached to VM3
- VM4
- Traffic allowed to VM4 since NSG isn’t associated to Subnet3 or interface of virtual machine
- All traffic allowed through a subnet & interface if they doesn’t have NSG associated
- For outbound traffic Azure processes rules in NSG associated with interface first then subnet (if there is one in both cases)
- VM1
- Security rules in NSG2 processed Unless security rule denying port 80 out to internet, then the AllowInternetOutbound default rule allows traffic in both NSG1 and 2
- If NSG2 has rule denying port 80 traffic is denied and NSG1 never evaluates
- To deny port 80 from VM either/or both of NSGs must have rule denying 80 or internet
- VM2
- All traffic sent through interface to subnet since interface is attached to VM2 doesn’t have NSG associated
- NSG1 rules are processed
- VM3
- If NSG2 has rule denying 80 traffic denied
- If NSG2 has rule allowing port 80 allowed out to internet since NSG isn’t associated to Subnet2
- VM4
- All traffic allowed from because NSG isn’t associated to network interface on VM or Subnet3
- Application Security Groups
- ASG enables configuration of network security as natural extension to apps structure
- Allows grouping VMs and defining network security policy on these groups
- Can reuse security policy at scale without manual maintenance of IP addresses
- Platform handles complexity of IP addresses and multi rule sets
- Create rules using service tags/ASG’s and avoid rules with individual Ips or ranges to minimize security rules needed
- Filter network traffic with an NSG using Azure Portal
- Use NSG to filter Rx/Tx from VNet
- NSG contain security rules filtering traffic by IP, port, protocol and are applied to resources in a subnet
- Key stages to filter traffic with NSG
- Create Resource Group
- Create VNet
- Create App Security Groups
- Create Network Security Groups
- Associate NSG with subnet
- Create security rules
- Associate NICs to an ASG
- Test filters
- More detailed steps see MS Learn site: Tutorial: Filter network traffic with a network security group using the Azure portal
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-deploy-network-security-groups-by-using-the-azure-portal/
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 6: Design and implement network security – Unit 4: Exercise – Configure DDoS Protection on a Virtual Network Using the Azure Portal
Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)
- Task 1: Create a DDoS Protection plan.
- Search and click DDoS Protection Plans in Azure Portal
- Click Create
- Select or Create New Resource Group (create new in this example)
- Enter unique name and click OK
- Enter unique name under Instance Details
- Choose Region from dropdown
- Click Review + Create
- Once Validated click Create
- Task 2: Enable DDoS Protection on a new virtual network.
- Search and click Virtual Networks in Azure Portal
- Click Create
- Choose Resource Group from dropdown
- Enter unique Name under Instance details
- Choose Next : IP Addresses >
- Choose Next : Security >
- Toggle DDoS Network Protection to Enable
- Choose DDoS Protection Plan created earlier from dropdown
- Select Review + Create
- Once validated select Create
- Task 3: Configure DDoS telemetry.
- Search and click Public IP Addresses in Azure Portal
- Click Create
- Enter unique name
- Enter DNS Name Label
- Choose Resource Group from dropdown
- Click Create
- Search for DDoS protection plan created earlier
- Choose Metrics under Monitoring
- Set Scope to MyPublicIPAddress
- Click Apply
- Set Metrick from dropdown
- Task 4: Configure DDoS diagnostic logs.
- Search and select my public IP address
- Choose Diagnostic settings under Monitoring
- Select Add diagnostic setting
- Check all 3 boxes under Categories
- Check AllMetrics box under metrics
- Check send to Log Analytics workspace box
- Task 5: Configure DDoS alerts.
- Search and navigate to Virtual Machines in Portal
- Click Create > Azure Virtual Machine
- Choose Resource Group from dropdown
- Provide Virtual Machine Name
- Choose Review + Create
- Once Validated click Create
- Click Download private key and create resource in Generate new key pair dialog
- Click Go to resource
- Click Networking under settings
- Click link next to Network Interface
- Select IP configurations under settings
- Chose ipconfig1
- Under Public IP address choose MyPublicIPAddress
- Click Save
- Navigate to DDoS protection plans in Azure Portal
- Choose MyDDoSProtectionPlan as created earlier
- Click Alerts under monitoring
- Click Create > Alert Rule
- Delete existing resource
- Click Select Scope
- Under Filter by resource choose search for and choose Public IP Addresses from the dropdown
- Choose MyPublicIPAddress as created earlier
- Click Done
- Choose Next : Condition >
- Choose Under DDoS attack or not
- Select Maximum under Aggregation type dropdown
- Select Greater than or equal too under Operator dropdown
- Enter Threshold value (1 in this example)
- Select Next: Actions >
- Select Next : Details >
- Enter Alert rule name
- Choose Review + create
- Click Create
- Task 6: Monitor a DDoS test attack.
- Search Public IP Addresses in Azure Portal and on page click MyPublicIPAddress as created above
- Copy the IP Address
- Click Metrics under Monitoring section in left panel
- In the Metric dropdown choose Under DDoS attack or not
- Value changes from 0 to 1 if under attack
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-configure-ddos-protection-on-a-virtual-network-using-the-azure-portal/
Load more