Category: Quick Post

Creating a secure Home/Guest/IOT Wifi environment with Ubiquiti

As many of my friends and colleagues will know, I am a big fan of Smart Home/IOT technology – plugs, lights, sensors, cameras… I like automating things around the house – partly for security reasons, partly for reasons of making my life easier, but mostly because I enjoy working with technology! 🙂

However, I am well aware of the security implications of Smart Technology – and in particular the risks associated with placing devices onto a home network, where devices with personal information are regularly used.

In this post I’ll give an overview of how I am securing my network – with minimal effort… (All of this can be configured in under 10 minutes)

I’m using the awesome Ubiquiti Unifi nanoHD APs:

Ubiquiti equipment and software is AWESOME, especially if you want effective and easy to use control over your network, without having to use complex configuration scripts or a confusing GUI. There are a few things you can do to secure Smart Technology items, and also to create a secure environment for Guest Users, Children, and anyone/anything else you may wish to restrict in some way. The key features that help here are:

  • Separate Wireless Networks – I have a Wireless Network setup for my own devices, another for Smart Tech items, and another for Guest Users – these are best off separated and kept apart! (These are all broadcast from the same AP too – with no need for extra hardware)
  • Time based Wireless Network access – this is more for those with children, whereby you can have a Wireless Network that is available only between certain times.
  • Throughput Control – this allows a Network to be restricted to a specified total bandwidth throughput. Useful for ensuring one device/user/network does not overload your internet connection
  • IP range restrictions – this allows devices on specific Networks to be restricted when trying to access certain IP ranges or addresses. This is great for Guest networks – and can be used to ensure those Guest users can only access the internet for example. Many Smart Tech devices also require only internet access, with no need for them to communicate with other items on your network.

Configuration of all of the above is extremely simply using the Ubiquiti Controller – I’m running this on my own server, but the Cloud Keys are worth a look if you don’t have this option or want a dedicated device. Thankfully all of the above is just a few clicks in the Controller interface too – no need for any configuration, cabling, or code!

Separate SSIDs

This is very easy to setup – from the settings interface, browse to Wifi Networks, and then create the networks you require:

Ensure that for any IOT or Guest Networks you mark these as Guest Networks – as the security restrictions (IP based) then apply:

Time based SSID access

Again, this is a breeze to setup – on the SSID you want to restrict select, Edit (shown below):

You can then control the time on a schedule:

This setting is probably more for those with children who’s access they are trying to limit – unless you have devices you don’t want online at certain times.

Throughput Control

Throughput control is based on creating User Groups – with a throughput limit assigned to the Group. I have the following Groups setup:

Personally I think I am quite generous with my Guest users…

Next – we need to associate the Groups with a Wireless Network, so that the bandwidth restrictions are applied to that Network. To do this, go back and edit the Wireless Network:

Within the User Group section – select the required Group:

Now your Wireless Network has a configured throughput limit!

IP Restrictions

These are also very easy to setup, browse to the Guest Control section of the Settings Menu – and then add any IP ranges or addresses you want to prevent Guest Users (any Wireless Network marked as Guest) accessing:

I’ve left this default – any private address is restricted – so my Guest Users and IOT Devices can only access the internet, and are prevented from accessing anything else on my networks.

Hope this helps – until next time!

Microsoft Flow, Microsoft Forms and Azure AD – what can we do?

Recently, I have been playing around more and more with Microsoft Flow – which is a tool designed to Automate processes and tasks. In a previous post I used a tool called Stringify to automate a number of Smart Home actions. Microsoft Flow provides a similar environment and allows integration between processes and tasks.

I was impressed from the first time I played with Microsoft Flow at how powerful the tool could be – and immediately set to work creating a simple flow, which I am going to demonstrate here.

Onboarding a new Azure AD User, by filling in a simple online form – the Flow will:

  1. Create the AD User Account based on the username we specify
  2. Set the users password based on a password we specify
  3. Add the user to either the “Staff” or “Student” Department
  4. Send an email notification with the account details ready for use

The key here is that this process can now be carried out, with commonality and uniformity, by someone with no technical knowledge of Azure AD at all.

To start this process – we need a Form. I’ve created a simple form in Microsoft Forms to capture all of the information above, to integrate this into Microsoff Flow. Creating forms is super simple in Microsoft Forms – I’ve created a basic new user data gathering form for our Flow below:


Now – when this form is filled in, we have the information captured that we will need for our Flow. The next step is to start building the Flow. To do this, log into Microsoft Flow and click on “Flows” and then “Create from Blank”:

Next up, we need to add a Trigger – this is an event that will cause our Flow to run. In our case – it will be when a new submission to our Form is received. Just search for Forms and then you’ll see the options required:

When we have selected “When a new response is submitted”, we then see the first step in our Flow has been added:

We need to tell Flow which Form to use now – because I am signed into my Microsoft Account, any forms I have in my account are shown in the drop down list:

Now we have our trigger, we need an action to follow – in this case, we need to get the Form response details. Do do this, just click on “New Step” (shown above) and then search for Forms:

You’ll see now that we need to select our Form again, so that the correct Form is associated with this step in the Flow:

When we add this Form you’ll notice we also have to specify a “Response Id”. In our case, this needs to be Dynamic Content – so that each response is processed by our Flow. When we click into the Response Id area – a new Window will open where we can select Dynamic Content, and then click “See more” – we can then select “List of response notifications…”:

Upon selecting this – Flow will recognize that we want to carry out an action for each response we get – and an “Apply to each” section will be automatically created:

Now we can start creating the Azure AD elements of our Flow, to do this, click on “Add an action” above, and then search for “Azure AD” – we will start by creating the user:

Once this element has been added we can start adding Dynamic Content from our Form to the new user section of the Flow – you’ll notice that when you click into areas that support Dynamic Content, the Dynamic Content window will show as below:

Once completed, we have the following in place for our user creation step:

Next I am going to configure a simple email notification – to let me know what’s been created. We can do this with the “Add an action” option, and then search for “email”:

We can then use Dynamic Content, as we did before, to create an email based on the response to our Form:

Important: Obviously using this method is bad security practice (username and password in the same email) – and in this case is used just to give an idea of the capabilities of the Flow. In production use, using something like the Office 365 “Send an Email” is better – as this supports sending to different addresses, so for example, the username and password can be sent to different lists or addresses. For example, the username to the new user, and the password to the manager (without the username).

Finally – we can test our Flow. To do this, it’s just a case of filling in the Form created earlier:

We can check that our Flow has run from the Flow web interface:

And also – drill down into exactly what was run by clicking on the “Succeeded” (or Failed) in Run History – below you can see some of the variables my Form data contained:

The next step is to check that an Azure AD user has actually been created:

Bingo – everything looking good here… and below we have the user with the details from our Form correctly filled in:

Finally – we can check to confirm we have been emailed the confirmation message with the details of the user account:

As you can see – the Flow has worked as expected, and we now have an Azure AD Account and email notification to go with it. Whilst this is really just scratching the surface of what we can do here – it gives an idea of where we could take this type of automation. A few things I can immediately think of for this type of new user scenario:

  • Add to numerous AD Groups – based on checkboxes in a form
  • Create an O365 Mailbox – based on username/names
  • Provide a welcome email to the mailbox
  • Notify a Slack or Teams channel that a new user has been created, for example “Please welcome [Username] to the department!”
  • Interact with one of the many 3rd party systems supported in Flow – for example adding the user to a CRM system, or SAAS application

Hopefully this has been interesting – and congrats for making it to the end of this post!

Testing out the Azure Firewall Preview

Azure Firewall was released for preview this week, so I thought I would give it a quick try and look at some of the features available. The firewall provides the following features at the current time:

  • Built-in high availability – built into the Azure Platform, so no requirement to create load balanced configurations
  • Unrestricted cloud scalability – the firewall can scale to meet your requirements and meet changing traffic demands
  • FQDN filtering – outbound HTTP/S traffic can be filtered on a specific set of domain names without requiring SSL termination
  • Network traffic filtering rules – centrally create allow or deny network filtering rules, based on IP, port, and protocol. Azure Firewall is fully stateful, and rules can be enforced and logged across multiple subscriptions and VNETs.
  • Outbound SNAT support – outbound virtual network traffic IP addresses are translated to the Azure Firewall Public IP so you can identify and allow VNET traffic to remote Internet Destinations
  • Azure Monitor logging –  All Firewall events are integrated with Azure Monitor. This allows archiving of logs to a storage account, streaming to Event Hub, or sending them to Log Analytics.

You can read more about the features here: https://docs.microsoft.com/en-us/azure/firewall/overview

Getting access to the Azure Firewall is easy – it’s built directly into the VNET Configuration window:

However, before we can use this, we need to enable the Public Preview for our Subscription with a few PowerShell commands:

Connect-AzureRmAccount
Register-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network
Register-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

You’ll need to wait upto 30 minutes at this point for the request to be enabled – see https://docs.microsoft.com/en-us/azure/firewall/public-preview for further information. You can run the following commands to check the status:

Get-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network
Get-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

If all is well – it should look like this:

Finally, run the following command to complete the setup:

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

Before we can add a Firewall to a VNET, we need to create a subnet called “AzureFirewallSubnet” – this is to allow the firewall to communicate with addresses on the VNET. Once this is completed, we can setup the Firewall. This is just a case of filling in some basic details:

Once we have completed the basic details, we can review and complete the deployment:

Now that the Firewall is created, we are ready to start testing. In order to test the Firewall out, we need a subnet that is routed out via this Firewall. To do this, I used a route table that directs traffic to the Firewall IP:

We now have a Subnet within our VNET that is routed via the Azure Firewall – so now we can test out some rules. My lab environment is now setup as below (Note the jump VM in a separate Subnet that is NOT routed to the Firewall. This is to allow me to RDP to the test box as I have no VPN in place to test from etc.):

From the Test VM, internet access is now blocked – because there is no firewall rule in place to allow it. I am going to add an “Application Rule collection” which I will use to allow HTTPS access to jakewalsh.co.uk, but not HTTP access. This is configured from the Firewall management interface via the Azure Portal:

Then you will be presented with the following window:

Once I have clicked on “Add” the rule will be added to the Azure Firewall. From my test VM, access to https://jakewalsh.co.uk works, but note that HTTP does not:

HTTPS:

HTTP:

The same also works in reverse, so we can selectively block HTTP or HTTPS sites as we require.

As well as the Application Rules we can deploy, we can also create more traditional firewall rules (replace 0.0.0.0):

Overall, the Azure Firewall complements and extends the functionality of Network security groups and gives additional control over networks residing within Azure. The rules are simple to adjust and easy to work with. It will be promising to see how this feature develops over the coming months…