Quelques digressions sous GPL...

L'inconvénient de vivre dans un appartement en plein Paris, c'est que l'espace manque rapidement. Moi, perso, tant que j'ai de la place pour brancher des machines à plus savoir quoi en faire, tout va bien, mais mademoiselle c'est une autre histoire. En fait, elle aimerait bien qu'on ai un chat à la maison. Vous savez ces trucs pleins de poils, au demeurant mignon et sympa mais, bon, je dois normalement pouvoir remplir ces fonctions. Sauf, peut être, pour le coté "laisse tes poils partout et surtout sous le lit". La dessus, je dois admettre que j'ai du mal.

Bref, je digresse.

Donc mademoiselle voudrait un chat, et elle a trouvé un parfait argument lorsque je lui ai parlé de mon projet d'acquérir une eKey. Selon ses dires, si l'objectif de l'objet est de générer du chaos, il serait tout autant efficace de disposer d'un de ces petits diables poilu et de le laisser toute la journée dans l'appartement.

Alors c'est quoi une eKey ? En fait, dans tout système Linux (et Unix souvent) existe un puit d'entropie nommé /dev/random. Le noyau collecte des bits un peu partout sur le système, dans les drivers des périphériques surtout, là ou l'activité est supposée difficile à deviner, et remplit le puit avec ces bits. Dés que l'on utilise un tant soit peu de crypto, OpenSSL, OpenSSH, etc..., on pioche dans ce puit. La problème est qu'il est pas bien grand notre puit, puisque sa taille se limite à 4KB. C'est d'ailleurs à cause de cette taille réduite que les systèmes disposent de deux périphériques: /dev/random et /dev/urandom. La différence entre les deux ? Ils fournissent les mêmes bits aléatoires collectés par le système mais, lorsque le puit est vide, /dev/random va bloquer jusqu'à ce qu'il se remplisse alors que /dev/urandom va bricoler pour renvoyer d'autres bits, moins aléatoires, mais sans bloquer le programme appelant.

Tout l'intérêt de l'eKey est donc de fournir une source externe d'entropie afin de s'assurer que ce puit n'est jamais vide, et que l'on peut donc utiliser /dev/random uniquement sans avoir à craindre de ralentir ses programmes. C'est particulièrement indispensables sur des serveurs réalisant un grand nombre de connexions SSL !

Revenons donc à notre Chaton Chaotique

Ma chère et tendre me propose donc d'utiliser l'incroyable capacité de ces petites bêtes à générer du chaos dans mon serveur (celui qui héberge ce site) plutôt que d'enrichir le britannique en important sa technologie. Elle n'a pourtant aucune famille du coté Napoléonien, mais je dois admette qu'elle marque un point.

Le pire, c'est que techniquement, c'est jouable. Une vieille webcam recyclée en caméra de surveillance du salon, un chaton qui passe sa journée à sauter du canapé à la table de cuisine, à fourrer ses pattes sur mes vinyles et à bouffer mes RJ45 ! En backend, un petit programme pour convertir les données reçues en bits à injecter dans /dev/random. Et en plus ça pourrait être rigolo à faire !

Bref, me voilà coincé. Mon argument principal de refus se retrouve confronté à la curiosité technique... Que faire ? Trouver une parade technologique sur laquelle ronger mon frein en attendant que l'espace vital du doux foyer conjugal soit compatible avec ledit prédateur de pelotes de laines.

cat /proc/sys/kernel/random/entropy_avail

Alors que je lisait un billet des plus intéressant sur planet.debian.org, j'ai réalisé que le niveau d'entropie disponible sous Linux était exporté dans /proc. C'est fou la quantité de choses que l'on trouve dans ce pseudo système de fichiers ! Curieux de voir si mon modeste système, qui n'est en fin de compte utilisé que pour des sites persos et des services à quelques personnes du domaines linuxwall.info, nécessitait réellement une source externe d'entropie, je me suis donc fendu d'un minuscule script bash et de quelques lignes de gnuplot.

Ca donne ça :

#! /bin/sh
while [ 1 ]
do
   DATE=`date +%s`
   ENTLVL=`cat /proc/sys/kernel/random/entropy_avail`
   echo "$DATE:$ENTLVL" >> entlvl.log
   sleep 1
done

Qui remplit gentillement un fichier entlvl.log avec des lignes du type :

julien@zerhuel:/$ tail entlvl.log
1260265664:177
1260265665:183
1260265666:191
1260265668:265
1260265669:265
1260265670:305
1260265672:322
1260265673:175
1260265675:199
1260265676:220

(le premier champ, c'est du temps Unix, le deuxième, c'est des octets).

Et que l'on va ensuite utiliser pour génerer des graphiques gnuplot avec le script suivant :

set title "Entropy level on zerhuel.linuxwal.info"
set xlabel "time"
set ylabel "bits"
set yrange [0:4200]

set terminal png
set output "/data/www/pki/entropy_level.png"

set xdata time
set timefmt "%s"
set format x "%d/%m/%y:%Hh%M"
set xtics nomirror rotate
set datafile separator ":"
plot '/data/julien/code/scripts/entropylevel/entlvl.log' using 1:2 with dots

Verdict ?

Tout cela a tourné sur ma machine pendant deux mois, en marquant une valeur toutes les secondes. La courbe en date de ce matin donne :

Plus précisement, si on regarde une période de deux heures pendant laquelle je travaillais intensément sur la machine (HTTPS + 2*SSH), ca donne ça :

Ces deux graphs montrent bien qu'on est loin du niveau de famine nécessitant une source externe d'entropie. Ca se confirme à l'usage, je n'ai jamais ressenti de lenteur dans l'établissement de connexios (sauf quand je joue avec --limit et iptables, mais c'est autre chose :p ).

On peut également calculer les moyennes pour vérifier le niveau d'entropie. Si ça vous amuse de jouer en bash, ça se fait facilement de la façon suivante:

Changez juste le nom du fichier 'entlvl.log' deux fois dans la ligne suivante:

julien@zerhuel:/$ sum=0;for i in `cat entlvl.log |cut -d : -f2`;do sum=$(($sum+$i));done;echo $sum / `wc -l entlvl.log|awk {'print $1'}`|bc -l

Sur deux mois, j'ai 3106.80. Donc plutôt un puit d'entropie bien remplit.

En période de boulot (sur deux heures), j'ai 2336.70. Donc c'est plutôt bien plein également.

En gros, et pour finir

Ca veut dire deux choses, ces petites mesures (outre le fait que j'ai encore passé du temps à geeker sur un truc qui potentiellement ne sert à rien).

1. Sur votre serveur perso, même avec une utilisation intensive, la collecte d'entropie mise en place par le noyau est suffisante. Maintenant ca peut varier selon la machine. Un collègue me parlait des mini-pc à base de mémoire flash sur lesquels l'ouverture de session SSH peut prendre assez de temps pour se repasser l'intégrale d'Annie Cordy.
2. Sweetie, I'm afraid the chaotic kitty will not be needed anytime soon... :p

Ouf !

Un peu de bidouille netfilterienne pour bloquer les réseaux définit par spamhaus comme indésirables. On pourrait faire cela avec ipset, puisque l'outil est désigné pour, mais apparemment, il faut jouer un peu avec le noyau et recompiler iptables pour avoir une version qui marche sur Lenny.

Du coup, j'ai trouvé que ca aller plus vite de le faire directement dans netfilter, avec quelques lignes de bash.

L'idée est simple: on prend toutes les NOUVELLES connections entrantes et on les fait passer une fois par une chaine spéciale qui va vérifier que l'IP source n'est pas listée par spamhaus. Donc il nous faut cette chaine spéciale et un petit script qui va, tous les matins, récupérer la nouvelle liste de spamhaus et l'intégrer dans netfilter.

C'est parti.

Dans un premier temps, on va créer deux chaines : une CHECKDROPLIST qui va contenir les réseaux et une LOGCHECKDROPLIST qui va loguer avant de DROPer les paquets.

iptables -N CHECKDROPLIST

iptables -N LOGCHECKDROPLIST

iptables -A LOGCHECKDROPLIST -j LOG --log-prefix \

"SOURCE IN DROPLIST" --log-level debug

iptables -A LOGCHECKDROPLIST -j DROP

Pour le moment, on a rien mis dans CHECKDROPLIST, ca va venir après.

Maintenant, il faut que l'on filtre les paquets entrant. Mais ou ? En fait, cela dépend de l'utilisation que vous faites de la machine. Dans mon cas, je n'effectue pas de routage, et donc la chaine FORWARD n'est pas utilisée. Je vais donc pouvoir filtrer simplement dans la table "filter" de la chaine "INPUT".

Pour un récapitulatif des tables et chaines, voir ici : http://wiki.linuxwall.info/doku.php?id=ressources:dossiers:advanced_networking:1_netfilter_en_grand

Dans ma chaine INPUT, j'ai tout d'abord une règle pour accepter les connections ESTABLISHED, et juste après je vais ajouter ma règle de check de la droplist. Encore après, je peux positionner toutes mes règles de filtrage classiques.

La règle de filtrage ne va s'appliquer que sur les états NEW, pour pas alourdir le filtrage et impacter les perfs :

iptables -t filter -A INPUT -i eth0 ! -s 192.168.1.0/24 \
-m state --state NEW -j CHECKDROPLIST

OK, on est pret ! La configuration actuelle ne va pas perturber le fonctionnement normal du firewall, les nouvelles connections vont juste passer dans CHECKDROPLIST et comme rien n'y est fait pour le moment, vont continuer leurs chemin.

Maintenant, le script que l'on va mettre en place va récupérer le fichier sur spamhaus.org, le parser et injecter les adresses dans la chaine CHECKDROPLIST. On va faire passer ces adresses dans une regex pour éviter d'injecter n'importe quoi.

#! /bin/sh

# get the drop list from spamhaus

# and import it into netfilter

URL=http://www.spamhaus.org/drop/drop.lasso;

DEST=/root/droplist/drop.lasso.`date +%s`



wget $URL -O $DEST



IPT=/sbin/iptables



if [ -e $DEST ]

then

  # drop existing set of rules

  $IPT -F CHECKDROPLIST

  # add new rules

  for i in `cat $DEST | awk {'print $1'}|\

           grep -E "^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]\

           {1,3}\.[0-9]{1,3}\/[0-9]{1,2}$"`

  do

      $IPT -A CHECKDROPLIST -s $i -j LOGCHECKDROPLIST

  done

fi

La regex pourrait être améliorée mais j'ai pas trop eu le temps de la paufiner (avis aux amateurs).

Je vous laisser tester ça chez vous. Au jour d'aujourd'hui, ça m'importe 158 réseaux dans la chaine CHECKDROPLIST. Je vais laisser tourner ça quelques jours puis je m'attarderais sur les stats pour voir si ya vraiment un intérêt à bloquer ces réseaux.

.