Transition from 1024 bits DSA key to 3072 bits RSA key

I’ve created a new 3072/RSA key and it’s time to replace my old weak 1024/DSA key.

The old key ID is 237E9DB2, the new key ID is 0661CBBA.

It’s available from the keyservers.

I’ve published a (joined) transition document signed with both keys. christophe-brocas-gpg-3072R-transition.txt

If you’ve signed my old key, download the document, verify it and if it fits you, please sign the new key.

To do it, follow these instructions (also described in the transition document) :

  • To fetch my new key from a public key server, you can simply do: gpg –keyserver pgp.mit.edu -recv-key 0661CBBA
  • If you already know my old key, you can now verify that the new key is signed by the old one: gpg –check-sigs 0661CBBA
  • If you don’t already know my old key, or you just want to be double extra paranoid, you can check the fingerprint against the one above:  gpg –fingerprint 0661CBBA
  • If you are satisfied that you’ve got the right key, and the UIDs match what you expect, I’d appreciate it if you would sign my key: gpg –sign-key 0661CBBA

Lastly, if you could upload these signatures, i would appreciate it.

You can either send me an e-mail with the new signatures (if you have a functional MTA on your system):  gpg –armor -export 0661CBBA | mail -s ‘Sig’ christophe@brocas.org

You have a last question ? « Why not a RSA 4096 bits length key as almost everybody ? »

Hmm … well … because of the OpenGPG Smartcard v2 and GPG2 limits on key length and I want to be able to use my new key with this Crypto USB token (OpenGPG smartcard v2 inside).

[RMLL/LSM 2010 – 3/3] RMLL : perfect setup

Dans le cadre de mon debriefing des RMLL 2010, ce billet est le dernier d’une série de 3 qui couvrent les sujets suivants :

  • Thèmes et partage d’une vision commune
  • l’internationalization ‘en)
  • RMLL : perfect setup (ce billet)

Disclamer : ces idées/sentiments/enseignements ne sont que des idées personnelles et ne représentent en aucun cas les idées/sentiments/enseignements du comité d’organisation des RMLL 2010 sur cette édition.

Si un seul point était à modifier, lequel serait-ce ?

Et bien, incontestablement, ce serait l’éclatement géographique en N lieux (chez nous 4) différents pendant la semaine. En effet, un tel éclatement a un impact notable sur l’organisation mais aussi le vécu des participants.

Mais pourquoi 4 lieux, déjà ?

Car tout simplement, nous avons pris la problématique dans le sens suivant :

Quels sont les besoins ? nous trouverons les locaux en fonction. Si cela peut paraître sensé dit comme cela (moi même j’ai fini par dire, ben oui, c’est comme cela qu’il faut raisonner), cela nous a surtout poussé à une sorte de course au gigantisme qui, si elle n’a pas été fatale, a eu des impacts notables.

Mais il est où le souci ?

Il est dans les points suivants tous remontés par des organisateurs ou des participants :

  • un thème majeur était l’accessibilité et notre organisation physique était un contre sens pour des personnes souffrant d’handicap quel qu’il soit
  • les rencontres (entre les publics, les communautés, les univers) pourtant au coeur de notre événement ont été affectées par cet éclatement
  • un tel éclatement empêche ou diminue sensiblement la capacité d’appréhension de l’événement par un visiteur étranger
  • l’organisation pratique (signalisation, conférences, captations vidéo, réseau, village etc) est juste rendue extrêmement plus difficile qu’avec un lieu unique. Et j’en oublie certainement.

Mais c’est quoi ta solution magique à toi ?

Je pense qu’il faut sélectionner un lieu unique. Un lieu le plus grand possible, doté des bonnes infrastructures (électricité, réseau, salles) mais un lieu unique. Et après on taille l’événement en fonction :

  • nombre de thèmes et leur durée
  • taille du village
  • événements supplémentaires éventuels

Cette solution n’est pas magique, elle a aussi des inconvénients comme devoir prioriser des choses par rapport à d’autres (diminuer le nombre de conférences par exemple). Mais, cette solution a le mérite je pense de privilégier la qualité d’accueil, les échanges et la simplicité de l’organisation ce qui me semble primordial.

[RMLL/LSM 2010 – 2/3] internationali(s|z)ation

This post is part of 3 posts about 2010 LSM debriefing.

The 3 topics covered will be :

  • Topics and sharing a same vision (previous post)
  • internationali(s|z)ation (this post)
  • RMLL : perfect setup (next post)

Disclamer : the ideas below are only mine and any way not those of the 2010 LSM organization team.

Prelude

Well, let’s speak about something that has been quite important for me this year : setting up a cross technical topics track in english. During the 2009 LSM, I have set up with my security topic co-chairmen an English spoken afternoon with the english speakers. The French speakers that have also their talks during this afternoon have to do them in English too.

After that I have a quite long discussion with Thomas Petazzoni on internalization of talks and of the event : for Thomas,a solution combining efficiently French and English for talks does not exist.

Either LSM is a total French speaking event or LSM will become a full English spoken talks event.

For me, combining the two languages is a crucial point. Let’s see why (from my point of view only of course …).

Why combining English and French talks is important ?

To understand why combining the two languages in talks is important, it is necessary to understand my vision of the utility of events like LSM. LSM for me (tends to) address several problems :

  • setting up bridges between free software developers from different communities (embedded vs Internet vs OS vs development etc) and languages
  • brings free software expertise from whatever it comes to LSM visitors
  • installs less barriers as possible between expertise and visitors

For me, to meet these expectations we have to be able to :

  • invite non french spoken speakers (expertise, bridge)
  • combine their talks with french talks (bridge, less barriers)

The 2010 answer at a Program level

So we invite english spoken speakers. And in counterpart, to put them in a situation the more comfortable we can, we decide this year to set up a cross technical topics continuous english spoken track. Our goal was to be able to say to english spearkers that at any hour of any day of LSM, they were able to find a technical talk in english. And this is exactly what we manage to set up through the commitment and hard work of all topic chairmen and speakers.

The result is here :

Why we do not succeed to provide a comfortable event for English speakers ?

First of all, because if you want to do so, it is definitively not at the Program level you have to work. It is at the top level of the event organization.

Through several long and deep discussions with Uriel, Jamey and Sarah Sharp, and Thomas several points emerge :

  • inconsistent signalization and translations
  • English track for talks has not been actively promoted enough on the website
  • a single point of contact for foreign speakers has always to be set up because coming from Oslo or Sydney and only speaking English is far not as simple as coming from Paris and speaking French
  • a single location is a definitive requirement to make talks, people, events easily accessed for English spoken people And I mention only a subset of all the remarks they made.

Ways to improve the process

First, we have to address above problems. But if I have to select one proposal, it would be the proposal made by Jamey which would be a major step IMHO on the road on a successful internationalized event : having a non French speaking person in the core team of the organization to be the « International conscience » of the event. This person would check all materials produced by the organization (website, practical informations, locations, process etc) from an International point of view.

Jamey said also it would be necessary to made an international call for paper. I agree despite the fact it requires some solids networks to succeed.

And to understand why even small details can break your initiative on the road to success, I let the final word to Sarah : « You want an idea to improve my LSM experience ? Just add a flag on the badge of each person to say what language each person speaks ! »

Enough said !

Conclusion

We tried, we don’t (entirely) succeed, we want to improve : thank you for your presence and your already made feedbacks !

We welcome another feedbaks of course.

For my part, I strongly believe mix-language speakers and talks are requirements to improve exchanges, networks but also local (the french area where LSM takes place each year) access to Free Software expertise. But to do so, we have to improve STRONGLY the way we handle internationalization of the event and the way we receive foreign people.

[RMLL/LSM 2010 – 1/3] Thèmes et partage d’une vision commune

Voilà, les RMLL 2010 ont fermé leurs portes au public (beaucoup sont encore en train de ranger …).

Préambule

Il est désormais temps de mettre par écrit quelques sentiments, impressions et enseignements que j’ai pu tirer de cette semaine très chargée en termes de boulot, rencontres et échanges.

Ce billet est le premier d’une série de 3 qui auront pour sujet :

  1. Thèmes et partage d’une vision commune (ce billet)
  2. l’internationali(s|z)ation
  3. RMLL : perfect setup

Disclamer : ces idées/sentiments/enseignements ne sont que des idées personnelles et ne représentent en aucun cas les idées/sentiments/enseignements du comité d’organisation des RMLL 2010 sur cette édition.

Gestion des thèmes

Cela faisait deux ans que j’étais coordinateur de thème (sécurité en 2008 et adminsys/sécu en 2009).

Cette année, en tant que régional de l’étape et garçon un peu expérimenté, le comité d’orga m’a proposé d’intégrer le comité de programmes. J’ai accepté avec joie 🙂

Une fois la liste des thèmes définie, le travail d’un membre du comité de programmes consiste notamment à trouver les responsables de thèmes qui géreront ces thèmes.

Le travail d’un responsable de thèmes est le suivant :

  • assurer la sélection des conférences qui sont proposées (voire à en chercher d’autres)
  • assurer le suivi des conférences retenues. Cela inclut leur saisie dans l’interface de programmes, leur planification, le suivi budgétaire du conférencier (niveau de prise en charge) etc.
  • une fois sur place, être présent dans la salle de conférences pour assurer le bon déroulement : présentation du conférencier, respect des horaires, récupération et mise en ligne de la présentation, suivi des remboursements, debriefing.

Et le tout en concertation permanente avec le comité de programmes : bref, du boulot !

Dernier point important : tout le travail de préparation du responsable de thèmes jusqu’à l’événement se fait online. Et surtout il n’a de lien avec l’organisation physique de l’événement que via le comité de programmes (moi et Patrice cette année pour les thèmes techniques).

Partage de vision

Afin de comprendre cet événement, il est bon de savoir que les RMLL c’est :

  • une mission d’évangélisation et de partage sur la région où elles se passent. Cette mission associative et éducative implique que toute personne touchée supplémentaire est un objectif accompli.
  • une organisation bénévole qui chaque année se renouvelle en grande partie. Cela signifie qu’au niveau des thèmes, nous ne sommes que le bout VISIBLE de l’iceberg qui bosse derrière dans l’ombre pour que ce grand bazar de milliers de spectateurs/participants fonctionne.
  • une organisation qui est importante en termes de budget géré, partenaires engagés. Cela impose une implication et un sérieux (même en short+tongs !) vital pour que les RMLL soient la manifestation attendue par le public et les partenaires qui l’ont soutenues.

Points à améliorer par rapport à cette année

Le fait de confier la responsabilité d’un thème aux RMLL à quelqu’un implique donc qu’il ait pleinement conscience de ces éléments.

Et c’est là où je pense je n’ai pas su anticiper un point pas vital mais tout de même important. Les RMLL ont une mission, une histoire et un fonctionnement qu’il faut partager et servir tous de la même manière.

Or, à mon niveau, je pense m’être contenté de trouver :

  • une personne compétente sur le thème en question
  • une personne utilisant/contribuant à des LL
  • une personne motivée

Et cela ne suffit pas ! J’aurais aussi dû insister sur le caractère associatif, militant et exigeant de cette manifestation.

Etre responsable de thèmes c’est aussi :

  • prendre en compte dans son attitude et sa communication les gens qui travaillent dans l’ombre sur l’événement et/ou depuis très longtemps en amont,
  • penser collectif, se sentir membre à part entière de l’équipe d’orga et non simplement comme un individu qui gère sa mission
  • prendre conscience que les RMLL sont un travail militant toujours en cours qui avance d’année en année. On s’inscrit dans une histoire et on monte sur les épaules des gens qui ont travaillé avant nous. Cela mérite le respect.

Ces trois points, je ne pense pas les avoir assez promus auprès des responsables de thèmes de cette année. Cela n’a rien engendré de facheux, juste quelques incompréhensions inutiles qui, si ce travail amont avait été (mieux) fait, n’auraient pas existées.

En dehors de cela, je pense que les 360 confs/ateliers/tables rondes/etc … n’étaient pas mal du tout 🙂 Merci à vous tous, responsables de thèmes, pour votre travail !

Conférence « Futur de L’Internet » : quelques notes :)

Se tenait aujourd’hui dans un amphi de l’ENSEIRB une conférence sur l’Internet et son futur avec Vinton Cerf, Bob Kahn et Louis Pouzin via visio conférence (Mountain View / Reston / Paris / Toulouse / Bordeaux Rennes / Nice etc).

Le tout a été mis en oeuvre par le Forum Aténa. Le rattachement de Bordeaux à cete visio s’est réalisé grâce à l’action de @quinetic et du Conseil régional, partenaires des RMLL 2010 se déroulant en Juillet à Bordeaux.

Edit 27/01/2010 :

Disclamer : ces notes n’ont aucune valeur d’exactitude. Particulièrement pour la partie en langue anglaise, les approximations sont certaines et des contre-sens sont mêmes probables. Ces notes ont pour seule volonté de tenter de faire partager un peu du contenu et du ressenti sur ces conférences.

  • 14h-14h35 : Tour de France et de Paris avec prise de paroles successives des organisateurs et de NKM via un reportage enregistré. Elle aborde notamment ses volontés d’utilisation de la part numérique du grand emprunt. Wait and see 😉 .
  • Très bonne prise de parole du délégué TIC du Conseil Régional Michel Eimer. Il rappelle que la participation Aquitaine à cette conférence se fait via le retour des Rencontres Mondiales du Logiciel Libre à Bordeaux en 2010. Il rappelle les priorités de l’Aquitaine pour l’Internet :
    • un accès global et sans fracture à l’Internet,
    • un historique sur le cablage de raccordement au réseau,
    • une volonté de voir disparaitre les télécoms derrière les usages,
    • et enfin permettre une vraie réflexion sur le pluri-linguisme sur Internet.
    • Il finit avec une phrase très vraie : « Hadopi ? une vraie question, une très mauvaise réponse ». Travaillons ensemble pour changer cela !
  • 14h45-15h00 : Vinton Cerf prend la parole et dresse un tableau d’Internet et des questions / usages actuels ou proche de nous : ** remerciements de l’investissement français dans l’avènement d’Internet ** ip v4 et les 10% d’adresses restantes ** internationalisation du DNS pour s’ouvrir ** mobilité et diversité des terminaux ** génération / consommation énergétique : green computing ** convergence numérique : anciens médias qui se retrouvent sur le net. ** cloud computing et interopérabilité ** sécurité et web of trust ** aspects légaux ((http://farm5.static.flickr.com/4023/4293192901_8166f82e9d.jpg))
  • 15h00-15:20 : Bob Kahn :__ ** Louis Pouzin, merci pour ta contribution ! ** Internet a prouvé sa capacité à supporter les échanges mondiaux mais … des challenges existent ! ** sécurité ** beaucoup de besoins différents voire opposés ** des protocoles ont pu être aisément déployés au dessus TCP/IP (http est le meilleur exemple !) ** neutralité du Net : les protocoles sont intrinsèquement agnostiques. Le challenge est d’arriver à maintenir cet état de faits ** Il y a encore une place énorme pour l’innovation mais il y a encore plus de place pour la transparence des fournisseurs de services et d’accès mais c’est une autre histoire (sic !) ** bootstrapping l’Internet : le réinventer pour pouvoir créer et développer des services plus perfectionnés et pointus. [((http://farm5.static.flickr.com/4029/4293938216_a1240049e8.jpg|Conférence Futur de l’Internet))|http://farm5.static.flickr.com/4029/4293938216_a1240049e8_b.jpg]  »[Conférence Futur de l’Internet|http://www.flickr.com/photos/cbrocas/4293938216/] » *
  • Questions / Réponses (15:20 – 16:00) :  ACTA (Vinton Cerf) & Google : Google n’a pas accès directement à ce projet. Mais Google peut mieux faire son métier d’indexation / profiling quand l’information est globalement et généralement accessible. ** Identité numérique comme partie intégrante de l’identité (Bob Khan) : on a besoin d’accès libre et sécurisé aux ressources numériques. L’identité numérique ne peut s’entendre qu’avec un moyen fiable et sécurisé d’authentification. Je ne rentrerai pas par contre dans le débat de droit ou pas de droit. Vinton Cerf : on ne peut pas lier directement l’accès à Internet à un droit inaliénable car Internet est une technologie voué à évoluer, à être remplacée. Une autre partie de la question est l’émergence d’une conscience collective à partir d’une technologie. ** Stabilité du réseau (Bob Kahn) : on voit beaucoup de positions nationales dans les questions de choix d’accès au réseau, de soucis de régulation mais la réalité de l’Internet aujourd’hui prouve que les solutions se trouvent à l’échelle mondiale par coopération entre entités. Vinton Cerf : le coeur de l’Internet et de ses usages est la volonté de partage de ce que l’on connait, de ce que l’on produit. Le libre accès à toutes les ressources mises en ligne est nécessaire. ** Cloud computing & ses problèmes (bob kahn) : le cloud n’est pas un concept unifié, signifie différents choses pour différentes personnes et pour différents contextes. Les gens vont l’utiliser, naturellement, par choix technique ou économique. La transparence va devoir augmenté, l’interopérabilité d’accès, la sécurité aussi. Le travail est devant nous ! * __Conclusion__ : conférence avec 2 personnes ouvertes et qui ont de la vision. Instructif tout le temps, passionnant par moment 🙂
  • 16:40 – 16:50 Louis Pouzin : vision de l’Internet et de son avenir__ : Réflexions sur les éléments indispensables aux protocoles de communication conçus originellement en couches par John Day. En opposition, on peut dire : on communique à deux. Tout le reste est compris dedans : noms, authentification, QOS, correction d’erreurs etc. Cela doit simplifier le développement de systèmes communicants. Ces caractéristiques seraient sélectionnables à la demande et ainsi ne pas être captif d’un modèle étroit organisé en couches. Captivant 🙂
  • 16:50 – 17:05 Jean-François C. Morfin, dit « Jefsey », sur l’internet des pensées :__ service perçu comme permanent, qui a une date de naissance, son expansion mesurée. L’IETF est l’organisme qui essaie que l’Internet aille bien et mieux. Puis réflexion sur la gouvernance et la mise en oeuvre. Beaucoup de terminologie, difficulté d’accès au contenu de la conf. Là, ça plane sec 😉
  • 17:05 – 17:20 Michel Riguidel et l’Internet polymorphe :__ malgré les applications distribuées et transverses, émergent des portails centralisées et des ressources concentrées, c’est l’anti-Internet. Les réseaux/protocoles actuels sont à bout de souffle et les dérapages constatés (cross layers par exemple) en sont issus. Pour lui, le réseau n’est plus un graphe, c’est obsolète. L’Internet du futur est pour lui : le réseau est un milieu en creux, perméable. Note perso : vous voulez savoir si vous êtes en face d’un chercheur en télécom ? Vous en êtes sûr quand il vous explique qu’un compilateur en fait, c’est comme … un routeur (sic !) ! Très intéressant en tous les cas 🙂 Y a de la vision et, les gars, là aussi, ça plane haut et sec 😉
  • 17:20 – 17:35 Michel Charron « L’insécurité de l’Internet » : les programmes, il y a des failles dedans. Dans tous les programmes. Donc l’Internet est unsecured par essence. Cette insécurité est une évidence mais aussi un business juteux. L’insécurité est une arme : remettre en cause les priorités d’une cible, la rendre paranoïaque, justifier des loix liberticides etc. Quelques chiffres sympas : dans 5 ans, USA : 9,4 % des internautes, la Chine, 27%. Conclusion : quelques idées justes bien que déjà connues. Dommage qu’il y ait trop d’esbrouffe comme (bcp trop) souvent en conf sécurité où on se plait à faire peur (« Moi, les applications déplaçables du W3C, je les détruis en rentrant en 15min dans les fichiers XML qui servent à les paramétrer ») de manière inutile et vaine,
  • 17:35 – 17:50 Nicolas Arpagian « Une cyberguerre est-elle possible ? »:__ présentation pas à la hauteur, contrairement à celles des fondateurs de TCP/IP et des autres chercheurs précédents (-> Michel Riguidel inclus). Terminologie imprécise, exemples vieux et archi-connus. On n’est ABSOLUMENT plus dans la vision et la prospective. On a même droit à l’éloge des réseaux privées, pilotés par les états et le tout bien filtré comme il se doit. Bref, à très vite oublier 🙁
  • 17:50 – 18:10 Joao Schwarz da Silva, Commission Européenne : l’Internet du futur, ce qu’en pense l’Europe.__ On reprend un peu de hauteur. Position de l’Europe disant qu’il faut mettre les meilleurs ensemble, sans compartimenter entre secteurs (énergie, réseaux etc).

[RMLL 2010] Appel à conférences

Pour bien lancer 2010, rien ne vaut un petit peu d’actualité Logiciel Libre 🙂

L’appel à conférences et le call for paper pour les anglophones) pour les Rencontres Mondiales du Logiciel Libre est donc lancé !

Si vous avez une conférence, un atelier ou même une table ronde à proposer, n’hésitez pas !

Attention : on parlera de Logiciel Libre et uniquement de Logiciel Libre 🙂

Pour rappel, cette année, les RMLL se déroulent sur l’agglomération Bordelaise du 6 au 11 Juillet 2010.

[mini] HOW-TO Linux : rip CD / MP3 / Tags id3

J’ai récemment acheté un lecteur MP3 (Sony Walkman NWZ S545). La principale raison de ce choix était sa compatibilité native avec tous les OS car vu comme une clé USB standard. Aucun besoin de logiciel tiers pour transférer des pistes dessus ou lire son contenu. Tout se passe bien avec ce balladeur sous Ubuntu 9.10 qui est ma distribution du moment 🙂 __Principal souci ?__ Je n’ai encore AUCUN morceau en MP3. Si, si. J’ai « juste » plusieurs centaines de CD. Le premier qui dit « has been » est … pas loin du compte 😉

J’ai récemment acheté un lecteur MP3 (Sony Walkman NWZ S545). La principale raison de ce choix était sa compatibilité native avec tous les OS car vu comme une clé USB standard. Aucun besoin de logiciel tiers pour transférer des pistes dessus ou lire son contenu. Tout se passe bien avec ce baladeur sous Ubuntu 9.10 qui est ma distribution du moment 🙂

Principal souci ?

Je n’ai encore AUCUN morceau en MP3. Si, si. J’ai « juste » plusieurs centaines de CD. Le premier qui dit « has been » est … pas loin du compte 😉

En plus d’has been, je vais être taxé de non libre car je parle de MP3, format soumis à brevet. Et là, j’abonde. La seule raison que je peux donner est l’interopérabilité assurée ou plus prosaïquement dit, le fait de pouvoir passer mes fichiers MP3 de machine en machine (autre PC / balladeur / autoradio) de manière plus simple et assurée que le faire avec un format OGG ou Flac. __Marche à suivre__ Il va donc falloir: # extraire les pistes des CD pour en faire des fichiers MP3 # Ensuite ces fichiers devront être correctement taggés tags id3v2 afin que le lecteur vous propose les morceaux dans le bon ordre, vous fournisse la liste des albums/artistes/morceaux ou vous affiche la pochette.

Bref, pour que ce ne soit pas un bazar innommable dans votre baladeur 😉

Extraction des pistes du CD 

Grip a été sorti de la distribution Ubuntu justement en version 9.10. Pas de chance hein 😉 Donc j’ai regardé l’offre.

RhythmBox est un lecteur multimédia qui sait ripper les CDs. L’interface est simple, fait correctement la récupération des tags MP3 auprès de la base FreeDB.

On installe donc les packages :

  • Rhytmbox
  • Ubuntu restricted extras NB : ce dernier point amène le support notamment des mp3.

Un point important : l’extraction en mp3 se fait par défaut sous Rhytmbox à un taux de compression de 128 kbits/sec ce qui est peu en termes de qualité.

Je souhaite numérier ma collection de CD en 320 kbits/sec.

Pour cela, il faut effectuer la modification suivante :

  • aller dans le menu Edition> Préférences> Musique> Format
  • choisir MP3 et l’éditer pour mettre la valeur : audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 quality=0 bitrate=320 ! id3v2mux

Une fois ceci fait, on peut ripper ses CDs :

  • insertion de CD
  • sélectionner parmi les choix proposés, lancer Rhytmbox
  • la récupération des tags MP3 depuis FreeDB se fait automatiquement dans la plupart des cas. Au pire, si le champ « Genre » n’est pas rempli par exemple, vous le saisissez dans la zone ad-hoc puis vous cliquez sur un des titres. Tous les champs « Genre » seront remplis.
  • ensuite on peut lancer l’extraction du CD vers la bibliothèque (clic droit ici sur le CD Master Séries volume 2)

Rajout des jaquettes et modification éventuelle des tags

Vous allez donc retrouver les plages extraites de votre CD sous le chemin (en fonction des paramètres saisies dans Rhytmbox sous le menu Edition/Préférences/Musique ) : Musique / Artiste / Album / *.mp3. Ces fichiers sont normalement taggés correctement.

Un petit ajout à ces tags devrait parachever votre travail : ajouter la jaquette à chaque plage. Je dis à chaque car si ce n’est pas le cas, votre baladeur ne vous affichera rien en termes de jaquettes.

Pour cela, j’ai utilisé EasyTag qui n’a pas la GUI la plus intuitive du monde mais qui travaille très bien. Donc on commence par un apt-get install puis on lance notre ami.

Pour appliquer la même jaquette (image récupérée sur Internet au préalable) à tous vos titres, on procède comme sur la capture :

  • on sélectionne tous les titres dans la colonne du milieu,
  • on clique sur sur l’onglet Images à droite
  • on ajoute l’image (clic sur l’icône +)
  • Important : on clique sur la petite coche à côté de la zone d’image : cela permet d’appliquer l’ajout à toutes les plages sélectionnées précédemment. Voir sur la capture l’info bulle. NB : cette consigne est à appliquer sur tous les champs que l’on souhaite modifier pour toutes les plages sélectionnées dans la fenêtre centrale.
  • on sauve nos modifications en cliquant sur l’icône en haut la barre, icône en forme de disque dur avec un flèche.
  • Edit : pour ce qui est des jaquettes, avec le Sony NWZ s545, il semble que 320*320 pixels soit la résolution maximale à utiliser pour l’image, sous peine de ne pas voir la dite jaquette s’afficher sur votre balladeur.

Ca y est vous avez une belle CD-thèque MP3 bien taggée 🙂

Article MISC Mai 2007 – Mon serveur DNS, mon IDS oublié

Cet article est issu de l’article publié dans le numéro de [MISC n°31 de Mai 2007|http://www.ed-diamond.com/produit.php?ref=misc31&id_rubrique=8&caracteristique=1-2-&caracdisp=2-9-|fr]. J’en suis l’auteur (christophe.brocas@free.fr). Tous droits réservés à MISC. Je le poste ici car l’idée d’utiliser son serveur DNS semble être dans l’actualité du monde de la détection d’intrusions.

Cet article est issu de l’article publié dans le numéro de MISC n°31 de Mai 2007. J’en suis l’auteur (christophe.brocas@free.fr). Tous droits réservés à MISC. Je le poste ici car l’idée d’utiliser son serveur DNS semble être dans l’actualité du monde de la détection d’intrusions.

Mon serveur DNS, mon IDS préféré
Christophe Brocas, christophe.brocas@free.fr

Le Système d’Information (SI) des entreprises est un capital de ressources à protéger des attaques et, si une attaque réussit, la compromission et les évasions de données doivent être détectées le plus tôt possible. Pour détecter des postes compromis sur le réseau de l’entreprise, des solutions complexes et onéreuses sont souvent proposées aux Directeurs Informatiques (DSI) mais le plus souvent, peu de solutions de détection anti-intrusions sont effectivement en place. Or, la bonne compréhension à la fois de son architecture et du comportement des codes malicieux présents sur les postes compromis permet de proposer une première réponse élégante, peu couteuse et efficiente à cette problématique.

1. Introduction

1.1 Compromission de postes

Uune détection, quelle détection ? Afin de sécuriser son SI, une entreprise doit déployer une interconnexion applicative filtrée par des proxies et des serveurs dédiées (exemples : filtrage http/smtp, relais dns) afin de pouvoir fixer des règles de sécurité consistantes. Cependant, une fois cette architecture déployée, la majorité des entreprises ne semble pas se préoccuper des tentatives de contournement/d’accès direct à l’extérieur depuis un poste du LAN compromis. Elles se reposent généralement sur les différentes alertes que peuvent remonter les solutions d’antivirus postes et serveurs. Or, si les protections amont de filtrages des flux HTTP/SMTP sont utiles, la détection des postes compromis est nécessaire tant sur le plan de l’intégrité des données de son SI que sur le plan de la responsabilité de l’entreprise qui pourrait ainsi fournir, par exemple, une base à des réseaux de postes zombies.

1.2 Avoir un IDS sans le savoir

La solution ? L’analyse des serveurs applicatifs est un moyen simple de connaître les compromissions potentielles dans son LAN. Les logs du serveur DNS et, dans une moindre mesure, ceux du pare-feu sont des sources de données disponibles pour effectuer cette veille anti-intrusion.

Concentrons-nous sur le DNS : comment diable un serveur DNS peut-il nous révéler les intrusions déjà effectuées sur son réseau ?

Et les réponses sont :

  • comprendre le comportement des différents types de codes malicieux présents sur les postes compromis ;
  • en déduire les types de requêtes DNS pouvant être émis par ces codes ;
  • en fonction de ces profils, analyser les logs du serveur DNS et isoler les postes susceptibles d’être compromis.

2. Architecture à base de proxies et de relais :

C’est un pré-requis nécessaire. Mais, attention, dans les logs d’un serveur DNS, rien ne distingue une requête émise par un poste de celle émise par un autre. Le seul moyen de stigmatiser une requête émise par un poste en particulier est de pouvoir définir le comportement normal d’un poste en termes de requêtes DNS. Et ce, par rapport à celui, différent, des serveurs de type proxies ou relais.

2.1 Flux vers l’Internet : « authentication required » !

Les flux émis vers l’Internet depuis un poste de travail sont nombreux : * émis consciemment par l’utilisateur : envoi d’email, navigation sur le web ou téléchargement de fichiers etc ; * mais aussi émis de manière invisible pour l’utilisateur : mise à jour du système d’exploitation, rapatriement de mises à jour antivirales etc . Et je ne parle que des flux légitimes !


Figure 1 : architecture proxies et serveurs relais

Et pour être reconnus comme légitimes, l’ensemble de ces flux doivent être soumis à habilitation. Pour cela, il faut que ces flux soient reroutés de manière systématique vers des équipements de filtrage nécessitant une habilitation, à savoir les proxies ou serveur relais. Habilitation que devra renseigner l’utilisateur pour chaque type de flux. !!2.2 Proxies et relais, uniques émetteurs de requêtes DNS vers Internet’ Les machines proxies ou relais se doivent, pour être utilisées, d’exiger de l’utilisateur une authentification. Cela se traduit par des demandes d’identification HTTP par le proxy HTTP ou l’utilisation de SMTP AUTH pour l’envoi de mail via le serveur SMTP de votre entreprise. Les flux émis par les postes vers Internet sont alors authentifiés, donc moins sujet à être vecteur d’attaques.


Figure 2 : étapes d’une requête HTTP

Le gain de cette architecture en termes de détection d’intrusion ? Tout le trafic émis par les postes à destination de l’Internet est dans un premier temps redirigé vers ces machines intermédiaires. Les requêtes DNS de résolution de domaines internet ne sont alors plus émises que par ces équipements proxies et relais :

  • En effet, afin de pouvoir router, par exemple, les requêtes HTTP vers google.fr émises par un poste (point 1 sur la figure 2) ;
  • le proxy de l’entreprise demande une résolution DNS de type A sur le domaine google.fr (point 2) pour le compte de ce poste ;
  • La requête peut ensuite être émise vers le serveur HTTP cible (point 3).
  • NB : Il en est de même pour les envois de mails où le serveur SMTP joue le rôle du proxy HTTP.

Comme vous pouvez le voir, grâce à cette architecture centralisée et maîtrisée, les logs de votre serveur DNS deviennent de manière mécanique des sources fiables de données de détection d’intrusion : toute demande de résolution DNS d’un domaine internet émise par un poste lambda peut être considérée comme une alerte d’une compromission potentielle.

3. Configuration du serveur DNS Bind

3.1 Configuration par défaut : état des lieux

Les configurations figurant dans cet article décrivent la configuration d’un serveur DNS Bind et ont été testées avec un serveur Bind en version stable 9.3.2 sous Ubuntu 6.06. La configuration par défaut d’un serveur DNS Bind ne collecte pas dans ses fichiers de logs les requêtes émises par les clients DNS. En effet, ces requêtes peuvent générer beaucoup d’écritures dans ces fichiers dont la taille peut donc augmenter rapidement. Nous allons donc utiliser la gestion automatique des fichiers de logs fournie par Bind, gestion améliorée depuis la version 9.3 par la gestion d’une taille maximale de fichiers de logs. Une présentation des options de logging de Bind a été faite dans un article précédent de MISC

3.2 Collecte des requêtes clientes dans les logs de Bind

Voici un exemple de définition d’un channel permettant de collecter les requêtes émises par les clients :

# Declenchement du log des requetes
querylog;
# paragraphe definissant le logging 
logging { 
channel querieslogs { 
file "queries.log" versions 10 size 20m; 
print-time yes;
print-category yes;
};
category queries { 
querieslogs; }; 
}; 

 

 

Des fichiers de configuration complets pour chaque type de serveur (cache interne, cache internet, maitre interne et maitre internet avec des sections de logs complètes sont disponibles sur le site de MISC. De plus, vous trouverez la documentation exhaustive des options de log de Bind en ligne sur le site du logiciel .

4. Que chercher dans les logs ?

4.1 Topologie du comportement réseaux des codes malicieux

Un poste de travail compromis par un code malicieux a pour vocation de devenir une source d’informations émises à destination de serveurs externes, ou une source d’attaques pouvant être pilôtées ou pas depuis Internet. Dans les deux cas, une communication vers des serveurs externes tentera d’être initiée. Ces serveurs peuvent être des cibles d’attaques (spams[], dénis de services distribuées[]), des serveurs de contrôle fournissant des instructions aux codes malicieux distribuées ou bien des serveurs de collecte d’informations usurpées à l’utilisateur du poste.

4.2 Requêtes DNS émises par des codes malicieux

Ils existent deux grands types de requêtes :

  • les requêtes de type MX qui sont émises par les moteurs d’envoi de spams et de virus qui sont lancés sur les postes une fois compromis. De même, ces requêtes servent à ces codes malicieux pour se propager via email. Ce type de requête fournit le nom et l’adresse IP du(des) serveur(s) SMTP réceptionnant pour le domaine passé en paramètre ;
  • les requêtes de type A représentent la majeure partie des requêtes restantes. Ces requêtes peuvent alors correspondre à des demandes de résolution de noms de futures cibles, de serveurs de téléchargement de nouveaux codes malicieux (ou de mises à jour) ou encore de sites fournissant des ordres aux codes malicieux(serveurs IRC par exemple) .
  • Pour les requêtes MX, on peut en avoir la trace pas plus loin que dans sa messagerie. Exemple d’entête de spam dans la BAL de votre serviteur :
[...]
Received: from 200.253.154.11 (HELO data-app.com) (200.253.154.11) by mrelay5-1.free.fr with SMTP;
14 Dec 2006 19:44:31 -0000
Message-ID: <01c71fb7$588313d0$0200a8c0@servidor>
Reply-To: "Kalpana Lo"
From: "Kalpana Lo"
To: "Charles Chickering"
Subject: Re: [...]

On y voit un mail émis directement depuis un poste sur l’Internet vers le serveur MX de l’hébergeur de ma BAL. Cette émission a donc fait l’objet d’une demande de résolution MX pour le domaine free.fr sur le serveur DNS du poste internet.

5. Exploitation des logs DNS

5.1 Extraction des données

#egrep -v -i "@IP1|@IP2" /var/log/queries.1og | egrep -v -i mondomaine.fr 

La ligne de commandes précédente permet : * d’isoler l’ensemble des requêtes émises par les postes de travail (premier grep) ; * demandant une requête sur un domaine différent du domaine de l’entreprise ici nommé mondomaine.fr (second grep). Les données produites par cette commande correspondent à une liste d’adresses IP ayant un comportement DNS anormal selon les critères décrit dans le chapitre 4 :

[...]
22-Jan-2007 22:55:24.978 queries: client 192.168.0.190#32788: query: google.fr IN A +
22-Jan-2007 22:55:49.228 queries: client 192.168.0.190#32788: query: hotmail.com IN MX + %%%
[...]

On voit dans l’exemple ci-dessus un poste interne d’adresse IP 192.168.0.190 demander au DNS l’adresse IP de google.fr ainsi que celle du serveur SMTP gérant le domaine hotmail.com. Or, ces deux requêtes ne devraient jamais être émises par un poste du LAN car elles portent sur un domaine différent de celui de l’entreprise. En effet, ces deux requêtes DNS devraient avoir été émises respectivement par le proxy HTTP et par le relais de messagerie de l’entreprise. Ces deux machines ayant auparavant demandé son habilitation HTTP ou l’utilisateur de messagerie à l’utilisateur du poste.

NB : On peut bien entendu spécialiser cette ligne de commandes pour obtenir soit les requêtes de type MX soit les requêtes de type A.

5.2 Faux positifs ?

Explications et actions correctrices Nous avons décrit dans le chapitre 2 un pré-requis ambitieux qui était que toutes les communications ou tentatives de communication vers Internet émises par les postes de travail passaient par un proxy ou une machine relais. Or, la première analyse que vous allez mener sur les données extraites des logs de votre serveur DNS risque fort de plus vous mettre sur la trace de postes lançant des Windows Update que sur celle de postes zombies (du moins je l’espère pour votre LAN 😉 ). Vos premières actions vont donc être de travailler sur ces mécanismes légitimes s’exécutant sur vos postes et émettant des requêtes vers l’Internet : * de forcer le passage par proxy des actions qui le peuvent ; * d’inactiver les mécanismes s’exécutant mais finalement ne le devant pas ; * de noter les mécanismes devant absolument exécuter des connexions externes directes afin de les exclure des remontées des logs DNS. Notez bien que ce type de connexion devrait être rarissime car étant anormales en termes de politique de sécurité.

5.3 Gestion des alarmes

La liste des adresses IP ainsi remontées par la scrutation du fichier queries.log permet aux administrateurs des postes et au responsable sécurité de déclencher les actions appropriées. Parmi elles, on peut lister les quelques actions suivantes : * mise hors réseau du poste incriminé ; * recherche du code malicieux ; * recherche de l’explication de la compromission : manque de suivi des mises à jour antivirales, mise en ligne du poste directement sur le net (ex: à domicile), contournement de la politique de sécurité etc ; * remasterisation du poste avec restauration des données sauvegardées à une date antérieure à la compromission si la date est identifiée ;

6. Limites et pistes d’améliorations

6.1 Limites

Le processus de recherche de postes compromis que nous venons de décrire possède des limites liées au fait que nous travaillons sur le serveur DNS. Les limites majeures viennent du fait que l’on suppose que le code malicieux n’utilisera pas de données d’authentification dérobées à l’utilisateur du poste. Ainsi, l’émission de mails en SMTP authentifié à travers le relais SMTP de l’entreprise. Idem pour l’utilisation du proxy HTTP de l’entreprise pour attaquer un site extérieur ou récupérer des ordres d’un serveur de synchronisation. La remarque que l’on peut faire est que la majorité des codes malicieux sont conçus pour travailler sur des architectures ouvertes (DNS/SMTP/HTTP ouverts vers l’extérieur).

6.2 Pistes d’amélioration

Elles sont de deux ordres : exploitabilité de la solution et consolidation des données DNS avec les tentatives d’accès direct à l’extérieur par adresses IP. L’exploitabilité de cette solution serait de travailler sur l’enchainement des opérations de recherche dans les fichiers de logs, cyclage, compression et suppression de ces fichiers. Pour ce qui est de la consolidation, il faudrait déclencher de telles recherches sur les rejets du Firewall concernant des requêtes en provenance de postes en plan d’adressage interne (ex: 10.0.0.0/8) à destination d’adresses externes (vers l’internet donc).

7. Conclusion

Comme nous venons de le voir, une architecture qui permet de bien maîtriser les flux de données couplée à une analyse des logs de son (ses) serveur(s) DNS permet de disposer d’une sonde de détection de postes compromis. Cette solution a l’avantage d’être légère, non structurante et … ne coûte rien ! Cela n’empêche en aucun cas le RSSI ou le DSI de doter l’entreprise de solutions plus complète (et complexe), intrusive et chère.