Ergonomie, Rails et Architecture de l'information web (2.0)

Dans les années 90, toute bonne attaque d’ingénierie sociale ne pouvait se passer d’une bonne séance de trashing. Cette visite méticuleuse – et même pas illégale – des poubelles de la future victime offrait une moisson gratuite et considérable de renseignements utiles voire confidentiels. Vous n’imaginez pas tout ce qu’on peut trouver dans une corbeille à papiers entre un trognon de pommes et un vieux chewing gum, au mépris de toutes les règles de sécurité des entreprises.

Mac OS X permet un peu le même genre de pratiques, comme j’ai pu m’en rendre compte ce matin.

Branchez une clé USB ou un disque dur externe sur un mac, effacez-en quelques fichiers, démontez, puis branchez-le sur une autre machine, un mac de préférence, et ouvrez la corbeille. Oh, miracle, tous les fichiers effacés sur la machine précédente sont là, prêts à être restaurés. OS X crée en fait une corbeille par système de fichier, et non par machine. Cela engendre deux problèmes :

• Effacer le contenu d’un système de fichiers mobile ne permet pas d’en récupérer l’espace sans un vidage préalable de la corbeille globale du système (pratique).
• Des documents sensibles ou confidentiels peuvent se promener dehors à l’insu du plein gré de leur propriétaire.

Je ne sais pas si c’est le cas sous d’autres plates-formes, mais l’exploitation de ce genre de choses peut être assez amusante. La solution : transférez vos données sur des supports cryptés, ne faites pas confiance aux ordinateurs pour garantir la confidentialité de vos documents, et d’une manière générale, ne faites confiance à personne agent Scully.

À l’époque lointaine où je finançais mes études en enseignant la sécurité informatique, je débutais chaque formation en en rappelant les enjeux trop souvent ignorés ou oubliés des stagiaires le plus souvent envoyés à leur corps défendant par leur DSI soucieuse de dépenser son budget formations jusqu’au dernier sou de peur de ne pas le voir renouvelé l’année suivante : confidentialité, intégrité et disponibilité des données.

Disponibilité des données

Il s’agit souvent de l’enjeu à coté duquel on passe le plus malgré sa criticité, tant il semble évident. Dans un monde dans lequel l’information est décentralisée et dématérialisée, la disponibilité de cette dernière représente une contrainte globale souvent dépendant d’un grand nombre de facteurs incontrôlables : état des connexions menant à l’information, bon fonctionnement matériel, logiciel et des infrastructures… On y pense jamais, mais c’est fou comme un tremblement de terre, un arbre qui tombe au mauvais endroit ou un bête coup de cisailles sur un cable peuvent mettre en péril tous nos systèmes d’information.

Intégrité des données

Là encore, un enjeu stratégique par bien des aspects : intégrité à la réception, mais aussi exactitude des données envoyées. Histoire de s’en rendre compte, il suffit de se poser trois petites questions :

1. Que se passe-t-il quand le destinataire reçoit des fichiers corrompus durant le transport ?
2. Que se passe-t-il quand une personne mal intentionnée supprime tout ou partie des données ?
3. Que se passe-t-il quand une personne mal intentionnée modifie les données de manière imperceptible à la source ?

Il existe évidemment des réponses simples à ces trois questions qui feront certainement l’objet d’un billet à venir. Ce qui l’est moins est généralement de faire prendre conscience de l’importance de ces enjeux à vos interlocuteurs.

Confidentialité des données

Sans doutes le plus vaste et le moins bien cerné des trois domaines, parce qu’il implique tout et son contraire, probablement parce que la notion de confidentialité est relative.

Dans le temps, d’abord. Ainsi, quand nous abordions la cryptographie, on me demandait quasi systématiquement quel était “le meilleur cryptage” disponible. Je répondais toujours la même chose : il n’existe pas de solution de cryptographie parfaite, mais juste de bonnes solutions. Une bonne solution est un système qui résiste jusqu’à ce que les données à protéger cessent d’être confidentielles.

En fonction des données ensuite : s’il est bon de laisser filtrer le moins d’informations possibles, il faut peser soigneusement la manière dont on les protège, en fonction de leur valeur, afin de ne pas donner trop d’informations sur la valeur des données contenues dans les systèmes d’informations. On n’entoure pas une maison vide d’un système de surveillance ultra moderne avec mirador, protections électroniques et chiens tueurs. Si la maison contient des toiles de maître, on prendra en revanche soin de les placer dans un endroit inaccessible, par exemple un coffre. Il en va de même avec les systèmes d’informations.

Deux exemples parfait de ce qu’il ne faut pas faire

Un vieux…

Dans les années 90, France Télécom Câble gérait ses classes d’adresses IP de manière un peu curieuse, et pour ainsi dire quelque peu anarchique. Les adresses étaient attribuées aux utilisateurs par DHCP sans vérifier le nombre d’adresses utilisées par un abonné, ni comment ces adresses étaient attribuées.

Cela entraînait des choses plutôt drôles (ou pas) :

• Pénurie d’adresses dans toute la France dès 17 heures.
• Possibilité de piquer des adresses IP déjà attribuées, avec les conflits que l’on imagine.

Mais le plus drôle, je crois, était la possibilité de voir tous ses voisins de hub à l’aide d’un simple sniffer. Bonjour la confidentialité des données, et encore ne parlait-on pas encore à l’époque d’attaque “Monkey In The Middle”.

… et un beaucoup plus récent

Le message suivant est passé avant-hier sur les groupes de discussion consacrés à la Dedibox dont j’ai déjà parlé ici.

Salut,

Peut etre deja debattu, mais rien vu a ce sujet, est-il prevu de mettre en oeuvre la gestion des tables arp en static sur les differents equipements de l’archi ?? En effet je suis tres sceptique sur la confidentialité des infos transmises entre un Dedi et un utilisateur.

Un simple test de MITM en ARP poisoning via ettercap par exemple permet de voir que la totalité du traffic des dedibox de votre subnet.

http, https, ftp, imap, pop, etc… et ssh < 2.00 inclus ;)

Des idées coté serveur pour contrer les curieux ?

Antoine.

Ce monsieur veut dire qu’il est possible, à une personne malintentionnée d’usurper l’identité d’un des équipements du réseau et ainsi de capter le trafic de ses voisins. L’opération ne nécessite pas vraiment de connaissances techniques en dehors de quelques commandes UNIX de base, d’un outil bien pratique généreusement indiqué dans le corps du message, et d’un cerveau pour en lire le manuel. Je n’avais pas fait le test, mais dans un sens, cela ne m’étonne pas vraiment.

La possibilité d’une telle attaque implique l’échec des trois enjeux évoqués plus haut :

• Les risques de rupture de la confidentialité de données sensibles sont très largement augmentés, qu’il s’agisse du contenu de courriers électroniques sensibles mais non chiffrés, ou de mots de passe de comptes utilisateurs utilisant les mêmes couples identifiants pour les protocoles en clair et chiffrés.
• Un risque de rupture de l’intégrité des données interceptées avant qu’elles ne parviennent à leur destinataire légitime.
• Un risque d’interruption de service pur et simple pour l’ensemble des machines se trouvant sur ce sous réseau.

Et j’en oublie certainement.

Conclusion

Une certaine prudence voudrait qu’on ne diffuse pas ce genre d’information sur le web avant que le problème n’ait été corrigé par les administrateurs de la plate-forme, surtout en y mettant un lien vers les outils permettant d’exploiter la faille.

On peut cependant se poser la question de la responsabilité dans cette histoire :

• Peut-on exiger d’un hébergeur ultra low cost comme Dedibox une sécurité optimale, ou même convenable de ses infrastructures ? Certainement, cependant le coût du matériel nécessaire à un tel renforcement risque fort d’impacterles tarifs de l’offre.
• D’un autre côté, l’administration d’un serveur est un travail de professionnel, et n’importe qui ne devrait pas s’y risquer sans de bonnes connaissances en administration système et une notion globale des enjeux qu’implique une présence constante sur Internet. À moins de vouloir devenir la prochaine usine à spam, évidemment.

Parce qu’un peu d’auto promotion ne fait pas de mal, un billet qui ne traitera ni de près ni de loin des standards, de l’ergonomie et du web 2.0.

J’ai commencé il y a quelques temps un projet de photos de l’ensemble des églises de la capitale. Il s’agit évidemment d’un projet de très longue haleine, entre le nombre incroyablement élevé d’édifices religieux que compte la plus belle ville du monde (ceci dit en toute objectivité), et le peu de temps que mon travail, mes projets et ma famille me laissent pour le réaliser, mais j’avance.

Après plusieurs mois sans pouvoir sortir, j’ai fait d’une pierre deux coups hier avec l’église Saint Médard, construite entre le XVème et le XVIIIème siècle, et l’église romane de Saint Julien le Pauvre qui est la plus ancienne de Paris. Dédiée au culte grec melchitec, cette dernière est particulièrement remarquable pour sa superbe iconostase. Le visiteur curieux pourra ensuite traverser la rue et se rendre à Saint Séverin, ma favorite dont je vous propose par ailleurs deux clichés pris hier soir.

Le choeur de Saint Séverin

Saint Séverin, l’allée latérale droite vers le fond

Veuillez nous excuser pour cette interruption de service. Ce blog va maintenant reprendre le cours normal de ses activités.

Histoire de fêter l’avancement de mon projet et un week-end bien mérité, je partage ce gag trouvé dans le courrier des lecteurs du très sérieux magazine Famille Chrétienne :

Le site www.catholiens.fr que nous avons cité dans notre numéro de la semaine dernière, p. 74 est en réalité une parodie (renvoyant notamment à des sites pornos) du vrai site chrétien (d’origine belge) www.catholiens.org.
Avec nos vives excuses aux internautes qui auraient été piégés.

Je ne devrais pas trouver ça drôle – en fait je trouve ça aussi honteux que stupide en pensant aux enfants qui pourraient tomber dessus – et pourtant Dieu sait que ça m’a fait rire.

J’ai un peu l’impression de réécrire le même billet tous les six mois, sorte de piqûre de rappel en forme de placebo inutile, mais je ne peux m’empêcher de pousser mon coup de gueule bisannuel, bien que je sache pertinemment que je ne fais que crier dans le désert.

J’apprécie déjà moyennement qu’on lie mes photos depuis cette machine sans en donner les crédits ; je laisse faire, un peu par flemme : je pourrais très bien mettre en place une rewrite rule qui renvoyant le contrevenant vers une source comique, amusante, voire cocasse.

Je viens de quitter Thunderbird, premier mailer graphique que je trouvasse à mon goût depuis ma découverte de Mutt il y a sept ans de cela, pour Mail.app. La raison en est simple : il est impossible de forcer iCalendar à utiliser Thunderbird pour envoyer mes invitations aussi bien personnelles que professionnelles. Ma fréquence d’utilisation d’iCalendar atteignant quasiment celle de Thunderbird, de Flock, de Textmate ou de Terminal.app, impossible de me passer de cette fonction si utile.

Je dédicace ce billet à tous ceux qui sont obligés d’attendre la prochaine série pour pouvoir la tester. Ici ça va très bien.

Le 24 avril dernier, je commandais sur le site d’Actualis – à ne pas confondre avec Actualys, mon nouvel employeur – une carte contrôleur SATA2 Promise TX2+, qui présente le gros avantage d’un support natif sous Linux.

Une fois n’est pas coutume, on va se détendre un peu pour l’arrivée du beau temps, du week-end et du BarCamp demain avec cette vidéo “plus geek tu meurs”. Effrayant.

J’ai abandonné depuis un moment les solutions bureautiques traditionnelles pour rédiger ma documentation au profit du tout XHTML + CSS bien plus simples selon moi à maintenir et convertir.

Pourquoi donc ? Pour deux raisons principales.