On vit en pleine “révolution” du cloud.

Plus simple, moins cher (dans la mesure où louer est moins cher que posséder, mais c’est un autre débat), permettant aux DSI de se dégager de nombreuses responsabilités juridiques, le Cloud a le vent en poupe.

Coté grand public, on surfe surtout sur la simplicité de partager [du rien] des “contenus”, à la Facebook.

DSIs, qu’adviendra-t-il de vos précieuses données quand la crise changera de forme ?

* Si la bande passante devient [beaucoup] plus chère, par exemple parce que les coûts de l’énergie explosent ?

* Si le pays qui héberge la société qui héberge vos données prend des mesures de restriction d’information à l’égard de votre pays ? (Rigolez pas, les iraniens sont privés de beaucoup de services internet en ce moment par exemple)

* Si la société qui héberge vos données est une start-up, elle dépend beaucoup de la résilience du système financier…

Plus j’y réfléchis, plus les Clouds, dans le principe et dans les implémentations, m’apparaissent comme des constructions complexes et fragiles. À l’opposé, il me semble que les évènements économiques, géopolitiques  que nous vivons semblent présager d’instabilité et vont nous demander de faire preuve de résilience.

La diminution de risques qu’ils induisent me semble être formelle, juridique, mais pas [du tout] pratique.

On verra bien, mais pour ma part je m’abstiens soigneusement de stocker en ligne quoique ce soit de précieux, confidentiel, sans de sérieuses précautions.

Conservez vos backups et plans de secours comme la prunelle de vos yeux ^^

Une idée simple : nombre de serveurs sont en ligne pour des utilisations autres que de la messagerie SMTP.
Ces serveurs sont appelés à envoyer quelques emails par jour au maximum, par exemple pour des tâches planifiées comme logcheck, ou de la supervision basique.
Chaque serveur consiste cependant en une réserve de ressources pour les spammeurs, qui adorent exploiter, entre autres, les vulnérabilités web, pour installer leur backdoor et relayer leur spam.
Dès lors, une contre mesure préventive très simple : sans attendre d’être la cible d’une attaque, chaque administrateur peut très simplement limiter à une poignée le nombre d’emails qui peuvent sortir chaque jour.
Sous Linux, cela ressemblerait à quelque chose comme :
iptables -t filter -A OUTPUT -p tcp –dport 25 -m limit –limit 12/d –syn -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 25 –syn -j REJECT

Il existe un système de miroirs dynamiques sur Internet permettant de visiter un site trop chargé. Il suffit d’ajouter au site visité le suffixe “nyud.net”.
Au hasard, en ces temps d’anxieté nucléaire, le site de la CRIIRAD est accessible ici : http://www.criirad.org.nyud.net/

En ce qui concerne les émanations radioactives, la CRIIRAD nous indique que les gouvernements réalisent un black-out sur les données de mesure déjà réalisées sur le sol américain, canadien, etc. et exige que ces données collectées avec de l’argent public soient fournies au public.

C’est ici : http://www.criirad.org.nyud.net/actualites/dossier2011/japon/11_03_23_Volet1der.pdf

Penchons nous sur un test, avec un oeil orienté “sécurité”, du célèbre CMS spip.
Je teste donc la version 2.1.8. Lors de l’installation, spip m’indique que quelques répertoires doivent offrir au processus “apache” les droits en écriture. Ce n’est pas délirant, dans la mesure où la publication se fait en ligne : je vais y injecter des images, etc.
J’applique donc la règle du “privilège le plus faible” traditionnelle des systèmes de fichiers unix : j’assigne à ces repertoires le groupe apache, et en accordant à ce groupe les droits en écriture :
chgrp www-data IMG/ tmp/ local/ config/
chmod g+w IMG/ tmp/ local/ config/
L’installation terminée, je crée une rubrique, un article, et j’y colle une photo pour voir le résultat.
Le résultat, le voici : une image est bien ajoutée dans le répertoire IMG/ avec les droits en 666.
De nombreux fichiers de spip sont automatiquement passés en droits 666 ou 777, dans les installations par défaut. Y compris des fichiers PHP executés par le serveur web.
Franchement, ça fait peur.
J’ai trouvé une solution simple : remettre un chmod global à une valeur plus saine de manière globale pour spip.
Éditez votre fichier ecrire/mes_options.php, et posez-y le code suivant :
define(‘_SPIP_CHMOD’, 0770);
ou mieux
define(‘_SPIP_CHMOD’, 0570);
Le serveur web aura ainsi les droits de lire les fichiers, et son groupe les droits de lire et modifier ces fichiers.

Je reste tout de même estomaqué de voir un logiciel aussi populaire faire la bêtise monumentale du “chmod 777″, qui est comme chacun le sait réputée pour être la bêtise traditionnelle du newbie.
Pour référence, en sécurité, on ne doit JAMAIS positionner les droits 666 ou 777 sur un fichier, c’est une hérésie, et on a TOUJOURS une meilleure solution. La littérature à ce sujet ne manque pas : commencer par cet article sur la Séparation des privilèges

Et voici la nouvelle crise majeure de sécurité de l’information.
Le FBI est accusé d’avoir fait implanter une ou plusieurs backdoors dans la pile de chiffrement IPSEC d’OpenBSD.
10 années après les faits supposés, le responsable de cette opération se déclare délié de l’accord de confidentialité qu’il avait signé et en fait part à Theo de Raadt.

Plusieurs points intéressants :
* Ces allégations sont invérifiables. Du code de ce type est éminemment complexe à écrire et à auditer (cf la faille Debian SSH, énorme et restée béante pendant plusieurs mois). Une équipe s’est mise à auditer le code en question, mais qu’en conclure si ils trouvent des problèmes ? Cela pourrait aussi bien être un bug. Ils peuvent aussi bien ne pas en trouver, cela ne prouvera pas l’absence de faille.

* Ces allégations sont parfaitement crédibles. La pile IPSEC d’OpenBSD était la première implémentation ouverte (à code source ouvert et réutilisable), et a donc été reprise par de nombreux systèmes. Cela en faisait a priori une cible de choix.

* Surtout : une fois le code complétement audité : qui pourra certifier que cette stack IPSEC est enfin sûre ? OpenBSD est déjà réputé pour être l’un des systèmes les plus audités du monde ; une scrutation de plus est-elle de nature à changer quoi que ce soit à la confiance que l’on peut apporter à la sécurité de ce système ? De ce point de vue, cette crise est un non-événement, car elle ne change rien à cet état de fait.

Open source ou pas, la question de la confiance dans les systèmes de chiffrements – et dans la sécurité des systèmes en général – est de nouveau posée. Ce ne sont certes pas les audits réalisés dans les cadres légaux (comme les critères communs) qui y répondront!

Salutations enfin au courage de Theo de Raadt, qui sait parfaitement que faire pour assurer la confiance à moyen et à long terme. À défaut de certitudes sur la sécurité de l’OS, voici de quoi étayer une conviction sur les intentions de ceux qui gèrent ce projet.

Je vois une sortie de crise, qui à défaut d’être complète, serait intéressante : que Monsieur Gregory Perry publie toutes informations en sa possession sur ces fameuses failles intentionnelles. Personne ne pourra dès lors le traitera de menteur ; on pourra au plus douter qu’il ait tout divulgué…

L’insécurité a son marché, et ses phénomènes d’adoption, analysables de manière très proche à celle dont on considère l’adoption d’une technologie de produits par le marché.
.
(Source : arstechnica )
Le marché de l’insécurité s’étant structuré, les exploits se vendent, s’industrialisent et se propagent très rapidement. On est vraiment très loin des auteurs de virus “sympa” des années 90.
Cette fois-ci, Java est en cause. Tout simplement parce qu’il est devenu universel, installé partout, et en particulier des systèmes Desktop aux terminaux mobiles en tous genres y compris les téléphones dits intelligents, en passant par les serveurs web. Et parce qu’il est, semble-t-il, vraiment facile à attaquer. Et ce qui tourne dans une machine virtuelle Java est bien loin de la couche d’analyse des antivirus.
Java dispose de toutes les qualités requises : la puissance d’un language complet, la difficulté pour les administrateurs de comprendre les tenants et aboutissants en terme de sécurité, un panel d’applications écrites par tout un chacun sans la moindre notion de ce qu’est la sécurité. Et j’oubliais, Java et ses failles sont portables.
Considérons Java du point de l’utilisateur moyen, et regardons les processus à suivre en cas de découverte d’une faille critique dans les versions installées. L’utilisateur doit mettre à jour :
- son ordinateur de bureau
- son téléphone portable
- sa voiture / son gps
- sa webcam, son alarme de maison, …
- bientôt, son frigo
- et j’en oublie
Il peut également tenter de s’assurer que les services en ligne critiques qu’il utilise sont à jour.
Et je ne parle pas du niveau moyen et de la sensibilité à la sécurité du développeur web moyen sur technologie Java.
Quand Java aura été corrigé (est-ce vraiment faisable? je ne suis pas bien placé pour le savoir), ou en tous cas quand le marché se sera doté d’outils pour protéger un peu mieux ses applications Java, nul doute que ce marché de l’insécurité passera à une nouvelle technologie. Pourquoi pas pdf? Notoirement, pdf est un language très puissant, et encore très facile à attaquer. Son tour viendra sur le marché de l’insécurité de masse.
[Edit] : Adobe en est bien conscient, qui annonce le sandboxing de son reader pdf

Tu as été le meilleur des chats… Tous ceux que tu as approchés ont ressenti cette aura de bienveillance et de bien-être que tu dégageais.
Ce 29 juillet au matin, un chauffard a mis fin aux bonheurs quotidiens que tu nous apportais, alors que tu n’avais pas 2 ans.
Tes 9 vies n’ont pas suffi… Je sais que tu resteras irremplaçable et je te souhaite de reposer en paix. Je n’oublierai jamais ma petite usine à ronronner ; ton départ abrupt me laisse un grand vide.
Mon esprit sait bien qu’on ne te verra plus entrer dans la maison et te frotter aux chaises, et pourtant toujours je regarde le soupirail que tu aimais ouvrir, et qui reste fermé.

Comme c’est ironique… Les footeux qui depuis des années adorent brailler, klaxonner à pas d’heure “ON A GAGNÉ” sans la moindre considération pour les gens qui ne s’intéressent pas à ce “sport”, ou simplement essaient de dormir la nuit, sont à présent incommodés par le bruit du stade. C’est quand même dingue, on ne s’entend plus brailler devant sa télé!

Vuvuzelas, pourvu que ça dure

Je dirais même :
Brrrrruuuuuuuuuuuuuuuuuu!

Le formalisme que nous trouvons dans nos contrats, que la Justice et que les administrations nous imposent m’a toujours fasciné, et, je l’avoue, sa simple existence me dépasse encore.

Je me souviens des jeux de billes dans la cour de récréation, en primaire. Celui qui avait une bille à mettre en jeu la posait au sol, traçait une ligne à la craie. Celui qui voulait gagner la bille se plaçait donc derrière la ligne. Et à ce moment, avant que le lanceur ne passe à l’action, le premier récitait, aussi vite que possible, une phrase, qui était toujours la même. Je ne me souviens malheureusement plus de la formulation exacte, mais cette phrase ressemblait à “Derrière la ligne, pas en biais, sans clin d’oeil, sans rebond” et contenait d’autres mentions “légales”. À l’époque déjà, je trouvais que ce système était “trop”, que nous connaissions les règles, et que les réciter à toute vitesse n’apportait rien à nos échanges.

Le formalisme nous entoure, en particulier dans le “monde numérique”. Notamment, pas un “service en ligne” sans des clauses que, si nous prenions le temps de lire et de comprendre, nous refuserions horrifiés. Je me lance avec quelques exemples : ici, ici ou encore ici (citations non ciblées, je suis sûr qu’on trouve facilement pire). Par chance, nous (les Utilisateurs) sommes trop paresseux pour ce faire. Je dérive du sujet, et m’arrêterai donc ici, mais la CNIL a du pain sur la planche pour sensibiliser le public à la maîtrise de ses données personnelles.

Mais pour conclure à charge des amateurs de formalisme, à quoi ressemblerait notre vie si nous devions intégrer ces clauses légales partout? Acheter du pain chez le boulanger, conduire les enfants du voisin, promener son chien… sont autant de prises de risques insupportables, n’est-ce pas ?