Bonjour à tous,
Soucieux d’un minimum de sécurité pour mon installation, je souhaiterais avoir vos avis/retour d’expérience sur la manière dont vous sécurisez votre installation « faite maison ».
Mon message s’adresse à eux qui possèdent un « homelab », typiquement proxmox ou similaire, et qui ont mis en place une suite de service virtualisés, dont jeedom, pour lesquels il est possible d’avoir un accès extérieur.
Ma config (rapide) actuelle :
Un serveur qui héberge un proxmox, sur lequel je fait tourner plusieurs services (jeedom, ad guardhome, plex, apache guacamole, crowdsec etc…)
Un service « nginx proxy manager » qui tourne dans un LXC et qui permet d’accéder à chacun de ces services via un sous-domaine dédié (domaine ovh avec une redirection type A). J’ai configuré chacun des accès au service avec une authentification simple que propose NPM (type user/mdp)
Un routeur qui n’expose que le port 80/443 et qui balance tout le flux vers l’ip du nginx proxy manager, qui s’occupe ensuite de rediriger vers le bon service en fonction du dns demandé.
Question 1 : quelles mesures avez-vous mises en place pour sécuriser ce genre d’installation ?
Question 2 : j’aimerais mettre en place de l’authentification MFA. J’ai vu qu’il existait Authelia qui a l’air vraiment pas mal. Notre amis @guipom a fait d’excellentes vidéos sur ce sujet (qui commencent à dater maintenant), mais qui utilise portainer et le montage de stacks, qui n’est donc pas tout à fait techniquement applicable à mon cas, car les container sont fortement imbriqués. Idéalement, j’aimerais monter un Authelia sur un LXC dédié, sans (trop?) devoir péter toute ma config. Quelqu’un a-t-il ce genre de truc chez lui ?
Bonjour,
Pareil que @Chrisax, j’utilise OpenVPN intégré à mon routeur Asus (bien que ma Freebox Ultra en propose un aussi…).
C’est bien plus simple à configurer et à maintenir, et ce sans sacrifier au niveau de sécurité global de l’ensemble de mes équipements (NAS, serveur web, proxmox, Jeedom,…).
J’ai un serveur proxmox et comme toi Nginx Proxy Manager en LXC pour rediriger vers la bonne VM
J’ai ajouté un filtre géographique (ipset) dans proxmox pour limiter les attaques + renforcement du ban dans les paramètres.
MAJ périodiques bien évidemment.
Authelia je ne connaissais pas mais ça peut être intéressant dans certains cas
Bonjour,
jeedom sur cluster Proxmox, reverse proxy avec Haproxy et firewall OpnSense avec Crowdsec et Suricat (IPS).
Il y a plusieurs Wan, c’est plus simple de gérer le tout avec un firewall.
L’option VPN (Wireguard, OpenVPN etc) revient beaucoup, et bien que j’ai effectivement monté un VPN sur mon routeur, je ne peux pas m’en servir tout le temps pour deux raisons :
Lorsque je suis au boulot, le réseau d’entreprise est extrêmement restreint niveau réseau. On est sur du « deny-all / allow-list only ». Seul le trafic sortant https reste ouvert sans « contrainte ». Tout le reste (c’est à dire tous les ports sauf 80/443, dont ceux utilisés par les protocoles VPN) est bloqué. Cela veut dire que je ne peux pas me connecter à mon serveur via VPN depuis le boulot (et ça m’emmerde fortement)
Deuxième raison : comment faites-vous pour « discuter » avec votre jeedom derrière un VPN avec une appli genre JeedomConnect depuis le smartphone ? La connexion n’est pas possible vu qu’il faut d’abord se connecter au VPN avant ? ou bien j’ai loupé quelque chose ?
Sinon dans les idées proposées, je ne connaissais pas Suricata, ni la possibilité de filtrer par ip géographique depuis proxmox (si j’ai bien compris, on garde un set d’ip connue pour être française, et on bloque tout le reste via le firewall intégré à proxmox ?)
Hello
2 esxi pour la VM jeedom maitre, une freebox.
J’avais pendant un moment un haproxy en VM vers quoi était natée via freebox le port 443.
J’en avais marre de gérer le certificat numérique alors j’ai complètement changé d’archi.
Supprimé le NAT 443 entrant, supprimé le HAproxy.
J’utilise la fonctionnalité (grauite) de cloudflare : tunnels avec 3 connecteurs locaux (1 vm dans chaque esxi + 1vm dans freebox)
Comme j’ai le dns de mon domaine public chez cloudflaire, c’est eux qui gèrent la rotation du certificat.
Avec Cloudflare tu peux ajouter du MFA fourni par l’annuaire de ton choix (saml), ou ton truc a toi comme Authelia.
Bonjour,
J’ai un peu comme toi, un service NPM qui sert de porte d’entrée, puis plusieurs services dont Jeedom caché derrière comme sous-domaine. Sauf que je suis sous docker au lieu de promox. Je trouve ça très pratique, il gère et renouvelle les certificats tout seul, je peux rajouter un nouveau sous-domaine en 3 clics, je suis fan J’utilise bitwarden (l’image vaultWarden compatible raspberry pi) comme coffre-fort je ne sais pas si Authelia est équivalent ? ça me permet de mettre des mots de passe super robustes de partout, et ça gère aussi le code pin si besoin, et j’envisage de passer à une clé USB de type ubikey mais j’ai pas encore franchi le pas.
Jeedom sur une VM (clé Zwave déportée sur un RPI pour me permettre de la livemigration)
NPM sur Docker ( sur un LXC dans une DMZ)
Les réseaux isolés DMZ / LAN via pfsense
Le VPN est plus sécure c’est sur, mais limite franchement les usages … notamment les appels via API / intégration home assistant etc …
Merci à tous ceux qui ont pris la peine de me répondre.
Suite aux messages, je me suis inspiré et je me suis lancé.
J’ai finalement pas mal fait évoluer mon architecture, donc voici un récapitulatif qui pourra peut-être servir à d’autres.
Contexte de départ
Jeedom dans un LXC sous Proxmox
Domaine chez OVH
Accès fibre Free
Avant
Mon exposition web reposait sur :
Nginx Proxy Manager dans un LXC, chargé de router les requêtes entrantes vers les bons services (Jeedom, AdGuard Home, etc.)
Port 443 ouvert sur l’IP publique, redirigé via NAT vers le container NPM
Un LXC CrowdSec qui recevait via rsyslog les logs de l’ensemble des services pour analyser les comportements et bannir en conséquence
Première tentative : ajout d’Authelia
J’ai tenté d’ajouter Authelia en parallèle de NPM. Fonctionnel, mais j’ai vite arrêté pour plusieurs raisons :
Un énième container dédié à la sécurité → complexité et ressources supplémentaires
Config NPM plus lourde (nginx avancé, règles spécifiques, maintenance délicate)
Le problème fondamental des ports 80/443 exposés reste entier
Gestion CrowdSec de plus en plus lourde (bouncer à ajouter dès qu’un nouveau container est déployé)
Nouvelle approche : tunnel Cloudflare
Je suis finalement parti sur l’option du tunnel Cloudflare, souvent recommandée. Mise en place :
Création d’un compte Cloudflare + installation d’un LXC cloudflared
Passage complet de mon domaine et sous-domaines sur les DNS Cloudflare
Mise en place de Cloudflare Zero Trust pour chaque service exposé
Bypass en LAN pour accéder aux services sans authentification depuis le réseau local
Règles spécifiques pour les services externes nécessitant un accès direct sans auth (Google Home, JeedomConnect, API Jeedom, etc.)
Configuration de règles WAF restrictives : filtrage géographique (France uniquement), blocage de bots, DDoS, crawler, etc.
Activation du MFA Cloudflare pour tous les accès
Ce que j’ai pu supprimer
Le container CrowdSec (filtrage désormais en amont et non plus après-coup)
Le container Nginx Proxy Manager
Le container Authelia
L’envoi massif de logs vers rsyslog
Le container rsyslog lui-même
Avantages de l’architecture actuelle
Plus aucun port ouvert sur mon IP publique
Mes services sont totalement masqués derrière les IP Cloudflare
Filtrage actif avant même que la requête n’atteigne mon réseau (au lieu d’un traitement a posteriori)
Potentiel important avec les fonctionnalités Cloudflare à explorer
Le tunnel Cloudflare est gratuit pour ce type d’usage
Inconvénients
Dépendance à un service tiers : si Cloudflare tombe, je tombe aussi
Cloudflare voit tout le trafic transitant dans le tunnel → niveau confidentialité, c’est moyen
Configuration firewall exigeante pour autoriser les services essentiels (Google Home, JeedomConnect, monitoring, etc.), et à réajuster à chaque nouveau besoin
État actuel
Aujourd’hui, mon architecture est totalement fonctionnelle, avec ce que je voulais atteindre : bien plus sécurisée qu’avant : Jeedom, par exemple, ne reposait que sur son propre système de login, alors que tout passe désormais par une couche de sécurité centralisée.
Elle est aussi nettement moins complexe, malgré la phase d’apprentissage nécessaire côté Cloudflare.
Et surtout, elle est moins gourmande en ressources, puisque j’ai pu supprimer plusieurs containers (NPM, Authelia, CrowdSec, rsyslog), au profit d’un modèle plus propre, plus cohérent et plus facile à maintenir.
Je pourrai bien sûr aider ceux qui galèrent sur la conf cloudflare (car je m’y suis pas mal cassé les dents).
Merci de m’avoir lu, et encore merci à ceux qui ont participé et qui m’a motivé à passer le cap.
Bonjour, j ai un peu suivis vos conseil cloudflare+ zerotrust (merci pour l idée) mais je suis bloqué concernant les règles a mettre en place pour les acces sans auth. Google home est orphelin chez moi. pouvez vous expliquer quelles règles ? Merci a vous.
Oui c’est une partie assez touchy sur laquelle j’ai pas mal galéré.
Pour cela, il faut créer une règle firewall spécifique qui autorise les services/ip de google home à taper sur ton dns.
Dans ton dashboard cloudflare, menu « Security » => « Security rules »
(ip.geoip.asnum eq 15169 and http.host eq "tonsousdomainejeedom.tondomaine.com" and http.request.uri.path eq "/api/google_assistant") or (http.request.uri.path eq "/auth/token")
Si t’as déjà des règles restrictives, faut positionner celle-ci avant (sinon les requêtes venant de google home seront filtrées avant).
Pour info, le numéro d’AS (Autonomous System Number) correspondant à 15169 est celui utilisé par Google LLC. Ca permet d’éviter de directement whiste-lister une liste ENORME d’ips appartenant à Google (et qui potentiellement peut bouger régulièrement).
Merci énormément Dreaky de m avoir répondu.
Effectivement je n’aurais jamais trouvé AS num déjà.
J’avais déjà tenté de renseigner les URI Path de google pour jeedom style « /core/api/jeeApi.php » sans succes.
Malheureusement malgré ta règle ca ne marche toujours pas chez moi.
Je dois avoir un truc qui me parasite.
Tu devrais virer ton adresse perso de ta copie écran.
Et oui je m’identifie à cloudflare grâce à google auth.
J’ai bien compris que c’est le gros bloquant mais je pensais qu’avec une règle sur les appel api ça marcherait. j ai essayé d améliorer tes règles avec l’aide de chatgpt mais rien n’y fait je pense que je vais devoir supprimer mon authentification .
J’ai du alexa et google home a la maison. Je vois bien du trafic passer en GET et POST sur Analytics mais mon app google home est désespérément vide de tous mes objets jeedom.
Si tu utilises Zero Trust, alors y’a aussi des règles de filtrages à configurer sur le dashboard One de Cloudflare :
Tu as donc probablement déjà une application « Jeedom » dans ta liste d’app sous le menu « Access controls » => « Applications », avec une policy de filtrage. C’est ce qui bloque les appels extérieurs depuis Google (ou autre).
Voilà comment j’avais fait à l’époque avant de passer sous home assistant :
Tu crée une autre application (je l’ai appelé chez moi « Jeedom external services », et tu autorises ces paths là :
Cela aura pour conséquence de ne pas passer par l’auth OIDC google pour toutes les requêtes qui tapent vers « core/ », « plugins/ », « data/ » et « 3rdparty ». C’est à dire la plupart des services extérieurs (type google ou alexa).
Avec cette technique, j’avais pu refaire marcher mon google home.
L’inconvénient, c’est que cela laisse un petit trou dans la raquette niveau sécurité. Car si une faille jeedom se trouve dans un de ces paths là, une attaque reste possible depuis l’extérieur.
J’utilise bitwarden (l’image vaultWarden compatible raspberry pi) comme coffre-fort je ne sais pas si Authelia est équivalent ? ça me permet de mettre des mots de passe super robustes de partout, et ça gère aussi le code pin si besoin, et j’envisage de passer à une clé USB de type ubikey mais j’ai pas encore franchi le pas.
.
