Azure Firewall demo enables you quickly deploy following environment:
These demo repo is closely related to JanneMattila/azure-firewall-and-network-testing which is test bed for validating your firewall rules to match the networking requirements of different Azure services.
- Quickly deploy Azure Firewall environment
- Initial deployment ~30-40 minutes and incremental deployments ~15-20 minutes
- You can deploy multiple ones to separate resource groups
.\deploy.ps1 -ResourceGroupName "rg-azure-firewall-demo1"
.\deploy.ps1 -ResourceGroupName "rg-azure-firewall-demo2"
- Learn how to structure firewall rules (and rule collection groups and policies)
- Quickly test your firewall configuration with deployed helper apps
- Provide ideas, how can you split responsibilities of firewall management
- Centralized team to manage higher level rules e.g.,
Common
,VNET
andOn-premises
- Enable other people to participate e.g., update
Spoke-specific
rules - Normal development practices apply (pull request, code review, automated deployments, etc.)
- Configuration is stored in git and deployed using service principal
- End users don't need to have
Contributor
access to actual Azure Firewall resource
- Centralized team to manage higher level rules e.g.,
- Separating solution into multiple resource groups
- As in any normal Enterprise environment
- On-premises connectivity deployment
To optimize costs some resource pricing tier decisions has been made:
- VPN Gateway is
Generation1
andVpnGw1AZ
- Jumpbox Ubuntu VM
Standard_B2s
- Estimated cost of demo environment:
< 20 EUR, < 20 USD per work day
Azure infrastructure resources have been divided into following feature folders:
.
├───firewall
│ └───rulecollectiongroups
│ ├───1-common
│ ├───2-hub
│ ├───3-vnet
│ ├───4-on-premises
│ └───5-spoke
└───infrastructure
├───hub
└───spoke
infrastructure
folder contains deployment of virtual networks, subnets, virtual network peering,
route tables, network security groups and sample test workload.
firewall
folder contains deployment of Azure firewall.
rulecollectiongroups
folder contains split of different firewall rules so that they would
be easier to manage:
1-common
contains common critical rules, such as Windows Update etc.2-hub
contains allhub
specific rules3-vnet
containsvnet-to-vnet
andvnet-to-internet
rules4-on-premises
contains rules specific to on-premises network connectivity5-spoke
contains rules that you need to implement as spoke specific
Centralized firewall team would maintain these rules:
1-common
2-hub
3-vnet
4-on-premises
Spoke teams can request firewall team to implement or they can implement their required changes under this path:
5-spoke
Note: It does not matter who changes the rules, pull request, code review and deployment automation still applies. No rule maintenance in portal should be done.
Note: Spoke subnets have Network Security Groups (NSGs) deployed with Allow
rule.
You can also change them to test different scenarios.
In order to test firewall setup, all spokes have webapp-network-tester deployed.
It enables you to execute paths of HTTP GET
or HTTP POST
requests (and other commands as well).
Example: Post command to spoke001
to then further post command to spoke002
.
Using this method you can test if your rules work as expected.
Here is diagram that illustrates the testing flow using webapp-network-tester
in our demo architecture:
If we look that same in sequence diagrams, we can see the overall process like this:
And then the end-to-end test scenario like this:
- Internet access via firewall
www.microsoft.com
is allowed
- All traffic is routed to firewall
- Internet access via firewall
github.com
bing.com
learn.microsoft.com
- VNet accesses
- Full access to spoke002
- Http (port 80) access to spoke003
- On-premises network access
- All traffic is routed to firewall
- Internet access via firewall
github.com
- VNet accesses
- Full access to spoke001
- No access to spoke003
- No on-premises network access
- Traffic targeted to spoke001 address space is routed to firewall
- Internet access via direct routing to internet
- No VNet network accesses
- No allow firewall rules defined
- No on-premises network access
- Clone this repository to your own machine.
- If you decide to download this as zip instead, then remember to
Unblock file
before extracting the content. Otherwise you might getRun only scripts that you trust. While scripts from the internet can be useful,this script can potentially harm your computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning message
error. See also Unblock-File for more details.
- Update Azure
Az
PowerShell module (instructions) - Install Bicep
- Open run.ps1 to walk through steps to deploy this demo environment
- Execute different script steps one-by-one (hint: use shift-enter)
Here are few tasks that you can try yourself:
Hint to get you started...
Open infrastructure/deploy.bicep
and look for spokes
array and
see how it's used.
Hint to get you started...
Open firewall/3-vnet/deploy.bicep
and look for Allow-VNET-To-Internet-Application-Rules
rule collection. It already contains rule for github.com
as example.
- ACI communicating with
wwww.bing.com
running insidespoke001
vnet
Hint to get you started...
Use IP address of ACI 10.1.0.4
and then target address in your AZFWApplicationRule
query.
Solution
Here is example query using resource specific AZFWApplicationRule table:
AZFWApplicationRule
| where SourceIp == "10.1.0.4" and Fqdn == "www.bing.com"
Here is example query using the older AzureDiagnostics
table:
AzureDiagnostics
| where Category <> "AzureFirewallDnsProxy"
| where OperationName == "AzureFirewallApplicationRuleLog"
| where msg_s contains "www.bing.com:443." and msg_s contains "10.1.0.4"
| project TimeGenerated, msg_s
- Look up (at least some) network IP ranges e.g., spoke vnet address spaces
and pass them to firewall deployment as parameters
- You wouldn't need to use hardcoded IP addresses
- You can use e.g., resource graph queries to list all spokes etc.
- See scan-spokes.ps1 for example queries
bicep/docs/examples/301/modules-vwan-to-vnet-s2s-with-fw/ example templates.
Azure Firewall DevSecOps in Azure DevOps is great blog post and was one inspiration to built this demo.
Strong typing for parameters and outputs would
further improve way how ruleCollections
are passed on to the ruleCollectionGroups
.