Avant de traiter le sujet du jour, je voulais vous dire que je suis désolé pour l'indisponibilité de ce site ces 2 derniers jours. Mon hébergeur n'avait pas prévenu de cette maintenance censée durer moins de 24h. J'ai bien évidemment envoyé un mail pour me plaindre : il n'est absolument pas normal ne pas prévenir les clients d'une maintenance longue. En tout cas, cela me prouve bien une chose : il faut toujours avoir une copie de son site en état de marche sur un autre hébergeur : comme ça, on a juste à changer un champ A dans le nom de domaine et ça repart !

Mais tout ça, c'est du passé. Parlons du sujet du jour : installer un Windows 7 chiffré avec TrueCrypt, un GNU/Linux Debian chiffré avec dm-crypt et une partition de données chiffrée avec dm-crypt sur un même disque dur . Le but final est de sécuriser (un peu plus) mon ordinateur portable.

Table des matières

Ne me demandez pas pourquoi j'utilise encore Windows malgré ma grande passion pour le monde du Libre : je vous l'ai déjà expliqué dans un billet : simplement par contrainte professionnelle.

Des tutoriels existent déjà sur le sujet : DualBoot OS FDE : Windows chiffré + Linux chiffré sur Artiflo Inside notamment mais ils ne sont plus à jour (passage de GRUB à GRUB 2).

Présentation des différentes solutions

Avant de commencer, sachez que plusieurs solutions existent (source : commentaires de Artiflo Inside) :

  • La méthode bricolage : Chainloading TrueCrypt with GRUB2 sur Ubuntu Forums. Bof bof comme méthode.
  • Repasser à Grub Legacy. Bof comme méthode vu les avancées de GRUB 2.
  • Laisser le bootloader de Truecrypt charger GRUB qui lui-même chargera votre GNU/Linux. Cette méthode est une des meilleures ... mais pas pour moi : TrueCrypt n'est pas un logiciel libre donc il est hors de question qu'il soit mon bootloader primaire ! Et comme je vais plus souvent sous GNU/Linux que sous Windows, il n'est pas normal que ce soit le bootloader de TrueCrypt que je vois le plus souvent
  • Utiliser grub2tc. Il convertit l'image de restauration de TrueCrypt en un fichier utilisable par GRUB2. Cette méthode me paraît être la meilleure. C'est donc elle que nous allons mettre en place.

ÉDIT du 24/05/2013 à 18h15 : Grub2tc n'est finalement plus la solution que je préconise. Il y a trop souvent des bugs bloquants : une fois la "compilation" foire, une autre fois on a le message suivant lors du boot sous Windows :

no physical memory is available at the location required for the windows boot manager

La solution qui marche toujours, c'est celle que je qualifie, finalement à tord, de bricolage ci-dessus : Chainloading TrueCrypt with GRUB2 sur Ubuntu Forums. Ce tutoriel reste toujours valable, seule la partie « Utiliser grub2tc » change. Fin de l'édit

Avant de commencer la mise en place de la solution grub2tc

Sachez que même pour cette unique méthode, il y a plusieurs moyens de la mettre en œuvre.

La méthode la plus souvent présentée sur internet consiste à : installer Windows puis installer un GNU/Linux chiffré, puis chiffrer la partition Windows, puis utiliser un LiveCD et grub2tc puis utiliser le disque de récupération de TrueCrypt.

Attention toutefois avec cette méthode souvent présentée :
Lors du prétest TrueCrypt, vous allez obtenir une erreur "No bootable partition". Pour remédier à ce problème, il suffit d'utiliser GParted et de mettre le drapeau "boot" sur la partition Windows.

Comme vous utilisez un live CD pour redéfinir GRUB comme programme d'amorçage, il vous faudra installer lvm, git et ruby (apt-get install git lvm2 ruby) pour pouvoir suivre les instructions d'utilisation de grub2tc. Il vous faudra ensuite monter votre partition chiffrée (j'utilise l'explorateur de fichier Nautilus pour faire ça). Puis vous devrez utiliser les commandes "vgscan" puis "vgchange -a y" pour trouver et utiliser votre volume LVM (sinon vous aurez l'erreur "not a mountable file systeme"). Ensuite vous devrez monter votre partition racine puis monter la partition /boot dans point_montage_racine/boot. Ensuite, vous devrez utiliser l'argument "--root-directory=/point_de_montage_racine" de la commande grub-install sinon, vous obtiendrez une erreur "Cannot find a device for /" ou "Cannot find a device for /boot". Tout un programme ! Pour grub-install, voir : Boot Problems:Cannot Find A Device For boot/grub sur Sourceforge/bootinfoscript.

Enfin, au redémarrage ou lors d'une mise à jour de GRUB2, TrueCrypt vous lancera des "Incorrect password" à la figure. Il faudra alors utiliser le disque de restauration de TrueCrypt pour demander la réécriture des headers ("Repair Options" puis "Restore key data (volume header)").

Un dernier mot : si vous comptez utiliser un liveCD Ubuntu 11.04 (Natty), je vous le déconseille. En effet, lors du lancement de la commande grub-install, vous obtiendrez une erreur "error: cannot stat `aufs'.". Il s'agit d'un bug reconnu. Vous pouvez utiliser Ubuntu 11.10 (The Oneiric Ocelot), dont les daily build se trouvent à cette adresse : Ubuntu 11.10 (Oneiric Ocelot) Daily Build. Ce bug y a été corrigé.

La méthode que je vous propose nécessite moins d'étapes et est moins "prise de tête".

Mise en place de grub2tc avec la méthode GuiGui

Partitionner

Utilisez un liveCD/liveUSB de GParted et créez 4 partitions :

  1. Une partition primaire de 1Gio (1024Mio) formatée en ext4 qui sera la partition /boot.
  2. Une partition primaire de 20Gio (20480Mio) formatée en NTFS qui sera la partition pour Windows 7.
  3. Une partition étendue de 50Gio (51200Mio) qui servira à stocker les différentes partitions de Debian.
  4. Une partition primaire utilisant tout l'espace disque restant et qui servira à stocker vos données.

Note : vous pouvez bien évidemment adapter les tailles de ces partitions à vos besoins.

Installer Windows

Je vous laisse installer Windows 7, sur la partition dédiée, tous seuls comme des grands et je vous attends à la prochaine étape.

Chiffrer la partition Windows

Rien de bien compliqué ici. Téléchargez, installez et lancez TrueCrypt.

Allez dans le menu "System" puis cliquez sur "Encrypt System Partition/Drive".

Sélectionnez les options suivantes : Normal => Next => Encrypt the windows system partition => Next => Single boot => Next => suivez le reste de l'assistant, il n'y a plus de questions piège.

La vitesse du chiffrement dépend de la capacité de votre processeur et de celle de votre système de stockage (SSD, disque dur).

Attention : Pensez à récupérez le fichier iso en lui-même, pas uniquement à graver le CD qu'il représente.

Installer GNU/Linux Debian chiffré

Nous allons utiliser l'image d'installation par le réseau. Suivez normalement l'assistant jusqu'à arriver sur les options de partitionnement. Choisissez le partitionnement manuel.

Choisissez la partition étendue créée précédemment et définissez-la comme un "volume physique de chiffrement". Refusez d'effacer les données et choisissez de terminer le paramétrage de cette partition.

Choisissez ensuite de configurer les volumes chiffrés. Validez les modifications, choisissez "Terminer" et saisissez votre passphrase.

Choisissez ensuite de configurer les volumes LVM. Validez les modifications et patientez. Créez un groupe de volumes, nommez-le (exemple : "Debian"), choisissez la partition chiffrée comme réceptacle et continuez en validant.

Ensuite créez des volumes logiques :

  • Un volume nommé "racine" de 25Gio.
  • Un volume nommé "usr" de 20Gio.
  • Un volume nommé "var" de 5Gio

Note : vous pouvez également créer une partition swap si votre ordinateur à une quantité limitée de mémoire vive. Vous pouvez également créer une partition pour recevoir le point de montage /tmp (fichiers temporaires). En ce qui me concerne, je compte utiliser le système de fichiers tmpfs pour mes fichiers temporaires. Je n'ai donc pas besoin d'une partition supplémentaire.

La séparation des points de montage /tmp, /var, /usr et / est recommandée. Notamment par le Guide to the Secure Configuration of Red Hat Enterprise Linux 5 de la NSA.

Terminez la configuration de LVM.

Choisissez la dernière partition primaire créée précédemment (et destinée à vos données) et définissez-la comme un "volume physique de chiffrement". Refusez d'effacer les données et choisissez de terminer le paramétrage de cette partition.

Allez à nouveau dans le menu "Configurer les volumes chiffrés" et suivez la même procédure que précédemment. Vous pouvez choisir une passphrase différente de la précédente pour plus de sécurité.

Vous n'êtes pas obligé de créer un volume LVM pour stocker vos données, une partition ext4 suffira.

Maintenant, il faut associer chaque point de montage à son volume LVM. Personnellement, j’ai choisi de formater toutes mes partitions en ext4.

  • Le point de montage "/" est à associer au volume LVM "racine".
  • Le point de montage "/usr" est à associer au volume LVM "usr".
  • Le point de montage "/var" est à associer au volume LVM "var".
  • "/boot" est à associer à la première partition primaire. N'oubliez pas cela sinon GRUB ne sera pas installé et vous aurez des problèmes.
  • Vous pouvez aussi attribuer le point de montage "/home" à la partition que nous avons créée pour recevoir vos données mais moi je ne le fais pas. Cela me permet de trier plus efficacement mes données. /home reçoit les données (fichiers de configuration, fichiers téléchargés) et je les range dans ma partition de documents quand cela m'intéresse.

Vous pouvez terminer le partitionnement et confirmer sa réalisation. Le reste de l'installation Debian n'est pas spécifique et se passe donc de commentaires.

ÉDIT du 18/03/2012 à 13h00 :
Attention : Lors de l'installation de Debian, ne définissez pas le drapeau d'amorçage sur la partition /boot ni sur aucune autre partition. Si vous le faites, vous aurez une erreur avec TrueCrypt : vous saisirez votre mot de passe au démarrage mais le système d'exploitation ne sera pas chargé et vous obtiendrez une erreur "no bootable partition found". Pour résoudre ce problème, il suffit, comme indiquer plus haut dans ce billet, de prendre un bon vieux live de Gparted et de définir le drapeau "boot" sur la partition Windows (oui, oui, la partition chiffrée que Gparted marque comme étant de type inconnu). Fin de l'édit.

Utiliser grub2tc

ÉDIT du 24/05/2013 à 18h15 : Grub2tc n'est finalement plus la solution que je préconise. Il y a trop souvent des bugs bloquants : une fois la "compilation" foire, une autre fois on a le message suivant lors du boot sous Windows :

no physical memory is available at the location required for the windows boot manager

La solution qui marche toujours, c'est celle que je qualifie, finalement à tord, de bricolage ci-dessus : Chainloading TrueCrypt with GRUB2 sur Ubuntu Forums.

Je copie ici les instructions afin d'en conserver une copie au cas-où :

1. Copy the rescue ISO to /boot
2. sudo apt-get install syslinux
3. sudo cp /usr/lib/syslinux/memdisk /boot
4. Add /etc/grub.d/40_windows_truecrypt:
#!/bin/sh
exec tail -n +3 $0
# Windows with TrueCrypt
menuentry "Microsoft Windows" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux16 ($root)/memdisk iso raw
initrd16 ($root)/truecrypt.iso
}
 
Step 4 will add the entry whenever updating grub. You'll have to modify some of this to fit your situation. Such as the (hd0,msdos3) partition is your /boot, and the numbers start at 1.

Fin de l'édit

Source : README de grub2tc.

Au redémarrage, vous booterez sur Debian. Installez ruby, git, gcc et make :

$ su -
# apt-get update && apt-get install git ruby make gcc

Récupérez grub2tc :

$ git clone git://gitorious.org/grub2tc/grub2tc

Placez-vous dans le dossier récupéré :

$ cd grub2tc

Copiez l'image de récupération de TrueCrypt et renommez-la "tcrescue.iso".

Ensuite, lancez la commande :

grub2tc$ make

Vous allez récupérer un fichier "tcloader". Copiez-le dans le répertoire /boot :

grub2tc$ cp tcloader /boot

Modifiez le fichier /etc/grub.d/40_custom pour y ajouter :

menuentry "Windows via TrueCrypt" {
           insmod multiboot
           multiboot /tcloader
}

Bien entendu, vous pouvez remplacer le texte "Windows via TrueCrypt" par celui que vous voulez voir apparaitre dans le menu de GRUB2.

Mettez à jour les fichiers de configuration de GRUB2 :

# update-grub2

Installez GRUB2 dans le MBR de votre disque dur système :

# grub-install <disque système>

Remplacez "disque système" par votre disque dur : /dev/sda par exemple.

Enjoy

Rebootez et profitez du résultat !

ÉDIT du 28/10/2011 à 13h55 : Lors d'une mise à jour de GRUB2 ou de l'initramfs (via apt-get/aptitude par exemple), TrueCrypt vous lancera des "Incorrect password" à la figure. Il faudra alors utiliser le disque de restauration de TrueCrypt pour demander la réécriture des headers ("Repair Options" puis "Restore key data (volume header)"). Pour prévenir tout problème, lisez la liste des paquets qui seront mis à jour : si vous voyez grub2 ou lvm2 ou initramfs, alors préparez votre CD de restauration TrueCrypt. Je sais : je l'ai déjà écrit plus haut mais je préfère me répéter car la première occurrence n'est pas forcement bien visible. Fin de l'édit.

Retour sur les performances (10/12/2011 à 18h00)

Cela fait un peu plus de 3 mois maintenant que j'utilise, au quotidien, l'installation décrite dans ce billet sur mon ordinateur portable. Mon portable est loin d'être un foudre de guerre (Celeron 900 à 2.20Ghz) et j'avais peur de voir un ralentissement de mon système. Je voulais donc vous faire un feedback sur ce point. Finalement, je n'ai ressenti aucune gêne sous Debian : le système reste fluide. En revanche, je ressens une baisse des performances lors des écritures sur le disque (installation de programmes, copie de fichiers, ...) avec Windows 7. Mais ce dernier point n'est pas grave puisque je n'utilise quasiment plus Windows et que celui-ci était déjà lent avant l'utilisation de TrueCrypt (ceci n'est pas un troll : expliquez-moi juste pourquoi la lecture de la même vidéo HD avec la même version de VLC et un nombre minimal de programmes/démons lancés en arrière plan saccade fortement sous Windows et pas sous Debian ... ).

ÉDIT du 26/05/2012 à 7h25 : Il semble qu'utiliser TrueCrypt sur un SSD soit contre-productif. Alors que cela se passe bien avec W7 sur un disque dur classique (5400 tpm ou 7200 tpm), W7 manque de réactivité quand on l'utilise sur un SSD avec TrueCrypt. Mais quand je dis "manque de réactivité", c'est vraiment beaucoup : le boot en 3 minutes, l'arrêt en quasiment 2 minutes, le lancement des programmes ... Avec le même SSD, les mêmes programmes et les mêmes mises à jour mais sans TrueCrypt, ce problème ne se produit pas. On pourrait toujours se lancer dans une analyse psychologique du genre "sur un disque dur 5400 tpm, on s'attend à un certain ralentissement donc le ralentissement induit par l'usage de TrueCrypt ne choque pas alors qu'il choque sur un SSD dont on attend aucune lenteur" mais je ne pense pas que cela explique un W7 ayant un tel manque d'adrénaline. Je n'ai aucune idée sur l'origine de ce problème. Cela dit, utiliser TrueCrypt sur un SSD est déjà une mauvaise idée selon le niveau de sécurité que l'on souhaite atteindre à cause du TRIM et du wear-leveling. Aucun problème n'est à signaler avec dm-crypt sous GNU/Linux. Attention : le TRIM n'est pas activé par défaut (il faut utiliser l'option --allow-discards lors du luksFormat) et la remarque concernant le wear-leveling est toujours d'actualité. Fin de l'édit.

C'est ici que je vous laisse et le mois d'août également.

ÉDIT du 18/03/2012 à 13h00 : J'ai effectué les manipulations décrites dans ce billet sur un autre ordinateur sans rencontrer de problèmes. Fin de l'édit.

Créez votre image personnalisée d’OpenWRT

Avant de traiter le sujet du jour, je souhaite vous informer que j'ai relu tous les billets traitants d'OpenWRT et que j'ai modifié/corrigé la plupart d'entre eux. En effet, certains d'entre eux comportaient des phrases imprécises, d'autres des bourrelets inutiles et enfin d'autres comportaient des phrases qui pouvaient prêter à confusion.

Commençons à traiter le sujet du jour : créer une image personnalisée d'OpenWRT pour votre routeur. Attention : je parle ici d'un routeur déjà supporté par OpenWRT, pas d'une adaptation d'OpenWRT à votre routeur qui n'est pas encore supporté.

ÉDIT du 15 juillet 2012 : Ce billet traite de Backfire 10.03. Quelques petites choses ont changées avec Backfire 10.03.1 et je vous conseille en conséquence de lire, en parallèle, cet autre billet : Créez votre image personnalisée d’OpenWRT : ce qui change avec Backfire 10.03.1.

ÉDIT du 04 janvier 2014 : Ce billet traite de Backfire 10.03. Quelques petites choses ont changées avec Attitude Adjustment 12.09 et je vous conseille en conséquence de lire, en parallèle, cet autre billet : Créez votre image personnalisée d’OpenWRT : ce qui change avec Attitude Adjustment 12.09.

Table des matières

Pourquoi créer une image personnalisée ?

Tout est déjà dit sur le wiki d'OpenWRT, je traduis juste :

  • Inclure les logiciels dont vous avez besoin directement dans l'image squashfs permet de réduire l'espace disque qu'ils occupent sur la flash de votre routeur. Cela est dû aux propriétés du système de fichier squashfs qui est compressé. Pour vous donner un ordre d'idée des gains : prenons une Backfire 10.03 brcm47xx fraichement installée et installons dnscache, ntpd, etherwake, tcpdump-mini, luci-i18n-french, ddns-scripts, iptables-mod-conntrack-extra et supprimons luci-admin-mini et luci-i18n-english. Il me reste 196k d'espace libre. Maintenant, intégrons ces mêmes packages dans une image et installons-la sur le routeur. À la suite de cette installation, il reste 492k d'espace libre dans la mémoire de mon routeur. L'espace gagné vous permettra d'installer encore plus de logiciels 🙂 .
  • Créer une image personnalisée vous évitera de tout réinstaller et de tout reconfigurer en cas de problème. Si une expérience vient à foirer, vous aurez juste à reflasher votre routeur avec votre image personnalisée pour retrouver une configuration aux petits oignons. Et si vous avez plusieurs routeurs, vous gagnerez un temps fou en déploiement.
  • Construire une image minimale qui correspond à vos besoins.
  • Apprendre ... Ça se passe de commentaires.

Préparatifs

Si vous n'avez pas déjà installé l'environnement de développement d'OpenWRT, alors le mieux est de récupérer l'image builder de votre déclinaison.

Si comme moi, vous avez déjà récupéré la totalité de l'environnement, buildroot, servez-vous en. Il est inutile de télécharger l'image builder puisque celui-ci est inclus dans buildroot.

Dans la suite de ce guide, je considérerai que vous avez déjà récupéré buildroot. Sauf mention contraire, je considérerai également que votre répertoire courant est backfire_10.03, c'est-à-dire la racine du buildroot. Si vous avez déjà compilé quelque chose, sauvegardez les binaire obtenus et faites un peu de ménage avec :

backfire_10.03$ make clean

Note : selon ce que vous voulez obtenir, vous n'êtes pas obligé de suivre toutes les étapes de ce guide. Par exemple, si vous voulez simplement supprimer rdate proprement, vous vous contenterez de créer l'image officielle puis de configurer les options de busybox et de compiler le tout.

Recréer l'image officielle

Si j'ai un conseil à vous donner, progressez à petits pas vers la création de votre image personnalisée : compilez une image de base, puis intégrez vos packages et compilez, puis effectuez leur configuration et compilez encore, puis ... Il est inutile de tout faire d'un coup : si la compilation foire (et elle le fera, faites-moi confiance), vous galérerez pour trouver l'origine du bug. Dans la continuité de ce conseil, je vous conseille également de sauvegarder l'intégralité du buildroot après une compilation réussie. Ainsi, si la prochaine compilation plante et que vous ne trouvez pas l'origine du bug, vous pourrez toujours reprendre depuis votre sauvegarde plutôt que de tout recommencer depuis le début.

En suivant ce conseil, notre premier objectif sera de parvenir à la compilation de l'image officielle. Traduction : l'image que vous allez compiler, c'est celle qui est disponible en téléchargement sur le site officiel d'OpenWRT (ex. : openwrt-wrt54g-squashfs.bin). Cela n'a pas d'autres intérêts que de se faire la main.

On y va ! 🙂

D'abord, on met à jour la liste des paquets disponibles :

backfire_10.03$ ./scripts/feeds update -a && ./scripts/feeds install -a

Ensuite, on efface les fichiers de configuration de la compilation (créés automatiquement par make menuconfig, nous y reviendrons) :

backfire_10.03$ rm .config && rm .config.old

On récupère le fichier de configuration officiel (ici : déclinaison brcm47xx) et on le met en place :

backfire_10.03$ wget http://downloads.openwrt.org/backfire/10.03/brcm47xx/OpenWrt.config && mv OpenWrt.config .config

Par défaut, tous les packages sont compilés (en module) puis exclus de l'image finale. Pour éviter cette perte de temps lors de la compilation, on va demander à ce que les packages qui ne seront pas intégrés à l'image ne soient pas compilés. Pour cela, on commente les lignes qui finissent par "=m" (module) avec la commande suivante :

backfire_10.03$ sed -i 's,^.*=m,# & is not set,g' ./.config

On lance la compilation :

backfire_10.03$ make

Je vous rappelle qu'en cas de bug, il est possible d'utiliser l'option "V=99" qui permet d'avoir des indices quand à l'origine du plantage. Si vous avez un processeur multicœur, je vous rappelle qu'il est possible d'utiliser l'option "-j <nombre de cœurs + 1> .

Le système va compiler le noyau, busybox et les packages installés par défaut. Vous êtes autorisé à aller vous chercher un café 8) .

Si la compilation réussie (et il n'y a pas de raisons pour qu'elle ne réussisse pas), vous trouverez les images, au format squashfs, dans le dossier ./bin/brcm47xx .

Félicitation, vous venez de créer votre propre image pour votre routeur ! Elle doit avoir une taille équivalente à celle que l'on peut télécharger sur le site officiel. Vous pouvez essayer votre image sur votre routeur mais ce n'est vraiment pas la peine voire une mauvaise idée : la mémoire étant de la flash, elle est plus limitée qu'un disque dur en terme de nombre de cycles d'écriture possibles malgré les algorithmes de lissage de l'usure. Essayer une image qui n'a aucun intérêt use le matériel plus qu'autre chose.

Nous allons maintenant créer une image personnalisée.

Créer une image vraiment personnelle

Comme fil rouge, je vous propose de créer une image personnalisée contenant (presque) toutes les manipulations que je vous ai présentées sur ce blog : un résolveur DNS, un serveur NTP, ... Cela vous permettra de vous faire la main et de créer votre image bien à vous par la suite.

Si vous ne comprenez pas la raison d'être d'une modification ou si vous voulez plus d’explications, reportez-vous au billet qui traite de la modification en question. Ils sont tous dans la catégorie "OpenWRT".

Modifier les options du noyau Linux

Si vous voulez consulter et/ou modifier les options du noyau, utilisez la commande :

backfire_10.03$ make kernel_menuconfig

Une interface semi-graphique s'affichera au bout de quelques instants. Les options actuelles me convenant, je n'ai rien modifié. Mais il est toujours intéressant et instructif de regarder ce qui est déjà fait.

C'est également dans ce menu que vous pouvez, par exemple, activer le support du contrôle par groupe des processus, activez le support de systèmes de fichiers supplémentaires ou bien encore saisir un nom personnalisé pour votre noyau (la classe 8) pour frimer devant les copains).

Si vous faites des modifications, mettez "Exit" (bouton droit de la souris pour y accéder) et répondez "Yes" à la question de la sauvegarde de vos paramètres.

Ajouter/Supprimer des packages

Rien de plus facile : il suffit d'utiliser la commande :

backfire_10.03$ make menuconfig

Dans l'interface semi-graphique qui s'affiche, vous pouvez ajouter ou supprimer des packages.

Si vous n'avez pas un usage spécifique, vous pouvez désactiver la génération du SDK et de l'Image Builder. Vous gagnerez ainsi du temps à la compilation.

Pour notre part, nous activerons :

  • etherwake dans Network.
  • tcpdump-mini dans Network.
  • djbdns.-dnscache dans Network -> IP adresses and Names.
  • ddns-scripts dans Network -> IP adresses and Names.
  • ntpd dans Network -> Time Synchronization.
  • iptables-mod-conntrack-extra dans Network -> Iptables.
  • luci-i18n-french dans LuCi -> Translations.

C'est également le moment de décocher les logiciels que vous ne voulez pas afin qu'ils ne soient pas intégrés à l'image.Pour notre part, nous supprimerons les packages suivants :

  • ppp dans Network.
  • ppp-mod-pppoe dans Network.
  • kmod-ppp dans Kernel Modules -> Network support.
  • kmod-pppoe dans Kernel Modules -> Network support.

Pour sauvegarder vos paramètres, mettez "Exit" (bouton droit de la souris pour y accéder) et répondez "Yes" à la question de la sauvegarde de vos paramètres.

À moins que vous ne teniez à désactiver tous les autres composants qui vont être compilés en modules mais pas intégrés à l'image à la main, utilisez la commande que nous avons déjà vu :

backfire_10.03$ sed -i 's,^.*=m,# & is not set,g' ./.config

Ces deux étapes (sauvegarde des paramètres et désactivations des modules) sont à faire avant chaque compilation si vous avez modifié quelque chose dans l’interface semi-graphique.

Vous pouvez compilez avec make. N'oubliez pas de faire un make clean avant ! Je ne vous le rappellerai plus à partir de maintenant, il faudra donc y penser !

Deuxième pause café ! 😀

Vous devriez obtenir une image d'une taille de 3Mo/3.1Mo environ . Il est encore inutile de tenter de l'installer sur votre routeur pour les raisons déjà évoquées ci-dessus.

Ajouter votre package personnel / vos modifications aux sources

Si vous avez créé/porté un logiciel pour OpenWRT, c'est le moment de le mettre en place dans l'arborescence avec son makefile et tout et tout. Je vous regarde faire 😉 .

Ensuite, vous n'avez plus qu'à le sélectionner dans l’interface semi-graphique de configuration.

C'est également le moment de faire les modifications que vous voulez dans les sources. Par exemple, dans un billet, je vous avais montré comment optimiser la sécurité de dropbear et l'espace qu'il occupe dans la flash. C'est le moment d'appliquer ces modifications si vous le désirez. Je vous laisse aller les chercher dans l'article d'origine : OpenWRT : sécuriser l’accès SSH - Compiler dropbear pour n’autoriser que 3 essais de mot de passe par connexion.

Vous pouvez compiler et fabriquer l'image. Là encore, il me paraît inutile de l'essayer. Si vous voulez juste tester la compilation d'un package personnel, vous pouvez compiler uniquement ce package avec la commande :

backfire_10.03$ make package/dropbear/compile

Modifiez les options de busybox

Busybox est très personnalisable. Sa configuration se fait encore via le menu obtenu via la commande :

backfire_10.03$ make menuconfig

Pour cela, il suffit d'aller dans Base system -> Busybox -> Configuration. Enjoy !

Dans le cadre de ce tutoriel, nous allons :

  • Désactiver "rdate" dans Linux System Utilities.
  • Activer "history saving" dans Busybox Settings -> Busybox Library Tuning. Cela permet de sauvegarder l'historique des commandes saisies par chaque utilisateur entre deux connexions. Cela peut être utile.

À vous de continuer à personnaliser votre installation. Vous pouvez compiler mais je ne pense pas que cela soit nécessaire vu le peu de modifications que nous avons apportées.

Modifier des options générales

En dehors de Busybox, il reste encore plein d'options à explorer.

Dans le cadre de notre fil rouge, nous allons commencer par changer la langue par défaut de LuCi. Pour cela, cochez "Image configuration", appuyez sur Entrée et cochez "Preinit configuration option". Dans "Default Language", tapez "fr" et validez.

Maintenant, nous allons supprimer luci-admin-mini. Nous ne pouvons pas le faire depuis le menu de configuration car d'autres packages dépendent de lui. Nous allons forcer sa désinstallation en éditant directement le fichier .config, chose qu'il faut éviter de faire au maximum.

backfire_10.03$ vi .config

Cherchez la ligne suivante :

CONFIG_PACKAGE_luci-admin-mini=y

et commentez-là :

# CONFIG_PACKAGE_luci-admin-mini=y is not set

Appliquons le même raisonnement pour le package "luci-i18n-english".

Enregistrer vos modifications et quittez vi.

Libre à vous d'explorer les autres options.

Vous pouvez compiler l'image. Et si vous le souhaitez, vous pouvez même installer cette image sur votre routeur.

Note : Oui, j'ai lu la première ligne du fichier .config qui dit de ne pas le modifier à la main. Mais, n'ayant pas trouvé les packages qui dépendent de luci-admin-mini et de luci-i18n-english, je n'ai pas vraiment le choix. De plus, ce conseil est donné dans le cas où vous activez un logiciel sans activer ses dépendances (ex. : activer djbdns-dnscache sans activer djbdns-base). Autrement dit : si vous connaissez les dépendances d'un package que vous voulez installer, vous pouvez modifier le .config à la main sans problèmes.

Configurer les logiciels

Logiciels configurables avec uci

Il suffit de créer des scripts. Ces scripts seront placés dans un dossier files/etc/uci-defaults à la racine du buildroot. Tous les scripts se trouvant dans ce dossier seront exécutés une seule fois après le flashage du routeur quelque soit leur nom. Voici, à titre d'exemple, les scripts destinés à configurer les logiciels que nous avons installés ci-dessus :

backfire_10.03/files/etc/uci-defaults/ddns (pour ddns-scripts et DynDNS) :

#!/bin/sh
 
# DDNS parametres
uci set ddns.myddns.enabled=1 2>/dev/null
uci set ddns.myddns.interface=wan 2>/dev/null
uci set ddns.myddns.service_name=dyndns.org 2>/dev/null
uci set ddns.myddns.domain=<votre ndd> 2>/dev/null
uci set ddns.myddns.username=<votre login sur dynDNS> 2>/dev/null
uci set ddns.myddns.ip_source=network 2>/dev/null
uci set ddns.myddns.ip_network=wan 2>/dev/null
uci set ddns.myddns.force_interval=24 2>/dev/null
uci set ddns.myddns.force_unit=hours 2>/dev/null
uci set ddns.myddns.check_interval=10 2>/dev/null
uci set ddns.myddns.check_unit=minutes 2>/dev/null

 
# On valide tout
uci commit 2>/dev/null

Vous pouvez également marquer en dur votre mot de passe (uci set ddns.myddns.password=XXXX 2>/dev/null), mais je ne vous le conseille pas. Même si votre compte DynDNS n'est pas le compte le plus précieux que vous ayez, ce n'est pas une bonne pratique.

Dans la même veine, la bonne pratique voudrait que vous mettiez votre IP à jour sur DynDNS en utilisant le protocole HTTPS. C'est possible, voir le wiki d'OpenWRT à ce sujet mais les libs prennent beaucoup de place et je n'ai pas assez d'espace pour les accueillir.

Si vous êtes derrière une box ou qu'autre chose fait que l'interface wan (eth0.1) n'a pas une ip publique, il vous faudra utiliser un service externe pour récupérer votre ip publique et remplacer ces deux lignes :

uci set ddns.myddns.ip_source=network 2>/dev/null
uci set ddns.myddns.ip_network=wan 2>/dev/null

par

uci set ddns.myddns.ip_source=web 2>/dev/null
uci set ddns.myddns.ip_url=http://automation.whatismyip.com/n09230945.asp 2>/dev/null

backfire_10.03/files/etc/uci-defaults/dnscache (pour djbdns-dnscache) :

#!/bin/sh
 
# On configure dnscache
uci set djbdns.@dnscache[0].interface=lan 2>/dev/null
uci set djbdns.@dnscache[0].defaultallowif=lan 2>/dev/null
uci set djbdns.@dnscache[0].forwardonly=0 2>/dev/null

 
# On valide tout
uci commit 2>/dev/null
 
# On met les bonnes autorisations sur le script d'init de dnscache
chmod ugo+x /etc/init.d/dnscache 2>/dev/null

 
# dnscache est déjà pris en compte par hotplugd, il n'a pas besoin d'init pour 
# se lancer
rm -f /etc/rc.d/S65dnscache 2>/dev/null

ATTENTION : dnscache est pris en charge par hotplugd uniquement si votre interface wan est configurée avec DHCP. Dans le cas d'une IP statique sur l'interface wan et d'après mes tests, hotplugd n'agit pas et init est nécessaire. Si vous êtes dans ce cas, ne supprimez pas le script d'init.

backfire_10.03/files/etc/uci-defaults/dnsmasq (pour dnsmasq) :

#!/bin/sh
 
# On désactive la fonctionnalité forward DNS de dnsmasq
uci set dhcp.@dnsmasq[0].port=0 2>/dev/null

 
 
# On valide tout
uci commit 2>/dev/null
 
# On met les bonnes autorisations sur le script d'init de dnsmasq
chmod ugo+x /etc/init.d/dnsmasq 2>/dev/null

backfire_10.03/files/etc/uci-defaults/dropbear (pour dropbear) :

#!/bin/sh
 
# On désactive l'authentification par mot de passe
uci set dropbear.@dropbear[0].PasswordAuth=off 2>/dev/null

 
# On valide tout
uci commit 2>/dev/null

backfire_10.03/files/etc/uci-defaults/firewall (pour configurer, un peu, netfilter) :
L'idée, c'est de définir, intégralement, nos propres règles, de A à z. Or, des règles sont chargées à chaque reboot du routeur à partir du fichier /etc/config/firewall. Plusieurs méthodes s'offrent, comme d'habitude, à vous : soit vous éditez /etc/config/firewall qui est dans un format classique d'uCi pour y intégrer vos règles. Soit vous supprimez ce fichier de l'image et vous définisez, dans un script d'init, les règles de filtrage qu'il convient d'appliquer. Ayant déjà un script standard qui charge mes règles de filtrage qui est pas trop mauvais, j'ai choisi cette deuxième solution. backfire_10.03/files/etc/uci-defaults/firewall contient donc :

#!/bin/sh

 
# On supprime les regles par defaut stockees dans uci
rm -rf /etc/config/firewall 2>/dev/null

 
# On met les bonnes autorisations sur le script d'init du firewall
chmod ugo+x /etc/init.d/firewall 2>/dev/null

backfire_10.03/files/etc/uci-defaults/ntpd (pour configurer, un peu, ntpd) :

#!/bin/sh
 
# ntpd est deja lance par hotplug.d, nous n'avons pas besoin qu'il soit lance par init
rm -f /etc/rc.d/S65ntpd 2>/dev/null

ATTENTION : ntpd est pris en charge par hotplugd uniquement si votre interface wan est configurée avec DHCP. Dans le cas d'une IP statique sur l'interface wan et d'après mes tests, hotplugd n'agit pas et init est nécessaire. Si vous êtes dans ce cas, ne supprimez pas le script d'init de ntpd.

backfire_10.03/files/etc/uci-defaults/system (pour configurer les options générales du système) :

#!/bin/sh
 
# Nom du routeur
uci set system.@system[0].hostname="Nouveau_Nom" 2>/dev/null

echo "Nouveau_Nom" > /proc/sys/kernel/hostname 2>/dev/null

 
# Fuseau horaire
uci set system.@system[0].zonename=Europe/Paris 2>/dev/null
uci set system.@system[0].timezone=CET-1CEST,M3.5.0,M10.5.0/3 2>/dev/null

 
# On finit de supprimer rdate
uci del system.@rdate[0] 2>/dev/null
rm -f /etc/hotplug.d/iface/40-rdate 2>/dev/null

 
# On valide tout
uci commit 2>/dev/null

backfire_10.03/files/etc/uci-defaults/network (pour configurer les interfaces réseau) :

#!/bin/sh
 

# Configuration interface LAN
uci set network.lan.proto=static
uci set network.lan.netmask=255.255.255.0
uci set network.lan.ipaddr=192.168.0.254
uci set network.lan.dns=192.168.0.254 #dnscache

 
# Configuration interface WAN
uci set network.wan.proto=static
uci set network.wan.ipaddr=192.168.1.253
uci set network.wan.netmask=255.255.255.0
uci set network.wan.gateway=192.168.1.254
uci set network.wan.dns=192.168.0.254 #dnscache

 
# On valide tout
uci commit 2>/dev/null

Je pense que les interfaces peuvent également être configurées depuis le .config puisqu'on peut y lire les lignes suivantes :

CONFIG_UCI_PRECONFIG_network_lan_dns=""

CONFIG_UCI_PRECONFIG_network_lan_proto="static"
CONFIG_UCI_PRECONFIG_network_lan_gateway=""
CONFIG_UCI_PRECONFIG_network_lan_netmask="255.255.255.0"
CONFIG_UCI_PRECONFIG_network_lan_ipaddr="192.168.1.1"

Mon test a échoué mais je pense que cela est dû à un autre paramètre que j'ai activé en même temps.

On peut même configurer l'adresse que prend le bootloader :

CONFIG_TARGET_PREINIT_IFNAME=""
CONFIG_TARGET_PREINIT_IP="192.168.1.1"
CONFIG_TARGET_PREINIT_NETMASK="255.255.255.0"
CONFIG_TARGET_PREINIT_BROADCAST="192.168.1.255"

Vu le nombre de fois où ce bootloader et son serveur TFTP m'ont sauvés la mise, je n'ai pas essayé de changer ces paramètres.

Vous avez compris le principe et vous pouvez créer vos propres scripts pour les logiciels que vous avez installés ou modifier les scripts ci-dessous afin de configurer plus finement certains logiciels (dnsmasq par exemple).

Logiciels ne pouvant pas être configurés avec uci

Il y a des logiciels qui possèdent leurs propres fichiers de configuration. Pour eux, il suffit de placer les fichiers dans l'arborescence, comme si vous étiez sur votre routeur. Par exemple, si à la fin du flashage, vous avez besoin qu'un fichier /etc/xxxx soit créez, alors placez-le dans backfire_10.03/files/etc/xxxx et il sera mis au bon endroit. Si le fichier existe déjà car il est fourni par un logiciel, par exemple, il sera écrasé par votre version.

Il y a une autre manière de procéder : mettre le fichier dans le package qui lui correspond. Exemple : vous avez un fichier de configuration pour ntpd (/etc/ntp.conf), alors vous le mettez dans feeds/packages/net/ntpd/files/etc/ntp.conf. Pour les packages par défaut (dropbear par exemple), le chemin est différent : packages/dropbear ...

Personnellement, j'ai choisi de tout mettre dans un même dossier car cela simplifie la maintenance.

Voici donc les fichiers que j'ai rajoutés.

backfire_10.03/files/etc/banner (le message de bienvenue lors d'une connexion SSH) :

Salut !

backfire_10.03/files/etc/ntp.conf (configuration de ntpd) :

server ntp-p1.obspm.fr iburst prefer
server canon.inria.fr iburst
 
restrict default ignore
restrict ntp-p1.obspm.fr mask 255.255.255.255 nomodify notrap nopeer noquery
restrict canon.inria.fr mask 255.255.255.255 nomodify notrap nopeer noquery
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
restrict 127.0.0.1
 
driftfile  /etc/ntp.drift

backfire_10.03/files/etc/services (nécessaire au bon fonctionnement de ntpd) :
Sans lui, vous aurez des messages d'erreur du genre "getaddrinfo: "ntp-p1.obspm.fr" invalid host address, ignored", "restrict: error in address 'ntp-p1.obspm.fr' on line 6. Ignoring...", "Deferring DNS for ntp-p1.obspm.fr 1" et "getaddrinfo(127.0.0.1) failed: Servname not supported for ai_socktype".

ntp             123/udp     # Network Time Protocol
ntp             123/tcp     # Network Time Protocol

backfire_10.03/files/etc/passwd (permet de rajouter des comptes utilisateur sans droits d'administration (ici : guest)) :

root:*:0:0:root:/root:/bin/ash
guest:*:65533:65533:guest:/home/guest:/bin/ash
nobody:*:65534:65534:nobody:/var:/bin/false
daemon:*:65534:65534:daemon:/var:/bin/false

backfire_10.03/files/etc/group (permet de rajouter des groupes utilisateurs destinés à accueillir les comptes standards) :

root:x:0:
guestg:x:65533:
nogroup:x:65534:

Authentification par clé publique/privée :

Mettez la clé publique de root dans backfire_10.03/files/etc/dropbear/authorized_keys si vous voulez utiliser l'authentification à clé publique pour vous connecter avec le compte root via SSH.

Pour chaque compte utilisateur créé, mettez sa clé publique dans un fichier ".ssh/authorized_keys" placé dans son home directory. Par exemple, pour le compte guest créé ci-dessous, la clé publique devra se trouver dans backfire_10.03/files/home/guest/.ssh/authorized_keys .

Si vous voulez utiliser l'authentification par clé publique pour vos comptes sans droits, ne changez surtout pas le propriétaire de leurs home directory (pas de chown -R guest:guestp /home/guest dans un script dans l'image). En effet, pour une raison qui m'échappe, l'authentification échoue sinon. Mais, dans ce cas-là, l'utilisateur n'est pas vraiment chez lui : il ne peut pas créer un répertoire par exemple. Heureusement, vous pouvez changer le proprietaire du home directory de chacun de vos comptes utilisateurs après le flashage et aucun problème n'apparait.

backfire_10.03/files/etc/hotplug.d/iface/15-dnsd (script permettant de relancer dnscache en cas de coupure de l'accès au net) :

#!/bin/sh
 
if [ "$INTERFACE" = "wan" ] 

then
	DNS_RUNNING=`ps  | grep dnscache | grep -v grep`

 
	case "${ACTION:-ifup}" in
        	ifup)
                	[ -z "$DNS_RUNNING" ] && /etc/init.d/dnscache start
       		;;

 
		ifdown)
               		[ -n "$DNS_RUNNING" ] && /etc/init.d/dnscache stop
        	;;

	esac
fi

ATTENTION : Il semble que ce script est inutile si vous êtes en IP statique sur l'interface WAN.

backfire_10.03/files/etc/init.d/dnscache (script d'init pour dnscache modifié pour logger les démarrages/arrêts du démon) :
ATTENTION : Le script n'est pas donné ici dans son intégralité. Attention donc aux copier/coller malheureux.

#!/bin/sh /etc/rc.common
# Copyright (C) 2007 OpenWrt.org
 
[...]
 
start() {
    echo "Starting $DESC: $NAME"

    logger starting dnscache
    config_load djbdns
    config_foreach get_userids global
    mkdir -p $ROOT
    cp -fa /etc/dnscache/* $ROOT

    rm -f $ROOT/resolvers
    rm -f $ROOT/ignoreip
    chown -R $UID:$GID $ROOT

    config_foreach start_dnscache dnscache
}
 
[...]
 
stop() {
    echo -n "Stopping $DESC: $NAME"

    logger stopping dnscache
    kill `pidof $NAME|sed "s/$$//g"` > /dev/null 2>&1

    echo " ."
}
 
restart() {
    echo "Restarting $DESC: $NAME... "

    stop
    sleep 2
    start
}

backfire_10.03/files/etc/init.d/dnsmasq (script d'init pour dnsmasq modifié afin d'indiquer uniquement notre résolveur DNS local) :
ATTENTION : Le script n'est pas donné ici dans son intégralité. Attention donc aux copier/coller malheureux.

#!/bin/sh /etc/rc.common
# Copyright (C) 2007 OpenWrt.org
 
START=60
DNS_SERVERS=""
DOMAIN=""
 
[...]
 
start() {
        include /lib/network
        scan_interfaces
        config_load dhcp
 
        args=""
        config_foreach dnsmasq dnsmasq
        config_foreach dhcp_host_add host
        config_foreach dhcp_boot_add boot
        config_foreach dhcp_mac_add mac
        config_foreach dhcp_vendorclass_add vendorclass
        config_foreach dhcp_userclass_add userclass
        config_foreach dhcp_circuitid_add circuitid
        config_foreach dhcp_remoteid_add remoteid
        config_foreach dhcp_subscrid_add subscrid
        config_foreach dhcp_domain_add domain
        config_foreach dhcp_add dhcp
 

        /usr/sbin/dnsmasq $args && {
                rm -f /tmp/resolv.conf
                [ -n "$DOMAIN" ] && echo "search $DOMAIN" >> /tmp/resolv.conf
                DNS_SERVERS="192.168.1.1" #A REMPLACER SI VOTRE ROUTEUR A UNE IP LAN DIFFERENTE !
                for DNS_SERVER in $DNS_SERVERS ; do
                        echo "nameserver $DNS_SERVER" >> /tmp/resolv.conf
                done
        }
}

 
stop() {
        [ -f /tmp/resolv.conf ] && {
                rm -f /tmp/resolv.conf
                ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
        }
        killall dnsmasq
        return 0
}

backfire_10.03/files/etc/init.d/firewall (pour configurer, un peu plus, netfilter) :
À adapter à vos besoins et à complèter car il manque encore des choses (séparation tcp, udp, icmp et filtrage différentié, éviter d'autoriser des connexions sur le simple fait qu'elles sont établies mais préciser le port source, ...)

#!/bin/sh /etc/rc.common
 
START=45

 
start() {
	#On fait le menage
	stop
 
	############### TABLE FILTER
	##On créer les chaînes correspondant à nos zones
	iptables -t filter -N lan-lan
	iptables -t filter -N lan-bas
	iptables -t filter -N lan-wan

 
	iptables -t filter -N bas-lan
	iptables -t filter -N bas-bas
	iptables -t filter -N bas-wan

 
	iptables -t filter -N wan-lan
	iptables -t filter -N wan-bas
	iptables -t filter -N wan-wan

 
	##On redirige les paquets vers nos chaines
	iptables -t filter -A INPUT -i br-lan -j lan-bas
	iptables -t filter -A INPUT -i lo -j bas-bas
	iptables -t filter -A INPUT -i eth0.1 -j wan-bas

 
	iptables -t filter -A FORWARD -i br-lan -o br-lan -j lan-lan
	iptables -t filter -A FORWARD -i br-lan -o eth0.1 -j lan-wan 
	iptables -t filter -A FORWARD -i eth0.1 -o eth0.1 -j wan-wan
	iptables -t filter -A FORWARD -i eth0.1 -o br-lan -j wan-lan

 
	iptables -t filter -A OUTPUT -o br-lan -j bas-lan
	iptables -t filter -A OUTPUT -o lo -j bas-bas
	iptables -t filter -A OUTPUT -o eth0.1 -j bas-wan

 
	##On traite nos chaines
	#Du lan vers le routeur d'abord
	#Etablies/relatives
	iptables -t filter -A lan-bas -m state --state RELATED,ESTABLISHED -j ACCEPT
	#SSH

	iptables -t filter -A lan-bas -s 192.168.0.0/24 -d 192.168.0.254/32 -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT 
	#DNS

	iptables -t filter -A lan-bas -s 192.168.0.0/24 -d 192.168.0.254/32 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
	iptables -t filter -A lan-bas -s 192.168.0.0/24 -d 192.168.0.254/32 -p tcp -m state --state NEW -m tcp --dport 53 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#DHCP

	iptables -t filter -A lan-bas -p udp -m state --state NEW -m udp --sport 68 --dport 67 -j ACCEPT
	#HTTP

	iptables -t filter -A lan-bas -s 192.168.0.0/24 -d 192.168.0.254/32 -p tcp -m state --state NEW -m tcp --dport 80 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#NTP

	iptables -t filter -A lan-bas -s 192.168.0.0/24 -d 192.168.0.254/32 -p udp -m state --state NEW -m udp --dport 123 -j ACCEPT
	#ICMP (echo request)

	iptables -t filter -A lan-bas -s 192.168.0.0/24 -d 192.168.0.254/3 -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT

 
	#Du lan vers internet ensuite
	#Etablies/relatives
	iptables -t filter -A lan-wan -m state --state RELATED,ESTABLISHED -j ACCEPT
	#FTP

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#SSH

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#HTTP/HTTPS

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 80 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 443 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#SMTPS/SMTP auth

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 465 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 587 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#POP3S

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 995 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#SVN

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 3690 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p udp -m state --state NEW -m udp --dport 3690 -j ACCEPT
	#IRC

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 6667 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 6697 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#Plesk

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 8443 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#Git

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 9418 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p udp -m state --state NEW -m udp --dport 9418 -j ACCEPT
	#ICMP (echo request)

	iptables -t filter -A lan-wan -s 192.168.0.0/24 -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT

 
	#Du routeur vers le lan
	#Etablies/relatives
	iptables -t filter -A bas-lan -m state --state RELATED,ESTABLISHED -j ACCEPT 
	#DHCP

	iptables -t filter -A bas-lan -p udp -m state --state NEW -m udp --sport 67 --dport 68 -j ACCEPT

 
	#Boucle locale
	iptables -t filter -A bas-bas -j ACCEPT
 
	#Du routeur vers internet

	#Etablies/relatives
	iptables -t filter -A bas-wan -m state --state RELATED,ESTABLISHED -j ACCEPT
	#FTP dans tunnel SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#DNS

	iptables -t filter -A bas-wan -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 53 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#HTTP/HTTPS pour opkg/HTTP dans tunnel SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 80 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 443 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#NTP

	iptables -t filter -A bas-wan -p udp -m state --state NEW -m udp --dport 123 -j ACCEPT
	#SMTPS/SMTP auth pour tunnel SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 465 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 587 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#POP3S dans tunnel SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 995 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#SVN

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 3690 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A bas-wan -p udp -m state --state NEW -m udp --dport 3690 -j ACCEPT
	#IRC dans tunnel SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 6667 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 6697 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#Plesk pour tunnel SSH

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 8443 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	#Git

	iptables -t filter -A bas-wan -p tcp -m state --state NEW -m tcp --dport 9418 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	iptables -t filter -A bas-wan -p udp -m state --state NEW -m udp --dport 9418 -j ACCEPT
	#ICMP (echo request)

	iptables -t filter -A bas-wan -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT

 
	#D'internet vers le lan
	#Etablies/relatives
	iptables -t filter -A wan-lan -m state --state RELATED,ESTABLISHED -j ACCEPT

 
	#D'internet vers le routeur enfin
	#Etablies/relatives
	iptables -t filter -A wan-bas -m state --state RELATED,ESTABLISHED -j ACCEPT
	#SSH

	iptables -t filter -A wan-bas -p tcp --dport 22 -m state --state NEW -m recent --name ATTACKER_SSH --rsource --update --seconds 600 --hitcount 2 -j DROP
	iptables -t filter -A wan-bas -p tcp --dport 22 -m state --state NEW -m recent --name ATTACKER_SSH --rsource --set

	iptables -t filter -A wan-bas -p tcp --dport 22 -m state --state NEW -j ACCEPT

 
	##On change les politiques d'accés
	iptables -t filter -P INPUT DROP
	iptables -t filter -P FORWARD DROP
	iptables -t filter -P OUTPUT DROP

 
 
	##############TABLE NAT
	##On créer des chaines qui correspondent à nos zones
	iptables -t nat -N prerouting-lan
	iptables -t nat -N prerouting-wan

 
	iptables -t nat -N postrouting-lan
	iptables -t nat -N postrouting-wan
 
	##On redirige les paquets dans nos chaines

	#C'est ici que l'on peut rediriger des ports (ex. : proxy transparent, on redirige port 80/443 -> 8080)
	iptables -t nat -A PREROUTING -i br-lan -j prerouting-lan

 
	#C'est ici que l'on fait le DNAT (ex. : monter un serveur web sur le LAN, accessible sur internet)
	iptables -t nat -A PREROUTING -i eth0.1 -j prerouting-wan

 
	iptables -t nat -A POSTROUTING -o br-lan -j postrouting-lan
 
	#C'est ici que l'on fait le SNAT ou MASQUERADE si ip dynamique

	iptables -t nat -A POSTROUTING -o eth0.1 -j postrouting-wan
 
	##On traite nos chaines

	##SNAT/masquerade
	iptables -t nat -A postrouting-wan -s 192.168.0.0/24 -j MASQUERADE

 
	##DNAT
	# Torrent
	#iptables -t nat -A prerouting-wan -p tcp -m tcp --dport 4444 -j DNAT --to-destination 192.168.1.138:4444
	#iptables -t nat -A prerouting-wan -p udp -m udp --dport 4444 -j DNAT --to-destination 192.168.1.138:4444
 
	##############TABLE MANGLE

	##Cette table sert pour la modification des paquets (ex:. marquer les paquets pour faire de la QoS ensuite)
	##Nous verrons cela plus tard
 
 
	##############TABLE RAW
	##Cette table sert à indiquer les connections qui ne doivent pas être suivies par conntrack
 
	echo "Firewall started"

	logger Firewall started
}
 
stop() {
	############### TABLE FILTER
	##On change les politiques d'accés
	iptables -t filter -P INPUT ACCEPT
	iptables -t filter -P FORWARD ACCEPT
	iptables -t filter -P OUTPUT ACCEPT

 
	##On fait le menage
	iptables -t filter -F
	iptables -t filter -X

 
 
	##############TABLE NAT
	##On change les politiques d'accés
	iptables -t nat -P PREROUTING ACCEPT

	iptables -t nat -P OUTPUT ACCEPT
	iptables -t nat -P POSTROUTING ACCEPT
 
	##On fait le menage

	iptables -t nat -F
	iptables -t nat -X
 
	#NAT

	iptables -t nat -A POSTROUTING -o eth0.1 -s 192.168.0.0/24 -j MASQUERADE

 
 
	##############TABLE MANGLE
	##On change les politiques d'accés
	iptables -t mangle -P PREROUTING ACCEPT
	iptables -t mangle -P INPUT ACCEPT
	iptables -t mangle -P FORWARD ACCEPT
	iptables -t mangle -P OUTPUT ACCEPT
	iptables -t mangle -P POSTROUTING ACCEPT

 
	##On fait le menage
	iptables -t mangle -F
	iptables -t mangle -X

 
 
	##############TABLE RAW
	##On change les politiques d'accés
	iptables -t raw -P PREROUTING ACCEPT
	iptables -t raw -P OUTPUT ACCEPT

 
	##On fait le menage
	iptables -t raw -F
	iptables -t raw -X

 
	echo "Rules cleaned and firewall stopped"
	logger Rules cleaned and firewall stopped
}
 
restart() {
	start
 
	echo "Firewall restarted"

	logger Firewall restarted
}
 
reload() {
	start
 
	echo "Firewall reloaded"
	logger Firewall reloaded

}

À vous de continuer la configuration de votre système (ex. : VLAN). La méthode exposée ci-dessus fonctionne pour tous les fichiers.

Vous pouvez compiler puis essayer l'image ainsi générée. Tous vos logiciels doivent être configurés.

Si jamais vous avez une erreur durant la compilation

La liste ci-dessous est loin d'être exhaustive.

  • N'avez-vous pas oublié de faire un make clean avant de compiler ? Faites-le et relancez la compilation en faisant un make clean au préalable.
  • N'avez-vous pas oublié de faire un sed après avoir modifié une option avec make menuconfig ? Faites-le et relancez la compilation en faisant un make clean au préalable.
  • Lancez la compilation avec le paramètre V=99, lisez le message d'erreur. C'est parfois tout bête (espace disque manquant (sisi ...), mauvaise saisie dans un makefile, ...).

Si rien n'améliore la situation, supprimez vos modifications récentes (d'où l'intérêt d'avoir fait des sauvegardes du buildroot à chaque étape concluante) et retenter la compilation sans oublier de faire un make clean. Si jamais quelque chose qui compilait avant ne compile plus, redémarrez votre ordinateur (sisi, ça arrive, même sous UNIX ...).

Ce qui vous reste à faire après le flashage

Le serveur SSH est fonctionnel et telnetd est déjà désactivé. Il est nécessaire d'attendre un peu pendant que dropbear génère la paire de clé du serveur. Durant ce laps de temps, le serveur rejette les tentatives de connexions sur le port SSH.

Changez le mot de passe de root, même si vous utilisez une authentification par clé publique avec la commande passwd.

Changez le mot de passe de chacun des comptes utilisateurs sans droits avec passwd <login> .

Définissez le mot de passe pour le DDNS avec la commande : uci set ddns.myddns.password=XXXX

Modifiez le proprietaire du home directory de chacun de vos comptes utilisateurs sans droits : chown -R login:groupe home_directory

Profit !

Sources

P.S. : Oui, j'ai remarqué les bugs de mon hébergeur (site inaccessible, billet qui disparait (ou plutôt base de données qui perd des données ...)). Ça devrait aller mieux ... peut-être 😀 .

Installer un serveur NTP sur OpenWRT

Table des matières

Pourquoi ?

Vous avez peut-être lu mon billet sur comment utiliser un client NTP sous OpenWRT et vous vous demandez peut-être pourquoi je décide maintenant d'utiliser un serveur.

Tout simplement car je me suis aperçu que j'avais fait une erreur lors de mon choix d'utiliser seulement un client NTP.

En effet, comment vais-je synchroniser les autres machines de mon réseau ? Comme avant, en utilisant un serveur externe ? Avouez que cela fait beaucoup de requêtes, ce qui encombre inutilement ma bande passante comme la bande passante du serveur externe. De plus, si la connexion au net tombe, un serveur local permettra de conserver le même temps (qui perdra en précision, certes) sur toutes les machines du LAN.

De plus, un serveur NTP permet une plus grande précision (certains se demanderont si on a besoin d'une telle précision ... à chacun de juger). À titre d'exemple : selon la documentation officielle, ntpclient utilise le premier serveur qu'il peut joindre parmi ceux que vous lui avez spécifiés. NTPd utilise des algorithmes plus complexes pour déterminer le meilleur serveur de temps de la liste.

Il doit surement y avoir d'autres arguments en faveur d'un serveur NTP mais je pense que je vous ai donné les principaux

Quel serveur choisir ?

root@OpenWrt:~# opkg list | grep -i NTP
chrony - 1.23-3 - A NTP implementation that has been specifically written to work
 connection to the network where your NTP servers are.
[...]
ntpd - 4.2.6-4 - The ISC ntp suite is a collection of tools used to synchronize
 the system clock with remote NTP time servers and run/montior
 local NTP servers.
 This package contains the ntpd server.
[...]
openntpd - 3.9p1-3 - A free and easy to use NTP (Network Time Protocol) implementation.

OpenWRT donne le choix entre trois implémentations du protocole NTP :

  • ntpd de ntp.org, le démon de référence maintenu par l'ISC.
  • openntpd, un démon maintenu par le projet OpenBSD.
  • chronyd, un démon NTP à préférer en cas de connexion instable au réseau.

Ma connexion est relativement stable donc chrony n'est pas fait pour moi. Le choix entre openntpd ou ntpd dépend de vos préférences ... Openntpd est sous licence BSD, ntpd est sous licence ISC. Openntpd est une implémentation allégée avec une configuration plus simple (je n'ai pas dit "simpliste" !) du protocole NTP mais le fait qu'il soit développé par l’équipe du projet OpenBSD est un gage de sécurité supplémentaire (openntpd tourne sous un compte sans droits par exemple). ntpd propose une configuration plus touffue (je n'ai pas dis "plus efficace"), un mécanisme d'authentification ainsi que des outils permettant de surveiller le fonctionnement du démon, ce que ne propose pas openntpd. Opennptd propose un système de poids pour choisir la priorité des serveurs NTP à interroger plutôt qu'une simple option "prefer" comme ntpd ... Bref, comme vous le voyez, la décision vous revient, dépend de vos besoins et est très personnelle.

Personnellement, j'ai choisi ntpd, le démon historique pour 2 raisons :

  • Sous OpenWRT, openntpd réclame le support de l'ipv6 (sinon un message "fatal: client_query socket: Address family not supported by protocol" s'affichera lors du lancement. Il faut donc installer le package kmod-ipv6. Je ne souhaite pas avoir le support ipv6 sur mon routeur pour l'instant (tant que mon FAI ne me proposera pas du full ipv6 en fait) et donc m’encombrer d'un package inutile. Source : can't start the NTP daemon (openntpd) sur forum.openwrt.org
  • Openntpd ne permet pas de déplacer le fichier servant à stocker la dérive de l'horloge. Celui-ci se trouve dans /var/db qui est un répertoire tmpfs donc effacé au redémarrage du routeur. Donc le serveur doit recalculer la dérive à chaque redémarrage. Même si ce n'est pas une opération lourde, c'est dommage.

Dans la suite de ce guide, je m’intéresserai donc uniquement à ntpd de ntp.org.

Installation de ntpd

Vous avez l'habitude :

opkg update && opkg install ntpd

Configuration de ntpd

Modification du fichier de configuration

La configuration se fait dans le fichier /etc/ntp.conf (attention, pas de "d" à "ntp" !). Voici le fichier que je vous propose :

## Les serveurs externes qui seront utilisés pour se synchroniser (strate 1 et 1)
server ntp-p1.obspm.fr iburst prefer
server canon.inria.fr iburst
 
## Contrôle des accès
# Par défaut, on ne répond à rien ...
restrict default ignore

# ... exception faite des serveurs externes sur lesquels on va se synchroniser ... 
# (rien ne circule sauf la correction du temps : dans l'ordre, on n'autorise 
# pas la création de hooks pour des journaux à distance, on ne peut pas consulter 
# ou modifier la configuration du serveur, les serveurs ne peuvent pas tenter 
# d'établir une connexion en tant que peer)
restrict ntp-p1.obspm.fr mask 255.255.255.255 nomodify notrap nopeer noquery
restrict canon.inria.fr mask 255.255.255.255 nomodify notrap nopeer noquery

# ... et des stations du réseau local (on peut demander le temps et consulter 
# l'état du serveur, les autres actions sont refusées)
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
 
# ... et en local (on peut tout faire)
restrict 127.0.0.1
## Fin du contrôle des accès
 
# On stocke le décalage de l'horloge système. Cela permet de maintenir, un peu, 
# l'heure en cas de coupures du net. Ne pas placer ce fichier dans un répertoire 
# temporaire : cela évite aussi à ntpd d'avoir à refaire les calculs permettant
# de déterminer la dérive de l'horloge après chaque redémarrage.
driftfile  /etc/ntp.drift

Malgré les commentaires, je souhaite ajouter quelques détails :

  • Pour trouver des serveurs NTP, vous pouvez faire une recherche Google et/ou consulter le site du Comité Réseau des Universités. Veuillez à respecter les conditions d'utilisation (ce n'est pas compliqué à envoyer, un mail). Essayez de choisir des serveurs qui ne sont pas sur le même réseau/FAI afin d'accroître la redondance en cas de problème sur un réseau. Ce point est relativement compliqué vu que beaucoup de serveur sont fournis par l'enseignement supérieur et donc sont sur le réseau RENATER. Ce point n'est pas non plus le point capital : même si tout un réseau venait à tomber (ce qui est déjà rare), votre horloge ne sera pas instantanément déréglée E de plusieurs minutes. Par contre, veuillez à choisir des serveurs qui ne sont pas dépendant l'un de l'autre. Exemple : vous choisissiez d'utiliser S1 et S2, deux serveurs pris au hasard et vous vous rendez compte qu'en fait S2 se synchronise sur S1 ... Pour vérifier cela, utilisez la commande "ntpq -np <ip_du_serveur>" sur chaque serveur que vous souhaitez utiliser.
  • Comme vous pouvez le constater, j'utilise des serveurs de strate 1. On pourra discuter sur les usages qu'un particulier peut faire de ces serveurs et de la précision associée. On pourra également s'interroger sur qui a réellement besoin d'une horloge en strate 2 et de sa grande précision (pourvu que la source soit fiable) : une PME, une institution bancaire, l'armée ?! Bref, je m'arrête là. Bien qu'on recommande habituellement l'usage de serveurs de strate 2 voire 3 pour un particulier, je signale que je ne suis pas le seul à utiliser un serveur de strate 1 : voir à ce sujet l'article "Installation pas à pas de Debian 6.0 (Squezze)" dans GNU/Linux Magazine/France n°139 de juin 2011.
  • L'option iburst permet de répéter les tentatives quand un serveur est inaccessible.
  • L'option prefer permet de marquer un et un seul serveur comme étant ... notre serveur de temps de référence préféré.

ÉDIT 25/08/2011 à 2h15 :
Attention :
De nombreux guides (y compris celui-ci avant cette correction) suggèrent d'utiliser l'horloge locale en insérant les lignes suivantes dans le fichier de configuration :

server 127.127.1.0
fudge 127.127.1.0 stratum 10

Cela permet, en théorie, d'utiliser l'horloge locale afin que le serveur continue à fonctionner dans le cas où les serveurs externes deviendraient inaccessibles. Cela permet également de pouvoir synchroniser les clients alors que le serveur n'est pas encore totalement synchronisé avec les serveurs externes. Et, en effet, cela fonctionne.

Mais sur OpenWRT, lors de chaque reboot, l'horloge revient à l'heure de compilation du noyau. Probablement car il n'y a pas de circuit temporel sur le WRT54GL. Donc, le fait d'utiliser l'horloge locale comme référence fait que ntpd va mettre doucement à jour l'heure au lieu de la mettre brutalement à jour au démarrage du système puis de la synchroniser régulièrement. Et comme le décalage est important, la synchronisation initiale va prendre beaucoup de temps. Trop de temps. Donc, je ne conseille pas cette option sous OpenWRT.
Fin de l'édit

A noter : Par défaut, ntpd envoie ses journaux à syslog. Ils sont donc accessibles via la commande logread. Si vous voulez les enregistrer dans un fichier différent, il est possible d'utiliser l'option "logfile /path/fichier" dans le fichier de configuration. Il est également possible d'utiliser l'option "logconfig" pour régler les informations qui seront logguées (via syslog ou via le fichier). "logconfig +all" permet de tout logguer. Je ne conseille néanmoins pas cette option sur le long terme vu la masse d'information qui est envoyée mais elle peut servir lors d'une phase de débogage. Referez-vous au man pour voir les autres valeurs que peut prendre cette option.

Il n'y a rien d'autre à configurer : un script d'init et un script pour le démon hotplugd ont déjà été fourni par OpenWRT.

On pensera tout de même à configurer convenablement le pare-feu du routeur. Mais là, c'est une autre histoire 🙂 .

Faire en sorte que ntpd n'écoute pas sur toutes les interfaces réseau

Pour cela, ntpd possède un paramètre, "-I", qui permet de préciser les interfaces sur lesquelles le démon écoutera. Bizarrement, il faut indiquer également l'interface de sortie (= l'interface par laquelle les paquets à destination des serveurs NTP externes passeront). De ce fait, ntpd doit, au minimum, écouter sur l'interface externe et sur l'interface LAN. Il le fait par défaut donc pas besoin de lui indiquer. Si vous avez plusieurs VLAN et que vous ne voulez pas proposer de serveur NTP sur l'un d'eux, il est préférable, à mon avis, de ne pas autoriser le plan d'adressage de ce VLAN dans le fichier de configuration de ntpd voir de bloquer le trafic NTP avec iptables. Si malgré tout vous voulez faire en sorte que ntpd écoute uniquement sur les interfaces que vous spécifiez, voici comment procéder.

Il suffit de modifier le fichier /etc/init.d/ntpd. Dans la fonction start, la ligne :

/usr/sbin/ntpd -g -p $PIDFILE

devient :

/usr/sbin/ntpd -g -p $PIDFILE -I <1ere_interface> -I <2eme interface>

Puis, relancez le démon :

/etc/init.d/ntpd restart

"ignore" versus serveur de strate >= 2

En effet, si vous utilisez un serveur dont la strate d'appartenance est supérieure à 1 combiné avec l'option de configuration "restrict default ignore", vous obtiendrez une sortie ressemblant à celle ci-dessous avec l'outil ntpq -p :

91.121.20.142   .INIT.          16 u    -   64    0    0.000    0.000   0.000

Votre serveur tente de savoir sur quel serveur se synchronise le serveur de strate > 1 que vous avez défini dans le fichier de configuration et il n'y parvient pas. Ce qui est normal puisque le serveur de référence du serveur de strate > 1 que vous utilisez n'a pas été autorisé dans le fichier de configuration. Le serveur défini est donc exclu du processus de sélection d'un serveur de référence. Cela n'a donc rien à voir avec les pool qui utilisent des serveurs aléatoires et ne permettent donc pas à ntpd de pouvoir réaliser l'association avec eux comme on le lit sur certains forums.

Deux méthodes s'offrent à vous pour résoudre ce problème :

  1. Ne pas utiliser l'option "restrict default ignore" dès le début afin de connaître les adresses des serveurs sur lesquels se synchronisent les serveurs que vous utilisez. Ainsi, vous n'avez plus qu'à les autoriser explicitement dans votre ntp.conf et à appliquer l'option "restrict default ignore" par la suite.
  2. La méthode n°1 trouvera ses limite dans le cas d'un pool de serveurs (ex. : fr.pool.ntp.org) car le serveur qui vous sert de référence change souvent (round-robin DNS (= fr.pool.ntp.org ne pointe pas toujours sur le même serveur de temps). Il vous faudrait donc pas mal de temps pour faire la liste complète de tous les serveurs qui servent de référence aux serveurs du pool. Dans ce cas là, au lieu d'utiliser l'option "restrict default ignore", vous devez utiliser l'option "restrict default notrap noquery nopeer". Vous pouvez supprimer les règles restrict que nous avons créées pour chaque serveur. Cela signifie aussi que toute machine arrivant à contacter votre routeur pourra se synchroniser sur celui-ci. Attention donc à bien configurer iptables sur l'interface eth0.1 si vous voulez éviter que votre bande passante ne soit pompée par des bots.

Test

D'abord, voyons les commandes que nous allons utiliser :

  • ntpq se trouve dans le package ntp (Debian) ou ntp-utils (OpenWRT). Vous pouvez utiliser cette commande depuis votre routeur.
  • ntpdate se trouve dans le package ntpdate (Debian).

Pour tester votre serveur, il vous suffit d'utiliser la commande ntpq -pn (l'adresse est facultative si vous lancez la commande depuis votre routeur). Vous devez obtenir une sortie qui ressemble à celle-ci :

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 145.238.203.14  .TS-2.           1 u   25   64    1   41.906  -35.002   0.113
 192.93.2.20     .GPSi.           1 u   24   64    1   42.545  -35.312   0.222
*127.127.1.0     .LOCL.          10 l   33   64    1    0.000    0.000   0.031

En essayant quelques dizaines de minutes plus tard (ça peut aller jusqu'à 30 minutes voire 1 heure), vous obtiendrez quelque chose comme :

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*145.238.203.14  .TS-2.           1 u   20   64    7   41.446  -38.169   3.057
+192.93.2.20     .GPSi.           1 u   22   64    7   42.545  -35.312   1.275
 127.127.1.0     .LOCL.          10 l   93   64    6    0.000    0.000   0.031

Vous constatez que le serveur ntp-p1.obspm.fr a été choisi comme serveur de référence et que le serveur canon.inria.fr est candidat en cas de problème. L'horloge locale a, quand a elle, été rejetée par l'algorithme de sélection. La valeur du champ pool doit augmenter progressivement jusqu'à atteindre 1024. La valeur du champ reach doit augmenter progressivement (1, 3, 7, 17, 37, 77, 177) jusqu'à atteindre 377. Cela indique que les 8 dernières tentatives de connexion à ce serveur ont réussi. En effet, chaque tentative réussie est marquée avec le chiffre 1 et chaque échec est marqué avec le chiffre 0. Ainsi, 2 réussites sur 2 essais donnent 11 en binaire et donc 3 en octal. 8 réussites sur 8 essais donnent 11111111 en binaire et donc 377 en octal.

D'autres commandes de ntpq permettent d'obtenir l'état des serveurs de référence de votre serveur (ex. : ntpq -c 'associations' 192.168.1.1) mais je ne vous les expliquerai pas dans ce billet. Reportez-vous au man ntpq pour obtenir plus d'informations.

Si tout est en ordre, vous êtes en mesure de synchroniser votre ordinateur avec votre routeur. Pour tester cela, utilisez la commande ntpdate . Vous devez obtenir une sortie ressemblant à celle-ci :

24 Aug 02:03:04 ntpdate[2448]: adjust time server 192.168.1.1 offset 0.002604 sec

Configuration des clients

Pour synchroniser vos clients en temps réel, je vous recommande d'utiliser ntpd/openntpd/chronyc plutôt que de créer une cron qui lancera ntpdate régulièrement pour la simple et bonne raison que ntpd permet un ajustement plus doux de l'horloge et qu'il ne consomme que très peu de ressources.

La configuration d'un client avec ntpd se fait comme nous l'avons vu : on définit le serveur sur lequel on se synchronise (le routeur), on ne répond à rien sauf aux requêtes locales et on laisse sortir les requêtes vers le routeur. En somme, on utilise un fichier ntp.conf comme celui-ci :

server 192.168.1.1 iburst prefer
 
server 127.127.1.0
fudge 127.127.1.0 stratum 10

restrict default ignore
restrict 192.168.1.1 mask 255.255.255.255 nomodify notrap nopeer noquery
restrict 127.0.0.1
 
driftfile  /etc/ntp.drift

Et on ajuste les règles du pare-feu en conséquence.

Pour aller plus loin avec NTPD

Je vais vous proposer quelques idées pour peaufiner votre installation et vous faire cogiter encore un peu 😉 .

Rendre son serveur public ?

Si vous répondez aux exigences demandées, vous pouvez envisager d'ouvrir votre serveur au public. Dans ce cas-là, pensez à modifier le fichier de configuration car le "restrict default ignore", ça va pas l'faire 😉 .

Vous pouvez également mettre en place de la QoS afin que votre bande passante ne soit pas entièrement consommée par des requêtes NTP.

Dans le fichier de configuration de ntpd, vous pouvez utiliser la directive "discard", qui permet d'appliquer des limites de nombre de paquets pour éviter les abus des clients. Utilisez ensuite la directive "limited" pour appliquer ces restrictions. Exemple :

discard average 3 minimum 2
restrict default notrap noquery nopeer limited

Ici, nous spécifions un espacement minimum entre les requêtes de 2 secondes et un espacement minimum moyen entre les requêtes de 8 secondes.

Attention : average est donné en log2. Ainsi, si vous voulez 8 secondes d'espacement minimum moyen entre deux paquets, vous indiquerez la valeur 3 (car log2(8) = 3). Utilisez ce convertisseur. La valeur de l'option "minimum" est donnée en secondes.

Enfin, vous pouvez activer l'envoi d'un paquet KoD (Kiss-of-Death) : il permet d'informer le client qu'il a dépassé les limites mises en place avec discard. Il doit donc cesser d'envoyer autant de paquets sinon il ne sera plus en mesure de récupérer le temps sur notre serveur. Activer cette option n'est pas nécessaire car, par défaut, les paquets qui dépassent la limite sont ignorés de toute façon. Mais informer le client permet d'avertir les clients un peu trop "speed".

Voir la documentation officielle pour plus d'informations sur discard/limited/kod.

Après, rien ne vous empêche d'ouvrir votre serveur pour vos proches/amis ou de le rendre totalement public même si vous ne pouvez pas rejoindre le pool ntp.org.

Me concernant, ma connexion ne répond pas aux exigences (ip dynamique, bande passante qui sera limite en pointe). Mon serveur restera donc privé.

Sécuriser la liaison entre votre serveur et vos clients

Il est possible de sécuriser ces échanges à l'aide de la cryptographie à clé publique ou de la cryptographie symétrique. OpenWRT propose ntpd avec le support d'OpenSSL dans le package ntpd-ssl.

Comme je ne souhaite pas cela en place sur mon LAN, je vous laisse vous débrouiller.

Devenir votre propre référence

Non, je ne suis pas fou. Si tout le monde n'a pas une horloge atomique chez soi ( 🙂 ), certains peuvent avoir un module GPS qui se branche sur un port série ou sur un port USB. Ce module peut être utilisé comme source de temps puisque les satellites GPS contiennent des horloges atomiques qui leur permettent de rendre leur service. Le temps acquis par le module peut être diffusé par ntpd sur l'ensemble de votre réseau.

Comme je n'ai pas ce matériel sous la main, je vous laisse, là encore, vous débrouiller 8) .

Références documentaires

OpenWRT : watchdog – en voilà un bon toutou !

Table des matières

Je vous propose un court billet afin de vous familiariser avec la notion de watchdog et à son utilisation sous OpenWRT. Les personnes connaissant ce concept peuvent zapper ce billet car elles n'apprendront rien de nouveau car je ne vais pas approfondir le sujet.

Définition

Je ne saurai pas mieux expliquer le concept de watchdog que Wikipédia : Chien de garde (informatique).

Implémentation sous OpenWRT

Le watchdog n'est disponible que dans la déclinaison brcm47xx de Backfire, pas dans la brcm-2.4. Peut-être est-il disponible sous les autres versions d'OpenWRT, Kamikaze brcm-2.4 par exemple, je ne les ai pas essayées. Je ne sais pas non plus s'il est disponible sur tous les routeurs mais dans le cas d'un WRT54GL v1.1, il l'est.

Sous OpenWRT, le watchdog est fourni par busybox et il se matérialise par un fichier /dev/watchdog et un démon. Par défaut, si rien n'a été écrit durant 60 secondes dans le fichier spécial /dev/watchdog, alors le routeur redémarre. C'est pour cela que le démon watchdog doit écrire dans ce fichier pour réinitialiser le compteur. Par défaut, il le fait toutes les 5 secondes. En temps normal, seul un blocage complet du système peut empêcher l'écriture dans le watchdog pendant 60 secondes.

Le watchdog permet donc d'accroitre la stabilité du système. Si vous utilisez votre routeur à distance et qu'une fausse manipulation (ex. : lancer 2 fois tcpdump) fige le système et qu'aucun watchdog n'est présent, vous ne pourrez pas réinitialiser le système ni vous en servir. Avec le watchdog, il vous suffit d'attendre que celui-ci agisse selon le timeout défini. La problématique est la même lorsqu'un logiciel fige le système (ex. sous OpenWRT : knockd peut parfois planter le système lors de son lancement).

Il n'y a pas de fonctions supplémentaires du genre redémarrage dans le cas où la charge système devient trop importante ou bien encore redémarrage dans le cas où un processus ne tourne plus comme c'est le cas sur d'autres systèmes : Watchdog sur Gentoo Wiki Archives.

Provoquer le chien

Si vous voulez tester le watchdog, plusieurs solutions s'offrent à vous selon votre niveau de sadisme (niark niark).

Tuer le démon

Lancez la commande :

killall watchdog

et attendez 60 secondes 🙂 .

Source : Watchdog - ArmadeusWiki

Utilisez une fork bomb

Pour ceux qui ne connaissent pas le principe : Fork bomb - Wikipédia FR.

Lancez la commande

bomb() {
 bomb | bomb &
}; bomb

et attendez une minute 🙂

Source : Understanding Bash fork() bomb ~ :(){ :|:& };: - NixCraft

Écrire un code dans le watchdog

On trouve également des sites qui nous disent qu'on peut écrire des données dans le watchdog avec echo. Exemples :

Ces commandes ne fonctionnent pas. Si vous ne tuez pas le démon watchdog, vous obtiendrez une erreur "-ash: can't create /dev/watchdog: Device or resource busy" qui est tout à fait normale. Si vous tuez le démon et que vous lancez une des commandes sus-citées, vous n'obtiendrez aucun résultat. En tout cas, c'est ce que j'ai observé.

Désactiver le watchdog

Il suffit de lancer les commandes suivantes :

/etc/init.d/watchdog disable
reboot

Et si vous voulez le réactiver un jour, ce seront les commandes :

/etc/init.d/watchdog enable
reboot

Régler plus finement le watchdog

Comme nous l'avons déjà dit, le démon watchdog est minimaliste. Il suffit de lancer le démon sans argument pour se rendre compte du peu d'options disponibles :

Options:
        -T N    Reboot after N seconds if not reset (default 60)
        -t N    Reset every N seconds (default 30)
        -F      Run in foreground

Régler le timing

Par défaut, le démon réinitialise le watchdog toutes les 5 secondes et si il n'a pas été réinitialisé durant 60 secondes, le système redémarre.

Vous pouvez néanmoins changer le timing. À titre d'exemple, la commande suivante permet de réinitialiser le watchdog toutes les 2 secondes et de redémarrer le routeur si le watchdog n'a pas été réinitialisé au bout de 30 secondes :

watchdog -T 30 -t 2

Pour appliquer ce changement, cela se passe dans le fichier /etc/init.d/watchdog . Il suffit de remplacer la 7e ligne ("watchdog -t 5 /dev/watchdog") par la ligne que vous aurez décidée ("watchdog -T 30 -t 2" dans notre cas). Toujours dans notre cas, voici ce que cela donnerai (fichier /etc/init.d/watchdog) :

#!/bin/sh /etc/rc.common
# Copyright (C) 2008 OpenWrt.org
 
START=97

start() {
        [ -c /dev/watchdog ] && [ -x /sbin/watchdog ] && \
                watchdog -T 30 -t 2
}

Personnellement, je recommande de ne pas modifier les valeurs par défaut ou alors de bien les tester tant que vous avez un accès local. Cela dépend bien évidemment des usages. Vous vous demandez peut-être ce qui peut bien arriver. Voici deux exemples :

  • Mettre une valeur de réinitialisation trop haute par rapport à la valeur de redémarrage (ex. : reset = 15 et reboot = 30) car dans ce cas, un plantage temporaire provoquera le redémarrage du système. Dans mon exemple, vous conviendrez qu'il n'y a qu'un ou deux essai(s) possible(s) avant un redémarrage. Il suffit que le routeur soit débordé alors que l’écriture devait être effectuée et c'est le drame alors que si ça se trouve, le système était occupé à charger un programme gourmand et que cela aurait pris 15 secondes maximum ...
  • Mettre une valeur de redémarrage trop faible peut entrainer une boucle infinie. Supposons un logiciel qui démarre durant le processus de boot et peut parfois mettre plus de temps à démarrer (qui a dit knockd ?) sans pour autant faire planter le système durablement. Si le watchdog est trop sensible, le système redémarrera. Le chargement sera a nouveau effectué et n'aura pas le temps de se faire et on repart donc pour un redémarrage, etc. .

Avoir des fonctionnalités avancées

Si vous avez besoin de fonctions plus avancées (ex. : redémarrer en fonction de la charge ou redémarrer un processus si celui-ci n'est plus en cours d’exécution), vous pouvez les implémenter à travers des scripts. Quelques exemples (à vous de leur chercher un intérêt dans votre situation et de vérifier si le script est optimisé pour la version stable actuelle d'OpenWRT) :

Conclusion - mais que fait donc la variable nvram watchdog ?

Pour les plus attentifs, une variable watchdog (de valeur 5000 par défaut) existe dans la nvram du WRT54GL :

nvram show | grep watchdog
watchdog=5000

Je ne sais pas à quoi elle correspond et Google n'est pas bavard sur le sujet.

J'ai tenté de la descendre à 1000 (nvram set watchdog=1000 && nvram commit && reboot) en croyant qu'elle indique un temps en millisecondes puis j'ai lancé une fork bomb en ayant pris le soin de désactiver le démon watchdog avant. Résultat : il ne s'est rien passé.

J'ai tenté de passer la valeur de cette variable à 10 en me disant qu'elle représente un temps en secondes, sans trop y croire. Après avoir renouvelé l’expérience que je viens de décrire, je ne suis pas plus avancé.

Ma dernière hypothèse est qu'elle concerne le démarrage du système. Si les premières couches qui se chargent au boot plantent, il faut bien relancer le système. Je ne suis pas en mesure de tester cette hypothèse.

Si quelqu'un a une information sur ce sujet, qu'il n'hésite pas 🙂 .

Réactions

Table des matières

Je souhaite réagir à différents billets vus sur différents blogs.

La fin de l'internet illimité ?

Billet d'origine : La fin de l'internet illimité ? chez le Hollandais Volant

Je n'ai pas grand-chose à rajouter ... tout est dit. Déjà que les FAI ont perverti l'esprit initial d'internet en mettant en place un débit asymétrique entre l'émission et la réception ... La base d'internet c'était justement l'égalité entre tous. Tout le monde pouvait devenir l'hébergeur d'un service et/ou d'un contenu ... Le web 2.0 (et bientôt le cloud) a fait croire aux utilisateurs qu'ils pouvaient publier ce qu'ils voulaient, qu'ils avaient le contrôle ... vaste blague.

Ce problème d'inégalité va être aggravé par le fait que les FAI freinent le déploiement de l'IPv6. Certains abonnés vont donc se retrouver derrière un NAT géant ... Essayez de faire un serveur derrière un NAT sans pouvoir faire de DNAT.

Maintenant, on nous parle de limiter la consommation générale ou de brider certains services en fonction d'un forfait. Ça me dépasse ... Comment certaines sociétés (dans les deux sens) peuvent-elles sacrifier une des plus merveilleuses inventions de l'Humanité ?

Le combat commence. Législatif évidemment, mais aussi technique vu les députés que l'on a (on reparle d'HADOPI, de LOPPSI, de la nouvelle CNI, ... ?) ...

Les filtrages selon le protocole (pas de P2P dans ce forfait !) et/ou destination (pas de Youtube dans ce forfait !) pourront être déjoués avec des proxies, des VPN, des tunnels (HTTP, DNS, ...) mais à quel prix sur le confort d'utilisation ?

Les limitations de consommations tous azimuts pourront être contrés (avec des limites tout de même) avec des services proposant des proxies "compressants" : le client envoi un flux fortement compressé au serveur, le serveur va chercher la ressource et la retourne au client sous forme compressée. On me souffle dans l'oreille que ce principe existe déjà sur les pages web ou chez Opéra (Opéra Turbo). En effet et j'en vois une version améliorée. Néanmoins, les consommateurs de flux lourds et faiblement compressibles seront toujours pénalisés (par le temps ou la qualité). Je ne parle pas des FAI alternatifs car ils sont plus chers (avec des bonus, je ne conteste pas) et donc ceux qui n'ont pas les moyens de se payer le superforfaitdelamortkitue ne pourront pas se payer un abonnement chez un FAI alternatif. Et il y a les solutions auxquelles je n'ai même pas pensé et celles qui n'ont pas encore été inventées.

Je crois en l'humain et je crois qu'il y a toujours une solution. Pour le pire et le meilleur : ils ont voulu sanctionner l'usage illégal du P2P sans proposer de solutions viables et en utilisant des moyens douteux et contestables ? On a vu le résultat (VPN, DDL, attaque de TMG, ...). Ils ont voulu condamner la liberté d'expression (pays arabes (même si c'est la galère pour certains d'entre eux à l'heure actuelle en fonction des sacro-saints intérêts économiques), Wikileaks ou même SebSauvage), on a vu le résultat (mass mirroring rendu accessible à tous (ex. : le projet autoblog), effet Streisand/Flamby, ...) . Ils favorisent encore et toujours la finance, on verra bien le résultat ... Ils veulent limiter toujours plus la liberté d'expression ... on reparlera de l'expansion des réseaux anonymes et chiffrés qui rendront impossible l'identification des vrais criminels ...

Et quand beaucoup de gens en auront beaucoup trop marre, on passera à l'internet version 2.0 : les réseaux maillés voir des réseaux maillés avec des liens chiffrés et une sortie dans un pays dont la masse politique est plus intelligente. Tout ça sans FAI.

J'ajouterai une dernière chose : le P2P, ça arrange bien les FAI. Les majors ont voulu faire passer les gens au DDL ... forcément, les coûts ne sont pas les mêmes.

Blogotext en licence CC-BY-NC

Hé oui, je me réveille : depuis le 12/05/2011, Blogotext est diffusé sous licence CC-BY-NC. Adieu la terrible clause ND. Je ne peux que féliciter le Hollandais Volant. A quand la suppression de la clause NC ? 🙂

Nous utilisons Linux pour le fun

Billet d'origine : « We use Linux because it's fun » chez le Hollandais Volant

Si je me contente de dire "+ 1", vous ne m'en voudrez pas ?

La GNU GPL, ça pue, c'est pas assez libre !

Billet d'origine : Les licences : GPL vs LGPL chez Migwel.

Si je suis d'accord sur l'argument avancé (la liberté c'est de laisser le choix à ceux qui utilisent notre composant logiciel de faire du libre ou pas), je souhaite quand même atténuer les reproches faits à la GPL.

D'abord il faut rappeler le contexte de sa création : de ce que j'en sais, les débuts de l'informatique étaient placés sous le signe du libre échange. Tout s’échangeait. Puis arrive l'époque ou certains refusent de partager pour des intérêts économiques. RMS, mais d'autres devaient partager ses pensées, a réagit, comme d'habitude, à l’extrême, en imposant le partage. Ceux qui veulent partager doivent le faire à fond, sans compromis possible. Pour moi, la montée en puissance des logiciels privateurs justifiait l'emploi d'une telle licence.

Ensuite, il faut revenir dans le contexte actuel : a-t-on besoin d'une licence virale de nos jours ? Oui, oui et encore oui. Je pense que rien n'a changé en 22 ans et qu'on en est toujours au même point : les intérêts économiques avant tout ... mais avec des modèles économiques dépassés ... forcement ça ne passe pas. Je ne parle même pas du manque de reconnaissance.

Enfin, la liberté, c'est aussi la possibilité de faire un choix et de l'assumer. De ce fait, si vous n'aimez pas le principe de la GNU GPL, vous pouvez choisir une licence qui sera plus en accord avec vos principes éthiques et moraux : BSD, MIT, WTFPL, ....

J'espère qu'on s'est bien compris : je n'attaque pas ceux qui critique négativement la GNU GPL et je ne leur demande pas de se taire, je dis juste qu'il est vain d’espérer un changement de cette licence qui a été prévue comme cela à l'origine et qui trouve encore aujourd'hui une raison d'être dans nos sociétés.

Un des plus beaux jours de ma vie sera le jour où la GNU GPL perdra de sa valeur car plus nécessaire.

Sans rapport mais tant que j'y suis : je vois beaucoup de gens parler de la Do What The Fuck You Want To Public License et autres. Il faut faire attention aux licences dont la valeur n'a pas encore été reconnue sur le territoire national (dans mon cas : la France). Celle de la GNU GPL l'est.

L'élitisme c'est le maaaal

Billet d'origine : OMG, je viens de me faire clasher par ma boulangère ! chez Mange ta main.

Comme lui, je me confesse : oui, j'ai été coupable ! Mais je le suis encore. Et je continuerai à l'être ! Tout comme la GNU GPL, l'élitisme peut se justifier. Un exemple tout bête : si des élitistes qui m'ont un jour pris pour un con viennent me demander quelque chose dans mes domaines de compétence, qu'ils ne s'attendent pas à obtenir une réponse correcte : je ferais comme eux, à savoir : "tu ne connais pas ?", "non, tu n'emploies pas le bon terme", "tu ne sais pas ce qu'est le support NFS par Firewall IP de masquerading Ethernet en double filtrage coaxial sur ICMP ?? Putain de grosse lame" (source : tRoU dU cULz hiDEoUt) ... Chacun son tour ...

Par contre, pour le reste des gens, je continuerai à partager sans problème mes connaissances et sans les prendre pour des cons. Le seul intérêt du savoir et du monde des idées, c'est de les partager. C'est d'ailleurs la raison d'être de ce blog. Je ne vous connais pas et si ça se trouve, vous être un élitiste et je m'en moque tant que je ne le sais pas. Je me répète mais le savoir doit être partagé uniquement entre les gens qui comprennent la valeur de ce partage.

Commentaires ou pas ?

Le débat fait rage :
Au revoir les comms. chez Korben
Edito du 02/08/2011 chez Korben
No comments chez SebSauvage
Vous savez pas vous tenir ? chez le Hollandais Volant

Tout a été dit donc je ne rajouterai rien. Ha si, deux choses : les échanges entre individus sont capitaux pour se forger une opinion, apporter des corrections, ... Les commentaires permettent cet échange. Néanmoins, si cela doit se passer dans de mauvaises conditions, autant ne pas échanger. On en revient donc à un problème similaire à celui de l'élitisme évoqué ci-dessus. Si ça devait arriver ici, je serais sans pitié : adieu les commentaires et pour toujours.

Le reste

Je zappe les pseudo actualités à la con : Depardieu qui pisse dans un avion je m'en fout, il y a plus important dans le monde. Le risque de canicule, qu'on informe les gens ok. Qu'on ne parle que de ça, ça me soule : il y a d'autres sujets plus importants (au choix : Libye, Syrie, Botzaris36, vraie finance (pas juste me dire que tout va bien), ...).

Je m'exprime rarement sur l'actualité mais ce n'est pas pour ça que je m'en moque et que je reste passif, bien au contraire (j'avais écrit aux députés de ma région concernant HADOPI, LOPPSI, ACTA, j'avais organisé des discutions dans ma ville afin d'informer les gens sur ces mêmes lois, idem pour la monté de la société de surveillance ...). Si je n'écris rien sur ce blog, c'est que, d'une part, je trouve que d'autres ont déjà écris sur ces sujets mieux que je ne pourrais le faire. Et, d'autre part, j'aime prendre un peu de recul avec l'actualité, histoire, entre autres, de contrer les effets d'annonce qui servent de guides aux politiques.