Quantification commune de la disponibilités des relais

Les quelques entités robot que je teste sont maintenant tout à fait capable de synchroniser des liens et objets divers. Le problème est souvent de savoir ce que l’on veut synchroniser en fait.

Chaque robot essaye de télécharger un objet sur toutes les autres entités qu’il connaît. Ou plus exactement sur toutes les localisations qu’il connaît, même si ce n’est pas une entité connue. Le téléchargement est actuellement unitaire. L’objet téléchargé doit être complet, on ne prend pas un bout à un endroit et le reste ailleurs comme avec le P2P habituellement. Ce raffinement sera pour plus tard. Et l’ordre des localisations est toujours parcouru de la même façon, c’est à dire dans l’ordre des liens de ces localisations avec l’objet qui les référence.
Évidement, la vérification de l’intégrité des objets et la vérification des signatures des liens associés permet de ne pas se soucier de savoir sur quel entité relais l’objet est téléchargé.

Ce système est assez primaire mais il remplit parfaitement son rôle. Cependant, en terme de performance, on peut faire mieux…

Une des solutions peut être d’enregistrer systématiquement le débit moyen de téléchargement d’un objet sur une localisation particulière. Des statistiques vont commencer à s’accumuler avec le temps et le robot pourra ensuite privilégier certaines localisations en fonctions de leurs statistiques.
Si chaque mesure de débit moyen est lié à la localisation comme étant une statistique, l’ensemble des statistiques des entités peuvent se propager d’une entité à l’autre. Ainsi c’est l’ensemble des robots qui peuvent profiter des statistiques pour affiner le classement des localisations.
Il faut quand même ne pas tout prendre brute quoiqu’il arrive. Des statistiques anciennes n’ont que peu de valeur. De même, comment interpréter les statistiques d’une entité à l’autre bout du monde, et donc qui a des temps de latence différents ? Une moyenne non pondérée entre les statistiques de toutes les entités est-elle suffisante pour gommer des valeurs anormales de débit moyen ?

Priorité des liens à date identique

Comment doivent être interprétés des liens différents et dont la date est identique. Ce peut être le cas d’un lien de type u ayant strictement la même date qu’un lien identique mais de type x.

Est-ce qu’il y a un ordre préférentiel de lecture, et donc inversement de prise en compte ?
Le lien de type x est-il plus important que le lien de type u ou f par exemple?

Aujourd’hui, les implémentations de références doivent traiter les liens dans l’ordre tel que définit dans la documentation de référence. Donc le lien x devient implicitement, par ce que étant le dernier appliqué, celui qui a le plus de poids.

Référence des librairies en bash

L’entité bachue commence sont rôle de diffusion de logiciels signés.

Le tout premier est logiquement la librairie nebule en bash puisque c’est l’implémentation la plus avancée à ce jour.

Déploiement

Un objet dédié contenant « nebule/bachue/reference/bash », de hash 2d0468b3153a1a43861ada08cc0a209df138f581df61b8ebc4cf022ee3d83aef, permet de suivre l’évolution des version successives de la librairie. Pour cela, un lien de type f est fait entre cet objet et les objets successifs contenants les différentes versions de la librairie.
Un autre lien de type u est fait directement entre deux versions successives de la librairie.

Annulation

Si une version de la librairie doit être annulée, il y a plusieurs méthodes possibles qui aboutissent à ce résultat :

  1. La première méthode est de déployer une nouvelle version de la librairie et de faire un lien de type u entre la version à annuler et la nouvelle version. Normalement, toutes les entités devraient ainsi mettre à jour leur copie de la librairie avec la nouvelle version, ce depuis la version à annuler ou depuis une version antérieur.
  2. La seconde méthode est d’annuler le lien de mise à jour (type u) avec un lien de type x. Dans ce cas, toutes les entités avec la version de librairie à annuler devraient ainsi mettre à jour leur copie de la librairie vers la version précédente en attendant une nouvelle version. Les entités avec une version antérieur de la librairie s’arrêteront naturellement à la version précédent la version à annuler, en attendant aussi une nouvelle version.
  3. Une troisième solution pourrait être d’ajouter un lien de type u en sens inverse, c’est à dire entre la version de la librairie à annuler et la version précédente. Cependant, cela crée une boucle dans les liens de mises à jour d’un objet avec tous les risques de boucles infinies à gérer que cela entraîne. C’est une solution similaire à la deuxième solution.

dans tous les cas, par sécurité on peut demander la suppression de l’objet contenant la librairie à annuler avec un lien de type d.

La seconde méthode me paraît plus hasardeuse dans le sens où elle nécessite une régression dans la mise en application des versions de la librairie. Cependant elle à le mérite de pouvoir répondre immédiatement à un problème sans attendre la mise en place rapide d’une nouvelle version.

Attention, la version actuelle de la librairie ne tient pas encore compte des liens de type u, x et d. Ce développement devrait arriver assez rapidement pour couvrir ce besoin de gestion des références de logiciels.

Ralentissement des échanges à débit constant

Je commence à voir ressortir un problème que je ne pensais pas avoir à régler si tôt.

Le nombre d’objets augmente, et avec, les liens associés aussi. Or lorsqu’un robot par exemple synchronise les liens d’un objet pivot, que l’on peut plutôt appeler un nÅ“ud, il télécharge systématiquement l’intégralité des liens… et vérifie leurs signatures.
Tant qu’il n’y en avait pas beaucoup, ça ne se sentait pas trop sur le temps de synchronisation. Mais ça commence à se voir aujourd’hui sur certains objets.

Une des solutions serait de voir si le lien est déjà connu. Cela oblige à parcourir l’intégralité des liens d’un objet qui justement peut en contenir beaucoup. On va gagner à court terme sur le traitement des liens. Mais on continue à télécharger des liens inutilement.
Et que ce passera-t-il lorsque la recherche de la présence du lien sera plus longue que la vérification de sa signature?
Bref, cela ne fait que reporter le problème à plus tard…

Il faut résoudre ce problème de façon plus élégante. Cela peut être fait en demandant les liens après un lien particulier, le dernier que l’on connaît déjà.
Cela oblige à implémenter la fonction côté entité, mais aussi côté serveur. Or la façon dont les serveurs web délivrent les liens et objets ne se pas prête à ça. Il faut leur ajouter un peu plus d’intelligence.

D’un autre côté, la vérification si le lien est déjà présent est réalisée juste avant de l’ajouter à un objet… On aura aussi un problème à résoudre à cette étape là…

Auto-vérification automatique périodique – 2

Suite à la mise en application automatique de la vérification des objets et liens, il y avait eu des pertes.

Je n’ai pas essayé de restaurer les objets qui n’ont pas d’importance ici. Mais j’ai restauré les liens depuis une autre entité. La restauration répare en grande partie les liens.

Le résultat est visible :

Auto-vérification automatique périodique

Une des expériences en cours est la vérification automatisée et à intervalle régulier de tous les objets et de tous les liens des objets.

Les objets sont faciles à vérifier, on calcule leur empreinte et on vérifie qu’elle correspond à leur nom. Si elle diffère, on le supprime. Si l’objet n’a pas de liens, il est jugé comme une pièce rapportée, on le supprime aussi.

Les liens sont assez faciles à vérifier aussi. Il faut procéder objet par objet, prendre les liens un par un et vérifier que la signature est valide pour l’entité qui l’a générée. Si la signature diffère, on supprime le lien. Si l’entité est inconnue, la signature ne pourra être vérifiée, le lien est donc supprimé aussi.

Ce petit bout de script reste assez simple et doit être testé soigneusement pour éviter des dommages collatéraux. Il m’avait semblé l’avoir testé suffisamment… mais visiblement il y a eu des dégâts pour certaines entités.

Voici notamment le résultat sur les sauvegardes de la machine zulu (à comparer à ce graphe ci) :

On peut encore allez plus loin. Non dans les dégâts collatéraux mais dans une forme plus poussée d’immunisation. L’entité peut entretenir une liste d’objets jugés dangereux, et donc à supprimer. Elle peut et surtout doit aussi se référencer à une entité dédiée au marquage d’objets dangereux, c’est le rôle justement de cerberus

Continuer la lecture de Auto-vérification automatique périodique

Chiffrement fonctionnel vers une entité tierce

Le chiffrement est fonctionnel vers une entité tierce. Toujours sans pré-compression des données.

Cela donne ce type de graphe pour le chiffrement de multiples objets vers une entité :

CF :
Chiffrement fonctionnel
Chiffrement et type mime
Chiffrement et vecteur initial
Chiffrement et compression
Introduction à la cryptographie

Localisation de fichiers

Une étape importante dans l’utilisation de nebule, c’est d’importer des données. Ces données sont typiquement des fichiers existants. Cette opération d’importation de fichiers, c’est la nébulisation de fichiers.

La nébulisation de fichiers ne présente pas à priori de difficultés. On calcule son empreinte et on lui associe tout un tas d’informations telles que son type mime, sa taille, etc…

Il y a cependant une propriété des fichiers qui pose un problème.
Un fichier est classiquement reconnu par son nom. ce nom est une propriété du fichier au même titre que sa taille par exemple. L’extension de fichier n’est qu’un indicateur, peu fiable, de son type. L’extension de fichier est repris comme suffixe du nom.
Il peut y avoir plusieurs fichiers qui portent le même nom (et même suffixe) et qui ont ou non le même contenu. Ils doivent dans ce cas être disposés dans des emplacements différents. Cet emplacement peut être repris comme préfixe. L’emplacement est la traduction textuelle de l’arborescence de répertoires dans lequel se trouve un fichier. Et l’emplacement peut être soit relatif (à un autre emplacement), soit absolu. Dans tous les cas, il fait implicitement ou explicitement référence au disque, la distinction entre les deux dépendant de la notation faite par les différents systèmes d’exploitations. Nous ne prendrons ici que l’emplacement absolu, seul à pouvoir discriminer de façon certaine deux fichiers au même nom.
On peut aussi avoir deux fichiers de même nom/suffixe dans le même répertoire, mais sur deux machines différentes. Dans les différentes notations, il est donc préférable de se restreindre à l’utilisation de notations impliquant le nom de machine. Sinon on risque de pouvoir restaurer correctement un fichier en cas de besoin (si c’est le but).

Le problème de la notation des noms de fichiers peut se poser aussi dans le cas de deux fichiers identiques au même emplacement sur deux machines différentes. Si un des fichiers est modifié, cela va entraîner la création d’un lien u pour l’objet correspondant. Si rien ne distingue les deux fichiers, cela implique que l’autre fichier non modifié sera marqué comme lui aussi modifié…

Références :
Nebule blog – Empreinte d’objets et URI
Nebule blog – Fiches perforées
Nebule blog – Fichiers et chemins
Nebule blog – Système de fichiers
Nebule wiki – Réflexion – analyse des applications – Système de fichiers

Chiffrement et type mime

Suite de la réflexion sur l’Introduction à la cryptographie.

Il n’existe pas de type mime généralistes pour des fichiers chiffrés. Comme les objets chiffrés ne sont liés à aucune application en particulier, je gratte un peu ce qui se rapproche le plus de mon besoin.

Il se trouve qu’il existe le type mime application/octet-stream un peu fourre tout pour les contenus… binaires. Mais il est standardisé en l’état.
Il faut aussi un moyen de préciser l’algorithme de chiffrement derrière. Une application aura besoin de connaître cet algorithme pour déchiffrer le flux d’octets.
Bref, en suivant la rfc2046, il reste la possibilité de créer quelque chose en application/x-

Voici donc comment seront définis les objets chiffrés dans nebule :
application/x-encrypted/aes-256-ctr
application/x-encrypted/aes-256-cbc
application/x-encrypted/rsa
Etc…

En fonction de l’algorithme invoqué, on sait si c’est du chiffrement symétrique ou asymétrique, et donc en principe si c’est pour une clé de session ou pas.

Gestion de programmes – création

Suite à la précédente réflexion sur la gestion des programmes, l’entité correspondante a été créée.

Cette entité s’appelle bachue, dérivé de Bachué. Son empreinte :

19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
http://bachue.nebule.org

bachue

Tuer l’ordinateur pour le sauver – 2

Il est encore aujourd’hui difficile de dire quel est le principal problème dans l’architecture de nos systèmes d’information. Il est d’ailleurs fort probable que ce soit un cumul de plusieurs causes qui rendre l’ensemble du SI si difficile à sécuriser. La conséquence, c’est que nous avons bien du mal à endiguer des attaques toujours plus complexes et nombreuses malgré les moyens considérables que nous déployons. Ces moyens sont de plusieurs ordres : financiers, organisationnels, humains et technologiques.

Est-ce la façon qu’on nos machines de communiquer sur l’internet qui est à revoir ?
A cette question, il est très tentant de répondre oui. Il faut filtrer, segmenter. Si l’on bloque l’internet mondial en le fermant au niveau des frontières, on résoudra une grande partie des problèmes. Mais on ne résoudra pas vraiment les vraies causes de nos problèmes. Cela ne fera que réduire la portée des conséquences. Et, en faisant cet enclavement, je pense que l’on ne fait que repousser à plus tard la résolution de ces problèmes.
Il faut peut-être plus simplement revoir comment nos machines communiquent et modifier la pile réseau. Mais cela ne tient pas compte des autres moyens de communication comme les périphériques de stockage amovibles.

Est-ce l’architecture de nos machines qui est vulnérable ?
Les attaques sur le SI ont de multiples formes parce qu’elles ont autant de buts différents. Le réseau est rarement la cible d’une attaque, alors qu’un serveur est une cible de choix. Et le serveur est une cible exposée si il veut remplir son rôle : servir. Les attaques sur les serveurs sont toujours passées par les interfaces, les entrées/sorties. Mes ces attaques n’ont de raison d’être que parce que le serveur est un objet actif, interactif. Et cette activité siège avant tout dans le processeur.
Le processeur permet l’exécution du code des programmes et notamment le système d’exploitation. Tous les systèmes d’exploitations actuels ont un (ou plusieurs) compte ou pseudo compte super-administrateur, qu’il s’appelle root ou SYSTEM. Or, le processeur ne sait pas reconnaître un compte. Il se contente d’exécuter le système d’exploitation qui, lui, contient toute la logique d’exploitation des comptes et de séparation des privilèges. Qu’est ce qui garantie aujourd’hui l’intégrité de cette logique ? Pas grand chose. Les élévations de privilèges sont courantes suite à des attaques.
D’un autre côté, le système d’exploitation repose sur un ordonnanceur. Celui-ci permet de répartir le temps de calcul du processeur entre les différents programmes, et donc de faire du multitâches entre les applications. Mais le processeur lui-même est fondamentalement monotâche. Le processeur dispose aussi d’un mécanisme, le RING, mais les systèmes d’exploitation ne l’exploitent qu’à moitié. La séparation entre les différents programmes est de fait artificielle parce que logiciel, et donc faible.
On en arrive à une aberration conceptuelle. Le super-utilisateur a plus de pouvoir sur le système que l’utilisateur qui manipule ses données, ce qui est normal. Mais ce qui l’est moins, c’est qu’il a aussi plus de pouvoir sur les données de l’utilisateur que ce dernier. En l’état de la technologie actuelle, le problème de confidentialité est insoluble sauf à considérer que l’utilisateur est le super-utilisateur. Et c’est sans compter les élévations de privilèges.
Et dire qu’un utilisateur est super-utilisateur de son système est aujourd’hui reconnu comme une aberration. La boucle est bouclée.

Le projet nebule est un premier pas vers une solution. Il est encore trop tôt pour savoir si c’est le début de la bonne solution. On permet à l’utilisateur de se réapproprier ses données. Malheureusement, l’architecture actuelle des machines ne permet pas de protéger efficacement l’identité d’une entité une fois déverrouillée, c’est à dire une fois la clé privée chargée en mémoire. Le super-utilisateur peut directement lire cette clé en mémoire. Aucune protection de prévaut dans ce cas, quelque soit sa complexité. Certes, il faut corrompre ce super-utilisateur… mais c’est justement ce qui est fait lors de la plupart des attaques informatiques actuelles.

CF : Tuer l’ordinateur pour le sauver

Gestion de programmes – suite

La précédente réflexion sur la gestion de programmes peut être complétée.

Les programmes doivent être validés par des entités. Il faut des entités dédiées à cette tâche. La validation et les mises à jours se font par les liens de ces entités.

Une des propriété qui va rapidement ressortir, c’est qu’une entité peut, sans grand risque de refus, demander à toutes les entités qu’elle connaît les objets et liens signés par une entité de gestion de programmes. En fait, il y a de grandes chances que toutes les entités partagent la même source de programmes. Cela rend la diffusion de mises à jours particulièrement rapides. On a un peu un effet virus sur la diffusion des objets.
Évidemment, comme cela se passe aujourd’hui, nous risquons d’avoir une hégémonie de certains programmes. C’est pour cela qu’il faut aussi être capable d’accepter simultanément plusieurs entités de gestion de programmes… et de strictement respecter la diffusion des liens et objets tel que définit par le projet nebule.

L’entité cerberus n’a pas vocation à diffuser des programmes, mais elle peut être amenée à interdire l’utilisation de certains programmes si ceux-ci sont reconnus malveillants. Cela ne bloque pas les mises à jours du-dit programmes mais oblige à le mettre à jour.

Il me faut donc maintenant créer la première entité de gestion des programmes, et il faut commencer par lui trouver un nom.

Objets privés et fonctionnement interne

Il existe des informations que l’on ne peut gérer par les liens nebule sous peine de fortement complexifier son fonctionnement, et donc la compréhension que l’on en a dans son ensemble.

Par exemple, c’est le cas pour mettre un poids à un objet. C’est à dire lui attribuer une méta information qui décrit son importance relative aux autres objets. C’est une notation en quelque sorte.
Un poids peut être fixé arbitrairement. Ce n’est pas le meilleur cas même si c’est réalisable en pratique. Le poids d’un objet a surtout de forte chance de refléter l’importance que l’on donne à cet objet. A cet objet pondéré sont liés d’autres objets. Ces autres objets, si leurs poids ne sont peut-être pas explicitement définis, vont hériter d’une moyenne des poids des objets autour. Ainsi, un objet va gagner de l’importance si il est lié à un objet jugé (donc pondéré) très important.
De ce poids peut en découler des conséquences concrètes. Par exemple si l’on permet l’oublie et l’effacement d’objets anciens de façon calculé et contrôlé, la pondération permet de conserver très longtemps un objet important.

Cette pondération des objets qu’une entité va réaliser est un travail ‘personnel’. Le fruit de ce travail peut avoir un intérêt public. Et une autre entité ayant fait le même travail ne donnera pas les mêmes pondérations.
Cependant, une partie de ce travail de pondération peut être jugé privé. Si le partage d’une pondération d’objets peut être réalisée simplement par des liens, comment protéger les pondérations privées ?

Une des possibilités est d’exploiter les objets stockants des liens.

Hash et type des objets – suite

Suite à la décision de modifier deux objets de base niveau, hash function et mime-type, les premières répercussions ont été faites sur puppetmaster, cerberus et kronos.

De fait, les premiers liens de type x ont été générés. C’est à dire que ce sont les premiers liens qui permettent la suppression d’autres liens précédemment créés.

Cela se voit sur le graph de l’objet entité de puppetmaster :

C’est un peu fouillis parce que le précédent lien supprimé est remplacé par un nouveau lien dont l’objet meta est différent. Il faudra améliorer le tracé de ces liens…

Chiffrement et vecteur initial

Dans l’Introduction à la cryptographie, le vecteur initial (IV) était définie comme était égale à la clé de session. Bien sûr, de fait, le vecteur initial n’était plus publiable comme on le fait habituellement.

Après consultation du fonctionnement du mode CTR (CounTeR), je me rends compte qu’il n’est peut-être pas opportun d’avoir l’IV identique à la clé de chiffrement. La première étape du chiffrement consiste en un ou exclusif (XOR) entre l’IV et la clé de chiffrement. Cela donne une clé pour ce tour égale à 0.
CF Wikipedia.org – Mode_d’opération (cryptographie).

Donc, un IV est ajouté. Il est lié à l’objet chiffré pour pouvoir déchiffrer celui-ci. Par défaut, sa valeur est aléatoire. Du fait du fonctionnement du mode CTR, l’IV s’incrémente à chaque bloc chiffré.

Si pas précisé, il est égale à 0.

Chiffrement et compression

Il est préférable d’associer de la compression avec le chiffrement.

La compression des données déjà chiffrées est impossible, non que l’on ne puisse le faire, mais le gain de compression sera nul. L’entropie détermine la limite théorique maximum vers laquelle un algorithme de compression sans pertes peut espérer compresser des données. Quelque soit l’entropie des données d’origine, une fois chiffrées leur entropie est maximal. Si un algorithme de compression arrive à compresser des données chiffrées, il faut sérieusement remettre en question la fiabilité de l’algorithme de chiffrement. CF Wikipedia – Entropie de Shannon.

A cause de l’entropie après chiffrement, si on veut compresser les données il est donc nécessaire de le faire avant le chiffrement.

Ensuite, il faut choisir l’algorithme de compression. On pourrait forcer par défaut cet algorithme, pour tout le monde. C’est notamment ce qui se passe pour le HTML5 avec le WebM ou le H.264… et c’est précisément ce qui pose problème. En dehors des problèmes de droits d’utilisation à s’acquitter, c’est une facilité pour l’implémentation de cette compression par défaut dans les programmes. Cela évite de devoir négocier préalablement l’algorithme de compression. Mais si il est difficile de présenter des vidéos en plusieurs formats à pré-négocier, ce n’est pas le cas de la plupart des données. On perd la capacité d’évolution que l’on a en acceptant de nouveaux algorithmes de compression. Et plus encore, on perd la capacité du choix de l’algorithme le plus adapté aux données à compresser.
Il faut donc permettre l’utilisation de différents algorithmes de compression.

Cependant, si l’objet à chiffrer est déjà compressé en interne, comme le PNG ou OGG par exemple, la compression avant chiffrement est inutile. Ce serait une sur compression qui bien souvent n’apporte rien. Le chiffrement n’implique donc pas automatiquement une compression.

Lors du chiffrement, l’objet résultant chiffré est lié à l’objet source non chiffré par un lien k. Il est aussi marqué comme étant un objet de type-mime correspondant à l’algorithme de chiffrement, via un lien l. CF Introduction à la cryptographie.
Pour marquer la compression avant chiffrement, un autre lien l est ajouté comme type-mime vers l’algorithme de compression utilisé. Ce lien n’est ajouté que dans le cas d’une compression réalisée en même temps que le chiffrement.

La seule contrainte, c’est l’obligation d’utiliser un algorithme de compression sans perte. L’objet, une fois décompressé doit être vérifiable par sa signature. Il doit donc être strictement identique, aucune modification ou perte n’est tolérée.

Le maître des poupées et le gardien de l’enfer

1/Le maître des poupées

Le maître des poupées, alias puppetmaster, vient de révoquer son ancienne incarnation :

63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

Contrairement à ce qui avait été annoncé, c’est un lien de type d qui à été utilisé, et non un lien de type u. Ceci pour un problème de sécurité. Ainsi son ancienne incarnation ne peut pas révoquer ce type de lien… et ressusciter.
Le détail ici : puppetmaster.nebule.org/l/63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

D’autres anciennes incarnations ont elles aussi été révoquées, à la fois pour la clé publique et la clé privée :
70668497b6a0ad481aa7e0c08131bc0d0be40cd7dde30a7de8613290d7c35543 puppetmaster (priv)
9e85d7d25af97760f8611b85c2765912606c7eec8307dc58c7782e34cc373c18 cerberus (pub)
905296b7070b8e7d601d9509893683d072bb22083006a9e545ceaf0228787c8c cerberus (priv)
d756efe28847a3723639aed49a40f08c22a576ff3f002750a18ad6a192717621 kronos (pub)
5f951d41db3b18001fbc8baf895d84cb4d460a6143b273b4f5b2d0e9b0d5c67b kronos (priv)

Dans le même temps, puppetmaster a reconnu plusieurs nouvelles entités :
01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 cerberus cerberus.nebule.org
abdbaa31e404463ecc644f1eecdeb9b5f94428eb140fa5c66a7687ee96ed47aa kronos kronos.nebule.org
975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5 stéphane stephane.nebule.fr
Voir le détail ici : puppetmaster.nebule.org/l/88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

2/Le gardien de l’enfer

Le gardien de l’enfer, alias cerberus, vient d’être régénéré en tant que :

01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
cerberus.nebule.org

Il est reconnu par puppetmaster. cf Cerberus et la mise en quarantaine d’objets.

Pour son rôle spécifique, il dispose de deux objets spécifiques :
nebule/danger
nebule/warning

Actuellement, les enfers n’ayant pas encore officiellement ouverts, cette entité est au chômage.
Seul le temps nous dira pour combien de temps…