Playing with Azure Firewall

What is Azure Firewall  – A fully stateful firewall as a service.

Before you can deploy Azure Firewall you need to register the provider in your subscription : https://docs.microsoft.com/en-us/azure/firewall/public-preview

Register-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network

Register-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

It can take up to 30 minutes for the feature registration to complete

The easy way to get going and play with Azure Firewall is to use the quickstart template https://github.com/Azure/azure-quickstart-templates/tree/master/101-azurefirewall-sandbox

I’ve used the above template to get up and running with Azure Firewall quickly, easily and so I don’t have to click around in the portal.

First up is Network Rules – the template deploys adds an example rule in which I have deleted so I can start from scratch.  At the moment I have no network rules in my firewall

netrule1

If I now try to telnet to another server of mine that has RDP open to the internet we can see the connection is not successful

telnet1

I now add a rule to my firewall:

netrule1

And now the telnet connection to 3389 to the target is successful:

telnet2

Next up is Application Rules.  Application Rules allow you to control what FQDNs can be accessed and, somewhat obviously, these rules are http and https based. Again the deployment I used created a single Application Rule which I have deleted to give me a clean slate from which to start:

apprules1

Now if I try to browse the web from my server in Azure I’m blocked.  Interestingly the message I get in the web browser depends on whether I’ve gone to a https site or http:

web1

web2

I now add a rule for http and https for *.microsoft.com

apprules2

I can now browse to Azure.microsoft.com

web3.PNG

 

To get the abilty to filter http/https traffic like this you’d have to deploy a Network Virtual Applicance (NVA) and to control what can route to where in your Azure infrastructure you’d require an NVA or something like a Linux IaaS server running iptables.

Azure firewall looks like a good solution to filtering internet traffic and for controlling routing between servers in Azure.  Compared to some NVA devices or iptables it may be more basic (at the moment) but it certainly does offer what I see a lot of people asking for.

Basic Active Directory Security

A large majority of breaches happen because of compromised credentials (https://blog.centrify.com/cause-of-data-breaches/) and so it stands to reason that a compromise of privileged credentials would be the worst case scenario. If someone gets hold of Domain Admin credentials the game is essentially over.

Because of this when I’m talking to customers about improving their security posture one of the first things I recommend is reducing the number of accounts in AD privileged groups such as Domain Admin, Enterprise Admin and Schema Admins as documented in the Best Practices for Active Directory Security.  What I often see is;

Lots of accounts in Domain Admins

IT administrators are often in Domain Admins.  Sometimes, but not always, this account is separate from their day to day ‘normal’ account.

Service accounts in Domain Admins

I often ask why so many accounts are put in these groups and the answer is usually along the lines of;

‘I need those permissions’ or ‘stuff just works when an account is in that group’.

For me one of the simplest things you can do to help reduce the attack surface of AD is to simply remove accounts from these privileged groups. Ideally the only account in there would be the built in Administrator (RID 500) account.

AD Security resources;

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory

http://adsecurity.org/

I’ll do another post soon on Group Policy settings to help secure and audit your AD and Windows environment.