LINICKX.com

DNSCrypt Proxy on Home Assistant

Nick Bettison — Sat, 27 Sep 2025 12:08:00 +0100

I have published a Home Assistant Addon for DNSCrypt Proxy.

TLDR:

In the HA Addon-store add my repository 👉🏻 https://github.com/linickx/ha-addons

Install DNSCrypt Proxy (and Start the addon)

Edit /addon_configs/ba53f40c-dnscrypt-proxy/dnscrypt-proxy.toml to suit your needs (restart addon to take effect)

Profit?!

What is DNSCrypt Proxy?

By default DNS traffic (TCP & UDP 53) is not encrypted, i.e. visible to snoopers; not all devices, especially IoT devices support modern encrypted DNS protocols like DoH or DoT so DNSCrypt Proxy is a way of securing DNS for those devices -- they send clear text DNS to the proxy, it encrypts the traffic up to your chosen DNS provider.

Why DNSCrypt Proxy?

This is choice depending on your security preferences/requirements, do you need or want encrypted DNS? Generally encrypting as much of your traffic as you can is a good thing, but if you don't agree that's ok:

How to install DNSCrypt Proxy.

DNSCrypt Proxy is presented as an addon, which are Home Assistant containers, get 3rd party addons you first have to setup a repository,

Step 1 - My Addon Repository

Within Home Assistant, perform the following:

Settings -> Add-ons -> ADD-ON STORE
In the top right 3x Dots, select Repositories
Add https://github.com/linickx/ha-addons

... Using the same top right 3x Dots, click check for updates. It also doesn't hurt to refresh your browser.

Step 2 - Install

With a little luck, now in Home Assistant under Settings -> Add-ons -> ADD-ON STORE, if you scroll to the bottom you should see this:

✨ Click it! ✨

Then, click Install, and once it's installed, click Start.

How to configure DNSCrypt Proxy.

DNSCrypt configuration is a .toml file; the easiest way to edit it in Home Assistant is with the VSCode Add-on, if your a terminal ninja use Vi in SSH.

Edit 👉🏻 /addon_configs/ba53f40c-dnscrypt-proxy/dnscrypt-proxy.toml

File Path Warning!

The DNSCrypt proxy runs as a container, the path you edit (from VSCode/SSH) is different to what the container sees, i.e.

/addon_configs/ba53f40c-dnscrypt-proxy/dnscrypt-proxy.toml == /config/dnscrypt-proxy.toml

So, if you need to include any external files, such as blocklists the use the later container path of /config/

/Done!

IoT DNS Anomaly Detection with Home Detector

Nick Bettison — Sun, 05 Jan 2025 18:01:00 +0000

After implementing an Open-Canary based home honeypot in part 1, for my research project I moved onto implementing a DNS based anomaly detection intrusion detection system ... try saying that 3 times fast after a few pints! 😆

📝 This post assumes that you already have Home Detector installed on your Home Assistant server.

The idea is an internal, home network honeypot would only trigger if there was already a threat on your LAN, in order to attempt to catch someone/something earlier I built a simple DNS anomaly detection engine; there's an important gotcha here, although the honeypot was low-effort-drop-in (plug-n-play), DNS inspection is a bit more technical you will need a method of updating the DNS settings on your IoTs to make this work, either by changing your DHCP setting, doing something on your router, or by touching each device (if they support custom DNS that is!).

How it works

Home Detector acts as a local DNS forwarder, point your IoT/Smart-Things at it and for 30days it'll start recording the DNS lookups. After 30days, it'll consider what it saw as the baseline and therefore anything new after that point will generate an alert.

The baseline is per IOT thing, which can be a single host IP, a range of IPs or a subnet depending on your home setup, so you're going to need the real-source-ip of your IOT thing hitting Home Assistant (The Home Detector Add-on)

Enable DNS Interception

The DNS interception is opt-in which means there's 2x steps:

Step 1

The first is point your system at it, i.e. update the DNS settings of the IOT device to have Home Assistant's IP as a DNS server.

How you do this will vary, you might be able to update your router to use Home Assistant as the DNS server for all your LAN. You might be able to change the DNS server on the IoT device it's self. Or if you cannot change DNS anywhere, disable DHCP on your router and install a DHCP server add-on and set the DNS server IP to that of Home Assistant.

Step 2

It's ok if all your DNS hits Home Detector (Home Assistant) as by default, the add-on will pass through, not touching the responses and everything should continue to work.

To enable the detection, under add-on settings, enable interception for specific IP addresses, like this:

Tweak any other settings you fancy from the Docs as necessary.

Enjoy the DNS goodness

Within the Home Detector Dashboard, there are 3x views.

(i) The Alerts

By default, Home Detector will generate dns-domain alerts, there are alarms for new domains being queried, the SOA record is used to determine domain ownership.

If you enabled Detected on Host Query then Home Detector will generate dns-query alerts, these are alarms for new host queries.

Here you can see a bunch of Amazon Alexa alerts on my console, these are new domains that the very talkative little box has started calling out to...

(ii) The DNS Domains

On the Domains page, you can review the domains that are in pass state or block state, for the first 30days (by default) all domains will be in pass, only after the baseline is created will blocks start to appear.

🔥 By Default, Block does not mean Block, it means 🚨 alarm 🚨 (perhaps not my best choice). Only if you enable the DNS Firewall under settings will the DNS be blocked, Home Detector will send NXDOMAIN (domain not found) responses.

This is what my domains page looks like, the first range for ntp.org is for my shelly devices, the next 5x are for my heating/themostat, and then the bottom ranges are for alexa's... as you can see there's 135 row, quite a lot of learnt traffic in my LAN.... and this is JUST the IoT devices, Phones/Laptops/etcs do not log here and in my documentation I warn against doing that 😬

(iii) The Queries

Like the domains page, the queries page allows you to review all the look-ups from a device in either pass or block state.

Why am I doing this?

If you've got this far, 👍🏼 nice 👍🏼 !

The point of this is to monitor what your IoT/Smart-Things are doing, you should get an idea quickly of what is normal, and IF a device got compromised it would certainly start doing different queries, like downloading malware-firmware, or downloading scripts from compromised sites... Command-and-Control needs DNS to function.

A word of Warning

The noise from my home stuff has been low, shelly, etc have a couple of domains and everything works as expected, but with 👾 Amazon Alexa devices there be monsters ahead! 👾 ... those things seem to be constantly using new hosts and new domains, it's eye-opening but also annoying, so intercept those things with care.

Next Steps

There's a fair amount of future work I'd like to look at, changing domains from pass to block by typing instead of drop-downs is quite annoying 💩 ... also, I'd like to implement some built-in signatures to assert what is normal before the learning phase is completed. Pull requests are welcome but the first thing I need to do is update all the dependencies, as since finishing the project, github's dependabot has been going mental!

Honeypot: Running Open Canary on Home Assistant

Nick Bettison — Wed, 01 Jan 2025 12:43:00 +0000

This project, 🎉 Home Detector 🎉 , started life as an academic project and is something I hope to continue, if you're interested in some home intrusion detection, read-on!

Some Background & Context

In my 40s, I have decided to go back to school and for my MSc final thesis I researched intrusion detection for home networks 😱 . The lens was simple do we know if our home LAN/Wi-Fi is under attack, does your Dad, Nan, Uncle or Aunt... even as a nerd reading this blog, do you have any intrusion detection at home?! (Hint: I didn't!)

It turns out, intrusion detection at home is hard, sure you can install HIDS (Host Intrusion Detection Systems) on your Laptop/PC but what about your phone, table or internet-enabled-fridge! 🤔

The last-one is the kicker, as a Home Assistant fan, I've got more and more smart-home, IoT stuff, how would I detect Mira-worm style compromise? ... do I even know what my IoT stuff is doing when I'm not looking?! NIDS (Network Intrusion Detection Systems) of course are an answer but not that practical, do you have a pinch-point to inspect/tap... what about networks with all-in-one Wi-Fi+Router, how do you inspect that?

In my paper, I proposed 2x solutions, this is Part 1 - A Honeypot.

A honeypot is know as Intrusion Detection via Deception, that is you place a juicy target on your network to draw attention away from your real stuff, when the threat actor trips the alarm you know about it; of course the threat actor is already on a device, but this is the point, how would you know? The honeypot approach is a something-is-better-than-nothing approach, if your CCTV is compromised, and the threat is looking for another device and they fire your honeypot you have an alarm to respond to. 🚨

Installing my Home Detector Add-On

I've wrapped up Open Canary into a Home Assistant Add-on, so installation is easy:

1. Install my Add-on Repository

To get my add-on, you can either click this link to add my repository or follow these manual steps:

Click Settings,
Click Add-ons,
Click Add-On Store,
Click The three dots in the top-right,
Click Repositories,
Type in: https://github.com/linickx/ha-addons and Click Add
Click The three dots in the top-right,
Click Check for Updates
Refresh the page a couple of times

2. Install Home Detector

Once you've got the repo' setup, scroll down to the bottom and install Home Detector.

Make sure the add-on is started & you're done.

Look Ma! I'm running a Telnet Honey Pot

With no config, and just a running add-on you have a Telnet honeypot. If you try to connect (& fail auth) you'll get a pop-up notification in Home Assistant.

And an entry in the Home Detector dashboard.

If you have SSH running, telnet will look like a weaker target for anyone running a sneaky port-scan on your LAN.

Enabling the HTTP (NAS Like) Honeypot

If you want to step-up, you can enable The HTTP honeypot which presents a NAS like log-in page.

Enabling is simply opening the port and re-starting the add-on!

To enable the port, within Home Assistant go to Settings -> Add-Ons -> Home Detector -> Configuration , scroll to the bottom to Network and toggle Show disabled ports, then type in 80 where it says HoneyPot (Fake) WebServer Port.

The cyber-kill-chain

At this point, it's important to remember the modus operandi of a threat actor. The first step is always some kind of reconnaissance even after compromise, there's usually another round of reconnaissance to pivot and further secure the footing, so if your CCTV is compromised, the default port-scan of home assistant (without SSH by default) doesn't look that interesting, the default admin port (8123) is above nmap's default range, by enabling the Telnet (& HTTP) honeypot, these interesting ports will appear in a default nmap, so the likelihood of detection increases and therefore the opportunity to kill the threat actors chain of actions.

Contributing

Open Canary has ✨ loads ✨ of features & customisation, none of which have been implemented here yet, but I would certainly love to implement some more features... top of my list, custom Web Theme for the HTTP Honeypot, pull requests welcome, I am only just about ready to start accepting merges, I had to wait for marking of my paper to be completed and 😊

Coming up in Part 2...

For my paper I moved onto DNS anomaly detection, as a way of detecting compromised IoT earlier than a threat actor trying to pivot, please take a look 👉🏻 HERE 👈🏼 if you're interested in home cyber security.

UniFi, OpenWRT, freeRADIUS: Mac Address Dynamic VLAN Assignment for WPA2-PSK

Nick Bettison — Sun, 07 May 2023 17:55:00 +0100

This is much simpler than I imagined...

Scenario

For my home Wi-Fi, I want a single SSID but I want to place devices (Such as IOT) into different VLANs, but since this is personal use I don't want the headache of certificates that comes with 802.1x / WPA-Enterprise, thus want to keep the simplicity of passwords (WPA2-PSK).

UniFi APs support Dynamic VLAN Assignment, but it wasn't obvious what needs to be done on the RADIUS side... well, it'd be simple for Cisco's ISE but I don't have that at home, so freeadius it is 😜

In this solution there's two key things:

MAC Authorization isn't a security feature; it's more of a convenience feature, Windows & Linux easily allow changing the MAC address of a network card
The config below has a default allow that is unknown Mac addresses are permitted

The idea is, I have one SSID for all my devices, new devices "just work" and they can be moved around afterwards. The security of the SSID hasn't changed the strength of the PSK is the key.

The example below assumes you have a working Wi-Fi, with working VLANs and a working firewall/router to connect them together, we start with installing freeradius onto OpenWRT.

Install Freeradius

On your OpenWRT box, install the default packages...

opkg update && opkg install freeradius3-default freeradius3-utils

Now, if you want to be fancy and install just the bare minimum you only need the below packages, this will exclude all the EAP stuff, but you'll have to hack about with the default site and config files to get the service to start properly... you've been warned!

freeradius3 freeradius3-common freeradius3-mod-always freeradius3-mod-attr-filter freeradius3-mod-chap freeradius3-mod-detail freeradius3-mod-exec freeradius3-mod-expiration freeradius3-mod-files freeradius3-mod-logintime freeradius3-mod-pap freeradius3-mod-preprocess freeradius3-utils

Edit Config files

The first step is to define your RADIUS Clients, the things that send authentication requests. The file you need to edit is /etc/freeradius3/clients.conf; the RADIUS packets come directly from the Access-Point so you can either add them one at a time, or add a subnet like this:

Place at the bottom of the file.

client vlan1 {
        ipaddr = 192.168.1.0/24
        secret = correcthorsebatterystaple
}

Now, add the WI-FI Clients to /etc/freeradius3/mods-config/files/authorize

Place at the top of the file.

de:ad:be:ef:00:01       Cleartext-Password := "de:ad:be:ef:00:01"
                        Tunnel-Type = VLAN,
                        Tunnel-Medium-Type = 6,                         
                        Tunnel-Private-Group-Id = 2

DEFAULT                 Auth-Type := Accept
                        Tunnel-Type = VLAN,
                        Tunnel-Medium-Type = 6,
                        Tunnel-Private-Group-Id = 1

Where de:ad:be:ef:00:01 is the MAC Address of the device, such as your phone or notebook and Tunnel-Private-Group-Id = 2 places the device into VLAN 2. This example places all unknown MAC addresses into VLAN 1

Testing & Logging

With the config files changed, I recommend you stop the radius service : /etc/init.d/radiusd stop and then start freeradius in debug mode: radiusd -X

In debug mode, you'll need to keep your SSH open but you'll see the authentication requests on the screen, if you've made any mistakes it's easier to spot this way.

After testing is complete, you can run /etc/init.d/radiusd start to run it as a background service.

While you are running radiusd -X no logs are produced, the output is to the screen; by default when you re-enable the service the logs will output to disk: /var/log/radius.log. If you want to see the logs in luci then, edit /etc/freeradius3/radiusd.conf change destination = files ➡️ destination = syslog you may also want to set auth = yes so that you see both failed & passed authentications.

UniFi update the SSID

Before changing the SSID, a RADIUS server needs to be defined under Settings > Profiles > RADIUS . The secret is the same secret which was defined above in clients.conf; the IP address is that of your OpenWRT box. Account is optional, enable if logging disconnect events is important to you.

Finally edit your SSID under Settings > Wireless Networks , scroll to the bottom and enable RADIUS MAC Auth, selecting the profile you just created.

If you have freeradius running in debug mode you'll see events when devices try to connect!

/End

Adding new devices is as simple as putting entries into the authorize file with your desired VLAN.

References:

https://openwrt.org/docs/guide-user/network/wifi/freeradius
https://neilzone.co.uk/2021/09/using-freeradius-to-assign-vlans-for-unifi-wi-fi
https://help.ui.com/hc/en-us/articles/360015268353-UniFi-Gateway-Configuring-RADIUS-Server

Ansible: Let's Encrypt's Certbot with Cloudflare DNS Challenge

Nick Bettison — Sat, 15 May 2021 17:25:00 +0100

There's quite a few options/roles in ansible-galaxy or github to generate a Let's Encrypt Certificate, before running a random role it's good practice to review the tasks to get an idea of what it's doing. Jeff Geerling is a very reputable source for ansible roles however his certbot role by default is for Internet facing systems, that is a server that can directly respond to a either a standalone challenge or apache/nginx with .well-known setup correctly.

A DNS challenge allows Certbot to issue a cert from behind a firewall, like at home, without creating any DMZ or port-forwarding; after reviewing a few roles on offer to do this with ansible I realized it's actually quite straightforward!

To start with, use ansible-galaxy to install geerlingguy.certbot:

$ ansible-galaxy install geerlingguy.certbot

Now the plan here is to make your system / playbook require the role, but not issue the certificate as part of the role, instead issue the cert as a follow up task. Here's the initial playbook:

---
- hosts: internal_servers
  become: true
  #check_mode: yes

  vars:
    certbot_auto_renew: true
    certbot_auto_renew_user: root
    certbot_email: "certbot-notifications@something.com"
    certbot_cloudflare_api_token: 'xxxxx'

  roles:
  - geerlingguy.certbot

  tasks:
  - name: Install Certbot Cloudflare
    package: 
        name: python3-certbot-dns-cloudflare
        state: present

  - name: Create Certbot folder - /etc/letsencrypt
    file:
      path: /etc/letsencrypt
      state: directory
      owner: root
      group: root
      mode: 0700

  - name: Certbot Template
    template:
      src: "{{ item.src }}"
      dest: "{{ item.dest }}"
      owner: root
      group: root
      mode: 0600
    with_items:
      - { src: 'dnscloudflare.ini.j2', dest: '/etc/letsencrypt/dnscloudflare.ini' }

  - name: Certbot | Generate Certificate
    command: certbot certonly --non-interactive --agree-tos --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/dnscloudflare.ini -m {{certbot_email}} -d {{ansible_host}}
    args:
      creates: /etc/letsencrypt/renewal/{{ansible_host}}.conf

What's gonna happen here is geerlingguy.certbot will install the certbot package and setup the renewal cron task... and that's it. Once the role is done, it'll move into our tasks, so let's step thru those:

1. Install Certbot Cloudflare

Cloudflare support in Certbot is an optional add0on that you need to install. I'm running this on Redhat Enterprise Linux 8, for me the package for certbot-dns-cloudflare is called python3-certbot-dns-cloudflare, so if you're running this on Ubuntu/Alpine etc you will need to change that.

2/3. Create Certbot folder & Template

The certbot-dns-cloudflare plug-in needs credentials, since we haven't issued any certs the files & folders are not in place. So first ensure the folder is there and then you need a template file: dnscloudflare.ini.j2

# Cloudflare API credentials used by Certbot
dns_cloudflare_api_token = {{certbot_cloudflare_api_token}}

As above it's actually just one line, so probably could do it with line-in-file task but I like the template approach when the file is being created by me and I'm not just editing an existing file 😉

As you can see, the template simply writes your API Token in a format that the plug-in expects.

4. Generate Certificate

Finally we run the command manually in a way that calls the DNS challenge with all the information it needs. In my example, the certificate domain matches the ansible hostname but you can change that to what ever you need!

...Final thoughts & Renewal

As you can see, it was simple no need to install multiple roles/etc to achieve our goal. A quick point will be as we've issued the cert manually we might need to manage a renewal hook, on option is to drop a script in /etc/letsencrypt/renewal-hooks/post that will be run each time certbot runs, the other is a task to put a line in the file...

- name: Check Certbot File - post_hook
  lineinfile:
    dest: /etc/letsencrypt/renewal/{{ansible_host}}.conf
    line: "post_hook = /bin/systemctl restart nginx.service"
    regexp: "^post_hook ="

Enjoy!

DNSCrypt Proxy on a UniFi Cloud Key

Nick Bettison — Thu, 15 Apr 2021 14:04:00 +0100

There's quite a few posts online around setting up dnscrypt-proxy on a USG or EdgeRouter but what about a CloudKey? This post will cover some high level instructions, I'm going to assume that if the reader is willing to customise their UniFi by installing non-standard packages that they are comfortable with CLI!

I've got a cloudkey+ running firmware version 2 and after enabling SSH, /etc/debian_version shows the box is based off quite an old version of debian that doesn't ship with the latest dnscrypt-proxy packages, so this is going to take a little more than apt-get install 🙄

Before installing any non-standard packages onto any appliance you should check for conflicts, a quick netstat -nap | grep 53 will show you that systemd-resolve is already listening on UDP/53, so to start with disable that by adding DNSStubListener=no to /etc/systemd/resolved.conf

The github documentation describes how to enable the testing repo and continue the installation, however that feels like a long way off the standard, what about just downloading the single .deb file? According to uname -a the processor of the cloudkey+ is a 64bit Arm therefore the latest compatible package can be downloaded directly from here:

https://packages.debian.org/bullseye/arm64/dnscrypt-proxy/download

Copy the file (via SCP), and run dpkg -i ....

root@UniKey:~# dpkg -i dnscrypt-proxy_2.0.45+ds1-1+b1_arm64.deb 
Selecting previously unselected package dnscrypt-proxy.
(Reading database ... 35495 files and directories currently installed.)
Preparing to unpack dnscrypt-proxy_2.0.45+ds1-1+b1_arm64.deb ...
Unpacking dnscrypt-proxy (2.0.45+ds1-1+b1) ...
Setting up dnscrypt-proxy (2.0.45+ds1-1+b1) ...
Removing obsolete conffile /etc/dnscrypt-proxy/dnscrypt-proxy.conf ...
root@UniKey:~#

(Notice in my output, I had tried apt-get before realizing how old the package was!)

A quick check of the service will show it's running...

root@UniKey:~# service dnscrypt-proxy status
● dnscrypt-proxy.service - DNSCrypt client proxy
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-03-15 13:02:26 GMT; 17s ago
     Docs: https://github.com/DNSCrypt/dnscrypt-proxy/wiki
 Main PID: 18613 (dnscrypt-proxy)
   Memory: 8.0M
      CPU: 630ms
   CGroup: /system.slice/dnscrypt-proxy.service
           └─18613 /usr/sbin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [NOTICE] dnscrypt-proxy 2.0.45
Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [NOTICE] Network connectivity detected
Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [WARNING] Systemd sockets are untested and unsupported - use at your own risk
Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [NOTICE] Wiring systemd TCP socket #0, dnscrypt-proxy.socket, 127.0.2.1:53
Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [NOTICE] Wiring systemd UDP socket #1, dnscrypt-proxy.socket, 127.0.2.1:53
Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [NOTICE] Source [public-resolvers] loaded
Mar 15 13:02:26 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:26] [NOTICE] Firefox workaround initialized
Mar 15 13:02:27 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:27] [NOTICE] [cloudflare] OK (DoH) - rtt: 27ms
Mar 15 13:02:27 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:27] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 27ms)
Mar 15 13:02:27 UniKey dnscrypt-proxy[18613]: [2021-03-15 13:02:27] [NOTICE] dnscrypt-proxy is ready - live servers: 1
root@UniKey:~#

... But you'll find it's useless as by default it's only listening on localhost, that's because of Systemd.

To change the port number (or IP), you need to create /etc/systemd/system/dnscrypt-proxy.socket.d/listen.conf (the directory won't exist), as this is the place to customise systemd. The contents should be:

[Socket]
ListenStream=
ListenStream=53
ListenDatagram=
ListenDatagram=53

The line duplication above is deliberate, systemd requires you to clear any previous values with a blank entry, then you can assign a new one. If you just add "ListenStream=5454" then it will add a port, not replace one!

...restart the socket and you should be good to go!

root@UniKey:~#systemctl status dnscrypt-proxy.socket
● dnscrypt-proxy.socket - dnscrypt-proxy listening socket
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.socket; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/dnscrypt-proxy.socket.d
           └─listen.conf
   Active: active (running) since Tue 2021-04-13 12:24:34 BST; 2 days ago
     Docs: https://github.com/DNSCrypt/dnscrypt-proxy/wiki
   Listen: [::]:53 (Datagram)
   CGroup: /system.slice/dnscrypt-proxy.socket

Apr 13 12:24:34 UniKey systemd[1]: Stopping dnscrypt-proxy listening socket.
Apr 13 12:24:34 UniKey systemd[1]: dnscrypt-proxy.socket: TCP_DEFER_ACCEPT failed: Protocol not available
Apr 13 12:24:34 UniKey systemd[1]: dnscrypt-proxy.socket: TCP_NODELAY failed: Protocol not available
Apr 13 12:24:34 UniKey systemd[1]: Listening on dnscrypt-proxy listening socket.
root@UniKey:~#

Notes: *Drop-In, if you box still isn't listening on the port, check to see if your file is created/read correctly.

Resolver Lists

By default the package selects Cloudflare's public DNS. The settings are stored in /etc/dnscrypt-proxy/dnscrypt-proxy.toml, so if you don't want to use Cloudflare, for example to use Cisco Umbrella (OpenDNS) change server_names = ['cloudflare'] to server_names = ['cisco']. The full list of resolvers is on DNSCrypt's website

Logging

By default the package didn't do any logging, that's a fairly easy fix, drop the following into the config file:

log_level = 2
log_files_max_size = 10
log_files_max_age = 7
log_files_max_backups = 1

[query_log]
  file = '/var/log/dnscrypt-proxy/query.log'

[nx_log]
  file = '/var/log/dnscrypt-proxy/nx.log'

Restart the service and then you can do a tail -f /var/log/dnscrypt-proxy/query.log to validate your resolver is working, if the file doesn't get created run chown _dnscrypt-proxy /var/log/dnscrypt-proxy to correct folder permission issues.

PowerShell: A little shortcut for signing Scripts

Nick Bettison — Fri, 05 Mar 2021 15:59:00 +0000

It's good practice to sign your powershell scripts, especially in an enterprise environment with an internal CA as it allows you to quickly identify internal code and if it's been modified. I've tweeted before that the process is a little cumbersome and have been meaning to post a little tip for making it easier.

I'm going to start from the point assuming you have had the cert issued to you by your admin, and it's already installed into your personal store, so you have something like this:

PS C:\Users\nick.bettison> Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert


   PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                                Subject
----------                                -------
1111111111111111111111111111111111111111  CN=Nick Bettison, OU=GROUP, OU=Users, OU=BLAH, OU=BLAH...



PS C:\Users\nick.bettison>

If you have multiple, take note of the one you want, the first one is [0], the 2nd is [1] and so on.

The process for signing a script (the long way) is:

$acert =(dir cert:\currentuser\My -CodeSigningCert)[0]
Set-AuthenticodeSignature ".\hello.ps1" -Certificate $acert

However, you can shorten this with a function in your profile. Powershell has a built in variable $profile, which is a predefined file path:

PS C:\Users\nick.bettison> write-host $profile
C:\Users\nick.bettison\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
PS C:\Users\nick.bettison>

Edit that file (create it, if it doesn't exist) and drop in the following quick little function:

function Sign-Script {
    $file = $args[0]
    $acert =(dir cert:\currentuser\My -CodeSigningCert)[0]
    Set-AuthenticodeSignature $file -Certificate $acert
}

(Remember the [0] from above, update -CodeSigningCert)[0] as appropriate for your cert store)

Save the file, and now you have Sign-Script shortcut, it's easy to use see the gif below 🙂

Teltonika RUT240 Let's Encrypt on RUTOS

Nick Bettison — Sat, 12 Dec 2020 09:19:00 +0000

I recently purchased a Teltonika RUT240 to use as a home 4G router, and very quickly I got irritated by the self-signed certificate on the WebUI! 😬 It's been a very long time since I've needed to really delve back into let's encrypt, certbot on centos meets my webserver needs and for home network previously I didn't have much else.

The Teltonika RUT240 is built on a very old version of OpenWRT therefore prebuilt package options are limited; I'd heard good things about acme.sh as it allows DNS based challanges. For internal devices, DNS based certificated issuance are the way forward, it allows let's encrypt to issue you a certificate without you having to run the relevant web server (no port 80/443 needing to be opened, all the traffic is outbound).

Getting going on RutOS was surprisingly easy, of course to start with you need to SSH onto your box, achme.sh recommend running as root so that's fine for me.

Run curl https://get.acme.sh | sh of course you shouldn't run/pipe random shell scripts into a root shell, so have a read of the code, read some of the github issues/feedback acme.sh is well established, so we're good to go.

root@rut240:~# curl https://get.acme.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   775    0   775    0     0    168      0 --:--:--  0:00:04 --:--:--   208
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  202k  100  202k    0     0   150k      0  0:00:01  0:00:01 --:--:--  157k
[Tue Dec  8 17:43:58 GMT 2020] Installing from online archive.
[Tue Dec  8 17:43:58 GMT 2020] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
[Tue Dec  8 17:44:04 GMT 2020] Extracting master.tar.gz
[Tue Dec  8 17:44:14 GMT 2020] It is recommended to install socat first.
[Tue Dec  8 17:44:14 GMT 2020] We use socat for standalone server if you use standalone mode.
[Tue Dec  8 17:44:14 GMT 2020] If you don't use standalone mode, just ignore this warning.
[Tue Dec  8 17:44:14 GMT 2020] Installing to /root/.acme.sh
[Tue Dec  8 17:44:16 GMT 2020] Installed to /root/.acme.sh/acme.sh
[Tue Dec  8 17:44:17 GMT 2020] No profile is found, you will need to go into /root/.acme.sh to use acme.sh
[Tue Dec  8 17:44:24 GMT 2020] Installing cron job
[Tue Dec  8 17:44:24 GMT 2020] OK
[Tue Dec  8 17:44:24 GMT 2020] Install success!
root@rut240:~#

RutOS runs the ash shell, so next up you need to tweak (or create) your /root/.profile file, I'm using the cloudflare DNS challange so mine looks like this (replace the xxx with your details)...

root@rut240:~# cat /root/.profile
export CF_Token="xxxx"
export CF_Account_ID="xxxx"
export CF_Zone_ID="xxx"

. "/root/.acme.sh/acme.sh.env"
root@rut240:~#

Close your SSH session and re-log back in, everything should now be ready to go.

This badboy is the command you want to run, but before you do, take a backup of your old self-signed cert & key (/etc/uhttpd.crt & /etc/uhttpd.key)... you know, just in case!

acme.sh --force --issue --dns dns_cf -d rut240.linickx.com --fullchainpath /etc/uhttpd.crt --keypath /etc/uhttpd.key  --reloadcmd "/etc/init.d/uhttpd restart" --log

Tweak as needed, replace rut240.linickx.com with the FQDN you want to use if you're not on cloudflare select a different provider.

If all goes well, you'll get something similar to this...

[Wed Dec  9 09:09:20 GMT 2020] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Wed Dec  9 09:09:21 GMT 2020] Single domain='rut240.linickx.com'
[Wed Dec  9 09:09:22 GMT 2020] Getting domain auth token for each domain
[Wed Dec  9 09:09:33 GMT 2020] Getting webroot for domain='rut240.linickx.com'
[Wed Dec  9 09:09:34 GMT 2020] rut240.linickx.com is already verified, skip dns-01.
[Wed Dec  9 09:09:34 GMT 2020] Verify finished, start to sign.
[Wed Dec  9 09:09:34 GMT 2020] Lets finalize the order.
[Wed Dec  9 09:09:34 GMT 2020] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/1234/1234'
[Wed Dec  9 09:09:37 GMT 2020] Downloading cert.
[Wed Dec  9 09:09:37 GMT 2020] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/abc123'
[Wed Dec  9 09:09:45 GMT 2020] Cert success.
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
[Wed Dec  9 09:09:45 GMT 2020] Your cert is in  /root/.acme.sh/rut240.linickx.com/rut240.linickx.com.cer 
[Wed Dec  9 09:09:45 GMT 2020] Your cert key is in  /root/.acme.sh/rut240.linickx.com/rut240.linickx.com.key 
[Wed Dec  9 09:09:45 GMT 2020] The intermediate CA cert is in  /root/.acme.sh/rut240.linickx.com/ca.cer 
[Wed Dec  9 09:09:45 GMT 2020] And the full chain certs is there:  /root/.acme.sh/rut240.linickx.com/fullchain.cer 
[Wed Dec  9 09:09:46 GMT 2020] Installing key to:/etc/uhttpd.key
[Wed Dec  9 09:09:46 GMT 2020] Installing full chain to:/etc/uhttpd.crt
[Wed Dec  9 09:09:46 GMT 2020] Run reload cmd: /etc/init.d/uhttpd restart
[Wed Dec  9 09:09:47 GMT 2020] Reload success

A couple of points to make about that output... in the command the post hook restarts the RutOS WebUI ("/etc/init.d/uhttpd restart) so as soon as it's finished it should just work, also I'm on a bit of a flaky 4G connection, you'll see "already verified" in my output, the first time I ran these I got the following errors..

[Tue Dec  8 18:01:51 GMT 2020] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Tue Dec  8 18:02:02 GMT 2020] Create account key ok.
[Tue Dec  8 18:02:03 GMT 2020] Registering account: https://acme-v02.api.letsencrypt.org/directory
[Tue Dec  8 18:02:19 GMT 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 35
[Tue Dec  8 18:02:32 GMT 2020] Registered
[Tue Dec  8 18:02:33 GMT 2020] ACCOUNT_THUMBPRINT='xxx'
[Tue Dec  8 18:02:33 GMT 2020] Creating domain key
[Tue Dec  8 18:02:38 GMT 2020] The domain key is here: /root/.acme.sh/rut240.linickx.com/rut240.linickx.com.key
[Tue Dec  8 18:02:38 GMT 2020] Single domain='rut240.linickx.com'
[Tue Dec  8 18:02:39 GMT 2020] Getting domain auth token for each domain
[Tue Dec  8 18:02:49 GMT 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 35
[Tue Dec  8 18:02:49 GMT 2020] Getting webroot for domain='rut240.linickx.com'
[Tue Dec  8 18:02:49 GMT 2020] get to authz error.
[Tue Dec  8 18:02:49 GMT 2020] _authorizations_map=',
'
[Tue Dec  8 18:02:49 GMT 2020] Please add '--debug' or '--log' to check more details.
[Tue Dec  8 18:02:49 GMT 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
root@rut240:~#

I didn't do anything to fix it, I simply went to bed and tried the next morning! 😂

Renewals should be already taken care of by acme, crontab -l shows a job already setup, I'll update this post if it doesn't work!

References:

https://community.teltonika-networks.com/10995/pem-ca-changed-https-ui-not-updating-certificate?show=11013#a11013
https://www.jamesridgway.co.uk/auto-renewing-ssl-certificate-unifi-cloud-key-lets-encrypt-cloudflare-dns-validation/

Example Azure Web Application Firewall (WAF)

Nick Bettison — Sat, 05 Sep 2020 09:16:00 +0100

I quite enjoyed my recent foray into setting up an example Azure Firewall, so he's a sequel! 🙃

As before, the post will be screenshot heavy but not all screenshots, the plan is to deploy a vulnerable web application behind the WAF in blocking mode so we can see basic exploits being blocked.

Step 1 - Planning

Here's a basic picture of what we want to achieve...

For the Web Server, we're going to run Damn Vulnerable Web Application (DVWA) in an Azure Container Instance.

Everything will be deployed into a single resource group to make cleanup/delete easier at the end.

Naming Convention

Here's a gotcha for Naming Conventions, in my last post I used hyphens, but container instances not allow that, so I'll have to plan a new way.

I still want to follow the region followed by a primary identifier approach...

uksrgwaf → Resource Group
ukswaf1 → Azure Web Application Firewall
uksweb1 → 1st Web Server (Docker DVWA)
uksvnetwaf1 → WAF Network

Something like that should do the trick!

Networking

Two networks will be needed, one for the Security Gateway and one for the Docker Web App, we'll then peer them together.... if you want to by-pass the WAF and access the App directly, plan yourself a 3rd network for a Virtual Windows box.

uksvnetwaf1 → 172.16.1.0/24
uksvnetweb1 → 172.16.2.0/24

Step 2 - Create a Container Instance

The build takes a little while, so kick that off first.

We're going to pull an image vulnerables/web-dvwa from the public docker hub based on linux.

We want the networking type to be Private as we're protecting this behind the WAF; I'm going to create a new vNet to meet my planning above, you are welcome to accept the defaults if you like.

Make no changes to Advanced Settings, skip the tags and hit create.

Step 3 - Create Log Analytics workspace

If you don't have one already, you need somewhere to send the logs...

Step 4 - Create the WAF... well actually the Application Gateway.

So here's the thing, the WAF is part of the Azure Application Gateway product, which is actually a load balancer... so we're going to setup a basic load balancer and then enable the WAF functionaility. Of course we've only deployed "1x Web Server" (docker container instance) but you get the gist!

Change the Tier to WAF V2, set the firewall mode to Prevention, scroll down to networking and create a new vNet...

For the frontend, setup a new PublicIP

Next we need to setup a backend pool, for now select Add backend pool without targets we'll come back to that later!

On the configuration page, notice how the left & right sides are already completed, we just need to add some rules in the middle...

For the listener, setup a basic HTTP routing rule..

And then select Backend targets, assign our pool and add a new HTTP Setting; the HTTP settings will be 100% defaults, this is all load balancer stuff that won't apply to us as we have 1x Web Server.

Skip over tags and we can finally create.

Step 5 - Start joining the dots.

At this stage we have two islands, a docker container and a WAF, they're not connected. The first thing you want to do it peer the vNets.

Peering

Open one of the vNets, I've selected uksvnetwaf1, select peering on the left and add a peering. Give it a name like uksvnetwaf1-to-uksvnetweb1, select uksvnetweb1 from the dropdown list and give that a name like uksvnetweb1-to-uksvnetwaf1

Scroll down to the bottom, and allow external traffic in...

Update the Pool

Remember that step we skipped when creating the WAF (Application Gateway)... time to fix that.

Go into your container instance and grab the private IP

Now, go into your application gateway → backend pool and set the IP, mine is 172.16.2.4

Diagnostic Settings

Remember that Log Analytics workspace we created; within your application gateway add some diagnostics pointing the logs to the workspace.

Step 6 - Bootstrap DVWA

If all has gone well, in a new tab/window you can browse to your public IP http://a.b.c.d and you should get the DVWA log in screen.

The default credentials are admin & password, scroll to the bottom and click create / reset database , you'll be redirected to the login screen where you can log back in.

At this stage you might want to change the password (under the CSRF menu) so you can play in peace, but just remember this thing is designed to be hacked 🙃

Step 7 - Lets test!

To prove the functionality we're going to do a couple of basic tests, a command injection and an SQL Inject, we're also going to disable a WAF RULE to show how to switch stuff off.

How to disable a rule

The WAF comes with a bunch of rules enabled by default, if you're deploying this into production the developers are going to be very concerned about the WAF blocking legitimate requests. To demonstrate the steps, we're going to disable the rule that flags "IP in header"; by default you should browser a site by it's name, but in our test we don't have one so let's switch off that rule.

Go into your logs, and run this query to find WAF events...

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and OperationName == "ApplicationGatewayFirewall"

Scroll to the right you should see message Host header is a numeric IP address with the rule ID 920350

Now go into Web Application Firewall → Rules and enable advanced configuration, search for 920350 and untick the box... then click save.

Job done, that should clean out your logs a bit for the next test.

Blocking Command Injection

We're going nice and simple, from your DVWA tab, select Command Injection and type in 127.0.0.1;cat /etc/password and click submit.

You should get a forbidden page, notice how it says Microsoft-Azure-Application-Gateway/v2 ... the WAF blocked the attack. At this point be a little patient, it can take a while for logs to show up in the azure portal, but this time run:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and ruleId_s == "932100"

You can see the command matched a rule that caused the block.

Blocking SQL Injection

For the 2nd test, browse to SQL injection and type in %' or '0'='0 and click submit.

Once again, you should see the blank Azure 403 forbidden page!

Run this log search:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and OperationName == "ApplicationGatewayFirewall" and Message contains "SQL"

You can see the SQL Injection was detected!

/End

That was another long post but we got there in the end, there's a lot to unpack there from setting up a docker container to disabling a WAF rule. As a reader there's a couple of area's you can follow up with, if you're not familiar with the basic exploits, set the WAF to detection mode to view DVWA get compromised, you will also want to spend some time looking at the logs and preparing better searches as my examples are very specific to this post.

Example Hub & Spoke Azure Firewall

Nick Bettison — Wed, 19 Aug 2020 11:49:00 +0100

It's been a while since I've done a Technical How-to, recently I wanted to get my head around Azure's firewall appliance, here's an example setup and in true MicroSoft style it comes complete with Point-n-Click screenshots! I'm assuming you at least know how to navigate Azure so post doesn't contain all the possible screenshots, for example I will skip screenshots for creating tags, but that all being said, it's still going to be a long one, hold on tight!

Step1 - Planning

Whilst reading the doc's and getting to grips with the Azure Portal it became clear to me, you really need to plan before clicking, it's sooo easy to get stuff running that I'm confident that most orgs will have objects with generic names like "monitoring server" and then forget details like, which region is the server hosted!

This picture is basically what I want to achieve, 2 servers separated by a firewall appliance for access to the Internet and each other; spoke 1 and 2 are isolated zones.

Naming Convention

To get started I planned a basic naming standard using region followed by a primary identifier and then a description...

UKS-FW-vNET → UK (South) Firewall Virtual Network
or
UKS-Route-Spoke1-to-Hub → UK (South) Routing table, Spoke 1 static routes to Hub
or
UKS-Spoke1-VM1 → UK (South), Spoke 1, Virtual Machine

I'm sure it could be better or more rigid but it should be enough for me to know what's what. In the GUI you can group by type & region so you don't really need these in your naming convention, but it's useful to know priority, in my examples the type "Route" is more important that if it's for Spoke1 or Spoke2 ... but for the VM, the location is more important... it's just a lab, do whatever you want 😉

Resource Group(s)

For this example, I'm creating a single resource group and putting it all there; in the real world we would expect to see different networks & VM's in different groups; I'm calling mine FW-Test plan what you need.

Networking (IP Addressing)

Before defining the IP structure, think about DNS, by default all networks/devices use Microsoft's DNS but now-a-days we expect our DNS provider to add some security filtering & protection, so I'll be using Cisco's Umbrella (OpenDNS): 208.67.222.222 & 208.67.220.220

Each Virtual Network is like a zone, it lives in a region and it can be calved up into smaller subnets when needed. I'll be working in /23 chunks, with the first /24 as the "main" subnet leaving the 2nd /24 to be used for other stuff, I'm also going to use the 172.16 RFC1918 space instead of the 10.x generated by Azure to really help show how networking hangs together in this example.

UKS-FW-vNET1 → 172.16.0.0/24
UKS-vNET-Spoke1 → 172.16.2.0/23
UKS-Spoke1-Subnet1 → 172.16.2.0/24
UKS-vNET-Spoke2 → 172.16.4.0/23
UKS-Spoke2-Subnet1 → 172.16.4.0/24

Create UKS-vNET-Spoke1 & UKS-vNET-Spoke2

Create the networks spoke networks first but not the firewall vNET, we'll do that after with the FW Appliance; There's nothing special about the Spokes at this stage, here is Spoke 1

Repeat for Spoke2.

After both vNets are built, if you want to use Custom DNS make that change...

Step 2 - Create the Firewall

The firewall build takes a little time, let's kick that off!

Under the firewall settings, we're going to now define the vNET... notice how the subnet has a special (reserved) name; we also need to create and assign a public IP.

Whilst you're waiting for the deployment...

Setup Logging

By default you don't get firewall logs, we need to switch that on. Before you start you need a Log Analytics workspace, go and create that.

Create Log Analytics workspace

This is how you access or visualise the FW logs, if you're using the eval/free subscription like my screenshots you'll need to select pay-as-you-go pricing, I've not been charged anything 😬

Setup Diagnostics

Back on the Firewall, if it's done, setup logging, it's under Diagnostics Settings....

Add a new Diagnostics Setting.

Tick all the lefthand boxes, we want all them logs! On the right, setup Log Analytics to the workspace you created. At this point, don't expect to see anything under the FW logs section, not only do we not have any traffic yet but it can take ~10mins before any hits appear in the logs.

Create some Rules

We're ready at this point to create some rules, we're only going to work with Add network rule collection rules.

This is where we start and are aiming for, so click add network rule collection and fill in these details...

Name: Basic-Networking
Priority: 100
Action: Allow
Rule 1:
- Name: DNS
- Protocol: TCP & UDP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: 208.67.222.222, 208.67.220.220
- Destination Ports:
Rule 2:
- Name: NTP
- Protocol: UDP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: 123

We want a nice and simple policy to test basic functionality; repeat the process for the following rules...

Name: HTTP-HTTPS
Priority: 1000
Action: Allow
Rule 1:
- Name: HTTP
- Protocol: TCP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: 80
Rule 2:
- Name: HTTPS
- Protocol: TCP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: 443

and

Name: Default-Deny
Priority: 65000
Action: Deny
Rule 1:
- Name: Deny
- Protocol: Any
- Source Type: IP Address
- Source: *
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: *

You should end up with something like this:

Azure & ICMP

Ok, a bit of an Azure quirk here! There's a few google hits of people complaining that you cannot "ping out" from Azure to the Internet, but if you want to be able to ping between spokes you can do that... weirdly tho, restricting the rule by IP/Subnet doesn't work, you have to setup an "any" rule 😒

If you want one, create a rule using these settings...

Name: ICMP
Priority: 101
Action: Allow
Rule 1:
- Name: ICMP
- Protocol: Any
- Source Type: IP Address
- Source: *
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: *

Step 3 Peering

Now we're onto some good stuff! You have 3x Virtual networks, and they're isolated from each other, our target is to route these via our firewall, we do this by setting up peering. We need two peering configs:

Peering on UKS-FW-vNET1 to UKS-vNET-Spoke1
Peering on UKS-FW-vNET1 to UKS-vNET-Spoke2

In new versions of the GUI (you'll not some differences between what you see and the official documentation) this will create Peering back the other way, I guess this had to be done manually before!

Navigate to the vNET: UKS-FW-vNET1 and click Add Peering

Take note of the bottom Enabled if that's not on, then Spoke 2 won't be able to speak to Spoke 1. If your vNET has an onward connect to a VPN gateway then you'll need to tick the bottom box.

Repeat for Spoke2.

Step 4 Create Some Routes

We need 2x routes, I reckon we could probably get away with bundling it together as one, but this feels cleaner and I know it works! 😝

The plan is to setup a default route for UKS-Spoke1-Subnet1/2 to the Firewall, we don't need static routes back the other way, that's sorted by the peering, these static routes give us Internet access and Spoke-to-Spoke connectivity.

Create a new Route Table: UKS-Route-Spoke1-to-Hub

For the next step, you need to pop back to the firewall and grab the private IP... in my example it's 172.16.0.4.

No go to the Route Table and add a default route, the gateway IP is going to the the private IP you just copied from the FW.

Then under Subnets, associate the Spoke1 Subnet.

All that done, now Repeat for UKS-Route-Spoke2-to-Hub!

Step 5 Add some machines

Foundations laid, we have something to stand a computer on lets build a couple of test machines. We'll use a windows server as a GUI client and a linux box as a server.

Windows - Spoke 1

Build a basic Windows 2019 Server...

Default Disk Settings is fine, but Networking settings are important, assign the server to Spoke1, Subnet1 and disable public IPS ...

Default settings for Management and advanced also fine.

Linux - Spoke 2

Build a Linux Server, pick whatever distro makes you happy; you can build a 2nd windows box if you like, but you'll have to install IIS afterwards for some sensible testing.

We're basically repeating the steps from above, the networking tab is the detail to pay attention to...

Step 6 - Bastions, get access to the machines.

As those servers build/deploy you'll be thinking, how am I going to access them?! Well, remember we left some space in the Subnets/vNETs, we'll use Microsoft's Bastion solution.

Go to your VM, scroll to the bottom and select Bastion, you'll notice there's a red error!

Click on Manage Subnet Configuration ... you need to create a subnet called AzureBastionSubnet ← That's a special/reserved name. Bastion's only need a small /27 subnet.

Once the subnet has been created you can then click the create button with no errors. Repeat for Spoke 2.

Test

Finally! After all that setup, we're ready to log into a server. Connect to your linux box first (Using the Bastion Option), install apache & start it.

Now connect to your Windows box:

open Internet Explorer you should be able to browse the web. Disable Enhanced Security if you want/need to! (Note: That's why I'm using Umbrella as a compensating control)
Now connect to your linux box, that should work to
Open a Command Prompt, if you created an ICMP rule, ping should work. If you are pining from the linux box, remember windows servers come with host based firewalls, you'll need a rule there to allow ICMP as well.
Finally, download putty and try to SSH to your linux box, that should fail!

(No Screenshots here, I'm sure you can figure that out 😅)

Check the firewall logs!

If all your tests went as designed, you'll need to filter the firewall logs to see them as any Internet traffic will be filling up the logs.

END

I hope this is useful to someone, it took me a little while and some twitter frustration to get there, but I'm pleased with the result! If I can find the time, I'd like to re-create this in powershell and automate all the things!

References:

https://docs.microsoft.com/en-us/azure/firewall/overview
https://docs.microsoft.com/en-us/azure/firewall-manager/secure-hybrid-network
https://docs.microsoft.com/en-us/azure/firewall/logs-and-metrics