En testant easydash, je m’aperçois qu’avec la clé api d’un Jeedom, il est très facile d’accéder aux commandes de Jeedom sans autorisation spécifique. Il suffit de rentrer la clé et l’adresse de la box.
De la même façon, j’ai l’impression (mais je peux me tromper) qu’à l’installation d’un plugin, l’autorisation d’utiliser la clé API est explicite (automatique).
Je ne trouve pas de façon évidente à mettre une sécurité (sauf à tout fermer) sur un accès.
Ma proposition des donc d’associer un user/mot de passe à l’usage de la clé API comme c’est le cas pour beaucoup de sites type ENDIS, Météo … ou un compte est nécessaire pour un programme tiers se connecte.
Lors de l’installation d’un plugin, par défaut bloquer l’accès API ou demander l’accord de l’utilisateur. Comment savoir si l’on doit désactiver ou pas l’accès API pour chaque Plugin ?
Peut-être que je n’ai pas vu quelque chose qui permettrait de mieux protéger les accès. N’hésitez pas me le dire.
Merci de vos avis et si vous pensez que c’est une évolution nécessaire pour améliorer la sécurité, mettez des pouces afin de motiver l’équipe à la mise en oeuvre rapide.
La clé api générale du core a effectivement un accès global et ca ne changera pas, il faut éviter de l’utiliser.
Il existe déjà des clés api par utilisateur donc en principe tu devrais pouvoir créer un user dédié et utiliser sa clé (et limiter ses accès)
Les clés des plugins ne sont pas activées automatiquement, seulement lorsque le plugin en a besoin.
Par contre pour les plugins la surface peut être réduite (limité à localhost ou liste blanche) mais ca c’est au plugin de gérer, le core ne sait pas le faire à sa place.
Perso sur tous mes plugins je limite à localhost lorsque c’est possible.
Si le plugin a un démon, je pense que la clé api sera systématiquement nécessaire, ca peut dépendre de comment c’est codé mais la plupart suivent ce schéma.
par contre souvent un accès « locahost » suffit puisque c’est une communication entre le démon (en local sur jeedom) et le code php.
Mais il peut y avoir des cas où un accès depuis l’extérieur vers le plugin est nécessaire, dans ce cas il faut que la clé soit marquée comme « Activée »
Dernier cas, si c’est un plugin qui recoit des requêtes externe à jeedom mais seulement depuis le réseau local, pas internet, alors un accès « liste blanche » sera le plus adapté.
Si tu as un doute, le mieux est de faire un post pour le ou les plugins concernés
une clé api c’est comme un mot de passe, si quelqu’un la connait, il peut faire des actions.
si ton mot de passe ou ta clé est compromise, c’est un problème, il faut renouveler l’un ou l’autre.
Est-ce qu’un plugin qui a accès à la clé api pourrait contenir du code malveillant permettant de d’activer des fonctions/commandes hors du périmètre du plugin ?
Exemple : j’installe un plugin météo avec du code malveillant (c’est pour l’exemple) qui active l’accès la clé API puis permet à son concepteur d’accéder à distance à Jeedom pour ouvrir ma maison par exemple.
Du coup, est-ce qu’il y a protection/une vérification/certification pour contrôler l’action potentiel d’un plugin ou un garde fou jeedom pour limiter ses accès ?
Est-ce qu’un outil du marché serait faire ça ?
Ps : je comprendrai que tu n’aies pas réponse à tout
les plugins sont vérifiés lors de leur première publication en stable, ensuite les mises à jour ne sont plus contrôlées, on a vu des « dérives » récemment (et je suis certain qu’il en reste) car la « ligne rouge » n’est pas la même pour tous les points de vues évidemment.
Jusqu’ici on fonctionne plutôt à la confiance et la réputation du développeur.
des outils (plutôt pro), peuvent analyser le trafic et détecter (voir bloquer) ce qui sort de l’ordinaire ou ce qui n’est pas explicitement autorisé par exemple, ca dépasse de loin le sujet ici et même l’utilisation du core, et perso je ne vais pas m’impliquer plus dans ce genre de sujet, j’ai trop à faire
Si une expert en sécurité passe par là, je suis preneur d’un point de vue/des idées pour sécuriser Jeedom et l’accès aux commandes. Ce n’est pas (encore) mon cas, mais je pense aux ouvertures de portes & garages par exemple.
En tant que rssi, je peux te dire que la première chose à faire est une analyse de risques.
On ne commence jamais une réflexion sur la sécurité par je veux sécuriser (comment), mais par pourquoi et quel est le risque associé.
Y a t’il plus de risque qu’on te pirate ton jeedom pour ouvrir ta porte de garage ou qu’on ne le fasse avec un pied de biche.
Si tu estimes que le risque le plus important, c’est le piratage de ton jeedom, tu commences par les éléments périphériques pour limiter la surface d’exposition et tu resserre le cercle, pas d’accès depuis l’extérieur, réseau wifi (bien) sécurisé,… avant d’attaquer le cœur de la bête.
Et ensuite (enfin, en parallèle), tu peux prendre des mesures de type compte utilisateur non admin (admin bloqué en local), chgt de mot de passe tous les x jours/semaines, rotation des clés api, …
Inutile de chercher la technique, la sécurité elle est de ton côté
Oui potentiellement ! ca dépend de la manière dont sont dev les plugins
Personnellement, je ne vois aucun intérêt à faire celà, plutot utiliser les capacités à restreindre leur portée :
Onglet API
Vous trouvez ici la liste des différentes clés API disponibles dans votre Jeedom. De base, le core a deux clés API :
une générale : autant que possible, il faut éviter de l’utiliser,
et une autre pour les professionnels : utilisée pour la gestion de parc. Elle peut être vide.
Puis, vous trouverez une clé API par plugin en ayant besoin.
Pour chaque clé API de plugin, ainsi que pour les APIs HTTP, JsonRPC et TTS, vous pouvez définir leur portée :
Désactivée : la clé API ne peut être utilisée,
IP blanche : seule une liste d’IPs est autorisée (voir Réglages→Système→Configuration : Sécurité),
Localhost : seules les requêtes venant du système sur lequel est installé Jeedom sont autorisées,
Activé : aucune restriction, n’importe quel système ayant accès à votre Jeedom pourra accéder à cette API.
Pour chaque clé API de plugin vous pouvez leur interdire les méthodes core (général) pour les limiter à leur seule méthode embarquée (attention certains plugins comme mobile ou jeelink ont absolument besoin des méthodes core)
Tu peux essayer de toutes les desactiver et les redemarrer si des plugins ne fonctionnent plus
Norbert
Pour le pied de biche. Je pense mettre un lecteur de badge pour extérieur afin de désactiver l’alarme puis ouvrir le garage. Je me suis également dit qu’un cambrioleur passera par ma porte d’entrée qui est plus fragile et mon exposée. C’est pas le lecteur qui sera « attaqué le premier ». Et comme mes collègues sont RSSI pour les uns et RED/BLUE team pour les autres… Je vais tester mon lecteur avec un Flipper. Par précaution
De manière générale si tu installe un plugin avec un code mal veillant, c’est déjà trop tard car la clé Api dans ce cas n’est qu’un moyen parmi d’autres.
Le seul moyen efficace c’est de n’installer aucun plugin ou une box jeedom n’ayant aucun accès sur l’extérieur .
Sérieusement à moins d’avoir des trésors chez toi, et faire l’objet d’une attaque ciblé et préparé, il est peu probable qu’un voyou vienne accéder à ta box, trouve la commande adéquate sur ton jeedom, ouvre le garage,… il mettra moins de temp avec un pied de biche !
si tu as des doutes renouvelle tes clé API de temps en temps c’est tous ce que tu peu faire et surtout bien comprendre que le risque 0 n’existe pas et n’est pas prés d’exister !!
Les alarmes et cameras c’est fais pour se rassurer, tu investie dans la « sensation » de tranquillité d’esprit et un peu de dissuasion du voyou occasionnel.
Les images que j’ai vu, tout était présent dans le petit boitier (le lecteur et la commande d’ouverture).
=> C’est typiquement ce qu’il ne faut pas faire. Sinon, un petit coup de marteau dans le boitier, on récupère le courant de l’alimentation pour ouvrir une gâche ou on shunt ce qui sert de commande d’ouverture sur votre porte.
- et la porte s’ouvre
Dans ce genre d’équipement « seulement et uniquement seulement » la partie lecteur de carte doit être en extérieur, de manière déportée, par rapport aux autres éléments qui doivent être en intérieur et sécurisé (alimentation et commandes).
Sans être parano, il me semblerait raisonnable d’associer un login/mot de passe à la clé API comme c’est le cas pour la très grande majorité des sites. Même si le risque zéro n’existe pas, autant diminuer les probabilité.
En surveillant sa ligne internet on voit bien qu’il y a très régulièrement des bots qui essayent d’entrer. C’est une réalité.
Il y a également une question d’assurance, si l’accès à une maison est possible sans infraction, l’assurance ne marche pas la plupart du temps.
désolé mais c’est complétement inutile
et personne ne fait ca: une clé API c’est un mot de passe… si ta clé api est compromise, pourquoi le mot de passe ne le serait pas? car du coup tu dois mettre les 2 dans ton script
donc si ca t’arrives, casse un carreau (depuis l’extérieur) ou un cylindre avant d’appeler l’assurance…
les mécanismes d’authentification ne sont pas standards, en fournissant cet cléAPi à une partie tierce on lui donne des privilèges predifint.
Et Non c’est pas spécifique à Jeedom, on trouve les clés Api partout (HA, comptes IA, google,…).
La seule chose c’est qu’un plugin peut l’utiliser sans que vous l’avez explicitement autoriser mais je sais pas si beaucoup de plugins l’utilise.
Pour le pied de biche. Je pense mettre un lecteur de badge pour extérieur afin de désactiver l’alarme puis ouvrir le garage. Je me suis également dit qu’un cambrioleur passera par ma porte d’entrée qui est plus fragile et mon exposée. C’est pas le lecteur qui sera « attaqué le premier ». Et comme mes collègues sont RSSI pour les uns et RED/BLUE team pour les autres… Je vais tester mon lecteur avec un Flipper. Par précaution
.