
Her på Robotnet.dk benytter jeg det meget populære WordPress CMS- og blog-system, og jeg har efterhånden en rimelig stor installation med plug-ins, modifikationer mv. kørende for at drifte denne “simple” hjemmeside; Robotnet.dk 😜
Og selvom dette ikke indlæg ikke handler om at bygge et smart hjem, så har jeg valgt at lave en sektion her på bloggen, hvor jeg også går lidt bag om det, at bygge en hjemmeside som denne. Om noget, så handler Robotnet om vidensdeling – og indenfor dette overordnede emne, tillader jeg mig at poste en masse – inklusive nu denne WordPress-sektion her på siden 😎
Cloudflare Access
Cloudflare har for nyligt lanceret et nyt produkt kaldet Cloudflare Access. Produktet går kort fortalt ud på, at du kan opsætte lukkede- og beskyttede områder på dine hjemmesider (Udover at beskytte hjemmesider, kan Access også implementeres på andre protokoller som f.eks. RDP / SSH).
Her på Robotnet.dk benytter jeg som sagt WordPress, og WordPress har en administrativ backend hvorfra jeg kan styre indholdet her på hjemmesiden. Denne backend tilgås normalt fra URLen /wp-admin/ – og den vil man naturligvis gerne lukke ned, så det kun er en selv <(eller ens team)> der kan tilgå denne URL – og det kan Cloudflare Access hjælpe med, endda helt gratis, hvis i er højst er 5 personer.
Så kort fortalt; Cloudflare Access beskytter følsomme områder på dit domæne med adgangspolitikker, så kun godkendte brugere kan få adgang til disse ressourcer.
Du kan vælge at lukke ned på mange måder, det kan være fra et bestemt land, fra bestemte IP-adresser eller vha. konto-validering, før der gives adgang.
Jeg har valgt her på Robotnet.dk at opsætte både IP-adresse- samt e-mail validering, så kommer jeg fra en gyldig IP-adresse, sendes der en kode til min e-mail, som jeg skal taste ind, hvorefter jeg får adgang.
Fordele ved Cloudflare Access
- Hurtig og problemfri opsætning uden ændringer på din server / kode / app*.
- Ingen kodeændringer på dit websted*.
- Let at installere og vedligeholde.
- Let at kontrollere og overvåge.
- Mulighed for politikker og grupper på tværs af websider.
- Se log i real-time og følg med i både succesfulde og fejlede login-forsøg.
- Virker på kryds af alle dine websider /domæner.
- Kører hurtigt på desktop såvel som mobile enheder.
- Autentificering kan ske ved bl.a. Facebook, Google, Github, e-mail og mange andre
- En centraliseret måde at sikre infrastruktur.
- Sikre beskyttede områder uden at bruge en VPN.
- Gratis ved op til 5 brugere.
- Kræver naturligvis at dit site oprettet og køres igennem Cloudflare ⚡
* Hvis du vil opnå den fulde beskyttelse, opsættes også en begrænsning til Cloudflares IP-adresser på din server. Så folk ikke kan gå bagom Cloudflare og direkte ind på din server.
Aktivér Cloudflare Access

Start med at trykke ind under fanen “Access” som vist på skærmbilledet herover. Herfra kan du følge guiden til at opsætte Cloudflare Access. Bemærk at du skal indtaste et kreditkort 💳 også selvom det er gratis – dette bruges naturligvis kun, hvis du giver mere end 5 personer adgang via Access 😎
Opsæt regler i Access

Vi skal oprette 3 regler i alt,
- Tillad adgang til: admin-ajax.php
- Bloker: wp-admin
- Bloker: wp-login.php
Tillad adgang til: admin-ajax.php

Den første regel opsætte således:
- Tryk på “Create Access Policy”
- Indtast “Application name”. Jeg har navngivet min “wp-admin/admin-ajax.php whitelist”
- Indtast Domain -> Path som følger:
wp-admin/admin-ajax.php
- Indtast “Policy name” som:
Ajax Policy
, Decision skal sættes somBypass
og Include sættes til:Everyone
. - Tryk på Save.
Bloker wp-admin

- Tryk på “Create Access Policy” igen
- Indtast “Application name”. Jeg har navngivet min “wp-admin”
- Indtast Domain -> Path som følger:
wp-admin/
- Indtast “Policy name” som:
wp-admin
, - Decision skal sættes som
Allow
- og Include sættes til:
Emails
og din e-mail adresser tastet ind i feltet til højre for. - Tryk på Save.
Bloker wp-login.php
Den sidste regel opsættes magen til den forrige, dog ændre vi “wp-admin” URL’en til wp-login.php:
- Tryk på “Create Access Policy” igen, igen 🙂
- Indtast “Application name”. Jeg har navngivet min “wp-login.php”
- Indtast Domain -> Path som følger:
wp-login.php
- Indtast “Policy name” som:
wp-login
, - Decision skal sættes som
Allow
- og Include sættes til:
Emails
og din e-mail adresser tastet ind i feltet til højre for. - Tryk på Save.
Det var det 🙂
Nu er dit site beskyttet
Nu er din WordPress installationen beskyttet med Cloudflare Access, og kun de indtastede e-mail adresser kan tilgå WordPress Administrationen. Nemt og sikkert! Når du åbner en side, som er beskyttet, skal du indtaste din e-mail adresse, og hvis den e-mail adresse du indtaster er blandt de godkendte, modtager du en e-mail med en kode, som du sætter ind, og så får du adgang.

Bloker evt. også IP-adresser
Det er muligt at opsætte et ekstra lag af sikkerhed, ved at bestemme hvilke IP-adresser der kan tilgå dine beskyttede områder. Det kræver naturligvis, at du har en fast IP-adresse derhjemme og opsat en VPN-adgang hjem til, så du kan koble op – som sad du hjemme – når du er på farten.
Dette gøres vha. sektionen Access Groups under Access-fanen, hvor du opretter en gruppe med dine IP-adresser:

Herefter sætter vi en ekstra regel op på vores wp-admin og wp-login.php politikker herover, hvor denne gruppe skal tilføjes under “include”:

Ekstra sikkerhed?
Jeg anbefaler også, hvis du gerne vil opsætte et ekstra lag sikkerhed, at blokere adgangen fra din web-server, så der kun tillades trafik fra Cloudflare’s IP-adresser.
Hvis folk kan gætte- eller snuse sig frem til din servers rigtige IP-adresse, kan de ikke omgås Cloudflare’s beskyttelse, hvis du ikke låser ned til disse IP-adresser:
Cloudflare IPv4-adresser
Listen er sidst opdateret af Daniel søndag d. 7. marts 2021 kl. 11:10173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/12 172.64.0.0/13 131.0.72.0/22
Cloudflare IPv6-adresser
2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32
Du kan enten blokere dem direkte i din firewall, webserver eller hvis du benytter Apache eller Litespeed som understøtter .htaccess, lave en blok øverst i din .htaccess fil, der blokerer adgangen. Her er et eksempel på dette med opdaterede IP-adresser fra Cloudflare:
# BEGIN Cloudflare Firewall Bypass Prevention
# Regler til Apache 2.4 Webserver
# Updated: 2021-03-07. Get the latest update from:
# https://robotnet.dk/2020/cloudflare-access-vpn-web-applikationer.html
<FilesMatch ".*">
Require ip 173.245.48.0/20
Require ip 103.21.244.0/22
Require ip 103.22.200.0/22
Require ip 103.31.4.0/22
Require ip 141.101.64.0/18
Require ip 108.162.192.0/18
Require ip 190.93.240.0/20
Require ip 188.114.96.0/20
Require ip 197.234.240.0/22
Require ip 198.41.128.0/17
Require ip 162.158.0.0/15
Require ip 104.16.0.0/12
Require ip 172.64.0.0/13
Require ip 131.0.72.0/22
Require ip 2400:cb00::/32
Require ip 2606:4700::/32
Require ip 2803:f800::/32
Require ip 2405:b500::/32
Require ip 2405:8100::/32
Require ip 2a06:98c0::/29
Require ip 2c0f:f248::/32
# Allow from DIN.EGEN.IP.HER Se den på https://ip.duck.tools/
</FilesMatch>
# END Cloudflare Firewall Bypass Prevention
Code language: Apache (apache):-)
Hejsa. Er det muligt at lave samme metode hvis man vil tilgå Home Assistant udefra? Lige nu bruger jeg Nabu Casa, men det giver stadig cert problemer med alle de web services jeg tilgår hjemmefra direkte på IP’en.
Hej Simon
Det har jeg faktisk ikke leget med 😮 Men det er da vildt relevant! 😄 Jeg bruger selv ligesom dig, Nabu Casa’s 5$ cloud-løsning, og elsker det – både fordi jeg støtter udviklingen af Home Assistant og fordi det gør integration med Google Assistant meget nemt! Og som bonus kan tilgå min Home Assistant fra hele verden, og det virker out-of-the-box med deres iOS app 🙂 Før Nabu Casa produktet kom, havde jeg selv opsat SSL-certificater mm. og det var meget bøvl, så bestemt rart at slippe for den del også 🙂
Men jeg tror da helt sikkert du vil kunne bruge Cloudflares teknologier her, det er oplagt 🙂 Det kræver jo stadig at du opsætter port-åbninger i din router fra public til din lokale IP, og det kræver at du blokerer adgang for denne public route til de nævnte IP-adresser fra Cloudflare’s scope herover – men det er der jo intet problem i, herefter vil du både løse SSL-problematikker (ude fra) og adgangsproblematikken ude fra.
Det vil dog ikke løse SSL-problemer inde fra på den lokale IP, men her har jeg valgt blot at køre alt internt over http:// (ingen ssl nødvendigt når det kun er til kommunikation på mit interne netværk)
Jeg vil prøve at opsætte et test-miljø med Home Assistant og Cloudflare + Access, og lave en artikel om det her på Robotnet.dk, hvis jeg får det til at spille 🙂
– Daniel
Ja, det er til et godt formål.
Det var mest fordi jeg var træt af de SSL fejl internt. Men hvis man bare kan se bort fra dem, så er det nok det nemmeste 🙂
Mit råd: Fjern alt SSL internt, og brug kun SSL eksternt – hvilket Nabu Casa klarer for dig 🙂 Ellers er der mange måder at løse dette på gratis, hvis man ikke betaler for Nabu Casa, som Let’s Encrypt eller Cloudflare.
Der er ingen grund til at bøvle med SSL internt, medmindre du deler netværket med andre, som har adgang til at sniffe din trafik (og i så fald du deler netværket med andre, burde du VLAN-seperere det, så de ikke kan se din aktivitet). Så længe det kun er internt, er der ikke noget at frygte. 🤗
Det eneste Chrome og andre browsere gør, er at vise en “Ikke sikker” tekst til venstre for URL’en, ingen prompts, ingen advarsler, ingen self-signed SSL-certifikater der skal installeres mm.
5ed7a678d5a1a52c520bb108.png
Tak. Det var netop den der “Ikke sikker”, som jeg troede skulle væk.
På lokale IP-adresser er der ingen problemer, der har Chrome, Safari, Firefox og andre browsers opsat mindre skærpede krav 🙂 Så “Ikke sikker” er kun en visuel lille ting, man hurtigt glemmer 😏
Hej Daniel. Nu sidder jeg lige og opgradere til nyeste HA med de små-problemer det altid giver, og så kommer jeg i tanke om hvorfor jeg ville have det “secure”. Når man åbner VSCode, installeret gennem addon-store, så står der at der er nedsat funktionalitet fordi det ikke er en sikker forbindelse. Og hvem gider “nedsat funktionalitet” ? 😅
Hej Simon. Super at du deler dette!
Jeg er endnu ikke selv stødt på nogle problemfyldte add-ons eller andre begrænsninger ved ikke at køre Home Assistant under https lokalt – men jeg bruger heller ikke VSCode 🙂 Så hvis man bruger VSCode, er man nødt til at have opsat SSL-certifikater og alt det bøvl det medfører – eller blot bruge Nabu Casa proxy’en over https til dette add-on. Godt at vide, og tak for deling 👍
Home Assistant har ændret sig markant siden jeg startede med HA for et par år siden, især henover de sidste måneder. Hvis du Googler, vil du også kunne se i Changelogs at YAML er på vej ud, og målet er ret synligt; alt skal konfigureres via webinterfaces. Alene henover de sidste måneder, er en del YAML-support/filer blevet deprecated, hvilket betyder det stadig virker, men på sigt, fjernes helt fra HA – og ved næsten hver opdatering har jeg kunne fjerne ting fra min YAML-config, og erstatte disse med UI-integrations, bl.a. Plex, som blev fjernet i 0.109. Daikin, TP-link, AVM m.fl.
Det betyder dog ikke at VSCode ikke skal virke, hvis man ønsker at benytte dette add-on. Man kan naturligvis bare bruge sin Nabu Case adgang, hvis man har tilkøbt dette, og så er det problem løst, ellers skal man opsætte SSL- dette vil jeg smide i TODO-listen, og lave et indlæg om snart 🙂
God dag Simon,
– Daniel Bahl