# dpkg-divert --divert /usr/share/doc/sun-java6-jre/US_export_policy.jar.ori \
 --rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar
Adding `local diversion of /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar
 to /usr/share/doc/sun-java6-jre/US_export_policy.jar.ori'
# dpkg-divert --divert /usr/share/doc/sun-java6-jre/local_policy.jar.ori \
--rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar
Adding `local diversion of /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar
to /usr/share/doc/sun-java6-jre/local_policy.jar.ori'

Attention, bien garder à l’esprit que si une faille de sécurité survient, il faudra mettre à jour manuellement ces fichiers.

debug1: Allocating pty
openpty: No such file or directory
session_pty_req: session 0 alloc failed

Si uniquement DEVPTS est monté, et pas PROCFS :

debug1: Allocating pty
openpty: returns device for which ttyname fails.

Voici donc les étapes pour lancer le serveur SSH chrooté avec Debian Lenny :

#  chroot /backup/jails/myserver mount -t proc proc-chroot /proc/
#  chroot /backup/jails/myserver mount -t devpts devpts-chroot /dev/pts/
#  chroot /backup/jails/myserver /usr/sbin/sshd > /dev/null

Pour ce premier post, la question classique : quand faut-il migrer sa machine vers Debian Lenny ? Tout d’abord, Etch reste maintenu environ un an après la sortie de Lenny, soit jusqu’en février 2010. Il n’y a donc aucune raison d’être pressé à migrer si l’on a pas besoin de nouveaux logiciels. Et surtout, je recommande le principe de précaution, à savoir attendre un certain temps ce qui permettra d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, il est important de bien planifier sa migration en fonction du métier de la société (haute/basse saison, vacances, etc.).

Évidemment, les précautions suivantes sont nécessaires : faire des essais de migration sur des serveurs de test, avoir des backups tout frais, couper les services durant la migration et bien prévenir à l’avance tous les utilisateurs et personnes concernées.

Entrons dans le vif du sujet. Au menu, un serveur web situé chez un hébergeur low-cost français. Ce serveur fait parti d’un pool de plusieurs serveurs (load-balancing via du round-robin DNS), donc il faut au préalable le désactiver et attendre que le time-to-live le rende totalement inactif. Ensuite, on reprend les Releases Notes, on modifie le sources.list et on se lance.

On s’assure que les partitions /usr et /tmp ont les bonnes options de montage:

# mount -o remount,rw /usr && mount -o remount,exec /tmp

On lance une mise-à-jour minimale :

# aptitude update && aptitude upgrade

Puis une mise-à-jour complète :

# aptitude dist-upgrade

Rien de bien complexe. Il reste à croiser les doigts pendant les opérations ci-dessus, mais si votre système est « propre », cela se passe très bien, comme souvent sur un système Debian. Il est ensuite important de lire les éventuelles instructions de mise-à-jour situées dans le fichier NEWS d’un paquet (en utilisant apt-listchanges, cela peut être affiché automatiquement).

En ce qui concerne la mise-à-jour du kernel, de mauvaises surprises sont possibles après le redémarrage. Il est notamment recommandé d’avoir un accès à la machine (accès physique, accès « rescue », etc.) pour corriger d’éventuels problèmes. Dans mon cas, l’interface réseau a été renommée de eth0 à eth1 suite à la mise-à-jour d’udev : le fichier  /etc/udev/rules.d/z25_persistent-net.rules se transforme en /etc/udev/rules.d/70-persistent-net.rules, jusqu’ici tout est normal, mais un problème surnaturel semble s’être produit, la carte e1000 (MAC=00:0c:29:65:ae:04) est « devenue » une r8168 (MAC=00:1c:c0:51:12:45) ; au final, c’est plutôt un soucis lié au matériel, enquête en cours chez l’hébergeur low-cost…

Un vrai problème s’est par contre posé avec la mise-à-jour du paquet nginx (un petit serveur web très performant). Suite à sa mise-à-jour, il ne démarre plus :

Starting nginx: 2009/04/19 20:45:26 [emerg] 28783#0: could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

Il faut donc ajouter dans la section http {} du fichier nginx.conf :

http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;

# Necessaire depuis l'upgrade Etch->Lenny
# (ajoute le 19.06.2009 by reg)
server_names_hash_bucket_size 33;
...

Voilà pour ce premier exemple de migration. Il s’agissait d’un serveur « simple » sans installation particulière, donc assez peu de problèmes rencontrés. Les prochains exemples seront certainement un peu plus complexes !

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

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

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

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

dig google.fr @<serveur DNS>

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

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

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

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

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

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

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

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

#!/bin/sh
MAILGRAPH_PATH=/usr/lib/cgi-bin/mailgraph.cgi # Debian
#MAILGRAPH_PATH=/usr/local/www/cgi-bin/mailgraph.cgi # FreeBSD
#MAILGRAPH_PATH=/usr/local/lib/mailgraph/mailgraph.cgi # OpenBSD

MAILGRAPH_DIR=/var/www/mailgraph

umask 022

mkdir -p $MAILGRAPH_DIR

$MAILGRAPH_PATH | sed '1,2d ; s/mailgraph.cgi?//' > $MAILGRAPH_DIR/index.html

for i in 0-n 0-e 1-n 1-e 2-n 2-e 3-n 3-e; do
        QUERY_STRING=$i $MAILGRAPH_PATH | sed '1,3d' > $MAILGRAPH_DIR/$i
done

Il peut être placé en crontab, ce qui permet une sauvegarde régulière des graphes générés. Testé sous Debian, FreeBSD et OpenBSD (variable MAILGRAPH_PATH à adapter).

• Du célèbre principe de Full Disclosure et de ses limites pratiques (période d’embargo),
• Des moyens de faire une veille sécurité à propos de logiciels Open Source (listes de diffusion à suivre, etc.),
• De la façon dont les distributions et logiciels Open Source s’organisent face aux problème de sécurité, en prenant l’exemple de Debian,
• Du choix entre l’installation par paquets ou ports et l’installation via des sources vanilla,
• D’exemples concrets de problèmes de sécurité récents : la faille concernant vmsplice dans le noyau Linux et du générateur de nombre aléatoire prévisible dans le paquet Debian openssl.

Vous pouvez télécharger les slides utilisés pour cette présentation (soyez indulgent, je les ai fait rapidement).

Le problème est désormais identifié et fixé grâce à glandium (Mike Hommey), mainteneur Debian d’Iceweasel/xulrunner/libxml2/xebkit/etc. Il s’agit d’un problème entre xulrunner et cairo, et l’installation d’un paquet xulrunner-1.9 modifié, ou mieux, libcairo2 modifié, corrige le problème pour mon ordinateur portable (carte Intel, xorg.conf minimal avec uniquement une entrée spécifique pour la disposition du clavier). Merci glandium !

Pour fêter cela, rendez-vous lundi 15 septembre 2008 18h au Shamrock Irish Pub situé sur le Vieux Port de Marseille (France). Après une bière (ou un pastis ;-), cela sera l’occasion de discuter voire de signer des clés PGP/GPG.

“cat /proc/mounts” vainqueur.