Tailscale Access Controls

J'ai souvent parlé de Zerotier que j'utilise au quotidien, mais qui dans sa version gratuite comporte quelques limitations en terme de contrôle d'accès dans un environnement mixant du site-to-site et des clients isolés. J'ai donc voulut voir ce que proposait Tailscale, qui est un VPN managé relativement similaire reposant sur Wireguard. Tous deux offrent des fonctionnalités gratuites et payantes. Si payer ne doit pas être un problème dans un environnement de production, c'est un peu différent en mode home lab.... d'autant plus que certaines fonctionnalités de la version gratuite ne se retrouvent que dans la version Premium à $18 /mois/utilisateur.

La version gratuite des Tailscale est plutôt généreuse, elle propose 100 nodes et 3 utilisateurs (à condition de disposer d'un "custom domain" (je vais utiliser des comptes Microsoft 365, mais plusieurs autres possibilités sont disponibles : SSO Identity Providers). On peut donc disposer de 3 comptes sur un même domaine. Je parle de comptes car nativement (et normalement) le contrôle d'accès se fait sur l'utilisateur. Manque de chance j'ai besoin de gérer 4 utilisateurs, et je ne suis pas prêt à payer 4 x $18, ce qui me ferait plus de $ 800 par an !

J'ai donc cherché à contourner et je vais finalement gérer mes autorisations à partir des machines Tailscale que j'ai approuvées (mode NFS pour ceux qui se souviennent). Dans cet usage je ne cherche pas faire communiquer les clients Tailscale entre eux mais à leur permettre d'accéder à des ressources situées sur différents subnets sur lesquels je souhaite restreindre les possibilités.

Pour la suite on considère que le réseaux Tailscale est configuré avec les nodes qui servent à joindre les subnets.

Je vais créer deux utilisateurs :

[email protected]
[email protected]

Le premier compte qui sera également le mien va également me permettre de configurer et approuver les machines clientes.

Le second servira à connecter mes utilisateurs et je pourrais approuver leurs machines. Ce compte étant protégé en MFA, il nécessitera une validation de ma part. Une fois la machine connectée, je désactive l'expiration de la clé et on passe au contrôle s'accès :

{
  "acls": [
    {"action": "accept", "src": ["[email protected]"], "dst": ["*:*"]}, // Ici l'admin dispose de tous les droits
    
    // Autorisation par machines
    {
      "action": "accept",
      "src": ["azura", "lydia"],      // Ici deux clients Tailscale
      "dst": [
        "pipa:25,53",                 // On autorise le host qui supporte le DNS si on veut utiliser les noms courts...
        "mixa:80,443,445,3389",
        "nona:80,443,445,1443,3389",  // Ports autorisés

        "lab-1:*",

        "192.168.2.12:80,443,9100,5001,3389", // Par IP + ports
        "192.168.6.0/24:*",                   // Par subnet
      ],
    },
  ],
  "hosts": {
    "azura": "100.1.2.3",        // Client Tailscale
    "lydia": "100.5.2.3",        // Client Tailscale

    "mixa":  "192.168.1.4",      // Host on subnet
    "nona":  "192.168.2.8",      // Host on subnet
    "pipa":  "192.168.2.1",      // Host on subnet

    "lab-1": "192.168.6.0/24", // subnet
  },

}

Dans l'ordre :

  1. J'autorise l'admin à tout voir.
  2. Ensuite j'autorise les machines azura et lydia à accéder uniquement aux hosts que j'aurais défini avec une restriction sur certains ports. C'est possible en définissant les hosts plus loin ou en se servant directement des adresses IP. L'ICMP (ping) est ouvert automatiquement vers les destinations autorisées.
  3. Je défini les clients et serveurs.

Voilà. Je n'ai pas creusé toutes les possibilité offertes par le contrôle d'accès proposé par Tailscale, la liste est longue et le documentation plutôt bien faire. Idées bienvenues !

Home Assistant & Cloudflare Zero Trust

Une fois de plus on va parler de VPN. J'avais ici évoqué Zerotier (gratuit pour 25 nodes) que j'utilise toujours notamment pour interconnecter plusieurs sites entre eux en remplacement d'IPSEC. Ca fonctionne très bien et ça se fait oublier. Entre temps on a découvert Wireguard qui est très performant et peut être utilisé en natif (faut faire le taff) ou via des intégrations comme Tailsacle (entre autres) dont la version gratuite sera suffisante pour bien des usages.

Aujourd'hui on va parler de Cloudflare Zero Trust. Au départ je voulais juste tester sous Home Assistant car cela permet de publier son Home Assistant sans ouvrir de ports sur le routeur, de la même façon que l'on peut le faire si l'on dispose d'un abonnement Nabu Casa. J'ai cet abonnement, mais je ne veux pas l'imposer aux utilisateurs que j'aide.

Si Zero Trust est basé sur Wireguard il n'a rien d'open source. Certains n'aimeront pas quelque chose qui passe par Cloudflare qui comme beaucoup d'acteurs du marché pratique la collecte de donnée. C'est le business de l'époque, d'autres font pire mais ce n'est pas le débat ici, alors épargnez moi vos digressions sur ce sujet, ce n'est pas l'objet. Si vous choisissez cette solution c'est en connaissance de cause. Il existe des alternatives, moins simples à mettre en œuvre.

Zero Trust est un VPN orienté client qui permet notamment deux approches :

  • Publier et sécuriser, sans ouvrir de ports, un (ou plusieurs) site hébergés en premise (premise = chez vous, dans votre entreprise) et le rendre accessible publiquement avec des restrictions qui assureront sa sécurité (MFA) et surtout des restrictions géographiques qui sont quasi impossibles avec les autres solutions, notamment à cause de Let'Encrypt.
  • Rendre accessible des réseaux privés (VPN) en passant par le client Warp de Cloudflare) et ainsi accéder à toutes les machines du réseau (RDP, SMB, SSH, etc...).

Ce qui fait la force de cette solution ce sont les policies qui permettent une très grande granularité. Cloudflare Zero Trust est gratuit jusqu'à 50 utilisateurs. Et dans l'absolu pour sécuriser Home Assistant on a même pas besoin du moindre utilisateur.

Home Assistant

Un Add-on est disponible ici et sa mise œuvre est 'une simplicité enfantine mais il y a une petite subtilité. En effet il y a deux façons pour gérer un tunnel :

  • En local et en CLI
  • Depuis le dashboard de Zero Trust

On part du principe que vous avez un compte Cloudflare et qu'un de vos domaines y est géré. Vous avez également activé Zero Trust. A faire avant toute chose.

Dans les deux cas on ajoute ou modifie le fichier de configuration de Home Assistant ainci :

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24

Option 1, gestion en local

On installe l'add-on sur Home Assistant, on choisit un host pour Home Assistant, ha.domaine.com par exemple et on lance l'add-on. Il suffit simplement ensuite d'aller copier dans le log l'url de validation et de la copier dans votre navigateur.

Et ça fonctionne, installation du certificat intermédiaire comprise. On pourra ensuite sécuriser et jouer avec les options, la doc de l'add-on est ici et cette  de Zero Trust . Si vous ne pensez pas utiliser Zero Trust pour autre chose c'est la solution la plus simple.

Option 2, gestion en remote

Vu que je compte utiliser Zero Trust à d'autres fin, c'est l'option que j'ai choisit.

  • Dans la console (Access/Tunnels) je crée un nouveau tunnel que ne configure pas.
  • Je copie le token que je viens reporter dans l'add-on et je lance l'add-on
  • Je vais dans le log et je copie l'url de validation que je colle dans le navigateur afin de finaliser l'installation et valider le certificat. 
  • Dans la gestion du tunnel je vais créer un Public Hots Name qui va correspondre à mon serveur et sera exposé avec le nom de domaine choisit :

Votre Home Assistant est maintenant accessible, ici https://test-ha.canaletto.fr (sans le port).

Aller plus loin...

En premier lieu je vous conseille de définir une policie dans Access/Applications afin que votre serveur ne soit accessible que depuis votre pays et surtout pas depuis des états plein de black hat's ...

Ensuite il faut savoir que vous avez installé sur votre serveur une passerelle VPN qui va vous permettre d'accéder à tout votre réseau local en passant par le client Warp. Pour cela il faut dans la configuration du tunnel déclarer un Private Network.

Ensuite dans les SettingsGeneral on va définir le nom de (Team) :

Dans Settings/Network on va changer le mode des tunnels. De base, dès lors que le client Warp est activé, Zero Trust va faire passer tout ce qui ne ressemble pas à une adresse privée dans ses tuyaux, c-a-d tout votre trafic, probablement à des fins de collecte de donnée... On va donc remplacer le mode Exclude par le mode Include et y déclarer uniquement notre réseau privé. Ainsi seul le trafic tunnelisé transitera par Cloudflare, et comme il est dans un tunnel ce sera théoriquement incognito. Je dis théoriquement car dans cette solution ce n'est pas vous mais Cloudflare qui a les clés... Mais nous sommes dans le cadre d'un service de classe entreprise et les CGU garantissent la confidentialité des données...

Dernier point, déclarer une méthode d'authentification. De base une authentification par code PIN est proposée, vous déclarez un domaine ou une adresse mail et vous revenez un code PIN à 6 chiffres qu'il suffit de rentrer... En option il est possible de configurer un SSO en utilisant une authentification que l'on exploite déjà (Azure AD, Centrify, Facebook, GitHub, Google Workspace, Google, LinkedIn, Okta, OneLogin, Saml, OpenID Connect, etc...). Plus complet, mais ça peut répondre à certains besoins en entreprise.

A partir de la on installe le client et on se connecte avec le nom que l'on a défini plus haut. On teste un RDP, SMB ou SSH sur une IP du réseau privé, et ça marche. Ca veut dire qu'à ce stade tout est ouvert dès lors que l'on a connecté le client, pourquoi pas dans le cadre d'une utilisation personnelle, mais je ne saurait trop vous conseiller de tout interdire et de n'autoriser que ce qui est utile (Gateway/Policies/Network).

Cet outil étant avant tout destiné à une utilisation en entreprise les possibilités sont immenses. Pour autant l'administration n'est pas très compliquée, avec quelques connaissance de base dans la gestion des réseaux.

Echanger

J'ai créé un sujet sur HACF, plus pratique qu'ici pour échanger.

 

TailScale, VPN/SDN simplifié

Avant, il y avait les VPN (PPTP, IPSec, OpenVPN, etc...) qui ne sont pas toujours très simple à implémenter. Et puis arrivent les SDN, qui dans l'absolu sont des VPN, orientés réseaux étendus et très simples à mettre en œuvre. D'aucun le savent, je sus un fan de Zerotier que j'utilise au quotidien, tant pour interconnecter 4 sites à la place d'IPSec, que pour des machines distantes ou quand je suis en déplacement.

Entre temps les barbus nous ont beaucoup parlé de Wireguard, qui peu ou prou fait la même chose en un peu plus compliqué avec de soit disant meilleures performances. Et puis arrive TailScale qui lui est basé sur Wireguard et lui apporte la simplicité. Une sorte de Wireguard pour les nuls, enfin, pas que, car TailScale apporte à WireGuard la notion d'annuaire qui lui manque (WG-Dynamic en cours de dev.). Comme pour Zerotier, au delà d'un certain nombre de nodes il faudra passer à la caisse, mais les tarifs sont comparables, tout comme les possibilités offertes par la version gratuite suffisante pour un usage home.

Comme pour Zerotier, il est possible :

  1. D'accéder depuis internet à une machine particulière avec un client dédié (MacOS, Windows, Linux, IOS, Android).
  2. D'accéder depuis internet à un sous réseau dès lors que l'on installe un node Linux qui servira de routeur
  3. D'accéder depuis internet à internet de façon sécurisée en passant par un node Linux installé en mode Exit-Node, chez vous ou sur un VPS.
  4. D'accéder depuis chez vous à d'autres sous réseaux, bon là c'est plus compliqué et il faudra passer à la caisse et avantage à Zerotier (ou Wireguard, mais je n'ai pas testé).

Le gros avantage de Zerotier est que l'on travaille en Layer-2 sur un subnet dédié avec la possibilité de figer des IP là ou TailScale affecte des IP aléatoires et travaille en Layer-3. Mais les deux peuvent cohabiter, et ça peut être intéressant dans certains cas. Vous trouverez ici un comparatif des deux solutions.

Ce qui est certain, c'est que si moi j'y trouve des limitations, TailScale a pour lui une simplicité qui en fera un bon choix pour ceux qui débutent et veulent juste un usage limité. On va donc se consacrer aux trois premiers points d'usage.

Accéder depuis internet à une machine distante

Je ne vais pas vous expliquer comment créer un compte (il suffit d'aller sur leur site), ou comment se faire coucou entre deux machines clic clic (MacOS, Windows, IOS ou Android), il suffit de lancer l'installation et de faire un ping. Par contre je vais le faire pour la machine Linux qui nous servira dans les deux cas qui suivent.

On part du principe que la machine existe dans sa config minimale et qu'elle communique avec Internet. On en fait un client Tailsacle, ça se passe ici et c'est un peu différent selon les distributions. J'utilise Ubuntu et on commence par ajouter les clés et le repository :

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add -
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list

On fait les mise à jour et on installe :

sudo apt-get update
sudo apt-get install tailscale

On lance le client et on copie l'url pour l'autoriser :

sudo tailscale up

Et voici notre IP :

ip addr show tailscale0

A ce stade si on a un autre client TailScale on peu faire un ping... A noter que sur la console d'admin on va pouvoir définir si la clé expire ou pas...

Si votre but est d'accéder à Home Assistant, il existe un addon qui fera le travail pour vous.

Accéder depuis internet à un sous réseau

Afin de ne pas devoir installer TailScale sur toutes vos machines, et surtout accéder à celle ou il n'est pas possible de l'installer (IoT par exemple), on va installer une machine en mode routeur. Pour l'instant ce n'est faisable que sous Linux, avec un petit RPI ou une VM par exemple... On continue sur la même machine.

Première chose on active l'IP Forwarding :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

Ensuite on active le routage du subnet :

sudo tailscale up --advertise-routes=192.168.210.0/24

Et pour terminer on va dans la console d'admin indiquer que cette machine servira de routeur pour ce subnet (sous réseau) (les ... au bout de la ligne) :

A partir de là un client TailScale pourra accéder à ce sous réseau.

Accéder depuis internet à internet de façon sécurisée

Quand vous vous connectez en WI-FI sur un hotspot public tout le monde vous dira que ce n'est pas très sécure et qu'il faut utiliser un VPN. Ici plutôt que de payer pour un VPN on va utiliser notre propre connexion, à la maison, ou encore dans un VPS. Pour ça on ajoute la fonction Exit-Node à notre machine :

sudo tailscale up --advertise-exit-node

Et on la configure de facon idoine au même endroit

Ensuite dans le client on choisit l'option Exit-Node afin que tout le trafic transite par notre nouveau point de sortie.

A noter que si l'in veut combiner les deux fonctions, subnet + Exit-Node la commande sera plutôt celle ci :

 sudo tailscale up --advertise-routes=192.168.210.0/24 --advertise-exit-node

Voilà, c'est pas plus compliqué, c'est gratuit et c'est sur. En parlant de gratuit sachez que Free a démarré une beta afin d'intégrer Wireguard dans les Freebox et que Wireguard tout comme Zerotier peut être intégré dans certains routeurs (Unifi, Asus, etc...) ce qui vous évitera la petite machine Linux. Mais ce n'est pas forcément aussi simple.

Sources :

 

Télétravail, RDP & VPN

Par les temps qui courent, le télétravail est de mise, mais tout le monde n’est pas placé à la même enseigne. Il y a les grandes entreprises ou les cadres sont équipées d’ordinateurs portables et ou les infrastructures de sécurité existent et ou il suffit juste d’extrapoler pour les salariés qui ne sont pas équipés. Et puis il y a les petites entreprises, voire très petites ou rien n’existe et ou bien souvent le salarié sera contraint dans l'urgence de travailler sur son ordinateur personnel.

Et dans ce cas on peu se retrouver dans des situations très précaires, en termes de sécurité ou de praticité, car l’ordinateur familial est généralement utilisé par d’autres personnes, souvent les enfants, ce qui peut rapidement poser des problèmes. On pourrait bien sur isoler une session, mais c’est ingérable et par définition l’intervention sur le PC personnel que l'on réalise en avec une prise de contrôle à distance doit se limiter au strict minimum.

La solution bien souvent utilisée conste à permettre au télétravailleur de travailler distance en se connectant à son ordinateur de bureau, et ainsi conserver son environnement habituel. Pour ce faire on pense d’abord aux solutions de type AnyDesk, TeamViewer, voire VNC, solutions simples à mettre en œuvre mais qui offrent peu de confort à l’usage. La seule vraie solution confortable est d'utiliser le bureau à distance qui fonctionne avec le protocole RDP. Le problème du RDP c’est sa sécurisation car ce protocole directement exposé sur internet est une véritable passoire dont les méchants hackers sont friands si on se content de simples redirections de port. Microsoft ne s’est jamais occupé de ce problème pour cet usage, la seule solution proposée est RDS (Remote Desktop Services), une usine à gaz certes efficace mais totalement inadaptée aux TPE. Royal TS Gateway peut constituer une alternative (il y en a d’autres), mais pas pour de très petites entreprises qui n'ont que peux d'infra et généralement pas d'IT.

L’autre alternative reste l’utilisation d’un VPN en équipant les postes clients. Il y a plusieurs façons de faire, mais je voulais quelque chose de transparent, facilement administrable, ne m’imposant pas d’intervention ultérieure sur le poste client et ne nécessitant pas l’installation d’un serveur. Je vais donc une fois de plus utiliser Zerotier qui répond à mon besoin et qui est gratuit jusqu'à 50 clients.

  • Pas de serveur à déployer
  • Installation minimale sur le poste client
  • Gestion des ACL centralisée

Ce n’est pas la façon de faire la plus sécurisée (le port RDP est ouvert entre le client et son PC de bureau), mais on va limiter le risque avec un bon équilibre risque / coût / praticité.

Zerotier

Je vais faire l’impasse sur la mise en œuvre, j’en ai déjà parlé. Ici on va installer le client sur les deux postes à associer et leur figer une IP sur la console d’admin (Zerotier supporte Windows, MacOS, Linux et même Android et IOS). Ensuite on va s’assurer que seul le trafic RDP du poste client soit autorisé à se connecter au PC de bureau en utilisant les règles dans la console.

# Allow only IPv4, IPv4 ARP, and IPv6 Ethernet frames.
drop
	not ethertype ipv4
	and not ethertype arp
	and not ethertype ipv6
;
accept ipprotocol tcp and dport 443 or dport 80;

accept dport 3389 and ipsrc 10.147.1.20/32 and ipdest 10.147.1.30/32; # André
accept dport 3389 and ipsrc 10.147.1.21/32 and ipdest 10.147.1.31/32; # Carole
accept dport 3389 and ipsrc 10.147.1.23/32 and ipdest 10.147.1.33/32; # Bernard

drop chr tcp_syn and not chr tcp_ack; # No new TCP connections
;
# Drop TCP SYN,!ACK packets (new connections) not explicitly whitelisted above
break                     # break can be overridden by a capability
  chr tcp_syn             # TCP SYN (TCP flags will never match non-TCP packets)
  and not chr tcp_ack     # AND not TCP ACK
;
cap superuser
  id 2000 accept;
accept; # Accept what's left, returning RDP traffic

Coté poste au bureau on s'assure que le PC ne se met pas en veille (veille et verrouillage de l'écran uniquement) et on autorise RDP (le bureau à distance) sur le poste. Pour ça il faut un Windows Pro (mise à niveau à envisager parfois car les TPE qui vont acheter leur PC à la Fnac ou sur Amazon se retrouvent souvent avec une édition Famille de Windows).

Le client RDP

Do coté du poste client, après s'être assurée que la machine est à jour (on ne fait pas ça sur un vieux PC sous XP) et pas vérolée, il va nous falloir un client RDP et surtout interdire la mémorisation du mot de passe afin que n'importe qui ne puisse pas se connecter. Pour ça il y a une stratégie (Policie) à configurer ou une modification de registry, sauf que le PC personnel est une édition familiale il faudra ruser pour avoir accès aux stratégies...

Registry Hive HKEY_CURRENT_USER
Registry Path SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Value Name DisablePasswordSaving
Value Type REG_DWORD
Enabled Value 1
Disabled Value 0

Tant sur Windows que sur Mac il existe plusieurs clients RDP proposés par Microsoft avec des possibilités inégales.

  • Client RDP de base Windows : Il supporte les redirections d'imprimantes, mais visiblement il est impossible malgré la stratégie d'interdire la mémorisation du mot de passe de session.
  • Client RDP enrichi que l'on peut télécharger sur le Windows Store pour Windows ou Apple Store MacOS : Il ne supporte pas la redirection des imprimantes, par contre il prend bien en compte la stratégie d'interdiction de mémorisation du mot de passe.

Tout ça se passe plutôt bien bien si le PC personnel est sous Windows, par contre si c'est un Mac vous imaginez bien que Microsoft ne s'est pas préoccupé du mappage du clavier qui est différent sur chez Apple. Et ça c'est juste insupportable à l'usage. Me voici contraint de chercher une alternative, alternative que je vais finalement utiliser sous Windows également car elle est plus sécurisée et bien plus fonctionnelle.

Royal TS/TSX

Royal TS (ou TSX sur Mac) est un client multi protocoles que j'utilise depuis des années pour gérer des douzaines de serveurs. Il inclus bien sur le RDP et une multitude d'options dont le mappage du clavier entre un Mac et un PC, la gestion des imprimantes et la possibilité de lancer des commandes avant et après une session. Et autre avantage il va être possible de chiffrer toutes les informations contenue dans ce client. De plus le fichier de configuration peut être partagé entre un PC et un Mac via un drive.

Royal TS/TSX n'est pas gratuit pour gérer une multitude de serveurs, mais cerise sur le gâteau il existe une version gratuite limitée à 10 connections. Juste ce dont on a besoin ici.

On installe sur le PC du salarié, on crée le profil (que l'on peut créer à l'avance) correspondant à son poste de travail avec l'option plein écran, on redirige les imprimantes et sur un Mac on gère le mappage. On n'hésite pas à enregistrer les identifiants car ici c'est le mot de passe de chiffrage de l'application qui sécurisera toutes les connections enregistrées.

A partir de là le salarié lance Royal TS/TSX, saisit le mot de passe de l'application et a accès à son PC de bureau. A noter qu'il est également possible de lui donner accès dans cette même application à d'autres environnements (RDP, VNC, SSH, PS, Terminal, ou des web apps sois IE ou Chromium). Et comme on peut batcher des process avant et après une ouverture de session on peut même imaginer de lancer et désactiver Zerotier avant et après.

Autre avantage de cette solution, il est possible de créer des fichiers de configuration chiffrés et facilement déployables (envoi par mail par exemple).

Voilà, ce n'est pas parfait, mais dans le contexte actuel rien n'est parfait. Et cette solution permettra le télétravail à peu de frais avec un minimum de sécurité et de confort.
 

Unifi Dream Machine Pro

Chez les afficionados de la marque on a généralement tous commencé par un AP WI-FI. Et puis comme ça fonctionnait bien et que c'était beau on s'est laissé aller pour un USG, et là c'était beau, mais pas exempt de bugs et surtout limité en CPU pour exploiter une fibre ou DPI/IPS. Il y a bien eu l'USG Pro, pas vraiment beaucoup plus puissant. Sur tous ces modèles le VPN n'a jamais été le point fort et quant à faire de la publication il n'y a rien d'autre qu'une possible translation de ports entrants comme sur un vulgaire routeur grand public, si cela pouvais se comprendre sur les modèles précédents, on aurait aimé un reverse proxy sur la machine censée nous faire rêver !


(source Unifi)

Mais il n'en est rien, il faut considérer l'UDM Pro, et c'est son positionnement marketing, comme un routeur d'accès avec des services (Contrôleur Unifi, Unifi Protect, contrôle d'accès, téléphonie IP, etc..). Si l'on souhaite publier des services on regardera plutôt du coté de pfsense ou autres Appliance qui font ça très bien. Et si on veut faire du VPN,  ce qui est par contre dans la cible du produit, ce sera IPSEC ou OpenVPN. Zerotier ayant été porté sur la gamme Edge, il y a des chances que quelqu'un fasse le portage sur l'UDM Pro, voire qu'Unifi le fasse, à moins qu'ils ne se laissent tenter par WireGuard...

A 319 € (HT) l'UDM est un produit intéressant qui combine donc plusieurs fonctions : 

  • un USG performant avec fonctionnalités de firewall avancées (IPS/IDS, DPI)
  • un switch 8-port Gigabit et un port 10G SFP+, un port WAN Gigabit et un second port WAN en 10G SFP+ (de quoi y raccorder les nouveaux produits en 2.5 GB et 10 GB actuellement en Early accès et profiter des offre fibre en 2.5 GB ou 10 GB proposées par certains FAI).
  • un contrôleur UniFi (= CloudKey ou CloudKey Gen2+).
  • un NVR UniFi Video avec emplacement disque dur 3.5″ ou 2.5".
  • d'autres contrôleurs à venir (contrôle d'accès, téléphonie IP, et certainement quelques autres projets dans les cartons...).
  • et enfin comme tous les Gen2 de la marque on est en présence d'un petit écran de contrôle en face avant. Petit gadget pour doigts de fée !

Si le contrôleur Unifi intégré pourrait très bien trouver sa place ailleurs (VM, Cloud, ...), l'enregistreur vidéo (Unifi Protect), qui est identique, mais plus puissant que celui que l'on trouve sur le CloudKey 2+, constitue un vrai plus si on veut gérer un grand nombre de caméras et stocker jusque à 14 TB de vidéos de surveillance. A noter qu'il existe chez Unifi un autre NVR plus puissant avec le support de 4 disques.

Le NVR

Ca c'était le bla bla marketing annoncé. Dans la pratique Unifi Protect sur l'UDM Pro me semble bien bogué pour un produit sorti il y plus de six mois. Ca commence avec le disque dur, quelque soit le modèle installé parfois il le voit, parfois pas, et quand il le voit il ne l'exploite pas (impossibilité d'enregistrer). Certains conseillent de le retirer et de le formater en ext4, pas mieux, de juste supprimer les partitions, là il est visible mais non exploitable. Pas très normal qu'on ne puisse pas lancer l'initialisation/formatage depuis l'interface. Et je passe sur les paramètres des caméras qui sont pris en compte depuis l'application mobile mais impossible depuis le portail web qui lui répond que la caméra n'est pas reconnue, alors qu'elle l'est bien sur... A cette heure je regrette ma CloudKey 2+ !

Le routeur

Le routeur d'accès qui lui remplacera l'USG reste à apprécier à l'usage, Ca remplace mais ça reste un USG dont je ne vais pas reprendre le détail ici, un une partie qui mériterais de la part d'Unifi quelques évolutions, avec notamment l'intégration à l'interface de tout ce qui n'apparait pas mais reste faisable en CLI.

2 ports WAN, mais un seul en 10 G !

A noter que le WAN1 qui est en 1 GB est toujours le port principal WAN et que si on souhaite faire du failover on le fera avec le WAN 2 qui lui est en 10 GB (SFP+) ou en 1 GB en utilisant un adaptateur UF-RJ45-1G. C'est d'autant plus bête qu'en utilisation normale on peut imagine une grosse fibre sur le WAN principal et un xDSL en secours. Ca reste du soft, et on peut imaginer une évolution du firmware, et pourquoi ne pas banaliser tous les ports en WAN/LAN comme le fait Cisco depuis plus de 10 ans sur des produits SMB de la gamme RV.

Dans tous les cas, sur le papier, on reste sur de l'agrégation ou du failover utilisable en sortie, et pour l'instant c'est failover only (La seule solution intégrale d'agrégation via un tunnel restant l'OTB d'OVH ou sa version open source openMPTCP).

Quand au WI-FI contrairement à l'UDM, l'UDM Pro qui se place dans un rack n'intègre logiquement pas d'AP. Alors on est tout de même en droit de se demander pourquoi sur un produit qui est censé gérer des AP et des caméras en POE, on ne trouve aucun ports POE ? Je pense simplement qu'à la conception la question a bien du se poser, le marketing l'a emporté en argumentant que cela ferait vendre des commutateurs POE, produits sur lesquels la marge est certainement bien plus importante. C'est dommage car avec quelques ports POE l'UDM Pro aurait été presque parfait ! Business is business !

Un firmware intégré...

Contrairement aux habitudes prises avec Unifi, ici le firmware intègre tout, le firmware de la machine de base proprement dite (USG), le contrôleur Unfi Network, le contrôleur Unifi Protect et les autres applications... Si la bonne idée est de simplifier, on va voir que dans la pratique ce n'est pas si simple tant les versions sont évolutives chez eux...

Coïncidence, mon UDM Pro est arrivé le lendemain du jour ou j'ai mis à jour (par erreur) ma CloudKey 2+ avec le contrôleur avec 6.0.20. Mal m'en a pris car cette version, tout comme la suivante en 6.0.22 est tellement buggées qu'on peut aisément penser qu'elle a été lâchée en release par erreur (un stagiaire ?). Problème, la 6.0.x n'existe pas sur l'UDM Pro qui est en firmware 1.8 qui intègre le contrôleur en 5.x. Dès lors impossible de migrer une installation en 6.x vers du 5.x ! (il ne s'agit pas vraiment d'un process de migration mais une simple opération de backup/restaure, il faut donc que la source ait un niveau de release inférieur ou égal au contrôleur de destination).

Alors j'ai cherché, j'ai fini par installer la 1.8.1 RC3 qui n'apporte hélas pas de contrôleur en 6.x ... et pour finalement découvrir qu'il était possible de mettre à jour le contrôleur d'UDM Pro en SSH. Et pourquoi pas avec un bouton upload ? On a parfois l'impression qu'il y a chez Unifi pas mal d'ingés de l'ancien monde, ceux pour qui le CLI est et reste la seule option possible... Ce qui n'est pas très logique pour un constructeur qui se démarque avant tout par ses magnifiques interfaces !

ssh udm ...
unifi-os shell
cd /tmp
curl -o "unifi_sysvinit_all.deb" https://dl.ui.com/unifi/x.xx.xx_version/unifi_sysvinit_all.deb
dpkg -i unifi_sysvinit_all.deb 
rm unifi_sysvinit_all.deb 

Et comme je n'ai pas reçu ce produit du service de presse pour le tester, mais que je l'ai acheté pour l'utiliser, me voilà donc en principe dans la possibilité de migrer. Je fait un export du contrôleur et un export du NVR depuis la CK 2+ (je ne me pose pas la question d'exporter les vidéos de la CK 2+, mais il parait que c'est possible...). Ensuite je débranche l'USG et la CK 2+, c'est important. A partir de la il me suffira en principe d'importer le backup du contrôleur sur l'UDM Pro et ensuite le backup du NVR.

Dans la pratique c'est un peu plus compliqué. Si l'importation se passe bien le redémarrage annoncé ne s'opère pas. Je le fais manuellement au bout d'une heure. Mais au retour je ne peux me connecter localement, ni sur l'ancienne l'IP (192.168.1.1), ni sur l'IP de configuration importée (192.168.210.1). Par contre je peux le faire à distance (à noter que c'est un nouveau portail d'administration). Et là en fouillant je constate deux choses :

  • Le port 11 (SFP) qui assure la liaison avec mon USW-48 a perdu sa configuration en 1 GB FDX (et non il n'est pas auto sense...)
  • Que si l'IP LAN a bien été importée dans la configuration, c'est toujours l'ancienne IP qui répond, et de fait le système ne voit pas les autres équipements importés (SW, AP).

Réactiver le port SFP en FDX est facile, pour que l'IP LAN soit bien prise en compte j'ai finalement rentré l'ancienne à la place de la nouvelle, appliqué la configuration, et ensuite remis la nouvelle, et oh merveille ça fonctionne. Oh merveille mon cul, car c'est vraiment n'importe quoi.

A ce stade tout semble fonctionner, bien que dans cette version non finalisée (6.0.22) certaines choses sont à faire dans la nouvelle admin (VPN) tandis que pour d'autres actions il faudra revenir à l'ancienne interface. beta bug beta bug ! Enfin, tout sauf que si le WAN2 sait bien fonctionner en failover, contrairement à l'USG il est ici impossible de la basculer en agrégation (pas de réponse à ce sujet pour l'instant).

Il y a également depuis le 6.0.x des équipements WI-FI qui décrochent. C'est par exemple systématique sur les ampoules Xiaomi/Yeelight, j'ai tout retourner sans trouver de contournement. Et pour mémoire, quand on migre d'une 5.x vers une 6.0.20 il y a un Vlan only network - 0 qui se crée, je pense que c'est lié à la nouvelle façon de gérer le WI-FI Guest, en attendant il empêche toute connexion WIFI normale et il faut donc l'effacer ou le le changer d'ID (en 100 par exemple). Sur le 6.0 le WI-FI est géré différemment et on peu créer plus de 4 SSID, ce qui est par exemple plus souple pour les différencier en 2 ou 5 Ghz. et en isoler certains (IoT par exemple).

Domotique

Pour information les intégrations Unifi et Unifi Protect que l'on utilise dans Home Assistant fonctionnent et reconnaissent bien l'UDM. Petit hic il faut les réinstaller car je n'ai pas trouvé (pas trop cherché non plus) la façon de changer l'IP du contrôleur et du NVR (dans HA). Le résultat est que certaine entités peuvent changer de nom et qu'il faudra s'adapter.

Accéder au contrôleur depuis l'extérieur

Le plus simple pour administrer le contrôleur intégré à l'UDM est bien sur de passer par le cloud Unifi et l'application. Mais on peu vouloir y accéder directement depuis le port WAN. Pour cela on va commencer par suivre ces recommandations et ainsi créer une règle WAN Local :

Action : Accept
IPv4 Protocol : TCP
Rule Applied : Before pre-defined rules
Destination : Create a new port group with port 443 in the group

A partir de là on peut accéder au contrôleur sur son port par défaut (443) depuis l'extérieur. Sauf que le port par défaut n'est pas une bonne idée et on peut vouloir en faire autre chose. On va donc créer une règle dans Port Forwarding qui redirigera par exemple le port 8443 sur l'IP LAN du contrôleur, et ainsi on y accède via ce port. Au même endroit on peut créer une autre règle pour rediriger le port 443 vers une autre IP du LAN, et si on en a pas besoin on la redirige sur 127.0.0.1 afin de bloquer l'accès externe via le 443... Je sais c'est un peu tordu par les cheveux mais je n'ai pas trouvé mieux ! En ce qui me concerne j'en ai eu besoin pour cette solution de backup. Attention toutefois à verrouiller cet accès sur des IP sources pour plus de sécurité.

Conclusion

Par la force des choses je me retrouve :

  • en prod avec du matériel qui tourne intégralement sur des versions beta. Une pratique à éviter.
  • avec un enregistreur qui n'enregistre plus rien...
  • des équipements WI-FI qui décrochent.
  • avec une foule de bugs dont une agrégation de ports inopérante.

Vous l'aurez compris, la machine à rêver ne m'a pas fait rêver mais perdre beaucoup de temps et me retrouver dans une situation très instable !

  • EDIT 22/09/2020 14:00 : la v6.0.23 du contrôleur est sortie et ça règle bien plus de choses qu'annoncé. Dont mes déconnections avec les ampoules Xiaomi/Yeelight. En fait non, mais ça tient quelques heures au lieu de 5 minutes...
  • EDIT 22/09/2020 17:30 : S'agissant de l'enregistrement sur détection de présence (Protect) et de l'enregistrement il semblerait qu'un paramètre n'ait pas été pris en compte lors de la migration ou qu'il soit nouveau (sur chaque caméra, Recording/Motion Events/Motion Algorithm), il faut faire un choix et aucun des deux n'était sélectionné. Dès lors qu'un disque dur est bien reconnu on a donc bien les enregistrements.
  • EDIT 23/09/2020 04:37 : Il est possible d'intervertir WAN1/WAN2 afin que WAN1 (le principal) profite de l'interface 10 GB sur WAN1 (et sans passer par SSH). Par contre pour l'instant seul le support du mode Failover, pour le Load Balancing (supporté sur l'USG) il faudra repasser plus tard.
  • EDIT 23/09/2020 18:22 : En parlant de plus tard, le SNMP, un peu la base sur un routeur, est caché (New Seetings + search snmp), mais pour autant il ne fonctionne pas. Il parait que apt-get ... etc... On se marre !
  • EDIT 23/09/2020 19:30 : Passage de la 6.0.23 en release et sortie de la 6.0.24 en beta. Ca turbine chez Uniquiti, il faut dire que ça grogne partout ! Nouveaux firmwares UAP/USW. Nouvelles déconnexions sur les ampoules Xiaomi.
  • EDIT 29/09/2020 17:17 : S'agissant des ampoules Xiaomi, j'ai essayé tous les paramètres possibles et imaginable ainsi que les version beta de firmware sans obtenir de résultat. J'en conclu que quelque chose a vraiment changé dans cette version qui a plus une allure de beta que de release. J'ai donc honteusement ressorti un vieil AP Netgear...
  • EDIT 29/09/2020 17:17 : A la version 1.8.4 du firmware les choses sont rentrées dans l'ordre.
  • EDIT 26/01/2022 16:16 : Au fil du temps et des firmwares successifs, parfois chaotiques, les choses sont rentrées dans l'ordre et maintenant l'UDMP fonctionne très bien. Pour Unifi Protect un SSD augmentera nettement les performances.

J'espère pouvoir échanger avec Unifi et qu'ils sauront m'apporter des réponse satisfaisantes à tous ces problèmes. Je mettrais bien sur à jour cet article énervé en fonction de.

Bonus

Quand on accède en local à l'UDM via son IP on a bien sur une erreur SSL. Pour remédier à ça :

  1. On exporte le certificat autosigné unifi.local depuis Chrome vers un fichier .CER (un simple clic sur copier dans un fichier quand on visualise le certificat).
  2. Avec une console MMC on importe ce certificat dans "Trusted Root Certification Authorities" store.
  3. On édite C:\Windows\System32\drivers\etc\hosts et on ajoute IP_de_l'UDM > unifi.local (éventuellement avec HostMan).
  4. Après avoir relancé le navigateur on accès de à https://unifi.local

Sources

 

Zerotier site to site

Pour faire suite aux articles sur Zerotier (1 | 2), voici un résumé de la méthode rapide pour produire un routeur / passerelle afin de mettre en place une infrastructure site to site, et dans mon cas remplacer des routeurs IPSec vieillissants (séries Cisco RV devenus des passoires au fil du temps) pour interconnecter 4 sites. Mon choix s’est porté sur des VM ESXi car j’ai des serveurs VMWare sur chaque site, sauf un ou la VM est sur un Hyper-V, mais on peut également le faire sur un petit PC ou Raspberry Pi auquel cas il faudra faire attention aux débits possibles, le modèle 4 devrait toutefois convenir. 

On installe Debian Stretch ou Raspbian Stretch (pour l’instant je conseille de rester sur Stretch car mes tentatives avec Buster n’étaient pas très stables). Je ne vais pas vous expliquer comment installer Debian, il y a plein de tutos, mais n'oubliez pas de choisir pas d'interface + SSH + Net Tools. On va toutefois éditer l’interface afin de lui donner une IP fixe avec nano /etc/network/interfaces (attention au nom des interfaces qui peuvent parfois différer et qu’il faudra adapter dans la suite, par exemple enp0s3 à la place de eth0) (on passe en root avec su si on ne veut pas jouer avec sudo…).

source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.216.16
netmask 255.255.255.0
gateway 192.168.216.254
nameserver 192.168.216.10
nameserver 8.8.8.8

On installe quelques outils utiles...

apt-get install sudo
apt-get install bash
apt-get install open-vm-tools (uniquement si on est dans un contexte VM)
apt-get install iperf (optionnel, mais ça permettra de faire des tests de performances)

Un petit reboot et on passe à Zerotier, En partant du principe que vous avez déjà un compte et une configuration sur my.zerotier.com.

curl -s https://install.zerotier.com | sudo bash
/usr/sbin/zerotier-cli join 35c145cf9bcc75ab

Ou une variante si on veut installer une version particulière de Zerotier, ici une 1.2.12 sur Rasbian

curl -O http://download.zerotier.com/RELEASES/1.2.12/dist/debian/stretch/pool/main/z/zerotier-one/zerotier-one_1.2.12_armhf.deb
sudo dpkg -i zerotier-one_1.2.12_armhf.deb
sudo systemctl enable zerotier-one
sudo systemctl start zerotier-one
/usr/sbin/zerotier-cli join 35c145cf9bcc75ab

Un petit reboot et on active le routage IPV4  avec sudo nano /etc/sysctl.conf en supprimant le # qui le mettait en commentaire)

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

On vérifie avec sudo sysctl net.ipv4.ip_forward et on récupère le nom du réseau Zerotier avec ip link show et on active les règles suivantes :

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i zt7nndoyds -o eth0 -j ACCEPT (En changeant le nom du réseau Zerotier que l’on a récupéré avec ip link show)

On rend le tout persistant et on fait un redémarrage :

sudo apt-get install iptables-persistent
sudo netfilter-persistent save
reboot

Ensuite on se rend sur my.zerotier.com pour ajouter les routes managées. Vous allez me demander pourquoi certaines sont en /23 et non /24. Simplement parce que si on les laisse en /24, ce qui semble logique, une machine cliente Zerotier (typiquement un PC portable) connectée sur un de ces réseaux ne pourra pas voir le réseau local sans ça.

Autre remarque, si vous avez configuré des règles de flux afin de restreindre certains clients Zerotier, n’oubliez pas de créer une capacité superuser et de l’appliquer aux machines qui servent de passerelle afin d’autoriser tout le trafic entre vos sites.

cap superuser
  id 2000 accept;

Pour mettre à jour Zerotier :

apt-get update
apt-get install zerotier-one

Voilà de quoi remplacer IPSec afin autant de sécurité et d’efficacité pour peu que le tout soit bien configuré et géré. N’oubliez pas non plus de changer les routes, soit en ajoutant une route statique vers la passerelle sur les routeurs de chaque site, soit via le DHCP (celui de Windows le permet avec l’option 121, mais n’est pas reconnue par tous les clients, ou encore avec un route add (sous Windows 10 il faut le faire en mode admin).

Enfin, Iperf va vous permettre de tester le débit utile. On voit sur la capture suivante une différence significative entre deux tests, sur le second j’ai passé la ram de la VM de 1 GB à 2 GB et de 1 vCPU à 2 vCPU. A vous d’ajuster, mais il ne faut pas perdre de vue que VPN = Crypto et que cela nécessite un peu de ressources…

Bonus

DNS

Pour les machines itinérantes se posera la question de la résolution des noms. Ce n’est théoriquement pas compatible RFC, mais rien ne vous empêche dans la pratique de renseigner dans un DNS public des enregistrements de type A associés à des IP privées et ainsi pouvoir joindre facilement les machines du réseau local via une machine ZT…

Netbios

L'accès aux partages SMB passera par le port 445, par contre si vous ne voulez pas que le Netbios bave entre les sites et vous retrouver avec des machines clientes Zerotier dans votre explorateur Windows, je vous conseille de bloquer les ports suivants :

drop
dport 137,138,139
;

Sources

https://mangolassi.it/topic/19493/zerotier-site-to-site 
https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one

Zerotier VPN / SDN et sécurité et DNS

Dans le précédent article on a vu comment créer facilement un SDN avec Zerotier qui de part ses possibilités explose les deux autres possibilités dont j’avais parlé. Un VPN SDN c’est un réseau étendu qui peu s’intégrer dans un LAN existant ou être totalement virtuel. Dès lors se pose la question de la sécurité des accès et il convient de considérer principalement à deux niveaux :

  • Sécurité d’accès aux ressources au niveau machine assurée par celle-ci ou une solution globale comme Active Directory. Dans un petit réseau local les utilisateurs ont tendance à laisser pas mal de choses ouvertes, voire très peu protégées. Dès lors que l’on ouvre un réseau à un SDN il conviendra de renforcer la sécurité des équipements.
  • Sécurité d’accès au niveau IP. Sur un LAN ou plusieurs LAN interconnectés via des VPN cette sécurité est assurée au niveau des routeurs et des switches afin d’isoler les départements, entremises, etc…

Dès lors que l’on étend un réseau à un SDN comme Zerotier on va se retrouver avec des devices isolés et il faudra définir ce que ces devices auront le droit de faire. Cela est rendu possible de façon centralisée via un système de règles relativement puissant qui se base sur l’ID de chaque client ZT qui va interagir avec des règles basées sur des tags, les adresses IP ZT ou internes aux réseaux, les ports et les protocoles. Je vais me contenter de donner ici quelques exemples que chacun adaptera à ses besoins.

On se base principalement sur 3 expressions

  • DROP, on supprime le paquet et on termine l’évaluation de la règle.
  • BREAK, on termine l’évaluation de la règle mais on accepte l’évaluation par une autre capacité.
  • ACCEPT, on autorise.

On va se servir de la règle de base et l'améliorer

Pour autoriser uniquement les trames Ethernet IPv4, IPv4 ARP.

drop
    not ethertype ipv4
    and not ethertype arp
    and not ethertype ipv6;

Pour éviter toute forme d’IP spoofing, mais ça bloque également les IP non ZT. Donc à exclure si on utilise des ponts vers des réseaux existants.

drop
    not chr ipauth;

Pour autoriser à tout le monde par exemple SSH, HTTP et HTTPS

accept
    ipprotocol tcp
    and dport 22 or dport 80 or dport 443;

Ici on va créer un TAG “department” que l’on va associer à des clients, et à partir de là on définira des possibilités. Ces TAG peuvent permettre de faire communiquer ensemble des clients d’un même service en comparant leur niveau (tdiff department 0 ou 0 est la différence acceptable entre deux clients pour être valide), mais on peut aussi utiliser ces TAG avec TSEQ pour affecter des droits.

tag department
    id 1000 #ID est arbitraire mais unique
    enum 100 Archi
    enum 200 Dev
    enum 300 Services
    enum 400 Finances
    enum 500 Ventes;

Autoriser Windows CIFS et Netbios aux clients d'un même groupe (différence = 0)

accept
    ipprotocol tcp
    and tdiff department 0
    and dport 139 or dport 445;

Autoriser les clients tagués 300 (to_LAN1_LAN2) à accéder à des réseaux internes spécifiques via un pont :

accept tseq department 300 and ipdest 192.168.1.0/24;
accept tseq department 300 and ipdest 192.168.2.0/24;

Pour supprimer les paquets TCP SYN,!ACK qui ne sont pas explicitement autorisés

break
  chr tcp_syn             # TCP SYN (TCP flags will never match non-TCP packets)
  and not chr tcp_ack     # AND not TCP ACK;

Pour interdire les destinations qui ne sont pas explicitement autorisées ci-dessus

break ipdest 192.168.1.0/24;
break ipdest 192.168.2.0/24;
break ipdest 192.168.3.0/24;

Si restreindre les IP est utilisé pour contrôler l’accès à des machines accessibles via un bridge, Il faut également pouvoir rendre inaccessibles certains clients ZT sensibles. Le modèle utilisé pour le contrôle d'accès ressemble à la façon dont les organisations militaires classifient les données. Les informations sont considérées classifiées et seules les personnes disposant du niveau de classification requis sont autorisées à y accéder. Il ne s'applique hélas pas aux clients non ZT

Au départ, les membres se verront attribuer un tag classified par défaut de 0 ("no"). Ceux-ci peuvent communiquer puisque leur étiquette de classification sera zéro. Pour restreindre l'accès à un membre, définissez son tag de classification sur secret (1) ou top (2). (Dans cet exemple, il n'y a pas de différence, mais deux niveaux sont inclus au cas où vous voudriez mettre en œuvre une sorte de segmentation plus détaillée basée sur ceux-ci.). Ainsi, la première correspondance (not tor classified 0) sera vraie et le paquet sera abandonné, à moins que les deux membres en communication aient au moins un flag (équipe) en commun grâce au bit clearance (tand clearance 0). (et si vous n’avez pas compris allez voir la doc en anglais…).

# Is this member classified?
tag classified
  id 2
  enum 0 no
  enum 1 secret
  enum 2 top
  default no
;

# Clearance flags (a bit like groups)
tag clearance
  id 1
  default 0
  flag 0 staging
  flag 1 production
  flag 2 financial
  flag 3 security
  flag 4 executive
;

# If one party is classified, require at least one overlapping clearance bit
break
  not tor classified 0
  and tand clearance 0
;

Pour ne pas être en reste, on va bien sur se créer une capacité "superuser" que l’on pourra affecter à des clients ZT pour passer outre les interdictions…

cap superuser
  id 2000
  accept;

Et enfin on accepte ce qui n’est pas interdit….

accept;

Ce ne sont que quelques exemples et en parcourant la documentation disponible on s’apercevra que les possibilités sont énormes. Je vais essayer de compléter cet article au fil de l'eau, et vos commentaires sont comme toujours les bienvenus.

DNS

A partir de la version 1.6 il est possible d'activer le DNS pour les clients ZT, ce qui veut dire que pour un ou plusieurs domaines spécifiques on pourra faire appel à un ou plusieurs serveurs DNS. On commence par renseigner l'IP du serveur DNS dans l'interface d'administration :

Ensuite au niveau du client il va falloir entrer la commande suivante (en mode admin) et ou $networkID sera l'ID de votre réseau.

zerotier-cli set $networkID allowDNS=1

Il faut bien avoir à l'esprit qu'on agit sur NRTP (Name Resolution Policy Table) sous Windows et que l'on ne verra rien avec un IPConfig... Je suppose que sur MacOS ou Linux  il existe une équivalence. Ce qui compte c'est que ça fonctionne et qu'il est désormais inutile d'encombrer vos DNS publics avec des adresses privées pour palier à ce manque !

Sources

 

Zéro VPN !

On va parler aujourd’hui d’une approche un peu différente des VPN (Virtuel Private Network).

Le principe d'un VPN est de créer un tunnel de données sécurisé dans lequel on routera des réseaux privés en IPV4 ou IPV6. On peu aborder les VPN en plusieurs usages :

  • VPN Remote : il s’agit pour un utilisateur itinérant de se connecter au réseau de son entreprise ou de son domicile depuis un terminal itinérant. On configure généralement ce service au niveau du routeur ou du firewall, plusieurs protocoles sont possibles selon le niveau de sécurité souhaité (PPTP, OpenVPN, L2TP, SSL VPN, etc). Ensuite on utilise soit le logiciel intégré à l’OS client, soit un logiciel spécifique, le tout étant plus ou moins compliqué à mettre en œuvre selon les protocoles. PPPT est le plus simple, c’est aussi le moins sécurisé.
  • VPN Site to Site : il s’agit ici d’interconnecter deux réseaux d’entreprise (le siège et un bureau distant par exemple) afin de rendre transparent l’accès aux équipements. C’est souvent fait en IPSec, mais il est possible d’utiliser d’autres protocoles (SSL VPN, OpenVPN, etc.), ça reste une affaire de spécialistes réseaux et ça se complique quand les deux extrémités utilisent des équipements hétérogènes.
  • VPN Internet : il s’agit ici de masquer son adresse IP afin de se cacher ou simplement laisser croire au service distant qu’on se situe sur une autre partie du globe. Il suffit généralement de contracter un abonnement et d’installer le logiciel fourni.

Tous ces VPN utilisent peu ou prou les mêmes technologies et commencent dater. Vu qu’elles sont massivement utilisées par les entreprises elles sont sures et fiables dès lors qu’elles sont mises en œuvre par de vrais spécialistes. Vous l’aurez compris, la chose n’est pas toujours des plus simples. Si le grand public amateur de DIY parviendra généralement à mettre en œuvre ces solution avec un peu de perspicacité et quelques nuits blanches, il existe des solutions alternatives qui peuvent s’avérer plus simple.

ZERO !

Zéro, comme zéro configuration. Un nouveau type de logiciels voit le jour depuis quelques temps, ils comportent généralement un petit client propriétaire à installer sur les devices (Windows, Mac, Linux, mobiles, etc…) et une interface de gestion quelque part dans un cloud privé ou public. Au niveau du device on ne fait que se connecter, alors que depuis l’interface de gestion on décidera de qui voit quoi. Cela va permettre la création de réseaux point à point et multipoints en mode peer to peer, les échanges se faisant toujours de point à point, le site central ne servant qu’à la gestion. Je vais en citer 3 selon les usages, mais il en existe d’autres et Google est votre ami !

Wirelends

C’est le plus simple, il fonctionne en deux clics mais il offre out of the box la possibilité de se connecter à l’ensemble des équipements du réseau distant, voire même d’accéder à Internet via le réseau distant. Cependant c’est du point à point et uniquement entre deux points en même temps. C’est la solution la plus simple que je n’ai jamais trouvée et bien sûr c’est gratuit. Je ne l’ai testé que sous Windows, mais il est possible d’installer le service Linux sur un équipement existant afin de s’en servir de passerelle. C’est gratuit, mais pas Open Source, donc quid possible au niveau sécurité. Dans le même genre très facile et sous Windows seulement on trouve également RAdmin VPN.

NeoRouter

Celui là je l’utilise depuis quelques années, pour par exemple donner accès à des serveurs aux développeurs. Il comporte deux parties, un client multi plateformes très basic et un peu daté, et un logiciel d’administration que l’on peu installer n’importe ou si on ne choisit pas la version commerciale ou ce service peut être fourni par l’éditeur. On peu définir des utilisateurs et des autorisations par machines et par utilisateurs. Chaque client obtiendra une adresse IP privée supplémentaire qui lui permettra de joindre les autres machines de ce réseau privé multipoint. C’est simple, basic et ça fait le job mais ce n’est pas Open Source et il sera pour certains usages nécessaire de passer à la caisse. Impossible également de bridger un client qui pourrait servir de passerelle pour accéder aux autres équipements du réseau.

Zerotier

Et enfin, celui qui me semble le plus intéressant, Zerotier. Ici on est face à un projet Open Source sous licence GPL. Si la philosophie rappelle celle de NeoRouter, le projet semble bien plus moderne et aboutit. Je me suis contenté au départ de créer un tunnel entre deux PC, en fait je l’ai fait entre trois postes et ça c’est très simple à mettre en place. C’était l’objectif de mon test et c’est réussi. Il est cependant possible de créer des réseaux multipoints complexes et de grande ampleur avec des possibilités de routage vers d’autres réseaux grâce à des bridges et de gérer très finement les autorisations, mais là il va falloir y passer un peu de temps. On est face à un produit intégrable en entreprise, mais il existe une version communautaire avec très peu de restrictions qui est disponible gratuitement.

Pour faire du point à point c’est donc simple et facile, il suffit de se créer un compte, de créer un réseau et de choisir un range d’IP, installer le client, sous Windows il n’y a qu’à cliquer et se connecter ou rentrer la clé API. A partir de là les deux points communiquent, le ping est ok.

Pinging 10.147.20.28 with 32 bytes of data:
Reply from 10.147.20.28: bytes=32 time=32ms TTL=64
Reply from 10.147.20.28: bytes=32 time=31ms TTL=64
Reply from 10.147.20.28: bytes=32 time=30ms TTL=64
Reply from 10.147.20.28: bytes=32 time=30ms TTL=64

Mais là ou ce logiciel devient intéressant c’est qu’il est possible de le configurer une machine du LAN en passerelle. Entendons par là qu’une machine sur mon LAN servira de passerelle et rendra accessible toutes les autres machines.

Sous Windows

On part du principe que Zerotier est installé et fonctionne entre deux points comme vu ci-dessus. Sur la console d’administration on coche Do Not Auto-Assign IPs sur l’interface virtuelle de la machine qui va servir de passerelle et on lui affecte une IP fixe dans le range choisit, ici 10.147.20.28. 

Sur cette même console on défini une Managed Routes pour définir que le LAN 192.168.210.0/24 sera accessible via 10.147.20.28.

EDIT : en fait il vaut mieux faire du /23 ce qui permettra de voir le réseau local quand on est localement connecté sur un réseau appartenant à une route managée.

Il faut ensuite activer le routage IP entre les interfaces, routage qui n'est pas actif par défaut. Pour ça on lance regedit et on cherche la clé IpEnableRouter qui se trouve sous:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

On la passe la valeur de 0 à 1 pour activer le TCP/IP forwarding pour toutes les connections actives sur la machine. Et surtout on relance la machine. A partir de là on peu depuis la machine distante faire un ping sur l’IP LAN de la machine passerelle.

Pinging 192.168.210.28 with 32 bytes of data:
Reply from 192.168.210.28: bytes=32 time=63ms TTL=64
Reply from 192.168.210.28: bytes=32 time=36ms TTL=64
Reply from 192.168.210.28: bytes=32 time=30ms TTL=64
Reply from 192.168.210.28: bytes=32 time=30ms TTL=64

Si l’on veut rendre accessible d’autres machines, il faudra bien sur définir une route statique sur celles-ci (avec un -p si on veut que cette route soit persistante :

C:\route add 10.147.20.0 mask 255.255.255.0 192.168.210.28 -p

Et on pourra depuis la machine distante faire un ping sur l’IP LAN de la machine située sur le LAN en passant par la passerelle.

Pinging 192.168.210.24 with 32 bytes of data:
Reply from 192.168.210.24: bytes=32 time=33ms TTL=127
Reply from 192.168.210.24: bytes=32 time=31ms TTL=127
Reply from 192.168.210.24: bytes=32 time=30ms TTL=127
Reply from 192.168.210.24: bytes=32 time=30ms TTL=127

Sous Linux

Une VM linux deviendra une bonne passerelle. Mais on peu aussi installer ça sur un Raspberry ou une autre machine existante, un Jeedom par exemple... On part du principe que Linux est installé avec une IP LAN fixe et que vous êtes connecté en root.

Pour installer Zerotier on se servira de ce script (et on hésite pas à aller lire les informations disponible sur le site de Zerotier, notamment les faqs et leur communauté et aussi sur Redit) :

[root@zero /]# curl -s https://install.zerotier.com/ | sudo bash

Ça va nous retourner une ID client que l’on rentre manuellement dans le manager.

Ensuite on découvre quelques commandes

[root@zero /]# /usr/sbin/zerotier-one -d < pour faire un bind, mais pas toujours utile…
[root@zero /]# /usr/sbin/zerotier-cli join 8044c2551c550881 < ID Réseau que l’on trouve dans le manager
[root@zera /]# /usr/sbin/zerotier-cli listnetworks

Pour activer la passerelle

On édite le fichier /etc/sysctl.conf (avec nano par exemple) pour supprimer le # devant la ligne net.ipv4.ip_forward=1

Avec un ip a on repère le nom de l’interface virtuelle Zerotier (ici : zt7erf5fdc)

Ensuite on édite le fichier /usr/local/sbin/firewall.sh et on lui colle ce qui suit en renseignant correctement le nom de l’interface virtuelle (attention, selon les configurations il faut parfois remplacer eth0 par ensXX)

/usr/local/sbin/firewall.sh

# !/bin/sh
# A very basic IPtables / Netfilter script /etc/firewall/enable.sh
# PATH='/sbin'
# service networking restart > /dev/null 2>&1

# Flush the tables to apply changes
iptables -F

# Default policy to drop 'everything' but our output to internet
iptables -P FORWARD ACCEPT
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT

# Allow established connections (the responses to our outgoing traffic)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow local programs that use loopback (Unix sockets)
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -t nat -A POSTROUTING -o ens32 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7erf5fdc -o ens32 -j ACCEPT

sleep 4
service networking restart

sleep 4
service ssh restart

exit 0

Un petit reboot et on peut maintenant depuis la machine distante faire un ping vers n’importe quelle machine du LAN dont la route idoine aura été renseignée.

Pour activer le pont (mode Bridge)

Pour l’instant on parlait de routage, ce qui implique que les machine à joindre aient une route statique vers celle qui va servir de routeur vers le réseau Zerotier. Mais il y a une autre option expliquée ici, faire un bridge. Comme vu plus haut on prépare une petite machine Linux sur laquelle on installe Zerotier, on y colle une IP Zerotier fixe + l’option Bridge et on la définie dans Managed Route en tant que celle qui va nous permettre de joindre le réseau local. On édite le fichier /etc/sysctl.conf (avec nano par exemple) pour supprimer le # devant la ligne net.ipv4.ip_forward=1 et un sysctl -p pour recharger la configuration. Avec un ip a on repère le nom de l’interface virtuelle Zerotier (ici : zt7erf5fdc) et on lance les commandes suivantes :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7nnf5jtx -o eth0 -j ACCEPT

Pour rendre ces commandes persistantes (j'apprends Linux en même temps...) :

apt-get install iptables-persistent

Et si tout ça se passe dans une VM autant installer les Open VMware Tools (ça aidera notamment pour les sauvegardes) :

apt-get install open-vm-tools
reboot

Voilà comment depuis une machine itinérante ou un VPS je peux joindre n'importe quelle machine de mon réseau local de façon simple et sécurisée. Et si ce réseau comporte d'autres routes, il sera également possible d'y accéder, pour peu qu'on les définisses dans la manager... Ce qui veut concrètement dire que je peux me passer des routeurs IPSec qui gèrent des VPN entre plusieurs sites et les remplacer par un bête Raspberry à deux balles...

 

Sur un routeur....

J'ai parlé ici de Windows et Linux, mais ça existe aussi pour Mac, IOS et Android, mais on peu aussi faire un bridge sur un routeur, un Edge Router par exemple. Dans ces cas je vous sugère de suivre ces deux tutos (1 | 2), une fois Zerotier installé c'est du pareil au même, sauf qu'ici notre passerelle c'est le Switch...

sudo iptables -t nat -A POSTROUTING -o switch0 -j MASQUERADE
sudo iptables -A FORWARD -i switch0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i zt7nnf5jtx -o switch0 -j ACCEPT

Par contre pas d'iptables-persistent ici, donc on crée un fichier avec vi (oui et les commandes sont ici) :

sudo vi /config/scripts/post-config.d/myfwd

et on y colle la config qu'il exécutera au démarrage :

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A POSTROUTING -o switch0 -j MASQUERADE
iptables -A FORWARD -i switch0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7nnf5jtx -o switch0 -j ACCEPT

Et si le routeur est sur une IP publique il faut également configurer le firewall car avec nos bricolages il n'ets plus géré par le firewall interne au routeur... Donc on ajoute quelques règles à notre fichier :

  • On ferme tout le trafic entrant sur le port Ethernet WAN (ici eth0)
  • On ouvre le port 9993 en tcp et udp (le port Zerotier)
  • On autorise le management distant via certaine IP et sur certains ports (ici 22, 80 et 443)
  • Et on peut aussi rerouter des ports vers des services internet (ici en sollicitant l'ip publique sur le port 2222 je joint le port 22 d'un serveur interne).
iptables -A INPUT -i eth0 -j DROP
iptables -I INPUT -i eth0 -p tcp --dport 9993 -j ACCEPT
iptables -I INPUT -i eth0 -p udp --dport 9993 -j ACCEPT

iptables -I INPUT -i eth0 -p tcp -m multiport -s 69.69.69.69 --dports 22,80,443 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp -d  62.63.64.65 --dport 2222 -j DNAT --to 192.168.1.10:22 -s 69.69.69.69

Ensuite on rend le fichier exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Et pour terminer on teste avec NMAP qu'il ne reste pas de portes ouvertes... Pour tester tous les ports (0-65534) ou seulement quelques uns en restreignant ce range...

nmap -Pn -p 0-65534 69.69.69.69

Qu'en faire ?

En substance Wirelends rendra service dans un cadre DIY, NeoRouter, un peu daté se situe entre les deux, en revanche Zerotier (ou Wireguard dont on reparlera) propose une approche d’entreprise décentralisée intéressante. Traditionnellement les collaborateurs travaillent dans l’entreprise et accèdent aux ressources locales ou distantes vie des VPN point à point. Quant ils sont itinérants on colle sur leur terminal un client VPN configuré localement par l’IT qui devra repasser si des modifications sont à effectuer.

L’idée des VPN, je dirais plutôt SDN, tels que Zerotier est d’installer un client générique, pas incompatible avec d’autres clients, et entièrement configurable d’un point central. De plus, contrairement à NeoRouter, l’approche de Zerotier est multi réseaux, l’utilisateur pourra ainsi faire partie de plusieurs réseaux privés en même temps. Certains sur des forums on même imaginé qu’il découle de cette approche une standardisation car il n’est pas impossible que de plus en plus d’internautes auront besoin d’accéder simultanément à plusieurs réseaux privés correspondant à plusieurs activités à sécuriser… Et ici on va justement parler sécurité autour de Zerotier.

Sources

https://gist.github.com/ort163/787000d371dae49a4a399b0f6a7aab56 
https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7536656/Running+ZeroTier+in+a+Docker+Container 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7438339/Layer+2+Bridging+with+LEDE+OpenWRT 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7471125/Layer+2+Bridging+of+Ethernet+and+ZeroTier+Networks+on+Linux 
https://www.reddit.com/r/zerotier/ 
https://news.ycombinator.com/item?id=16329046 
https://blog.reconinfosec.com/build-a-private-mesh-network-for-free/ 
https://github.com/cormacrelf/terraform-provider-zerotier 
https://0wned.it/2017/12/04/building-a-zerotier-bridged-network/ 
https://mangolassi.it/topic/8566/zerotier-bridging-configuration 
http://espressobin.net/ 
https://gist.github.com/adamierymenko/7bcc66b5f7627699236cda8ac13f923b 
https://ngrok.com/ (pas exploré mais ça peut être intéressant dans certains contextes)

 
 

 

 

Sophos XG Firewall Home Edition

On parle souvent de PF Sense et d’autres firewalls plus ou moins gratuits, moi je vais vous parler de Sophos XG dont la version Home est une version logicielle gratuite qui est parfaite pour un environnement de test ou un home lab. C'est le même logiciel que l'on retrouve sur les appliances du constructeur à ceci près qu'il faudra le faire tourner sur une petite machine ou une VM.

Il offre une protection complète de votre réseau, notamment anti-malware, filtrage Web et sécurité Web, contrôle des applications, IPS, gestion du trafic, VPN, rapports et surveillance, et bien plus encore. Le pare-feu Sophos XG Free Home Use contient son propre système d'exploitation, par conséquent, un ordinateur dédié distinct est nécessaire, qui deviendra une Appliance de sécurité entièrement fonctionnelle. Parfait pour un NUC ou une VM. Si Sophos est utilisable pour protéger les services entrants (mail, web) en direct ou en reverse proxy, il prend en compte très finement le trafic sortant afin de lisser et hiérarchiser le trafic des applications sur votre connexion Internet et même vous abonner à plusieurs FAI pour obtenir davantage de bande passante ou de résilience en cas de panne de l'un d'eux. Il est possible de surveiller et contrôler la navigation web, d'utiliser le filtrage Web pour empêcher les sites de vous infecter de virus et de logiciels espions, empêchez vos enfants de surfer sur des sites malveillants et d'obtenir un rapport complet sur l'activité de votre maison. On peut également configurez des horaires d’accès ou des quotas d’utilisation pour les membres de la famille qui perdent peut-être trop de temps en ligne. C'est également un serveur VPN pour accéder à votre réseau à distance depuis n'importe où dans le monde. Sophos étant également un fournisseur notoire d'antivirus, cette fonctionnalité est intégrée. Les moteurs d'analyse Dual AV bloquent les virus dans les téléchargements de fichiers, les pièces jointes aux e-mails et les sites web malveillants. Sophos les stoppe sur la passerelle avant qu'ils ne puissent attaquer vos ordinateurs. Et bien plus encore ...

Ce dont vous avez besoin,  simplement un ordinateur compatible Intel avec deux interfaces réseau ou une VM. (Tout système d'exploitation précédent ou tous les fichiers présents sur l'ordinateur seront écrasés lors de l'installation de XG Firewall Home Edition.) L'édition familiale et gratuite est limitée à 4 cœurs et à 6 Go de RAM. L'ordinateur peut en avoir plus que cela, mais XG Firewall Home Edition ne pourra pas l'utiliser. Mais c'est déjà largement suffisant dans bien des cas d'exploitation.

Ah si, j'oubliais, dans le cadre d'un usage familial il vaut mieux que l'un des membres de la famille soit un bon geek, car ne nous y trompons pas, Sophos XG est un vrai produit d'entreprise qui ne s'installe pas en un clic...