Securiser l'accès à ma VM Jeedom en HTTPS [besoin d'accès en local]

Interfaces
1

Bonjour,

J’utilise un VM Jeedom sur un NAS Synology.
J’aimerai activé le HTTPS pour sécurisé ma connexion à l’interface web Jeedom et le requêtes API que je peux faire vers Jeedom.
Je précise que je n’ai pas besoin de me connecter à distance à l’interface web Jeedom, cela ne me sert à rien… si j’avais ce besoin, j’ai la possibilité de me connecter en VPN.

Est-ce qu’il est possible d’activer l’authentification HTTPS pour sécuriser les échanges ?
Si oui, comment ?

Merci pour votre aide.

1 « J'aime »
2

Salut @Elrick

Bon si tu veut vraiment faire celà il y a pas mal de sujet, fait une recherche …

si tu ne te connecte pas depuis l’extérieur il n’y a que peut d’intérêt !

3

J’ai trouvé des tas et des tas de post, mais aucun qui parle uniquement de ce besoin.
Si je me connecte pas depuis l’extérieur ca a évidement un interet…
Par exemle, si je n’ai pas envie que les trames soit lus en clair en wifi, j’ai plutot intérêt à faire en sorte que le flux soit sécurisé.

4

Bonjour, est ce que tu as trouvé une solution ? Car je cherche à faire la même chose.

5

Non, je n’ai pas trouvé la solution pour sécuriser les échanges… :frowning:

6

Salut.

Sécuriser en https c’est pareil que ce soit depuis internet ou depuis le WiFi… C’est le même fonctionnement, le même protocole.
Mais bon sécuriser uniquement en local, c’est pas réellement utile :

  • ça utilise plus de resources. Surtout si beaucoup de trafic.
  • le Wi-Fi n’est en principe accessible qu’aux utilisateurs de confiance. Si c’est pas le cas, alors le problème est ailleurs. Par exemple, il faut juste faire attention à ne pas partager trop sa clé ou en changer.
1 « J'aime »
7

Le wifi n’est absolument pas quelque chose de sécurisé, n’importe qui avec une distribution Kali est en mesure d’utiliser une ataque du type man in the middle, ll faut arreter de dire n’importe quoi.
Bref, y a rien qui existe pour sécuriser sa connexion en local et c’est bien dommage.

8

Ok… A priori, tu es l’expert …

Voilà mon point de vue et ça servira aux autres lecteurs:
Autant une attaque MITM ça a du sens sur internet parce que les rebonds entre toi et le serveur sont nombreux et non maîtrisés … Autant dans ton cas avec le WIFI, c’est absurde. Je m’explique : pour pourvoir appliquer ce type d’attaque ça implique :

  • d’être à portée de wifi… Autrement dit, dans les 100m autour de chez toi. Et en supposant que les murs etc ne perturbent pas la qualité de réception.
  • Pouvoir faire ça implique aussi d’avoir eu accès ton Wifi et d’avoir décodé la clé … Alors bon, c’est pas complètement impossible, il y a même des outils très efficaces pour le faire; mais bon le WPA2, c’est pas aussi simple que le WEP
  • ça implique aussi de casser le fonctionnement DHCP/DNS de ton réseau… Parce que bon en général(et dans ton cas, j’ai quasiment aucun doute), le lien entre ton pc et jeedom est direct à travers ta box (à la grosse différence d’un trajet sur 'internet)… Pour se retrouver au milieu, il doit chopper l’adresse à la place de jeedom, lui en filer une autre, et faire le routage (type proxy http voir https…)… Et ça c’est pas le premier gosse du quartier qui sera en mesure de le faire. Kali dans ce cas, n’apportera rien de plus. Encore plus si tu n’utilises pas le DHCP, il y aura toujours conflit d’ip
  • Ensuite le but du https (authentification simple) c’est aussi de s’assurer que le serveur est bien le bon… Parce que chiffrer les échanges c’est bien gentil mais si tu ne parle pas avec la bonne personne, ben ça sert absolument à rien. Pas de bol, comme sur le réseau wifi, tu n’as pas de nom de domaine complet, ben … la vérification de l’hôte distant… comment dire … ben il n’y en a pas. Et donc ça sert à rien contre une attaque mitm

Alors vouloir prétendre mieux savoir et que les autres racontent des aneries, pourquoi pas, mais quand on coince à mettre en place du simple https… ça laisse interrogatif…
A ta place, cable tout en rj45, et met un doberman dans le jardin, ça sera 10000 fois plus fiable
Mais c’est avec plaisir que je prendrais un cours de sécurité avec ta solution.
Bon courage

1 « J'aime »
9

Qui te dit que le wifi dont je parle se trouve à mon domicile ?!
Les entreprises ont le droit d’avoir un reseau Wifi dans le leur local et si il ne veulent pas se faire tartiné par une attaque MITM ils ont besoin de securisé à minima leur réseau ?!
Bref, tu juges un peu rapidement sans connaitre le contexte et tu ne connais pas grand chose à ce type d’attaque.
Je te laisse à tes croyances.

10

Effectivement, une entreprise qui craint les attaques MITM, qui exploite du wifi et crois que le HTTPS est la solution pour s’en prémunir à toutes les chances de voir ses pires cauchemars se produire.
Je retourne à mes croyances

1 « J'aime »
11

Bonjour Elrick,

Pour ma part, j’ai activé le SSL et j’ai bien un Jeedom en HTTPS dispo sur le LAN sans qu’il soit accessible depuis internet.

Si tu tiens toujours à faire cette mise en place voilà comment je l’ai mis en place et à adapter à ton cas.

Les prérequis indispensable pour moi sont :
1 nom de domaine. (dans l’exemple ici ce serait mondomaine. fr)
1 cle api chez l’hébergeur pour modifier les DNS
1 serveur qui peut accéder à internet (ou jeedom)

En premier, faire rediriger en interne ton alias dns vers jeedom, par exemple madomo.mondomaine. fr redirige vers 192.168.1.X ton ip jeedom.
Cela permet d’avoir une url madomo.mondomaine. fr qui fonctionne en local. (plus-tard en https)
Cette action est à faire sur ta box / ton routeur / ton dns…

Sur jeedom ou sur un autre serveur qui aurait accès à internet. installer acme.sh qui est très simple (il y en a d’autres, certbot, etc.) et permet de faire de la génération de certificats letsencrypt uniquement par dns. Il y a de nombreux plugin pour se connecter au différents hébergeurs du net (gandi, etc.) la doc : https://github.com/acmesh-official/acme.sh.

Une fois installé :
Créer la demande de certificat pour ce sous domaine (pas besoin qu’il existe vraiment chez ton hebergeur): Exemple chez gandi :

acme.sh --issue --dns dns_gandi_livedns -d 'madomo.mondomaine. fr'

Deux fichiers sont utiles :

fulchain.cer
madomo.mondomaine.fr.key

Si tu fais ça depuis un autre endroit que ton jeedom (c’est mon cas, un serveur fais les demandes de certificats et les distrib aux autres), il faut le transférer vers jeedom en ssh par exemple via scp :

scp fullchain.cer pi@192.168.1.xx:/etc/ssl/fulchain.cer
scp madomo.mondomaine.fr.key pi@192.168.1.xx:/etc/ssl/madomo.mondomaine.fr.key

Ensuite il faut activer le https sur Jeedom.
Pour ça il y a la documentation officielle mais ça se résume à ça :

sudo a2enmod ssl
sudo a2ensite default-ssl.conf
sudo service apache2 restart
cd /etc/apache2/sites-enabled/

éditer le fichier default-ssl.conf et ces deux paramètres avec le chemin vers tes 2 fichiers key et cer.

            SSLCertificateFile      /etc/ssl/fulchain.cer
            SSLCertificateKeyFile /etc/ssl/madomo.mondomaine.fr.key

redémarrer l’apache
sudo service apache2 restart

Voilà, c’est un bon début. jeedom est accessible en https maintenant via le sous domaine madomo.mondomaine. fr

Ensuite le renouvellement du certificat :
acme.sh gère à travers un cron le renouvellement automatique.
Il faut si tu ne l’as pas généré depuis jeedom faire une copie de ce fichier à interval régulier par exemple via scp dans un crontab.

En espérant que ça t’inspire.
Mickaël

1 « J'aime »
12

@mikeul, sans t’offencer, c’est pas tres « safe » de mettre ton certificat et ta cle privee dans /home/pi
Par defaut, positionne plutot dans un sous-repertoire de /etc/ssl en limitant les droits d’acces.
Nb: tu trouveras également dans /etc/ssl les chaines de certification.
C’est l’emplacement qui j’utilise pour des sites pros

1 « J'aime »
14

Oui effectivement j’ai copié un peu vite une de mes notes mais c’est biensur pas le bon endroit pour le stocker. Bonne remarque je vais éditer le post. /etc/ssl reste le chemin standard pour les stocker.
je comptais juste donner une guideline pour la mise en place mais faut être plus rigoureux :blush:

15

Le plus simple si l’on est dans le cadre d’un réseau local d’entreprise, c’est d’utiliser la pki de la société pour créer un nv certificat. Exemple, domaine local de la société : masociete.local. on crée un certificat jeedom.masociete.local. et sur toutes les workstations, on installe le Root ca de masociete.local via gpo. on a qqch de propre sans devoir sortir sur le net avec des certificats ayant des durées de vie vachement plus long que letsencrypt. Et on n’est pas dépendant d’un service sur le net.

Je le répète, c’est la seule manière a mes yeux pour de l’entreprise.

Après, il suffit de placer le certificat sur le serveur comme expliqué plus haut et activité le ssl ds apache. Après si tu veux encore augmenter la sécurité, tu peux limiter a certaine clé de chiffrement et d’activer que le TLS1.2. La sécurité, c’est un monde ds l’informatique

Pour revenir sur le wifi. Toujours en entreprise, tu peux travailler avec des certificats pour pouvoir donner accès a des workstations au réseau wifi. La tu seras sur qu’il n’y aura personne d’autre qui a accès. C’est ce qu’on appel le nac

Il y a moyen d’en parler pendant des heures…