Francesco Molfese presented on Azure network security best practices. He discussed how to use Azure networking services like virtual networks, network security groups, application security groups, service endpoints, Azure Firewall, and DDoS protection to implement a zero trust network model. A hub-spoke topology with services in the hub and workloads in the spokes provides segmentation and security. Monitoring, logging, and alerts from services like Network Watcher and Azure Monitor help provide visibility and protection. The presentation provided demos and recommendations on configuring these services to securely network Azure resources.
3. Who am I?
Francesco Molfese
francesco.molfese@progel.it
LinkedIn: https://www.linkedin.com/in/francescomolfese/
Twitter: @FrancescoMolf
• Senior Consultant presso Progel S.p.A.
• Microsoft MVP Cloud Datacenter Management
• Microsoft Certified Trainer (MCT)
• Community Lead dello User Group Italiano di System Center e Operations Management Suite
(http://www.ugisystemcenter.org)
5. Agenda
• Network security challenges in the cloud
• Azure Networking: which network security offering to use when
• Understand Azure network security best practice
7. What we get asked by customers around resource protection
How do I control network and application access to resources?
How do I embrace a zero trust network security model?
How do I enable DDOS protection for my application?
How do I protect my application from malicious intent?
How do I do segmentation and isolation to protect resources?
8. Azure Networking Services
CDN
Front Door
Traffic Manager
Application Gateway
Load Balancer
Virtual Network
Virtual WAN
ExpressRoute
VPN
DNS
Network Watcher
ExpressRoute Monitor
Azure Monitor
Virtual Network TAP
DDoS Protection
Firewall
Network Security Groups
Web Application Firewall
Virtual Network Endpoints
9. Virtual Networks
Your virtual private network in the cloud
• Private isolated logical network
• Supports Network ACLs and IP Management
• User defined routing for network virtual
appliances
• Extends on-premises network to the cloud
• Provides secure connectivity to Azure services
10. Hub-spoke network topology in Azure
Typical uses for this architecture include:
• Workloads deployed in different
environments (dev, testing, and
production) that require shared services
(DNS, IDS, NTP, or AD DS).
• Workloads that do not require
connectivity to each other, but require
access to shared services.
• Enterprises that require central control
over security aspects, such as a firewall in
the hub as a DMZ, and segregated
management for the workloads in each
spoke.
11. Hub-spoke benefits
• Cost savings by centralizing services that can be shared by multiple
workloads, such as network virtual appliances (NVAs) and DNS
servers, in a single location.
• Overcome subscriptions limits by peering VNets from different
subscriptions to the central hub.
• Separation of concerns between central IT (SecOps, InfraOps) and
workloads (DevOps).
13. Multiple protection services to enable rich controls
• App Gateway with Web Application Firewall (WAF): Web Application
Protection
• Network & Application Security Groups (NSG): Internal VNET
segmentation
• Service endpoints: Secure access to public PaaS resources
• Azure Firewall: Full VNET egress and ingress (non-http/s) protection
• DDoS protection for Public IPs
14. Application Access Patterns
Access private traffic
-Networksecurity groups (NSGs)
-Application security groups (ASGs)
-User-Definedroutes (UDRs)
Access to/from Internet
-DDoSprotection
-Web Application Firewall
-Azure Firewall
-NetworkVirtual Appliances
Access to Azure PaaS services
1
3
2
ServiceEndpoints
Backend
Connectivity
ExpressRoute
VPN Gateways
Users
Internet
Your Virtual Network
BackEndMid-tierFrontEnd
15. Application Gateway and web
application protection
Layer 7 load balancer for web applications
16. Application Gateway
Web application protection
• Protects your application against prevalent X-
Site Scripting and SQL Injection attacks
• Blocks threats based on top 10 OWASP (Open
Web Application Security Project) signatures
• Integrated with Azure Security Center
• Real-time logging with Azure Monitor
App
Gateway
L7 LB
WAF
• Platform managed built in high availability and scalability
• Layer 7 load balancing URL path, host based, round robin, session affinity, redirection
• Centralized SSL management SSL offload and SSL policy
• Public or ILB public internal or hybrid
• Rich diagnostics Azure monitor, Log analytics
Web Application Firewall (WAF)
18. Network and Application Security Groups
Network Security Groups
• Protects your workloads with distributed ACLs
• Simplified configuration with augmented security rules
• Enforced at every host, applied on multiple subnets
Application Security Groups
• Micro-segmentation for dynamic workloads
• Named monikers for groups of VMs
• Removes management of IP addresses
Service Tags
• Named monikers for Azure service IPs
• Many Services tagged including AzureCloud
Logging and troubleshooting
• NSG flow logs for traffic monitoring
• Integrated with Network Watcher
• JIT access policies with Azure Security Center
19. Monitoring VMs App Servers
Database Servers Log Servers
Web Servers
Domain Servers
Quarantine VMs
Domain Clients
Network Security Group (NSG)
Action Name Source Destination Port
Deny QurantineVMs Any QurantineVMs Any
Allow AllowInternetToWebServers Internet WebServers 80,443(HTTP)
Allow AllowWebToApp WebServers AppServers 443 (HTTPS)
Allow AllowAppToDb AppServers DatabaseServers 1443 (MSSQL)
Allow AllowAppToLogServers AppServers LogServers 8089
Allow AllowOnPrem
10.10.0.0/16
192.168.10.0/24
MonitoingVMs 80 (HTTP)
Deny DenyAllInbound Any Any Any
Network security for your VNet traffic
22. Service Endpoints Policies
• Prevent unauthorized access to
Azure services
• Restrict Virtual Network access to
specific Azure services
• Granular access control over
service endpoints
VNet 1 Account A
SERVICE ENDPOINT
Account B, …
Allow Account A
SERVICE ENDPOINT POLICY
Enhanced VNet security for Azure services
23. Azure services available on Service Endpoints
• Azure Storage
• Azure SQL Database
• Azure CosmosDB
• Azure Keyvault
• Azure Database services for PostgreSQL
• Azure Database services for mySQL
• Azure SQL Datawarehouse (Preview)
• Azure Event Hubs (Preview)
• Azure Service Bus (Preview)
26. Azure Firewall
Central governance of all traffic flows
• Built-in high availability and auto scale
• Network and application traffic filtering
• Centralized policy across VNets and subscriptions
Complete VNET protection
• Filter Outbound, Inbound, Spoke-Spoke & Hybrid
Connections traffic (VPN and ExpressRoute)
Centralized logging
• Archive logs to a storage account, stream events to your
Event Hub, or send them to Log Analytics or Security
Integration and Event Management (SIEM) system of choice
Cloud native stateful Firewall as a service
Spoke VNets
On-Premises
28. FQDN tags in Azure Firewall
• An FQDN tag represents a group of fully qualified domain names (FQDNs) associated with well known
Microsoft services
• FQDN tags can be used in application rules to allow the required outbound network traffic through
your firewall
• Supported tags:
• Windows Update
• Windows Diagnostics
• Microsoft Active Protection Service (MAPS)
• App Service Environment
• Azure Backup
• Some tags may require additional configuration. For example, ASE has customer-specific Storage and
SQL endpoints, which must be enabled using Service endpoints
29. Inbound traffic filtering recommendation
• Application Gateway WAF is the preferred service for inbound application level HTTP/S
protection
• Use Azure Firewall inbound network level protection for non-HTTP/S protocols (e.g. SSH, RDP,
FTP)
• Destination Network Address Translation (DNAT)
• Inbound traffic filtering is enabled by mapping of your firewall public IP and port to a private IP and port
• Known issues
• DNAT doesn’t work for port 80 and 22. These can be specified as 80, 22 as the translated ports. For example, you can map public ip:81 to private ip:80. We are working to
fix this soon.
30. Azure Firewall for hybrid links
Traffic filtering between Azure VNETs and
on-premises networks
• Works with either Azure VPN Gateway or Express
Route Gateway
No support for traffic routing from on-
premises to internet
• This is a key roadmap feature for Azure Firewall in a
Virtual WAN Hub
31. Hybrid links filtering: recommended configuration
• UDR on the spoke subnet pointing to Azure Firewall private IP as default gateway
• BGP route propagation must be Disabled on this route table
• UDR on the hub gateway subnet pointing to Azure Firewall as next hop to spoke
networks
• Pointing to Azure Firewall as the default gateway is not supported on gateway subnets
• No UDR on Azure Firewall subnet (it learns routes from BGP)
• Allow spokes to use VPN/ER gateway in the hub
• Set AllowGatewayTransit when peering VNet-Hub to VNet-Spoke
• Set UseRemoteGateways when peering VNet-Spoke to VNet-Hub
33. Azure Firewall synergies and recommendations
Application Gateway WAF
• Provides inbound protection for web applications (L7)
• Azure Firewall provides network level protection(L3) for all ports and protocols and application level
protection (L7) for outbound HTTP/S. Azure Firewall should be deployed alongside Azure WAF
• Azure Firewall can be combined with 3rd party WAF/DDoS solutions
Network Security Groups (NSG)
• NSG and Azure Firewall are complementary, with both you have defense and in-depth
• NSGs provides host based, distributed network layer traffic filtering to limit traffic to resources within virtual
networks
• Azure Firewall is a fully stateful centralized network firewall as-a-service, providing network and application
level protection across virtual networks and subscriptions
Service endpoints
• Recommended for secure access to Azure PaaS services
• Can be leveraged with Azure Firewall for central logging for all traffic by enabling service endpoints in the
Azure Firewall subnet and disabling it on the connected spoke VNETs
37. Azure DDoS Protection Standard
DDoS Attack Analytics
Mitigation Reports
• Near real time attack data snapshot
• Stats include attack vectors, protocols, traffic, top sources & ASNs and
more
• Summary report at the end of the attack
Mitigation Flow Logs
• Near real time sampled flow logs with details of action taken during
attack mitigation
• Logs include Source & Destination IP with Port and Action taken
DDoS Rapid Response (DRR)
• Access to Rapid Response team during an active attack for
specialized support
• Mitigation policy customizations for anticipated events
Recommendations in Azure Security Center to protect
Virtual Networks against DDoS attacks
Support for Azure Firewall, IPv6 Virtual Networks & VPN
Gateway as protected resources
39. Key Takeaways
• Pick network security offerings based on application access patterns
• Layer security by mix-and-match based on your requirements
• Scale the security model, as your workloads scale
40. Protection services enabling zero trust
Centralized outbound
and inbound (non-HTTP/S)
network and application
(L3-L7) filtering
Distributed inbound &
outbound network (L3-
L4) traffic filtering on
VM, Container or
subnet
Restrict access to
Azure service
resources (PaaS) to
only your Virtual
Network
Centralized inbound
web application
protection from
common exploits and
vulnerabilities
Azure FirewallDDoS
protection
Web Application
Firewall
Network Security
Groups
Service
Endpoints
DDOS protection tuned
to your application
traffic patterns
Prevent SQL injection, stop cross
site scripting and an array of other
types of attacks using cloud native
approach
Better central governance of all
traffic flows, full devops integration
using cloud native high availability
with autoscale
Full granular distributed end node
control at VM/subnet for all
network traffic flows
Extend your Virtual Network
controls to lock down Azure service
resources (PaaS) access
SegmentationApplication protection
Hyperfish intro
We are really excited to bring you something great
Founded 2015
Co-Founders Brian Cook & Chris Johnson
Brian was the founder and CEO of Workflow company Nintex,
Chris Johnson was a Group Product Management in Office 365 & SharePoint
Joining them were