Planet PLUG

Comme tous les mois depuis bien longtemps, le PLUG organise sa soirée mensuelle. Ouverte à tous les fans de technologie, informatique, logiciels libres, … c’est la bonne occasion pour discuter de ses passions, rencontrer du monde, discuter de sujets connus ou pas et dans un endroit particulièrement sympa et confortable (La Bo[a]te). Au programme de juin : quelques [...]

Une fois n’est pas coutume, voici un petit compte-rendu de la dernière soirée au PLUG, le “Linux User Group” de Marseille. Les soirées se déroulent une fois par mois (souvent le 1er vendredi du mois) à partir de 19h à LaBoate, un endroit très sympatique proche du Vieux Port.

Arrivé un peu en retard, j’ai raté les premières dicussions (anisées), et je suis arrivé pour les traditionnelles pizzas. À cette occasion, certains nous ont rapporté le déroulement de la conférence de Richard Stallman l’après-midi même à Marseille. Ce dernier nous a d’ailleurs proposé de renommer notre LUG (Linux User Group) en GLUG (GNU Linux User Group), condition nécessaire à sa venue à l’une de nos réunions (!). Cette proposition n’a pas fait l’unanimité pour diverses raisons et a finalement été rejetée par les membres présents. D’autres discussions ont suivi, comme l’exploration de Marseille via  Google Maps/StreetView et OpenStreetMap, ou encore la démonstration d’un téléphone portable HTC-Dream tournant sous le fameux système d’exploitation Android.
Ensuite s’est déroulé la première édition des “Lightning Talks du PLUG”, à savoir des petites présentations de quelques minutes sur des sujets/actualités ouvertes à tout volontaire. Françoise Roure nous a tout d’abord parlé d’une Install Party pour les non-voyants en septembre à Marseille. Outre l’appel à la participation, une discussion s’est engagée sur les différents outils libres, notamment Orca ou eSpeak. Ensuite, c’est Jérémy Lecour qui a parlé de l’internationalisation (i18n) de logiciel, et nous a fait de son expérience récente avec l’internationalisation d’un projet en Ruby on Rails. Un petit débat s’est ouvert sur la terminologie d’internationalisation et de localisation, tandis que d’autres ont découvert les jeux de mot avec I18N et l10N.
Après ces petites présentations, j’ai pu mener une présentation générale sur les gestionnaires de paquets dans les distributions GNU/Linux. J’ai repris les bases, à savoir définir un paquet (code source, binaire, compilation, etc.) et l’intérêt d’un gestionnaire de paquets (installation, dépendance, suppression, mise-à-jour, etc.). Pas mal de questions ont été posées, et l’on aura sûrement l’occasion de faire des présentations sur des gestionnaires de paquets précis (APT, YUM, emerge, ports BSD, etc.) les prochains mois.
La soirée a duré fort tard (jusqu’à 3h pour les plus courageux), et un grand sujet s’est improvisé sur le microblogging. Présentation du principe, des sites en vogue (Twitter, identi.ca), débats sur l’intérêt (Microblog vs IRC !), l’infrastructure d’hébergement nécessaire, et les extensions comme l’amusant twistori. D’autres discussions se sont improvisées, par exemple sur la gestion des tâches via la messagerie et plusieurs personnes ont montré leur fonctionnement (principe du Zero Inbox, exemple avec GMAIL, flags avec Mutt, etc.).

Bref, une soirée riche en discussions comme chaque mois. Le mois prochain (vendredi 1er mai), on abordera en outre le sujet des gestionnaires de code sources (CVS, SVN, Git, etc.). Venez nombreux !

Il est important de fermer complètement son Bind, à savoir mettre dans son named.conf :

allow-query { localhost;};
allow-recursion { localhost; };
allow-transfer { none; };

Cela provoque un statut REFUSED pour toutes les requêtes non autorisées. Si refuser les transferts (requêtes AXFR dévoilant toute votre zone) est sage et refuser les requêtes récursives est logique (vous ne voulez pas être serveur DNS pour le monde entier), il faut également refuser toutes les requêtes par défaut afin d’éviter de potentiels dénis de service.

Vous noterez que les directives ci-dessus autorisent les requêtes classiques de la part de localhost dans la mesure où il est fréquent que votre machine se serve de son propre Bind. Si ce n’est pas le cas, mettre toutes les directives à none.

Un moyen simple de vérifier qu’un serveur DNS refuse bien toutes les requêtes :

dig google.fr @<serveur DNS>

Vous ne devez pas obtenir la(les) réponse(s), ni même obtenir la liste des ROOT SERVERS. Vous devez obtenir status: REFUSED (ou alors un timeout…).

J’ai souvent eu du mal à expliquer pourquoi il fallait fermer complètement son Bind, car la menace des attaques DOS restait un peu vague. Ce n’est désormais plus le cas depuis quelques semaines où chaque administrateur d’un Bind assiste (dans ses logs ;-) aux multiples requêtes “. NS IN” générées par des robots/virus :

client 76.9.16.171#39068: query (cache) './NS/IN' denied
client 69.64.87.156#42646: query (cache) './NS/IN' denied

On déplore même des victimes de ces attaques DDOS de grande ampleur, notamment NetworkSolutions qui l’explique sur son blog. Pour contrer cela, on peut refuser les paquets en amont : voici un fameux paquet (format PCAP). On voit donc que l’on peut interdire les paquets comportant une requête DNS récursive (flags = 0×0100). Sur une machine Linux, on peut le faire avec iptables et le module u32 (attention, il semble y avoir des bugs avec certaines versions) :

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0>>22&0x3C@10=0x01000001" -j DROP

SI vous ne voulez pas interdire toutes les requêtes récursives, j’ai trouvé sur Internet une règle plus précise qui matche sur le “. NS IN” (voir commentaires de ce post) :

iptables -A INPUT -j DROP -p udp --dport domain -m u32 --u32 \
"0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@21=0x00020001"

Enfin, sur l’excellent blog de Stéphane Bortzmeyer, vous trouverez plus de détails et des outils pour mesurer le nombre d’attaques sur votre serveur.