Maisons connectées et Cybersécurité au programme du jour. Cet article a vocation à sensibiliser les particuliers « auto-installateurs » de solutions autour de la maison connectée. Pour les autres, ce sujet peut-être utile, rugueux ou complémentaire.
En « domotique moderne » (Internet des objets, SmartHome, Maison connectée, Objets connectés) on omet souvent de parler de sécurité, voilà pourquoi depuis quelques temps je souhaite aborder ce sujet un peu complexe et assez vaste pour s’y perdre. Après des semaines de collecte bibliographique nécessaire à parfaire ma vision globale de ce sujet, je vous livre un dossier non-exhaustif, mais assez représentatif de la situation, ainsi qu’un ensemble de mesures permettant de limiter les risques d’expositions de votre infrastructure numérique résidentielle.
A la lecture de cet article vous serrez je l’espère mieux sensibilisé aux risques que peuvent comportés les réseaux locaux de nos maisons connectées, et ce que nous en faisons avec les dispositifs que nous y connectons. Non non, nous n’allons pas parler de système d’alarme spécifiquement.
Remarque : Je ne suis, ni ai été expert en sécurité informatique. Cet article a pour objectif de transmettre un minimum de pistes aux lecteurs passionnés de la maison connectée sur la base de mes connaissances et expériences de l’IT et des différents tutoriels de la toile.
Sommaire
Petit éclaircissement terminologique de l’abus de langage :
Il est courant aujourd’hui d’employer un mot pour un autre par abus de langage. Le titre de cet article est volontairement un abus de langage dans l’emploi du du mot sécurité au lieu de sûreté. Cette confusion ayant été induite par la traduction des termes anglophones. Nous devrions théoriquement parler de sûreté plus que de sécurité.
- La sécurité consiste à prévenir contre les accidents (liés à des évènements fortuits ou des actes sans intention de nuire)
- La sûreté consiste à prévenir contre les actes de malveillance (liés à des actes délibérés ou à la négligence avec intention de nuire)
Voici une petite réflexion : Positionnement de la Cyber-sécurité entre Sécurité et Sûreté, « faux-amis » ou vraies synergies ?
1. Maisons connectées, le contexte
1.1. La connectivité IP
La « Maison connectée » offre le plus souvent une accessibilité distante, très attendue des utilisateurs avant tout. Garder le contrôle total de sa maison nécessite un accès à distance le plus souvent au travers d’internet, et cela même s’il existe d’autres moyens d’interagir avec notre maison comme par exemple avec des SMS.
Dans cette chaîne de communication TCP/IP, nos communications vont traverser un ensemble d’éléments constituant des réseaux (réseau Internet ou public / réseau local ou résidentiel).
Exemple : Smartphone > réseau opérateur > Internet > Box internet (Routeur) >Réseau résidentiel > nœud réseau (Appareil avec une adresse IP comme votre contrôleur domotique)
![Maisons connectées et Cybersécurité - surface d'exposition ip Maisons connectées et Cybersécurité - surface d'exposition ip]()
Aparté : La convergence IP (intéropérabilité IP) oblige beaucoup de domoticiens et d’intégrateurs à remettre régulièrement à jour leurs compétences et leurs connaissances des réseaux IP, par la compréhension des risques, des menaces ou vulnérabilités des installations. Alors n’oubliez pas, les « Sachants » sont dans ce cas les professionnels. Il est donc de leur responsabilité de ne pas ajouter de failles de sécurité supplémentaires chez l’utilisateur. Cependant, l’explosion d’offres produits et la demande grandissante, accélèrent le décalage des besoins face aux compétences aujourd’hui disponibles.
1.2. La connectivité Radio et Bus terrain
Dans le même esprit, la communication entre les équipements domotique (que nous appellerons des nœuds) offre une surface d’exposition aux risques, au même titre que les réseaux IP. En effet, que la technologie soit maillée, en point à point ou en étoile, cette technologie s’expose dans le monde hertzien (radio-fréquences) ou encore sous forme de signal électrique dans un bus terrain filaire.
Il y a donc une lointaine similitude avec les réseaux IP, car une contrainte de proximité rend le risque moins important. Un attaquant devra donc se trouver à portée quasi immédiate des équipements physiques ce qui peut limiter naturellement la menace.
2. Risques principaux
![Maisons connectées et Cybersécurité - méthodes attaques Maisons connectées et Cybersécurité - méthodes attaques]()
La sécurité numérique résidentielle est à prendre en considérations pour plusieurs raisons. Sans tenter de vous faire peur, il existe plusieurs types de menaces plus ou moins critiques ou dangereuses.
2.1. Menaces concernant les données
- La perte intégrale ou partielle de vos données,
- Le rapt partielle ou intégrale de vos données contre rançon financière (Ransomware),
- L’accès libre à vos données privées (usurpation d’identité, accès au données bancaire, manipulations et falsifications).
- Accès à vos services en ligne.
2.2. Menaces par nuisances (maliciel)
Un logiciel malveillant ou maliciel, aussi dénommé logiciel nuisible ou programme malveillant ou pourriciel (« malware » en anglais), est un programme développé dans le but de nuire à un système informatique, sans le consentement de l’utilisateur dont l’ordinateur est infecté.
De nos jours, le terme « virus » est souvent employé, à tort, pour désigner toutes sortes de logiciels malveillants. En effet, les maliciels englobent les virus, les vers, les chevaux de Troie, ainsi que d’autres menaces. La catégorie des virus informatiques, qui a longtemps été la plus répandue, a cédé sa place aux chevaux de Troie en 2005 Source : Wikipédia
2.3. Menaces concernant les équipements
- Prendre possession d’équipements,
- Accès à vos service locaux comme vos caméras IP,
- Piloter votre domotique et capacité d’agir sur votre résidence,
- Contrôler votre système d’alarme.
2.4. Menaces récemment découvertes
Voici un nuage de mots interactif avec une trentaine de liens vers des articles représentatifs des menaces actuelles. Ces menaces et donc ces vulnérabilités ne représentent que partie émergée de l’Iceberg (le connu). En effet, d’autres vulnérabilités existent forcement, mais non pas encore étaient découvertes ou annoncées.
Passez votre souris sur les mots pour activer les liens. Plus c’est gros plus c’est important …
3. Infrastructure numérique résidentielle
3.1. Vulnérabilité des systèmes
Avant d’aller plus loin, il faut comprendre et identifier le périmètre de risques. Nos résidences connectées sont un ensemble d’équipements divers et variés. Notre périmètre est étendu par de multiples technologies de connectivité et beaucoup de systèmes d’exploitation différents (Windows, Windows mobile, MacOS, iOS, Androïd, Cisco IOS, OpenWRT, DSM, Linux [x distros], EdgeOS, AirOS, RTOS…).
![Maisons connectées et Cybersécurité - Système d'exploitation sécurité Système d'exploitation sécurité]()
Votre maison connectée est donc bien le plus souvent un milieu hétérogène riche en diversité. En aucun cas un des systèmes n’est à l’abri d’une défaillance passée ou future. Si vous voulez réaliser l’étendue des failles passées et résolues, il existe un site qui risque de vous faire réviser vos idées reçues aux sujets de vos systèmes d’exploitation et des applications. Je vous laisse 5 minutes de pauses pour jeter un œil et revenir.
Par exemple : [ Voici les 50 mauvais élèves en 2017 ].
Une règle simple en la matière, et lors que l’on n’est absolument pas spécialiste, est de mettre à jour systématiquement les dispositifs constituant cette infrastructure résidentielle.
3.2. La connectivité et surface d’exposition
3.2.1. Exposition réseaux IP
Nos contrôleurs ou passerelles domotique, nos caméras IP, nos objets connectés, nos Smartphones sont autant de systèmes différents que d’adresse IP déployées sur notre réseau local. Que cela soit par une connexion physique (Ethernet) ou sans-fil (Wifi), ces équipements ne sont généralement pas maîtrisés comme nous le devrions. Ces dispositifs mettent au jour dans le temps des failles de sécurité de conception logicielle ou matériel.
Nous sommes donc tributaire des mises à jour constructeurs/éditeurs corrigeant telle ou telle faille de sécurité, mais nous avons rarement la main sur l’évolution des corrections de ces vulnérabilités.
Ne sous-estimons surtout pas les Smartphones de systèmes et de versions hétérogènes compliquant fortement la sécurité en raison d’un double accès au réseau local de votre réseau WiFi et la connectivité IP de leur 3 ou 4G sur le backbone opérateur.
Le terminal mobile se connecte impunément à tous les points d’accès internet disponible sur son chemin. La capacité d’exposition et de contact d’un smartphone est énorme et cela fait de lui le principal intérêt des pirates. Un logiciel malveillant dans votre smartphone, c’est l’assurance d’une propagation proportionnel aux mouvements potentiels de l’appareil.
Nous comprenons à présent que notre installation n’est pas moins concernée par les enjeux de sécurité qu’un site « professionnel » lambda. Même si il est moins intéressant pour un pirate de s’attaquer à votre installation que celle d’une entreprise (à priori ?), nous ne connaissons pas toujours les motivations des attaquants. Il n’y a pas forcement de gain attendu au bout de chaque assaut, comme par exemple le fait de devenir esclave d’un maître DoS (attaque massive par dénis de service).
Votre exposition publique avec Shodan.io
Shodan est un moteur de recherche créé en 2009 par John Matherly. Ce site référence le résultat de balayages de ports massifs effectués sur le réseau Internet mais il référence aussi les tentatives de connexions réussi aux dispositifs (ex.: CamIP, routeur …) ayant conserver leur configuration d’origine (constructeur) en termes d’identifiant et de mot de passe.
Que connait Shodan.io de votre adresse IP publique (45.58.121.250) ?
|
Edit du 17 avril 2018 :
Remarque pour les terminaux en contact direct avec internet : Par exemple, les smartphones avec un APN 3 ou 4 G logiques sont protégés partiellement d’une exposition directe par le backbone opérateur, mais les APN avec adressage publique (option opérateur) sont directement exposé au contact d’internet. Donc faire le test depuis votre smartphone non connecté à un réseau local n’aura pas de sens … Vous obtiendrez la réponse 404 suivante :
![shodan.io erreur 404 shodan.io erreur 404]()
Un réseau est comme une maison, il dispose de points d’entrées ou de sorties. Pour un réseau, l’IP correspond à l’adresse postale et le port à l’identification de la porte ou fenêtre d’entrées/sorties. Plus vous avez de points d’entrées/sorties plus votre réseau comme votre maison à de faiblesses.
Plus un réseau est isolé ou hermétique, plus il se protège. Si vous stoppez l’accès à internet, ou que vous barricadez votre maison, vous augmenterez sa résistance aux attaques externes. Mais attention pour autant les risques intérieurs sont toujours potentiellement existant.
![Maisons connectées et Cybersécurité - zones adressages opt Maisons connectées et Cybersécurité - zones adressages opt]()
Le trafic entrant ou sortant sont des surface d’exposition :
- Les trafics entrant sont les flux de communication réseau venant d’internet (extérieur), et don,c à destination de votre réseau loca.
- Les trafics sortant sont les flux de communication réseau allant vers internet (extérieur), et donc en provenance de votre réseau local.
3.2.2 Exposition des bus terrain (avec et sans-fil)
Le bus terrain est le moyen de transporter les communications protocolaires entre chaque appareil constituant votre domotique. Cela peut-être des liaisons filaires ModbusRTU, série, KNX, Bacnet … ou encore des liaisons radio-fréquences EnOcean, KNX-RF, Zigbee, Zwave…
Pour les bus-terrain filaires, c’est uniquement un accès par une passerelle IP de cette technologie qui peut la rendre fragile. En effet sans accès physique direct aux câbles de ce bus, il parait complexe d’intercepter les communication de cette liaison. On peut donc dire que le procédé filaire offre moins de surface d’exposition.
Notre domotique sans-fil met en oeuvre d’autres technologies de connectivités sans-fil tierces (Zigbee, EnOcean, Zwave, Zwave+, Zwave S2, bluetooth …). Ces technologies sont « sécurisables » ou déjà sécurisées mais sont implicitement connectable par les radio-fréquences, et offrent donc une faiblesse à l’écoute des communications hertzienne. Des tests et démonstrations de pénétrations des réseaux maillés tel que Zwave ont déjà été publiés et le minima sécurité n’est pas toujours respecté de l’utilisateur/installateur (inclusion en mode sécurisé).
Il existe des technologies de chiffrement (type AES) pour tous ces protocoles, mais rarement avec une clé cryptographique supérieure 128 bits. Rassurons-nous ces équipements ne rayonnent pas à une portée exceptionnelle (quelques dizaines de mètres), et de facto oblige le pirate à se rapprocher pour écouter ou usurper les communications. D’un désavantage pour certain, cette portée devient une protection naturelle de votre domotique sans-fil.
Nos solutions domotique « grand public et professionnelle » à base de protocole radio-fréquences ont tous la capacité d’être sécurisé. Il faut cependant ajouter un bémol à cela, car même si les spécifications de la technologie en question propose plusieurs niveaux de sécurisation par chiffrement des communications, c’est le plus souvent l’utilisateur lui-même qui définit ce niveau de sécurité lors de la phase d’appairage d’un module avec son contrôleur. Nous sommes donc souvent à l’origine de la rétrogradation de sécurité.
Voici quelques éléments de compréhension de la sécurité de ces technologies :
3.2.3. Exposition interne
Mettre en place des barricades sur le front internet ne résout rien en termes de stratégies intérieures. Pour cela, il faut un niveau d’intégrité interne pour éviter les agressions locales pour lesquels les utilisateurs sont les principales faiblesses. Un terminal non fiable (ordinateur/Smartphone), un CD/DVD, une clé USB, un mail, un lien, une image, une messagerie instantanée, le navigateur internet mais bien-entendu aussi les objets connectés sont autant de points faibles qu’il faut impérativement isoler, protéger et surveiller.
Comportement :
Cet aspect de la sécurité est presque le plus important, car ceux sont bien souvent des comportements humains qui sont à l’origine de la faiblesse en sécurité. Nous sommes les principaux responsables de beaucoup d’ouvertures et de faiblesses sur nos infrastructures numérique résidentielles. Nos attitudes sont des risques que nous ne mesurons pas toujours. La navigation internet et les courriers électronique nous exposent facilement jour après jour un peu plus à des menaces insoupçonnées comme le phishing/hameçonnage ou encore le Hijacking/Détournement. Nos enfants sont aussi visés par ces méthodes au travers de leurs centres d’intérêts de navigation internet. Il faut donc aussi maîtriser le trafic sortant de votre réseau résidentiel afin d’éviter les sites potentiellement dangereux.
J’insiste sur cette aspect très souvent oublié des utilisateurs finaux. Certain dirons : – Je n’ai rien à cacher. – Je n’ai rien à protéger.
Alors si ce n’est pour vous pensez à vos enfants, et mettez en place des dispositifs de protections limitant les risques à vos bambins (à minima des heures d’accès et des filtres « sortant » de navigation).
Porte dérobée (backdoor) :
Bien souvent le procédé utilisé pour s’introduire sur votre réseau sera votre crédulité et votre naïveté (comportement). Ainsi en pensant avoir téléchargé une application officielle ou un lien officielle (…) vous allez vous retrouver en situation de modifier le contenu de votre terminal d’accès à internet. Une fois fait, l’exécutable présent sur votre appareils effectuera des opérations plus ou moins critique malgré vous.
L’introduction d’une porte dérobée dans un logiciel (ou un objet connecté) à l’insu de son utilisateur transforme le logiciel ou cet appareil en cheval de Troie. A partir de cette instant votre système est corrompu et fait prendre des risques aux autres appareils sur votre réseau local.
3.2.4. Exposition dans le nuage (cloud)
C’est quoi le cloud [Partie 1] [Partie 2]
C’est la partie du dossier que je préfère le moins car je ne suis pas fan de ces solutions. Certes j’exploite quelques espaces de stockages en ligne pour le partage essentiellement mais de manière générale, si je peux m’en passer, cela me convient mieux. Ce n’est que mon point de vue en tant qu’utilisateur final. Comme je maîtrise personnellement les problématiques de stockage et de flux réseau, je suis effectivement en capacité de me passer de ces architecture le plus souvent.
Toutefois si je sais personnellement interagir avec un réseau privé depuis l’extérieur de ce réseau, Madame Michu, elle ne sait pas faire toute seule. Aujourd’hui pour pénétrer le marché de masse et adresser un maximum de personnes (démocratisation), il faut accepter qu’un objet soit d’abord connecté au « cloud » (services du fabricant) avant d’interagir avec nos autres équipements connectés comme nos téléphones .
L’idée étant de permettre de manière transparente l’accès aux services du dit objet dans toutes les circonstances de connectivité à internet (chez moi, ou en déplacement ça fonctionne). Un deuxième argument est aussi souvent employé pour motiver l’utilisateur de l’intérêt du cloud. « On sauvegarde gratuitement ses données collectées ». Génial alors! Le marché est ainsi fait, qu’il faut apprendre à vivre avec ces architectures.
L’accessibilité permanente et le stockage des données sont les avantages vendus à l’utilisateur, mais il existe aussi des d’avantages pour le fabricant.
En effet, certains développements IoT permettent de limiter considérablement le coût de R&D matériel en déplaçant les capacités en ressources (CPU, RAM et/ou Stockage…) du côté du nuage (90% des objets connectés.), et ainsi permettre une interface homme/machine (IHM) déportée sur internet.
L’autre avantage et non des moindre est que le fabricant peut exploiter les séries de données temporelles de tous les utilisateurs, et ainsi il peut opérer quelques calculs savant sur le jeu de données (Machine & Deep learning, IA) lui permettant d’optimiser des fonctions de services du produit, voir « prêter » les données anonymisées à des tiers (Mon article sur la Valorisation des données de vos objets connectées).
Dans cette course rapide qu’est la valorisation des données, certains fabricants en oublient parfois l’essentiel. La sécurité ! Sachant que le cloud ajoute en surface d’exposition internet (Objet connecté > internet > Cloud > internet > Smartphone), on comprend que le flux de communication extérieur s’en trouve doublé et de facto l’exposition aux menaces aussi.
Il faut donc veiller à la qualité de chiffrement des canaux de communications (tunnel) et à la qualité des interfaces de connexions (API) avec de l’authentification forte. Ces interfaces devrait idéalement être développées avec des technologies comme TLS/SSL, OAuth, OpenID, SAML, SW-Security, ou encore des branches (fork) de ces développements.
La sécurité peut être pour certain le cadet des soucis, et pour d’autres aussi important que les fonctions de la solution. Oui la sécurité est une « feature » comme les autres. Même si elle se matérialise par rien de palpable pour l’utilisateur au niveau produit et marketing, cela devrait-être un passage obligé pour les fabricants responsables.
Pour résumer, nous sommes donc tributaire et dépendant de la stratégie de développement du fabricant de l’objet connecté, qui ne communique pas souvent les éléments techniques permettant d’évaluer la solution dans sont ensemble. Il ne nous reste donc plus que les retours d’expériences des différentes communautés ainsi que de leurs tests pour évaluer le niveau d’intégrité des produits et des architectures en attendant de constater les changements liés au nouveau règlement européen sur les données personnelles.
Opportunité RGPD
Le règlement européen sur les données personnelles (RGPD) va considérablement redistribuer les cartes du jeu. D’un point de vue utilisateur et fabricant cela peut restaurer la relation de confiance que le marché attend pour exploser. Les obligations Européennes vont avoir un effet positif sur nos territoires, mais aussi à l’international pour les fabricants/éditeurs offrant des services dans le nuage pour les Européens.
Le gros avantage de ces obligations, sont qu’elles définissent des spécifications structurantes en termes de fonctionnalités génériques (Transfert, formats, portabilité, flux administratif …) et d’un point de vue « architecture technique » devrait amener plus de sécurité aux données personnelles.
Ce cadre réglementaire semble presque arriver au bon moment pour ceux en phase de conception d’un produit connecté au cloud, et un peu en retard pour ceux ayant déjà développé ces dernières années.
Le développement de ce marché nécessite inéluctablement des architectures « Cloud » dont l’universalité est aujourd’hui démontrée, et n’ayant pas d’alternative technologique simple pour l’instant.
Gageons que toutes ces années sans cadre normatif soient derrière nous, et attendons de voir les changements se mettre en place…
4. Préconisations, quelques bonnes pratiques
Restons positif, même s’il existe souvent des trous dans la passoire, il existe des dispositifs et des contre-mesures pour se protéger d’une grande partie des menaces et des vulnérabilités. L’important dans ce domaine est de s’informer et de corriger en permanence les risques potentiels.
Il existe un ensemble de mesures simple permettant de limiter facilement la surface d’exposition aux menaces (attaques). Il faut donc identifier les risques afin de mettre en place les modifications adaptées à votre Infrastructure numérique résidentielle.
Sans devenir un paranoïaque ou un expert en Cyber-sécurité gonflé à bloc, il est opportun de sensibiliser les utilisateurs aux enjeux et risques des failles dans nos systèmes numérique résidentiels.
Il va de soit que je ne peux vous proposer que des pistes de sécurisation, mais il est impossible de faire un tutoriel pour chaque solution proposée en raison de l’aspect hétérogène (Système d’exploitation) de nos infrastructures. Voici donc un ensemble de bonnes pratiques plus ou moins adaptées au contexte, à nos connaissances et nos compétences.
4.1. Les identifiant et mot de passe
La principale menace : Les attaques brute force
- Renommez OBLIGATOIREMENT les comptes aux privilèges administrateur.
- Pas de compte nommé d’origine (root, admin, administrator, administrateur…)
- Désactiver les comptes invités (guest).
- Pour l’identifiant vous pouvez aussi augmenter sa complexité au même titre que le mot de passe.
- Ne pas utiliser systématiquement le même couple identifiant/mot de passe sur tous les services réseaux que vous exploitez.
- Sécurisez vos mots de passe (voir recommandations de l’agence nationale de la sécurité des systèmes d’informations [ANSSI]).
Pour faire simple, deux méthodes pour choisir vos mots de passe :
- La méthode phonétique : « J’ai acheté huit cd pour cent euros cet après-midi » deviendra ght8CD%E7am ;
- La méthode des premières lettres : la citation « un tien vaut mieux que deux tu l’auras » donnera 1tvmQ2tl’A.
4.2. Les protections individuelles
Les protections individuelles sont les dispositifs hébergés par chaque machine/terminal. Voici un ensemble de règles qu’il faut impérativement s’imposer :
- Toutes vos machines sur votre réseau ou vos sous-réseaux privés et en fonction de leurs usages, doivent disposer de leurs propres défenses et protections (Antivirus, et Anti-malware puis bien entendu un pare-feu limitant les accès entrant sur la machine, Anti-spam, Adblocker ….).
- Toutes machines inconnues (invités, amis, famille) doivent se connecter un autre réseau (DMZ, LAN, VLAN) que votre cœur de réseau. Cette mise en quarantaine physique est nécessaire pour vous protéger des terminaux que vous ne maîtrisez pas en termes de sécurité.
- Remarque pour les terminaux en contact direct avec internet : Par exemple, les smartphones avec un APN 3 ou 4 G logiques sont protégés partiellement d’une exposition directe par le backbone opérateur, mais les APN avec adressage publique (option opérateur) sont directement exposé au contact d’internet.
4.3. Interface de bordure (routeur de bordure)
C’est le dispositif recevant l’adresse IP publique de votre fournisseur d’accès à internet. Communément appelé « patte externe » ou « patte WAN » c’est la première interface réseau que vous gérez et la première au contact direct d’internet. C’est donc la carte réseau vue de l’extérieur. Cette interface doit disposer d’un maximum de défense face à internet.
- Une des premières choses est de configurer cette interface externe de manière à ce qu’elle ne réponde pas au Ping ICMP (Option courante des routeurs FAI). En effet, il faut considérer que les robots d’attaques peuvent d’abord vérifier la présence de l’IP publique sur internet. Vous me direz qu’il est possible de faire un ping applicatif est découvrir que finalement une adresse IP publique peut répondre à des requêtes protocolaires diverses, et ainsi déterminer la présence de l’IP publique sur internet. Nous sommes bien d’accord et personnellement j’ai divisé par 300 le nombre d’attaques « Brute force » en faisant cela.
- Une des actions les plus évidente et généralement configurer par défaut sur un routeur qui se respecte, est l’activation de la protection DDoS (Distributed Denial of Service attack). Ce n’est pas une option c’est obligatoire.
- Activez le pare-feu et éviter de faire de la translation d’adresse entrante [NAT et Port forwarding]. Voir section « Gestion des flux » ci-dessous.
- Ne pas activer les options d’administration à distance des routeurs de bordure (box internet FAI) que cela soit en HTTPS ou SSH. Les éléments actifs constituants votre infrastructures réseaux ne doivent jamais être accessible directement depuis l’extérieur (Ou alors ponctuellement pour une problématique particulière).
- Désactivez les options de configuration du protocole Universal Plug n’ Play [UPnP].
4.4. Administration distante (SSH)
Bien que je ne sois pas favorable à l’exposition du port SSH (22) sur l’interface publique d’une machine (NAT ou pas), il y a des situations pouvant l’imposer (Hébergement Serveur dédié ou VPS …). Dans ce cas particuliers il va falloir mettre en place au moins deux défenses voir trois pour sécuriser cette situation dangereuse. Il existe dans le monde Linux et les autres mondes aussi des solutions que je citerais de manière générique. Voici les solutions élémentaires, mais il en existe d’autres. La logique de défense SSH doit-être mise en place quelques soit l’environnement ou le protocole à partir du moment où un accès avec privilèges élevés est mise en place et disponible sur l’interface publique d’une machine (RDP par exemple) :
- Clé publique/Clé privé : Mettre en place la relation de confiance croisée sur la base de clés publique et privé.
- Bastion SSH : Mettre en place une forteresse SSH pour disposer d’un point d’entrée unique sur tous les services « sshd »de votre réseau privé.
- SSH Proxy ou reverse SSH : Mettre en place des tunnels montant de vos ressources SSH intérieures vers le bastion (ssh proxycommand).
- Port Knocking : Mettre en place un code séquence « Toc To Toc » sur trois ports pour ouvrir à la demande et ponctuellement SSH sur le port 22.
- Bannissement IP : Mettre en place un logiciel gardien de connexions, pour bannir les IP après X tentatives de connexions échouées (Fail2Ban par exemple).
![Administration distante SSH - Bastion SSH - Port knocking Administration distante SSH - Bastion SSH - Port knocking]()
Dans le schéma ci-dessus est expliqué l’architecture mixant Clés publique et privé, le mode Bastion pour gérer d’autres machines dans votre réseau privé et le Port-Knocking (Code sessions : Toc Toc Toc, port1 port2 port3) pour autoriser ponctuellement le port 22.
4.5. Gestion des flux avec internet
Voici quelques petites règles évidentes à respecter le plus strictement possible.
4.5.1. Filtration entrante
- Dans la mesure du possible limitez un maximum l’ouverture de ports vers votre réseau privé.
- Si vous devez le faire n’utilisez pas les ports logiques « port/service » comme « 21/FTP » mais modifiez par exemple en 1021/FTP.
- Préférez les protocoles sécurisés comme « HTTPS » au lieu de « HTTP ».
- Jamais au grand jamais n’activez les fonctions
UPNP (de vos routeurs/pare-feu/box-internet/ordinateur)
4.5.2 Filtration sortante
- Dans la mesure du possible limitez un maximum l’ouverture de ports vers internet. Pourquoi ? Me diriez-vous. Car par exemple les logiciels malicieux pourraient entrer simplement en communication Peer to Peer et donner la main sur vos fichiers à un pirate.
- Envisagez la filtration d’URL avec un « cache proxy » (Comme Squid Cache, mitmproxy … ), ou par filtration DNS externe (Comme OpenDNS).
- Bloquez le port 53 (DNS) en sortie afin de préserver les routes DNS que vous mettez en place depuis votre routeur/DHCP. Ainsi vous vous préservez des logiciels malveillants utilisant des resolveurs DNS racine (extérieur) malgré votre stratégie de sécurité.
![filtration des flux filtration des flux]()
4.6. Accès sécurisé à votre réseau depuis l’extérieur
Accéder à son réseau local est parfois nécessaire pour effectuer des opérations d’administration système ou réseau à distance. Pour ce type d’usage n’utilisez que l’accès VPN. Ainsi une fois connecté de manière sécurisée et à l’abris dans un tunnel de communication chiffrés, vous pourrez utiliser tous les services locaux d’administration de vos machines (SSH, RPD, SCP, … ) comme si vous vous trouviez physiquement chez vous, sur le même réseau.
- Pas de port SSH entrant exposé sur internet (sans protections précisées en section 4.4).
- Mettez en place un accès sécurisé à votre réseau privé par l’utilisation d’un réseau privé virtuel (RPV = VPN). C’est la manière la plus efficace de préserver l’intégrité de votre réseau résidentiel.
- Préférez les protocoles robustes comme L2TP/IPSec (et authentification Radius) ou OpenVPN plutôt que PPTP.
- Optionnellement, mettez en place un VPN sortant pour anonymiser vos usages d’internet (The best VPN Review 2018).
![Réseau privé virtuel Réseau privé virtuel]()
4.7. Le cloisonnement (ou segmentation)
- Un vieil adage nous dit : « Ne mettez pas tous vos œufs dans le même panier« . Il en va de même pour vos systèmes. Tant que faire se peut, catégorisez vos nœuds (appareils) par niveau de criticité (ex.: risques inconnu, risques faible, fiable ) et isolez les d’un contact direct sur le même sous-réseau en mettant en place une DMZ derrière votre routeur internet (Zone au niveau de risque supérieur ou les machines devront faire l’objet d’une configuration en sécurité accrue).
- Si vous disposez d’un serveur DHCP « multi-étendues » et d’un « switch administrable » compatible avec les VLANs, préférez la mise en place d’une segmentation par LANs virtuels (Comme le schéma ci-dessous).
- Mettez en place entre les zones (V/LAN) des polices pare-feu (entrantes/sortantes) et des routes adaptées aux usages et aux risques en fonction de vos zones.
![cloisonnement par vlans cloisonnement par vlans]()
L’avantage est de permettre une configuration dédiée et adaptée avec pour chaque segment des stratégies de sécurité différentes.
Par exemple, le VLAN KIDS est aussi un accès Wifi dédié aux enfants. Au-delà du contrôle d’accès horaire (plage d’accès) pour les enfants, nous pouvons mettre en oeuvre une filtration par catégories de sites avec OpenDNS (Family/Home) pour éviter que vos enfants accèdent à des sites potentiellement dangereux ou aux contenus douteux. Dans ce cas : Bloquez le port 53 (DNS) en sortie afin de préserver les routes DNS que vous mettez en place depuis votre routeur/DHCP.
![webfiltering opendns webfiltering opendns]()
4.8. Services Web hébergés chez vous
Si vous deviez vraiment publier des services en ligne de type Web :
- Préférez la mise en oeuvre du chiffrement « TLS/SSL » (443/HTTPS
80/HTTP) avec un certificat d’autorité publique (ex.: Let’s Encrypt), et si vraiment vous n’avez pas le choix un certificat auto-signé.
- N’utilisez plus les authentifications HTTP (BasicAuthentification) qui circule en clair (sans chiffrement) sur la toile.
- Configurez votre serveur avec le maximum de protection (Ne pas renvoyer de signature logiciel [système, serveur web], « .htaccess », IPTable, Fail2Ban)
- Mettez en oeuvre un ou plusieurs dispositifs de « sécurité et de redirection de services » avec une fonction « reverse proxy » (Configuration Ngnix, VirtualHost Apache, HAProxy …) pour ainsi rediriger les flux de services internes et éventuellement de l’équilibre de charge.
![Gestion des redirections d’accès HTTPS Gestion des redirections d’accès HTTPS]()
4.9. Interopérabilité « Extérieur/Intérieur »
Avec nos envies de « technophiles avertis (Mon article sur l’interopérabilité)« , il arrive souvent que nous testions et mettions en oeuvre des flux de communication entre objets, serveur local, contrôleur domotique afin d’augmenter des fonctions résidentielles (scènes) par l’interopérabilité des dispositifs intérieur et extérieur.
Il est totalement dénué de bon sens de mettre en relation ces appareils sans se prémunir d’un minimum de sécurité. Dès que cette interopérabilité nécessite une relation extérieure avec API, préférez les technologies sécurisées comme TLS/SSL, OAuth, OpenID, SAML, SW-Security. On voit couramment des tutoriels mettant en oeuvre des connexions directes de l’extérieur vers l’intérieur de votre réseau sans aucune sécurité. Évitez ce piège !
- De manière générale, limitez l’exposition logiciel entre extérieur et intérieur de votre réseau local.
- N’utilisez jamais les URL avec authentification dans la requête HTTP :
http://user:password@192.168.1.x/
- Préférez les dispositifs IdO offrant une interface (IHM) locale, et une interface de communication locale aussi [API] (sur votre réseau).
- Limitez l’interopérabilité sur les interfaces externe ne disposant pas d’API sécurisées.
- Ne mettez pas en place de Webhook IFTTT vers l’intérieur de votre réseau sans accès SSL à votre réseau.
La vraie fausse bonne idée est de faire quelque chose parce qu’il n’y pas d’autre solution à votre portée. En ce domaine il vaut mieux rien que certaines configurations dénuées de défense. La vraie fausse bonne idée serait d’appliquer un tutoriel sans comprendre ce qu’on fait et les risques d’exposition auxquels on s’expose.
![webhook ssl ifttt sur oauth2 ngrok webhook ssl ifttt sur oauth2 ngrok]()
Le schéma ci-dessus explique une alternative à l’ouverture de ports sur votre routeur. Le dispositif Ngrok permet de déporter/projeter le point d’entrée d’un service web en dehors du réseau local avec un tunnel sortant sécurisé vers le service Ngrok. C’est l’infrastructure du service Ngrok qui va offrir le point d’entrée à la ressources intérieur de votre réseau. Qui plus est, l’infrastructure offrira une API d’authentification forte de type OAuth. Ainsi on peut mettre en place un webhook IFTTT sécurisé de bout en bout.
Dans le cas présent, le webhook provient d’IFTTT, mais cela pourrait très bien provenir du service cloud de l’objet connecté en question. Ce type de service est préjudiciable en entreprise mais l’est moins pour un particulier qui maîtrise son environnement système et réseau. En effet, il est évident que si des développeurs sans scrupule mettent en oeuvre cela en entreprise et sans que la DSI n’ait de filtre DNS sortant sur « ngrok.com », ils exposent une machine interne (qui peut devenir relais) à l’extérieur du SI de manière invisible pour l’entreprise.
Si maîtrisé, cela n’a donc rien de plus dangereux qu’un NAT 443 vers une machine interne, ou un reverse proxy qui redirige sur une machine interne de votre réseau. L’avantage est donc de ne pas ouvrir un port entrant sur notre routeur, et voir même de multiplier plusieurs points d’entrées en multi-domaines xxx.ngrok.org sans faire de Virtualhost Apache et/ou d’alias web (Free ou offres d’abonnements).
Par contre, dans le cas de requête venant du Cloud Google home (ou d’autres), cela peut prendre du sens, car on expose pas son routeur/Pare-feu, mais bien une machine qui va s’apparenter à un « DMZ Server ». Si en plus Ngrok s’exécute sur une VM ou un container Docker, On minimise encore les risques par cloisonnement.
Une alternative plus simple avec de l’huile de coude
Toujours dans la perspectives de trouver plus simple pour des codeurs, il existe d’autres méthodes, permettant de monter rapidement une interface applicative sécurisée avec encore une fois une authentification OAuth2 (SSL/433 avec ou sans reverse Proxy.).
Par exemple je veux que mon Google Home interagisse avec mon contrôleur domotique. Voici donc la chaîne de communication à mettre en oeuvre :
GH > Google Actions > Client Oauth2 > HTTPS/433 > API Restfull (Python + Flask + Librairie Oauth2) > API locale de la domotique
Un simple script python et deux librairies (flask, flask_oauth) permettent la mise en place d’une API sécurisée de bordure. C’est assez simple à mettre en oeuvre lorsque l’on maîtrise son infrastructure réseau et le code python. Veuillez trouver sur ce Git l’exemple expliqué : https://github.com/mitsuhiko/flask-oauth
4.10. Accès direct au réseau local
Au même titre que les ports qui sont des portes/fenêtres sur votre maison connectée, accéder à votre/vos réseau(x) parce que les portes ou les fenêtres ne sont pas verrouillés vous laisse encourir des risques. Pour éviter ces risques, vous devez verrouiller systématiquement l’accès direct à votre réseau.
« Diviser » pour mieux régner : Dans le même esprit que le cloisonnement par LAN virtuel vous pourrez par exemple mettre en place plusieurs réseaux Wifi SSID et isoler les terminaux invités/amis/famille sur un autre sous-réseau que votre cœur de réseau.
Pour l’Ethernet (Câcle réseau RJ45)
- Pas d’accès physique et direct à vos switchs, routeurs et autres éléments actifs.
- Privilégiez les authentifications Radius 802.1x si vous disposez de ces options sur vos switchs/routeurs/serveurs.
- Réservez les relations port switch/MAC adresse (NAC) si vous disposez de ces options sur vos switchs.
- N’attribuez des baux DHCP qu’aux machines connues.
Pour les sans-fil (WiFi)
- Pas d’accès direct en mode Wifi
Open.
- Privilégiez l’authentification/chiffrement WPA2 (TKIP/AES/CCMP), oubliez WPA (TKIP/AES/CCMP).
- Évitez le mode portail captif pour les invités sauf si vous louez ou prêtez votre maison connectée.
4.11. Maintien opérationnel
4.11.1 Mise à l’épreuve (Auto-évaluation)
Mettre à l’épreuve vos infrastructures est un moyen de mieux mesurer les risques auxquels vous vous exposez.
Sans entrer dans les spécificités d’un certain nombre de distributions Linux orientées Sécurité (comme Kali), sachez que ces distributions « Live CD » vous permettent d’effectuer des tests externe ou interne à vos infrastructures. Si vous n’avez pas l’énergie pour vous y mettre, vous pouvez déjà évaluer votre exposition publique avec des solutions en ligne comme :
![Security Space Audit Security Space Audit]()
4.11.2 Veiller
- Afin de mettre en oeuvre un suivi régulier des vulnérabilités, il faut consulter régulièrement les alertes CERT-FR [gouvernemental](Computer Emergency Response Team) Il existe des services d’abonnements et notifications.
- Un CERT est un centre d’alerte et de réaction aux attaques informatiques, destiné aux entreprises ou aux administrations, mais dont les informations sont généralement accessibles à tous.
- Cherchez et mettez à jour vos appareils régulièrement.
4.11.3 Surveiller
![Maisons connectées et Cybersécurité - surveiller monitoring Maisons connectées et Cybersécurité - surveiller monitoring]()
Là, le sujet est assez fastidieux mais mérite quelques pistes tout de même. Surveiller quoi et avec quel outil ? Ce n’est pas évident de conseiller des outils en la matière. Je me cacherais donc derrière la même excuse que précédemment : Dans le cas présent l’hétérogénéité de nos installations ne permet pas d’élire les meilleurs outils pour chacun des systèmes d’exploitations que nous utilisons. Pour ma part, système et réseaux sont sur des plateformes Linux à 100% et seul les terminaux (Ordinateur, Smartphone, Tablette) sont iOS et Windows.
Mes outils favoris reste assez souvent des commandes terminal Linux comme :
- netstat,
- netcat (nc),
- nmap, tcpdump,
- mitmproxy
En mode graphique, Wireshark reste un incontournable.
Pour les aspects analyse de flux (Paquet) j’utilise les fonctions DPI (Deep Inspection Packet) d’« Unifi controler » [Demo en ligne] ce qui est très accessible graphiquement.
![Analyse DPI Analyse DPI]()
Nous pourrions aussi expliquer les outils comme Bro IDS, Suricata, Moloch, Pentestbox, P4wnP1, USB Rubber Ducky, Elasticsearch, Logstash, Kibana, Critical Stack, Tripwire, BriarIDS, Security Onion, ou encore SweetSecurity, mais un autre dossier serait nécessaire pour distinguer les différences entre ces puissants environnements logiciels de type IDS/IPS (Intrusion detection system ou Intrusion prevention system) ou de Pentesting.
![pentesting ids ips pentesting ids ips]()
Ceux sont des solutions assez consistantes pour lesquels il faut déjà avoir une connaissance TCP/IP très approfondie. Pour ma part, j’ai utilisé plusieurs de ces solutions, et j’utilise finalement l’implémentation Bêta de l’UniFi Controller (A partir de la version UniFi 5.7.2 la fonction IPS apparaît en fonction bêta).
Lorsqu’une action anormale est détectée une alerte par mail ou une notification dans l’app mobile est envoyée :
![Unifi Controller IDS / IPS Unifi Controller IDS / IPS]()
Cela sera donc à vous de définir vos logiciels favoris en fonction de votre contexte technique.
L’intelligence artificielle, une révolution pour la cybersécurité ?
Nul doute que l’analyse temps réel de centaines de logs nécessite un traitement réaction accéléré. Il semble donc plus que probable que IA trouve rapidement sa place parmi les futurs solutions IPS .
Face à une quantité toujours plus importante de données, identifier une activité illicite parmi un flot d’actions légitimes devient de plus en plus complexe. Le balayage manuel d’une telle quantité de données (ex : logs) n’est plus possible depuis longtemps. [Source]
Le miracle et mirage commercial
Quant aux solutions résidentielles clés en mains agrégeant box/routeur/wifi + VPN + IA pour protéger vos appareils à la maison, il me semble que ceux ne sont pour l’instant que des arguments commerciaux pour vendre des routeurs SOHO avec une refonte ergonomique les rendant plus accessible, mais paradoxe intéressant, ces « boxes » ont souvent moins d’options de configuration que des routeurs deux fois moins chers. De mon point de vue, Il n’y a à ce jour aucune vraie solution intégrée de protection résidentielle.
5. Conclusion
Si vous hébergez qu’un seul ou deux objets connectés, ou si votre pool d’adresses IP ne dépasse pas 10 nœuds (appareils), pas la peine de mettre en place des solutions surdimensionnées comme évoquées plus haut. Une bonne stratégies de filtration internet et quelques règles pare-feu peuvent faire l’affaire. A minima tenter de cloisonner/isoler les objets pour lesquels vous semblez avoir des doutes.
Ne comptez que sur vous-même, car les éditeurs et les constructeurs sont souvent trop discrets quand à leurs erreurs de développements. Les éditeurs et constructeurs de renommées internationales sont implicitement obligés de corriger leurs vulnérabilités en raison de leur forte exposition aux piratages de leur systèmes.
Un produit vendu à de grandes quantités reste l’objectif de choix des pirates. Microsoft en son temps était le symboles des failles dans tous les sens… Maintenant, Google/Androïd est au devant de la scène car c’est la plateforme connectée la plus représentative sur terre. Donc la cible la plus pertinente pour toucher le plus grand nombre de machines. Heureusement que ces grands éditeurs corrigent parfois leurs systèmes.
Par contre, on constate parfois beaucoup moins d’implication et de réactivité sur les aspects « sécurité » pour les éditeurs et fabricants à cycle de développement court. En effet, à ce jour que les produits mis sur le marché « rapidement » (opportunisme) sont assez souvent dépourvu de stratégies de sécurité. Il faut donc être très vigilant avec ces équipements et sociétés récentes qui répondent en priorité à la demande commerciale sans intégrer de spécifications dédiées à la sécurité.
- Le règlement européen sur les données personnelles (RGPD) devrait lisser le niveau d’exigence attendu.
- Et si un label cyber-responsable permettait d’identifier rapidement les constructeurs répondant à un minimum de qualité sécuritaire ?
- Y a-t-il un moyen de savoir rapidement si un périphérique IoT domestique est sécurisé ?
Il existe une plateforme web indépendante (sur le papier) effectuant des évaluations de sécurité d’objets connectés. Cette plateforme se nomme https://www.iot-tests.org. La base de données est loin d’être exhaustive et le barème d’évaluation n’est pas d’une grande précision, mais les éléments d’analyse de l’objet sont intéressants.
La vérité est parfois douloureuse, mais dans certains cas, mieux vaut se rendre à l’évidence. C’est ce qu’a fait le Broadband Internet Technical Advisory Group (Bitag), qui, dans son dernier rapport, a décidé de regarder les choses en face au regard de l’Internet des Objets : non, les consommateurs ne vont pas mettre à jour le microcode de leurs appareils. « Il est plus raisonnable de supposer que la plupart des utilisateurs finaux ne prendront jamais les mesures nécessaires pour mettre à jour leurs logiciels », a ainsi déclaré le Bitag qui recommande, entre autres choses, aux fabricants de mettre en place des mécanismes de mises à jour automatiques et sécurisés.
« Par défaut, les périphériques IoT ne devraient pas être accessibles par des connexions réseau entrantes, y compris à partir de périphériques qui se trouvent dans la même maison, car ceux-là ont pu être compromis », déclare le Bitag qui rappelle qu’un pare-feu ne suffit pas pour bloquer les communications non sécurisées.
Source : Le Monde Informatique – Comment sécuriser l’IoT : en s’attendant au pire
Nous espérons que ce dossier vous aura permis d’assimiler les risques et vous sensibiliser à votre part de responsabilité dans vos choix et vos actes.
The post Maisons connectées et Cybersécurité appeared first on Domotique Info.