Sur le même principe que mon article "Limiter les accès à l'interface admin de Yunohost via Nginx". J'ai un site qui tourne sous le SPIP installé sur un Yunohost sur un VPS. Je souhaite restreindre l'accès de l'interface d'administration de SPIP (accessible via le chemin ./ecrire)

Là encore, il suffit de modifier la configuration de Nginx (à la main cette fois ci) pour limiter les accès à certaines IP connues. En l'occurence celle de chez moi (ma Freebox) et si je suis en extérieur, je passe par le VPN Wireguard et me retrouve alors de nouveau avec mon IP publique. Attention, il faut à bien penser à ajouter son IPv6 publique car sinon, on se retrouve bloqué (et on cherche alors que la solution est simple).

# Sécurisation de l'accès à l'espace d'Administration de SPIP

$sudo nano /etc/nginx/conf.d/spip.d/spip.conf

location / { (...) location ~/ecrire/ { allow AAA.BBB.CCC.DDD; allow 2a01:XXX:XXX:XXXX::XXX:XXX; deny all; }

On teste et on relance Nginx

$sudo /etc/init.d/nginx -t $sudo /etc/init.d/nginx reload

On peut tester en se connectant depuis une connexion extérieure (partage de connexion du téléphone par exemple). Et si l'IP qui demande à afficher la page n'est pas autorisé, on a bien un message d'erreur Nginx.

# Objectif

Pour un serveur Yunohost qui est chez moi, je veux n'autoriser les accès à l'interface d'administration que depuis les IP du réseau local. Et si je suis en extérieur, je dois passer par le VPN Wireguard (de la Freebox), qui fait en sorte que je me retrouve sur le réseau local. Les accès aux services sont quand à eux protégés par le SSO (ou pas si ouvert, selon les applications).

# Sécuriser acces Admin Yunohost

L'interface d'administration dispose d'un champ permettant de restreindre l'accès à certaines IP. C'est dans cette interface que l'on saisit les IP.

On peut tester en se connectant depuis une connexion extérieure (partage de connexion du téléphone par exemple). Et si l'IP qui demande à afficher la page n'est pas autorisé, on a bien un message d'erreur Nginx.

# Configuration nginx

Ce qui se passe dans les coulisses

Il est assez facile de retrouver la liste des fichiers modifiés, qui est la suivante :
– /etc/nginx/conf.d/yunohost_api.conf.inc
– /etc/nginx/conf.d/yunohost_admin.conf.inc
– /etc/nginx/conf.d/security.conf.inc

Et dans le contenu de ce fichiers, on a des nouvelles lignes (allow/deny) avec les adresses IP

location /yunohost/admin/ { alias /usr/share/yunohost/admin/; default_type text/html; index index.html; allow 192.168.0.0/24; # Autorisation de la toute la plage d'IP locale allow 192.168.27.68; #Adresse obtenue via la connexion VPN Wireguard allow 2a01:e0a:XXX:XXX::XXX:XXX; #Autorisation de l'IPv6 de ma machine deny all;

J'utilise le VPN wireguard sur un smartphone dont je partage la connexion. Je me suis posé la question suivante : "Est-ce que les machines utilisant ce partage de connexion passent par le tunnel VPN du client du smartphone ?"

# Ca marche ?

J'ai testé. La réponse est simple : Non. Les machines qui se connectent via le partage de connexion (hotspot) d'un smartphone ne passent pas automatiquement par le tunnel VPN actif sur le smartphone. La connexion Wireguard est établie uniquement pour la connexion du téléphone et non pas pour la connexion partagée en Wifi, malheureusement.

# Dans le détail

Quand on active un VPN (comme WireGuard) sur le smartphone, seul le trafic du smartphone passe par le tunnel VPN. Quand on actives le partage de connexion (hotspot), len smartphone crée un réseau local (Wi-Fi ou USB) pour les autres appareils. Ce réseau local est indépendant du tunnel VPN du smartphone, sauf configuration spécifique. Les appareils connectés au hotspot utilisent la connexion internet du smartphone, mais pas le tunnel VPN. Leur trafic passe directement par la connexion mobile (4G/5G) du smartphone, sans être chiffré ou routé via le VPN.

#La solution

La solution reste donc de lancer le client Wireguard sur l'appareil qui se connecte au travers de la connexion Wifi.

# Et comment on teste ?

Pour vérifier si un appareil connecté au hotspot utilise le VPN, c'est très simple. On ouvre un navigateur sur un site qui affiche l'IP publique comme whatismyip.com et on compare cet adresse IP publique du smartphone à celle du serveur VPN qui fait tourner le service Wireguard et qui est le point de sortie du tunnel. Si elles sont différentes (si ce n'est pas l'adresse du serveur VPN), le trafic ne passe pas par le VPN.

Par le présent article je souhaiterai faire une sensibilisation qui relève de l'hygiène numérique.

# Récupération d'un PC abandonné

Dans la rue, pas très loin de chez moi, sur un trottoir devant une entreprise type PME, j'ai trouvé un PC abandonné. Je l'ai ramené chez moi pour voir si il y avait des choses de récupérable. Très poussiéreux, des traces de brûlure sur la carte mère. Rien. Si ce n'est un SSD et un disque dur.

Dans ma réserve de vielles machines, j'ai pris une tour, j'ai branché SSD et disque dur, écran, clavier, souris. Mais surtout pas le réseau. On est donc face à un PC dit "airgap"

# Airgap ?

Un PC airgap (ou "air-gapped computer" en anglais) est un ordinateur qui est physiquement isolé des réseaux non sécurisés, notamment d'Internet et des autres réseaux locaux. Le terme "airgap" signifie littéralement "espace d'air" : l'idée est qu'il n'y a aucun lien physique ou sans fil entre cet ordinateur et d'autres systèmes ou réseaux, ce qui le protège contre les cyberattaques provenant de l'extérieur.

Pourquoi utiliser un PC airgap ?
– Sécurité maximale : Il est utilisé pour protéger des données extrêmement sensibles, comme celles des gouvernements, des militaires, des infrastructures critiques (centrales nucléaires, systèmes bancaires, etc.) ou des entreprises manipulant des secrets industriels.
– Protection contre les cyberattaques : Sans connexion réseau, il est presque impossible pour un pirate informatique d'accéder à distance à l'ordinateur ou d'exfiltrer des données.
– Prévention des fuites de données : Les logiciels malveillants ou les ransomwares ne peuvent pas se propager vers ou depuis un PC airgap, sauf en cas de manipulation physique (par exemple, via une clé USB infectée).

# Contenu des disques

Sur le SSD, un OS Windows avec un compte nominatif verrouillé. Je redémarre donc avec une clef USB sur un live-USB d'une distribution Ubuntu. Et là.... j'ai bien accès à l'intégralité du contenu des deux disques : ils ne sont pas chiffrés !!!

Quand je dis intégralité, je ne suis pas allé plus loin que ce qu'illustre la capture d'écran.
J'aurai pu chercher des informations, informer sur les clients de l'entreprise et les informer, contacter la CNIL ou autre. Je n'ai rien fait de tout ça. Car c'est très certainement illégal.
J'ai de suite formaté le disque, regardé son état SMART (pour pouvoir si il est encore utilisable) et je l'utilise désormais pour du stockage de données volatiles (des VM de tests dans Proxmox). Les données ont disparues à tout jamais (pour être sûr et pour vérfier la santé du disque, un formatage bas niveau de plusieurs passages a été réalisé)

# Ce qu'il faut donc retenir

Plusieurs leçons :
– Abandonner une machine dans la rue est tout sauf écologique : il y a des recycleries pour recycler le matériel. C'est ce que j'ai fait (porter la machine en recyclerie)
– Abandonner un PC avec des données sur des disques dur non chiffrés : c'est très simple d'y accéder, de les consulter, de les récupérer.... et d'utiliser ces données à des fins malveillantes (même si c'est répréhensible par la loi). Si ce n'est pas chiffré, on formate le disque avec un outil qui va bien. Pas une fois (des outils comme Testdisk /recurva sont là pour récupérer les données) mais plusieurs fois, y a des tutoriels sur le sujet : la commande shred est très bien pour ça !
– L'entreprise a eu droit à un petit courrier anonyme et moralisateur de sensibilisation !

# Introduction & Adguard

J'ai en brouillon plusieurs articles et tutoriaux sur Adguard (l'équivalent de Pihole) que je fais tourner chez moi en local sur une machine via Yunohost. L'IP de la machine Yunohost (et donc de Adguard) est défini comme DNS par défaut fournie aux machines du réseau qui se connecte en DHCP (la Freebox sert de routeur). Ainsi toutes les machines du réseau bénéficie d'un filtrage des DNS pour bloquer publicités, tracker etc. (Fonctionnalités apportées par un PiHole/Adguard).

Le présent tutoriel n'a rien de spécifique et s'adapte facilement à toute configuration où il y a un serveur PiHole/Adguard et un serveur VPN Wireguard.

# Wireguard sur la Freebox

Sur la Freebox, j'ai activé la fonctionnalité de serveur Wireguard. Ainsi quand je suis à distance, je peux me connecter via un client sur le service VPN Wireguard de la Freebox (sur smartphone ou PC) et je surfe alors comme si j'étais chez moi (en affichant l'IP publique de ma box Freebox et non plus celle du réseau local), je sécurise ma connexion en chiffrant entre mon appareil et ma Freebox chez moi.

Dans l'interface de Freebox OS, j'ai crée un utilisateur, un compte Wireguard et récupéré le fichier généré.

On trouve facilement des tutoriels sur comment faire.

# Quelques explications sur le fichier généré

J'ai activé le serveur VPN sur différentes Freeebox (chez mes parents, une Mini 4k ; chez moi, une Freebox Révolution).

Voici les explications sur le contenu du fichier à fournir au client Wireguard. Comprendre permettra de modifier et d'adapter par la suite à des besoins plus avancés (qui ne sont pas le sujet de cet article).

[Interface] PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Address = 192.168.27.68/32 DNS = 212.27.38.253 MTU = 1360 [Peer] PublicKey = /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= Endpoint = 82.XX.YY.ZZ:ABCD AllowedIPs = 0.0.0.0/0, 192.168.27.64/27, 192.168.0.0/24

Avec cette configuration, quand on se connecte avec le client Wireguard, on a accès au réseau local et on passe par la Freebox pour aller sur Internet. C'est comme si on était sur le réseau local.

L'adresse dans l'Interface est toujours sur la plage 192.168.27.6X/27.
La plage IP fournie en DHCP au réseau local est sur la plage 192.168.X.0/24

Pour que Wireguard puisse atteindre le réseau privé, il faut autoriser le dit réseau dans les AllowedIPs du Peer et il faut aussi autoriser le trafic de l'IP du client à atteindre le réseau. C'est ce qu'on retrouve dans le fichier de conf généré par la Freebox.

AllowedIPs = 0.0.0.0/0, 192.168.27.64/27, 192.168.X.0/24 (X à remplacer par la plage IP privée de la freebox)

Remarque : si vous ne voulez pas que le trafic internet passe par la Freebox, (mais soit en direct) et utiliser le VPN uniquement pour la connexion au réseau local, il faut supprimer 0.0.0.0/0

# Modification à apporter à la configuration par défaut

On est donc sur le réseau local, à une différence prêt : on a une IP routée différentes des IP fournies par le DHCP, et on a par défaut, usage du DNS indiqué, 212.27.38.253, qui est celui de Free.

C'est cette adresse IP qui est à remplacer par l'IP de son PI Hole/Adguard. Dans mon cas ça donne

[Interface] PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Address = 192.168.27.68/32 DNS = 192.168.0.1 MTU = 1360

Et comme le réseau local est accessible, la machine utilise alors le serveur PiHole/Adguard pour la résolution DNS.

# Comment vérifier ?

Tout simplement en allant l'interface web du PiHole/Adguard et on voit alors les requêtes émises par la machine (avec date & heure de connexion).

# Aller plus loin

Si on a une configuration particulière pour certaines machines, comme des NAS avec un parefeu, pour atteindre le NAS qui est sur la plage d'IP du réseau local (en 192.168.x.x), il faut bien évidemment que la plage d'IP de Wireguard soit autorisée dans le parefeu du NAS (il faut y ajouter la plage 192.168.27.64/27 comme autorisée dans le parefeu).