Quelle sécurité pour Jeedom?

[tomasxb]

Bonjour!

Suite à la lecture d'un article relatant et expliquant différentes méthodes testées afin de pirater une box Fibaro Home Center, je me questionne sur la sécurité de ma box domotique Jeedom Smart.

Quelqu'un saurait il nous en dire plus et si notre box favorite est mieux protégée?

Lien de l'article: https://securelist.com/fibaro-smart-home/91416/

[fwehrle]

Article très intéressant et qui montre une fois de plus les limites du cloud. Ça pourrait être sympa d'organiser un concours en mode Pen test

[vador69]

...........

[fwehrle]

Pourquoi? Tu préfères que les failles restent secrètes et non connues des concepteurs?
Ce genre de concours permet de déceler et corriger des failles de sécurités rapidement, et ca profite à tout le monde...

[vador69]

...........

[fwehrle]

Ah ok. mauvaise interprétation de ma part alors... Désolé.
Quand on développe un logiciel, il faut de toute façon allouer (et prioriser) du temps pour les mises a jour et les correction de bugs et failles de sécurité.
Je pense qu'au contraire, Loic serait content qu'on lui envoi des infos sur de potentielles failles (comme je l'ai deja fait d'ailleurs).

[mjeanne]

La base du système est plutôt bien sécurisée, c'est un dérivé de Debian.
Le core est plutôt bien contrôlé, mais une inspection du code pourrait surement révéler des failles: inputs non typées, pas de filtrage d'IP strict, etc.
Les soucis, s'il y en a, proviendront plus probablement des plugins qu'on peut appeler via des URL. L'injection de code, par exemple, est certainement possible avec quelques plugins.
Il faudrait des règles de bonne conduite pour les dev, comme des filtres d'IP, des contrôles systématique des variables, etc.. Par exemple ,lorsque j'ai écris ma passerelle pour passer les trames téléinfo de GET vers POST, je n'ai pas pris le temps de tout contrôler (il devait être minuit quand j'ai pondu le code), du coup j'ai mis une restriction d'IP en début de script et seul le module de téléinfo peut appeler l'url.

[fwehrle]

Ah.. je pensais que les appels http vers les plugins étaient centralisés par jeedom. Dommage.
D'accord avec toi sur les restrictions d'ip, mais pour ceux qui accedent a jeedom de l'extérieur avec un mobile en 4g, l'IP n'est pas fixe.
Pour ce qui est de l'injection, ce qui est embettant, c'est que même le core s'en sert lors de la sauvegarde des équipements. Mon firewall web n'arrêtent pas de râler quand je paramètre jeedom de l'extérieur. Injection sql, XML, PHP, etc...

[loic]

Bonjour,

La securité est quelques chose d'important sur Jeedom, nous faisons faire des audits (nécessaire pour certain projet) de temps en temps et je m'efforce a corriger la moindre faille de sécurité dans les 48h.

@fwehrle je sais pas c'est quoi ton firewall mais j'ai quand meme des doutes sur qu'il te remonte, hormis rare cas de plugin il n'est pas possible de faire d'injection SQL (PDO s'occupe de protéger ca), les injection XSS non plus (y un token pour les requête ajax qui change toute les 24h) .

Après ya surement des failles de sécurité du a PHP/apache ou autre ou peut etre meme dans le core (rien n'est infaillible) mais on surveille ca de très près.

[mjeanne]

D'accord avec toi sur les restrictions d'ip, mais pour ceux qui accedent a jeedom de l'extérieur avec un mobile en 4g, l'IP n'est pas fixe.

Ce n'est pas de l'accès à l'interface dont je parle. Cet accès est déjà surveillé par fail2ban, en théorie. De nombreux plugins fonctionnement sous forme de démons, et passent les infos à Jeedom via un appel http. Du coup, il serait bien de limiter l'API à 'localhost' puisque aucun humain n'est supposé appeler ces URL. De même, refuser tous les protocoles autres que GET/POST/PUT permet d'éliminer les scans (qui utilisent souvent HEAD ou TRACE).
Si on prend le plugin 'teleinfo', on peut lui envoyer des données via internet, alors qu'à 99% du temps, le module est physiquement sur le même réseau local. Donc ajouter un filtre local (+ une option pour désactiver pour les 1% restant) serait un plus. Il en est surement de même pour tous les plugins à base de passerelle (zwave et autres)
Si ce filtrage était disponible par une fonction du core Jeedom, chaque dev pourrait l'ajouter facilement dans ses plugins. ex: un test en début de code "if (!localCall(x)) {exit();}" avec x qui donnerait le choix entre 'localhost' et 'localnet' coté plugin, et la fonction serait activée ou non dans les options de Jeedom.

[loic]

Le filtrage est disponible par une fonction du core et tous les plugins utilisant une clef api s'en servent déjà... Tu peux même le configurer comme tu veux sur la page du core permettant de gérer les clef api...

[fwehrle]

@Loic : j'utilise modSecurity sur un proxy nginx.
Si tu veux, je peux t'envoyer la liste des exceptions que j'ai dû ajouter pour utiliser jeedom.

[mjeanne]

Le filtrage est disponible par une fonction du core et tous les plugins utilisant une clef api s'en servent déjà... Tu peux même le configurer comme tu veux sur la page du core permettant de gérer les clef api...

Rhôo... j'avais jamais vu cette possibilité... je vais restreindre de ce pas quelques trucs....