Les posts auxquels vous avez échappé

Bloguer demande une rigueur d'écriture et certains billets ne sont donc pas publiés.
Les raisons en sont multiples. La principale est souvent liée au temps nécessaire à son écriture. Une bonne idée n'est pas forcément un bon article s'il n'est pas étayé par des références fiables et s'il n'a pas eu plusieurs relectures. Mais ces idées ne gagnent rien non plus à rester dans ce statut.
Voici donc une liste des posts auxquels vous avez échappés, cela videra une partie de mon stock de brouillons :)

Le plus ancien date de juin 2009, la parution de zf05 a permis de se rendre compte que l'hébergement mutualisé est un gros FAIL en terme de sécurité. En lisant ce zf05.txt on se rend compte que les personnes visés utilisaient leur hébergeur mutualisé pour héberger aussi des données privées. Un mutualisé ne devrait servir qu'a placer des données publiques comme un blog. Donc FAIL de l'hébergeur, ou FAIL de celui qui y place ses données privées?

Un autre post qui a été repris plusieurs fois concerne les tunnels DNS. On sait comment ça fonctionne, et comme tout à été à peu près dit dessus, à quoi bon revenir une fois de plus. De plus, j'ai lu http://www.daemon.be/maarten/dnstunnel.html (la page semble down en ce moment). Que dire de plus sinon paraphraser cet article? Donc brouillon, avec quantité de liens comme des tunnel DNS brokers, et autres analyses de débits de ces tunnels, etc etc..

Une analyse réseau d'une capture d'une centaine de Mo avait commencée de manière amusante car dans les premiers paquets apparaissait une recherche google sur les mots clés "on peut être féminine et poutrer du zombie" (mais qui cherche ça?).
Analyser des .pcap de cette taille, c'est long et ennuyeux, surtout que le reste de la capture était vide d'intérêt; pas de virus, pas de troyens, pas de données curieuses, rien. tshark permet facilement de réduire les données d'entrées. Je devais réordonner les one-liner tshark et les diffuser quelque part. La seule option manquante est l'extraction complète des fichiers échangés en HTTP en une passe. Wireshark permet de le faire fichier par fichier, mais apparemment rien n'existe de manière globale. Je pensais bloguer sur cette analyse, mais mis à part pour dire que la majorité des utilisateurs surfent en HTTP et que de fait firesheep a encore de beaux jours devant lui, il n'y avait hélas pas grand chose.. (et puis la sécurité réseau est ennuyeuse, alors..)

Certains messages de bluetouff m'avaient amené à creuser les questions sur le DPI en cœur de réseau opérateur. En regardant chez Orange, on apprend que ce genre d'équipement existe déjà et sert à protéger des clients de DDoS (mais ne donnait pas d'ordres de grandeur). Le dernier DDoS chiffré à l'époque de l'article était celui de wikileaks, 10Gb/s. J'en conclus donc que les équipements de DPI existent déjà, et filtrent au minimum à cette vitesse (les équipements sérieux s'entend, je ne sais pas si l7filter arrive à ce débit :) ).
Le DPI semble une notion assez mal définie ceci dit. Les firewalls ne filtraient à l'origine que des IP/port, puis sont devenus statefulls. Aujourd'hui l'analyse remonte d'un cran pour être applicative. Jusqu'où peut remonter cette analyse? Un firewall bloquant un port nuit il à la liberté d'expression plus ou moins qu'un firewall qui bloque une URL terminant en .exe? Et un firewall DPI protocolaire peut il continuer à remonter, i.e. étudier les fichiers utilisant ce protocole? Intéressant, mais il me faudrait du temps pour rassembler mes notes encore une fois.
Cet article finissait aussi sur la mort du firewall. La sécurité réseau n'intéresse personne, on pose des firewalls de la même manière qu'on pose des antivirus sur des machines windows: "Il en faut". Mais on sait très bien que ça ne bloque pas un seul instant le pirate déterminé. Alors pourquoi en mettre? Il s'agit sans doute de deux idées trop différentes pour en faire un unique post, je reviendrai peut-être la dessus.

Wikileaks devait aussi faire l'objet d'un article. Il s'agit d'un phénomène intéressant de résilience de l'information. Je voulais faire le distinguo entre la résilience d'une information et la résilience d'un service. Une information sur internet est facilement résiliente, sa duplication peut se faire à coût nul (ou négligeable) et sa diffusion peut être faite par tout un chacun, ce qui a été le cas pour wikileaks. La résilience d'un service (imaginons twitter ou facebook) est autrement plus compliquée à obtenir.
Un deuxième axe de réflexion sur wikileaks concerne bien évidemment les Denials of Service qui sont complètement sortis de la sphère "cyber" pour se propager dans le monde réel.

Voilà quelques posts qui n'ont jamais été terminé. J'aurais également souhaité rencontrer un juriste pour parler de LOPPSI2 et des intrusions informatiques "légales", mais l'emploi du temps ne me l'a pas permis.

Certains autres brouillons devraient eux se retrouver bientôt en message de blog.