GuiGui's show

Avant de commencer, je tiens à préciser que ce billet sera forcement incomplet. En effet, il existe une multitude de portails captifs en circulation et je n'ai pas la prétention de tous les connaître ni de faire un billet qui les concerne tous. Sans compter les configurations qui varient d'un intégrateur à un autre pour un même produit ... Dans ce billet, je vais vous donner les bases, des pistes de recherche et rien de plus. Ne soyez donc pas déçus.

Ha ! Les portails captifs ! Entre ceux qui les croient indétrônables et les mettent en place sans d'autres mesures complémentaires de sécurité et de bon sens et ceux qui passent leur temps à pester contre eux lorsqu'ils les empêchent de faire des actions légitimes ...

Dans ce billet, je parlerai des portails captifs que l'on trouve sur les accès WiFi "ouverts" comme des portails captifs que l'on trouve sur des connexions filaires. Leurs principes de fonctionnement sont identiques.

Table des matières

Contourner un portail captif

Je sais que les poils de certains lecteurs se sont hérissés à la lecture du mot "contourner". Bah oui, contourner un portail captif c'est forcement dans une mauvaise intention. Bah non ... On peut contourner un portail captif pour des raisons légitimes. Au pif : vous attendez toujours votre identifiant alors que vous avez payé il y a déjà longtemps votre accès à internet ou bien le portail captif déconne une fois de plus et vous avez besoin de vous informer, de vous divertir, de communiquer rapidement, ou que sais-je.

Plusieurs méthodes de contournement (= accéder à internet sans identifiant) sont possibles, parmi lesquelles :

• Pinger une machine du réseau et dès qu'elle ne répond plus, on peut considérer que son propriétaire l'a éteinte sans pour autant prendre le temps de se déconnecter du portail captif. Il suffit donc de prendre l'adresse IP de cette machine et vous serez authentifié. Sisi, une technique aussi basique fonctionne encore en 2011 (à qui la faute ?) !
• Pour les portails captifs un peu plus exigeants, il suffira d'usurper l'adresse MAC en même temps que l'adresse IP. Un ping puis un arp -a suffira à découvrir l'association entre adresse IP et adresse MAC sans utiliser d'analyseur réseau (vous savez, des logiciels comme tcpdump ou wireshark). Cette usurpation peut même avoir lieu pendant que la victime est connectée.
• Normalement, tous les ports sont verrouillés tant que le client ne s'est pas authentifié. Mais parfois, on trouve des portails captifs avec des ports standards ouverts. Il suffit d'héberger, en dehors du réseau, un serveur (SSH/OpenVPN si c'est un port TCP qui est ouvert, OpenVPN pour un port UDP) et de faire du tunneling. Ex. : si vous constatez que le port 53/UDP est ouvert, montez un serveur OpenVPN sur le port 53/UDP. Attention toutefois à ce que le trafic ne soit pas dirigé vers une destination précise (ex. : le port 53/UDP est ouvert, mais le trafic sur ce port est dirigé vers un vrai résolveur DNS qui ne laissera pas passer votre connexion VPN). Ce genre de manipulation peut être démasquée en regardant le TTL des réponses. Si le paquet de retour a un TTL de 1, 2 ou une valeur faible, le serveur est tout près et il ne s'agit probablement pas du serveur que vous cherchez à atteindre.
• Si aucun port n'est ouvert ou si le trafic est redirigé vers une machine particulière, il vous reste le tunneling plus avancé : TCP over ICMP, TCP over DNS, etc. De mon expérience, si le protocole ICMP est souvent bloqué, le protocole DNS n'est jamais bloqué afin de permettre la redirection du navigateur vers la page d'authentification (votre navigateur cherchera à résoudre google.fr, par exemple. S'il n'y parvient pas, il n'enverra pas de message HTTP et la passerelle ne pourra donc pas le rediriger vers la page d'authentification). Parmi les logiciels utilisables, on peut citer iodine (mon préféré), heyoka, ozymanDNS, dnstunnel ... Je vous propose ce site : Le Blog du grand loup Zeur comme tutoriel. Attention toutefois : ce genre de tunneling n'est pas le plus efficace qui soit en terme de débit (pour avoir essayé ...). De plus, vous pouvez facilement être détecté par une analyse volumétrique du trafic dû au flot inhabituel que vous allez générer sur le service choisi (ex. : DNS). À noter que ce type de tunneling permet aussi de passer les firewalls qui inspectent le contenu des paquets pour vérifier qu'ils sont conformes aux spécifications du protocole auxquels ils prétendent appartenir (ex. : iodine passera très bien un l7-filter configuré pour ne laisser passer que le protocole DNS sur le port UDP/53).
• À l'aide d'un "complice" ayant une machine authentifiée sur le réseau, il suffit d'utiliser le NAT. Le concept est simple : sa machine est authentifiée et va transmettre vos paquets sous son identité. Vous allez peut-être vous dire qu'il faut donc que votre complice ait une machine avec deux cartes réseau ou qu'il vous faut un commutateur. Que nenni ! Vous vous raccordez sur le même réseau, via les prises murales ou que sais-je. Sur le serveur (la machine de votre "complice"), vous passerez en IP fixe (en utilisant évidemment une IP routable sur le réseau, c'est-à-dire une IP appartenant au même réseau que la passerelle), vous activez l'ip forwarding et le NAT. Pour accroître un peu la sécurité, le serveur ne NATera que les paquets dont l'IP source est celle de votre machine (le client). Ceci est à configurer dans la chaîne FORWARD pour les iptabliens. Cela évite que quelqu'un d'autre, par hasard, comprenne le truc et utilise aussi le serveur sans votre accord. Sur le client, il suffit de passer en IP fixe (= pas de DHCP), de déclarer le serveur comme route par défaut et en avant ! Cette technique peut également vous servir si vous avez deux machines vous appartenant pour un seul identifiant. Si en plus vous avez deux machines pour une seule prise murale, alors là oui, vous aurez besoin d'un commutateur.
• ...

S'authentifier automatiquement sur un portail captif

Il n'y a rien de plus embêtant que de devoir se connecter à chaque fois au portail captif. Pour éviter ce calvaire, il suffit d'utiliser curl (mon préféré) ou wget pour qu'ils vous connectent automatiquement.

Il suffit d'analyser le code source de la page d'authentification et notamment les paramètres passés via l'URL ou via un formulaire. Méfiez-vous des champs cachés qui doivent tout de même être remplis ! Faites également attention aux pages qui s'enchainent (ex. : une page vous demande votre login, puis une page qui vous demande votre mot de passe, seule la deuxième page est importante). Il suffit ensuite de créer une commande curl qui remplira le formulaire pour vous et vous connectera automatiquement.

Par exemple, si la page d'authentification ressemble à ça (exemple inventé) et se trouve sur le serveur 10.123.36.254) :

<form method="post" action="fin.html">
	<input type="hidden" name="url" value=""/>

	<input type="hidden" name="meth" value="radius"/>
	<input type="hidden" name="action" value="login"/>

	<input type="hidden" name="time" value="360"/>
	<input type="password" name="pswd" size="25"/>

	<input type="hidden" name="uid" value="mon_login"/>
 
	<input type="submit" value="OK">

	<input type="button" value="Annuler" onclick="window.location='/';">
</form>

Alors la commande curl correspondante ressemblera à :

curl -m 5 -d pswd=votre_mdp -d uid=mon_login -d time=360 -d url= -d meth=radius -d action=login "http://10.123.36.254/fin.html" > /dev/null 2>&1

Le paramètre "-d" permet de remplir les champs, "-m 5" demande à curl d'arrêter sa tentative de connexion après 5 secondes.
À vous d'adapter ceci à votre situation. Exemple : si votre portail captif utilise le protocole HTTPS et un certificat non valable, utilisez l'option "-k" de curl pour contourner ce problème.

Il ne vous reste plus qu'à mettre cette commande dans un script shell, de le rendre exécutable et d'utiliser le Network Manager ou bien Wicd (Propriété de la connexion, Scripts, Exécuter un script après connexion) ou le fichier de configuration /etc/network/interfaces et son paramètre "post-up" pour exécuter le script dès la connexion au réseau et ainsi être authentifié automatiquement.

Maintenir l'authentification

Il n'y a rien de plus chiant que d'interrompre une séance productive de travail pour se reconnecter, car le timeout du portail captif a expiré ! Le pire, c'est quand le timeout est démesurément court : 30 minutes, par exemple (sisi, j'ai déjà vu ça !).

La solution est simple, il suffit d'utiliser cron pour lancer le script d'autoconnexion écrit ci-dessus à un intervalle régulier. Pour cela, il suffit d'utiliser la commande :

crontab -e

Et de rajouter une ligne. Par exemple (le script sera lancé toutes les 5 heures) :

* */5 * * * /home/guigui/.autoconnect

Astuces bonus

Il arrive que le portail captif refuse de vous identifier alors que vous avez fourni les bons identifiants. Deux causes peuvent expliquer cela : le fait que le serveur DHCP vous ai attribué une autre IP (lors d'une demande post-reboot ou lors d'un renouvellement) et la cause inconnue.

Dans le premier cas, il suffit de reprendre votre ancienne IP et si vous le souhaitez, de vous déconnecter du portail, de reprendre l'IP qui vous a été attribué en dernier et vous authentifier. Le problème étant de connaître son avant-dernière IP. La commande suivante devrait vous aider à connaître les 2 dernières IPs qui vous ont été attribuées :

sudo grep "dhclient: bound to" /var/log/daemon.log | tail -2

Dans le deuxième cas, j'ai constaté que ce problème se résout en envoyant plusieurs requêtes d'authentification au portail captif. Il suffit donc de répéter la commande d'autoconnexion plusieurs fois. Par exemple :

#!/bin/bash
 
while let 1; 
do 
	curl -d pswd=votre_mdp -d uid=mon_login -d time=360 -d url= -d meth=radius -d action=login "http://10.123.36.254/fin.html";

done

Vous vous apercevrez que le portail va très rapidement (dans les 30 secondes) vous authentifier puis repartir en erreur. Mais ce n’est pas grave : vous serez authentifié ! Contrairement aux apparences, ce script n'est pas une boucle infinie destructrice : un simple CTRL+C suffit pour tout arrêter). Faites quand même attention lorsque vous l'employez afin que l'on ne vous accuse pas de porter atteinte à un système automatisé de traitement de données alors que vous cherchez simplement à rétablir un service légitime. C'est la mode ces temps-ci ...

Se déconnecter automatiquement (ÉDIT du 03/04/2012 à 18h15)

Je vous ai montré, plus haut, l'importance de se déconnecter du portail captif avant de quitter le réseau mais je ne vous ai pas encore montré comment vous déconnecter de manière automatique. Nous allons faire en sorte de vous déconnecter automatiquement durant l'arrêt de votre machine.

La première étape est de trouver l'url et les paramètres de déconnexion. Tout comme pour la connexion automatique, il va falloir y aller au reverse. Tout comme pour la connexion automatique, vous devez obtenir une commande curl.

La deuxième étape est de modifier le fichier /etc/network/interfaces et d'y ajouter une ligne "pre-down". Cela demandera à la commande ifdown de vous déconnecter du portail avant de rendre l'adresse (si vous êtes en DHCP) et d'éteindre la carte réseau. Exemple :

allow-hotplug eth0
iface eth0 inet dhcp
pre-down curl -d pswd=votre_mdp -d uid=mon_login -d time=360 -d url= -d meth=radius -d action=logout "http://10.123.36.254/fin.html"

Attention : pour ceux qui seraient tenter d'utiliser wicd ou le network-manager, ce n'est pas une bonne idée. Ces deux services seront stoppés lors de l'arrêt et ne vous déconnecteront donc pas.

Pour ceux qui veulent se déconnecter sans pour autant éteindre leur machine, il n'y a pas, à ma connaissance, de méthode 100% automatique. Si vous avez modifié le fichier /etc/network/interfaces comme ci-dessus, vous pouvez lancer la commande "sudo ifdown eth0". Vous pouvez également placer votre commande dans wicd (Propriété de la connexion, Scripts, Exécuter un script avant déconnexion) ou le network-manager comme ça, vous aurez juste à cliquer sur "Déconnexion" pour quitter le portail captif et le réseau. Cette deuxième possibilité n'impose pas d'avoir modifié le fichier interfaces.

SSH auto-reconnect

Je vais finir ce billet en vous parlant d'un sujet qui n'a qu'un rapport limité avec le thème de ce billet : la reconnexion automatique à un serveur SSH. Vous savez que, sur les réseaux insécures, je fais transiter tout mon trafic par un tunnel SSH en attendant de me monter un VPN. Le keepalive permet de maintenir la connexion. Mais si jamais un problème survient sur le réseau et provoque une déconnexion, cela peut-être ennuyeux si je ne suis pas là pour relancer la connexion et si je télécharge un fichier, par exemple. C'est dans cette optique que j'ai créé le script suivant.

Il me semble au point, mais il y a sans doute moyen de l'améliorer. Il peut être simplifié, car il est, pour le moment, adapté à mes besoins/désirs :

• Connexion au serveur SSH via le système clé publique/clé privée.
• Je vérifie que la connexion est down via une requête DNS effectuée via mon tunnel SSH. Il est nécessaire d'ouvrir deux tunnels distincts (un pour le test, l'autre pour les données), car sinon, en cas de trafic dans le tunnel, la requête DNS de test n'est pas prioritaire et le script diagnostique, à tort, une connexion SSH down. Il est bien sûr possible de contrôler l'état de la connexion SSH via d'autres moyens comme la surveillance des connexions actives avec netstat ou la surveillance des processus actifs avec ps. Mais ces méthodes sont plus lentes pour détecter une connexion down du fait des timers, entre autres.
• Ce script suppose que le serveur SSH soit configuré dans votre fichier ssh_config.
• Ce script suppose que le port 53/tcp soit redirigé, grâce à iptables, sur le port 5300. je vous avais déjà expliqué pourquoi.
• La commande dig doit être disponible sur le système (package dnsutils sous Debian).
• Le résolveur DNS utilisé doit accepter les requêtes DNS sur le port 53/tcp.
• Ce script est complexifié par le fait que le serveur SSH procède à un bannissement par IP après deux tentatives de connexion en moins de 10 minutes. C'est pourquoi le script attend 12 minutes en cas de reconnexion ratée et a été adapté à cette contrainte.

Trêve de parole, voici le script que j'utilise :

#!/bin/bash
 

ssh-add /chemin/vers/la/cle/privee
 
while true

do
	dig google.fr @127.0.0.1 +tcp > /dev/null 2>&1
	if [ $? -eq 0 ]; then

		echo "La connexion SSH est OK."
		sleep 60
	else
		echo "La connexion SSH semble KO."

		dig google.fr @127.0.0.1 +tcp > /dev/null 2>&1
		if [ $? -ne 0 ]; then

			echo "La connexion SSH est réellement KO."
			killall ssh > /dev/null 2>&1

 
			echo "Tentative de reconnexion ..."
			ssh -N -D6666 serveur &
			ssh -N -L5300:resolveurDNS:53 serveur &

 
			sleep 60   
			dig google.fr @127.0.0.1 +tcp > /dev/null 2>&1

			if [ $? -ne 0 ]; then
				echo "Tentative de reconnexion KO, attente de 12 minutes."

				killall ssh > /dev/null 2>&1
				sleep 720

			else
				echo "Tentative de reconnexion OK."
				sleep 60
			fi
		else

			echo "Mais la connexion est OK en fait."   
			sleep 60
		fi
	fi
done

ÉDIT du 26/01/2012 à 14h00 : De nouvelles versions des paquets libxine* ont été poussées dans les dépôts testing de Debian aujourd'hui. Ceux-ci résolvent le problème énoncé ci-dessous sans aucune intervention de l'utilisateur.
Fin de l'édit

ÉDIT du 10/12/2011 à 17h40 : De nouvelles versions des paquets libxine* ont été poussées dans les dépôts testing de Debian. Ceux-ci ne résolvent toujours pas le problème et l'astuce présentée ci-dessous reste de rigueur.
Fin de l'édit

ÉDIT du 16/10/2011 à 19h40 : Comme suggéré dans les commentaires, j'ai soumis un rapport de bug concernant ce problème à l'équipe Debian/KDE extras. Je ne suis pas satisfait par ce rapport de bug malgré le fait de m'être renseigné sur la démarche à suivre mais c'est mon premier ... Puis, je me suis aperçu qu'une solution a été trouvée depuis le 10 octobre : DVB video & sound problem Kaffeine on Wheezy sur Linux Archive. Je l'ai testée et elle fonctionne. Il suffit donc de modifier le fichier ~/.kde/share/apps/kaffeine/xine-config en remplaçant la ligne "#audio.driver:auto" par "audio.driver:pulseaudio" (ou alsa).
Fin de l'édit

Comme vous le savez, j'utilise le logiciel Kaffeine pour regarder la TV (TNT) sur mon Debian GNU/Linux mis à jour avec les dépôts testing (donc je sais à quoi m'attendre).

Depuis la fin de la semaine dernière (probablement le 22/09), le paquet Kaffeine fourni dans les dépôts Debian ne fonctionne plus : il n'affiche plus du tout la vidéo et affiche parfois un message "périphérique audio non disponible" lorsque l'on zappe sur n'importe quelle chaîne. Dans tous les cas, il n'y a jamais d'images ni de son.

Je me suis très vite dirigé vers un problème dans les paquets Debian puisque j'avais vu, lors d'une mise à jour de mon système réalisée le 22/09 au soir, que les paquets libxine* allaient être mis à jour sur mon système. Or, je sais que la libxine est une dépendance nécessaire à Kaffeine.

Je vous passe les différentes méthodes que j'ai essayées sans succès (utiliser le dépôt unstable au cas où cela soit corrigé, essayer le dépôt stable, ...) pour vous présenter la méthode qui fonctionne : utiliser les dépôts snapshot.

Les dépôts snapshot sont des instantanés (= des images à un instant donné) des dépôts Debian. Ils permettent d'obtenir, toujours via apt, une ancienne version d'un paquet. Ils sont préconisés dans le cas de problèmes liés à une mise à jour.

Après tâtonnement, il s'avère que le dépôt snapshot du 21/09 et du 22/09 ne fournissent pas une dépendance nécessaire à Kaffeine (libxine1-ffmpeg). En revanche, aucun problème avec le dépôt du 20/09. C'est donc lui que nous allons utiliser.

Si vous avez déjà une version de Kaffeine installée, pensez à la désinstaller avant de commencer :

apt-get autoremove --purge kaffeine

Pensez aussi à supprimer les paquets conservés dans le référentiel local :

apt-get clean

Commentez tout votre fichier /etc/apt/sources.list puis et ajoutez-y la ligne suivante :

deb http://snapshot.debian.org/archive/debian/20110920T211952Z/ wheezy main

Ensuite, on lance un apt-get update en précisant l'option "Acquire::Check-Valid-Until=false" qui permet d'éviter le message d'erreur "E: Release file for http://snapshot.debian.org/archive/debian/20110918T212936Z/dists/wheezy/InRelease is expired (invalid since 5h 9min 33s). Updates for this repository will not be applied." :

apt-get -o 'Acquire::Check-Valid-Until=false' update

Enfin, on installe Kaffeine comme d'habitude :

apt-get install kaffeine

On lance Kaffeine et on constate qu'on a la vidéo et le son. Le problème est donc résolu.

Vous pouvez décommenter votre fichier /etc/apt/sources.list et supprimer la ligne concernant le dépôt snapshot.

Néanmoins, si nous ne faisons rien, un apt-get dist-upgrade mettra à jour notre libxine ... dans une version encore bugguée. Nous allons donc geler notre libxine temporairement :

echo "libxine1 hold" | sudo dpkg --set-selections

Ainsi, nous pouvons faire un apt-get dist-upgrade sans problème.

Il faudra toutefois surveiller la sortie d'une version corrigée de la libxine et, lorsque ce sera le cas, lever le gel qui pèse sur elle.

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.

Table des matières

Dans ce billet, je vais vous parler de plusieurs méthodes pour améliorer la sécurité de votre accès SSH à votre routeur sous OpenWRT. Un deuxième objectif sera d'éviter au maximum les attaques par bruteforce. Bien qu'elles soient sans espoir avec un mot de passe bien choisi, elles consomment un peu des ressources (processeur et bande passante) et ça m'énerve. Nous verrons quatre méthodes au total. Il est bien entendu qu'il est inutile de combiner toutes les méthodes. Néanmoins, certaines peuvent être combinées (ex. : 3 et 4 ou 1 et 2 ou ...). Évidemment, tout ceci est inutile si vous n'utilisez pas SSH en dehors de votre LAN.

Un changement du port d'écoute et une règle iptables

J'ai déjà présenté une règle iptables permettant de limiter l’impact d'une attaque par bruteforce sur le démon SSH dans ce billet : Adieu DG834G, bonjour WRT54GL et OpenWRT

Pour rappel, voici ce que j'écrivais :
Je change le port sur lequel écoute dropbear (démon SSH). Pour cela, il faut éditer le fichier /etc/config/dropbear en changeant la ligne « Port ».

Ensuite, j’ouvre le port, dans iptables, pour qu’il soit accessible depuis internet et je protège le service contre une attaque par brute force. Pour faire cela, il faut éditer le fichier /etc/firewall.user avec vi, par exemple, et ajouter :

iptables -A input_wan -p tcp --dport 7523 -m state --state NEW -m recent --name ATTACKER_SSH --rsource --update --seconds 600 --hitcount 2 -j DROP
iptables -A input_wan -p tcp --dport 7523 -m state --state NEW -m recent --name ATTACKER_SSH --rsource --set
iptables -A input_wan -p tcp --dport 7523 -m state --state NEW -j ACCEPT

Notes :

• 7523 est le port d'écoute choisi.
• Ce code est inspiré de celui fourni sur le wiki officiel mais lui fonctionne, au moins 😉 .
• Ce code nécessite que les packages iptables-mod-conntrack-extra et kmod-ipt-conntrack-extra soient installés. Ils ne le sont pas par défaut.

Explication rapide : L’attaquant sera donc bloqué pendant 10 minutes après 2 connexions (qui permettent chacune d’essayer 10 mots de passe). On ne peut pas plus réduire le nombre de connexions. Si vous mettez 1, vous ne devrez jamais vous tromper quand vous tapez le login. Car dans ce cas, vous devrez quitter la session et en recommencer une mais vous serez alors bloqué pendant 10 minutes. Évidemment, cela s’applique uniquement aux paquets venant d’internet, pas du LAN.

Malheureusement, il n'est pas toujours possible de changer le port d'écoute : certains réseaux vérifient les ports utilisés dans le trafic sortant, voir plus (reverse-proxy ...) et vous ne pourrez donc pas accéder à votre routeur depuis ces réseaux. Mais n'oubliez pas qu'il reste beaucoup de ports ouverts et qui ne sont que rarement contrôlés par de reverse proxy ou des règles qui matchent le contenu des paquets. À ce sujet, privilégiez les ports qui utilisent un protocole de chiffrement (ex : SSH, HTTPS, POPS, IMAPS, SMTPS, ports VPN, ports IPSEC, ...). De plus, Dropbear, le démon SSH utilisé par OpenWRT permet d'essayer 10 mots de passe par connexions. Ce qui fait qu'ici, un bot aura le droit d'essayer 20 mots de passe par session.

Bon, vous me direz que 20 essais toutes les 10 minutes, ce n'est rien comparé à un mot de passe de 12 caractères chiffres, lettre minuscules, majuscules et caractères spéciaux ne représentant pas une séquence connue (ex. : azertyuiop75) ni un mot du dictionnaire. Sachant que, d’après mes observations, les bot bloqués ne reviennent pas au bout de 10 minutes mais au bout de 24H, cela fait donc 20 essais de mot de passe par jour. Autant dire : rien. Et je ne parle pas des bots qui sont seulement capables de tester un mot de passe par connexion. Ceux-là essayent donc 2 mots de passe par jour. Néanmoins, comme je l'ai déjà dit ces tentatives, même vouées à l'échec, m'énervent.

Compiler dropbear pour n'autoriser que 3 essais de mot de passe par connexion

Édit du 25/08/2011 à 2h40 :
Attention : J'ai oublié de préciser que ce point vous concerne même si vous utilisez l'authentification à clé publique. En effet, même si vous n'avez pas besoin de limiter le nombre d'essais de mot de passe, il peut être intéressant de limiter la durée pendant laquelle l'authentification est possible, de limiter le nombre de d'utilisateurs non authentifiés simultanés ou bien encore de limiter la taille du binaire.
Fin de l'édit

Ici, les manières de procéder sont diverses. La plus adaptée serait d'utiliser le SDK d'OpenWRT puisque nous voulons compiler uniquement un seul paquet. Néanmoins, celui-ci n'est pas disponible pour Backfire 10.03. Certains internautes du forum officiel d'OpenWRT utilisent le SDK de la version Kamikaze au prix d'une petite bidouille d'opkg par la suite. Nous n'allons donc pas employer cette méthode mais nous allons utiliser buildroot, une série de scripts qui permet de compiler facilement un système embarqué avec Linux comme noyau et qui est utilisé par OpenWRT, pour compiler dropbear.

Pour rappel : le SDK ou l'image builder, sont des composants du buildroot. Ils peuvent donc être remplacés ou compilés par buildroot (voir make menuconfig).

Préparer votre GNU/Linux Debian Squeeze pour buildroot

Il faut installer un certain nombre de paquets :

# apt-get install asciidoc autoconf bison build-essential fastjar flex gawk gettext git-core intltool libextutils-autoinstall-perl libncurses5-dev libssl-dev libtool subversion zlib1g-dev

Source : OpenWrt Buildroot – Installation. Le reste des paquets seront installés via le jeu des dépendances.

C'est l'heure d'aller se chercher un premier café ! 😉

Récupérer les sources

Nous allons récupérer les sources stables de la version Backfire 10.03 :

~$ svn co svn://svn.openwrt.org/openwrt/tags/backfire_10.03

S'assurer que toutes les dépendances sont satisfaites

~$ cd backfire_10.03
~/backfire_10.03$ make defconfig
~/backfire_10.03$ make prereq

Modifier le Makefile de dropbear afin d'accroitre la sécurité

Ouvrez le Makefile spécifique à dropbear (./package/dropbear). Dans la rubrique "Build/Configure", constatez que certains fichiers sources sont modifiés avant compilation. Il s'agit notamment du fichier options.h que l'auteur de dropbear nous conseille (via le fichier README des sources) d'ailleurs de consulter afin de personnaliser notre installation. C'est ce que j'ai fait et je vous livre ici les modifications utiles que j’ai trouvées. Signalons au passage la présence de nombreux commentaires, dans le code, qui aide à faire des choix. Rien ne vous empêche donc de vérifier que je n'ai rien oublié 😉 .

Voici donc les lignes que nous allons rajouter dans la rubrique "Build/Configure du Makefile" :

$(SED) 's,^#define AUTH_TIMEOUT 300,#define AUTH_TIMEOUT 60,g' $(PKG_BUILD_DIR)/sysoptions.h
$(SED) 's,^#define MAX_UNAUTH_PER_IP 5,#define MAX_UNAUTH_PER_IP 2,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define MAX_UNAUTH_CLIENTS 30,#define MAX_UNAUTH_CLIENTS 2,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define MAX_AUTH_TRIES 10,#define MAX_AUTH_TRIES 3,g' $(PKG_BUILD_DIR)/options.h

Explications simplifiées :

• La première ligne passe le délai pour s'authentifier de 5 minutes à 1 minute. Il ne faut tout de même pas 5 minutes pour taper un mot de passe !
• La deuxième et la troisième ligne réduisent le nombre de clients non authentifiés qui peuvent se connecter simultanément.
• La dernière ligne passe le nombre d'essais de mot de passe de 10 à 3 pour une session.

Évidemment, ces options, et notamment celle pour le nombre de clients non authentifiés simultanés, doivent être adapter à votre situation (nombre d'utilisateurs, ...).

Modifier le Makefile de dropbear afin d'optimiser l'espace occupé par le programme

Tant que nous y sommes, nous allons désactiver les fonctions dont nous ne nous servirons pas afin que le binaire généré occupe moins d'espace sur la flash du routeur. Par la même occasion, nous augmentons la sécurité du démon (moins de code donc moins de bugs/failles possibles).

Sachez que le développeur de dropbear donne des conseils pour que dropbear occupe moins d'espace dans le fichier SMALL des sources. Je vous cite le contenu de ce fichier, ci-dessous, pour information :

Tips for a small system:

If you only want server functionality (for example), compile with
make PROGRAMS=dropbear
rather than just
make dropbear
so that client functionality in shared portions of Dropbear won't be included.
The same applies if you are compiling just a client.

---

The following are set in options.h:

- You can safely disable blowfish and twofish ciphers, and MD5 hmac, without
affecting interoperability

- If you're compiling statically, you can turn off host lookups

- You can disable either password or public-key authentication, though note
that the IETF draft states that pubkey authentication is required.

- Similarly with DSS and RSA, you can disable one of these if you know that

all clients will be able to support a particular one. The IETF draft
states that DSS is required, however you may prefer to use RSA.
DON'T disable either of these on systems where you aren't 100% sure about
who will be connecting and what clients they will be using.

- Disabling the MOTD code and SFTP-SERVER may save a small amount of codesize

- You can disable x11, tcp and agent forwarding as desired. None of these are

essential, although agent-forwarding is often useful even on firewall boxes.

---

If you are compiling statically, you may want to disable zlib, as it will use
a few tens of kB of binary-size (./configure --disable-zlib).

You can create a combined binary, see the file MULTI, which will put all
the functions into one binary, avoiding repeated code.

If you're compiling with gcc, you might want to look at gcc's options for
stripping unused code. The relevant vars to set before configure are:

LDFLAGS=-Wl,--gc-sections
CFLAGS="-ffunction-sections -fdata-sections"

You can also experiment with optimisation flags such as -Os, note that in some
cases these flags actually seem to increase size, so experiment before
deciding.

Of course using small C libraries such as uClibc and dietlibc can also help.

If you have any queries, mail me and I'll see if I can help.

Nous allons suivre le dernier conseil : utiliser les options de gcc pour dégager le code inutilisé. Pour cela, ajoutez les deux lignes données en haut de la rubrique Build/Compile du Makefile de dropbear. Comme cela :

define Build/Compile
	LDFLAGS=-Wl,--gc-sections
	CFLAGS="-ffunction-sections -fdata-sections"	
	$(MAKE) -C $(PKG_BUILD_DIR) \
		$(TARGET_CONFIGURE_OPTS) \
		LD="$(TARGET_CC)" \
		PROGRAMS="dropbear dbclient dropbearkey scp" \
		MULTI=1 SCPPROGRESS=1

	$(MAKE) -C $(PKG_BUILD_DIR) \
		$(TARGET_CONFIGURE_OPTS) \
		LD="$(TARGET_CC)" \
		PROGRAMS="dropbearconvert"

endef

Nous allons maintenant suivre les conseils précédents en rajoutant les lignes suivantes dans la rubrique "Build/Configure" du Makefile :

$(SED) 's,^#define INETD_MODE,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DO_MOTD,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define SFTPSERVER_PATH "/usr/libexec/sftp-server",/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define ENABLE_X11FWD,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DROPBEAR_BLOWFISH,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DROPBEAR_TWOFISH256,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DROPBEAR_TWOFISH128,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DROPBEAR_3DES,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DROPBEAR_AES128,/* & */,g' $(PKG_BUILD_DIR)/options.h
$(SED) 's,^#define DROPBEAR_MD5_HMAC,/* & */,g' $(PKG_BUILD_DIR)/options.h

Explications :

• La première ligne demande à dropbear de ne pas être lancé par un quelconque démon réseau mais de toujours se lancer en standalone. Le mode inetd est inutile sur OpenWRT qui ne possède pas ce genre de démon.
• La deuxième ligne désactive le message du jour. Le fichier /etc/banner nous suffira pour afficher un message.
• La troisième ligne désactive le support d'un serveur SFTP. Nous avons déjà SCP pour copier des fichiers de manière sécurisée.
• La quatrième ligne désactive le X11 forwarding. Par défaut, il n'y a pas d'environnement graphique accessible via SSH sur OpenWRT et nous n'en voulons pas. Autant gagner de la place en désactivant cette fonctionnalité.
• Les autres lignes désactivent les algorithmes de chiffrage/hachage les plus faibles (bien qu'ils ne soient pas "non sécurisés"). Seuls l'algorithme de chiffrement symétrique AES 256 et les fonctions de hachage SHA1_HMAC et SHA1_96_HMAC resteront.

L'auteur de dropbear nous conseille aussi de désactiver le port forwarding et l'agent forwarding. Dans mon cas, ceux-ci me seront utiles donc je ne les désactive pas. Enfin, il nous conseille de désactiver l'authentification par mot de passe ou celle par clé publique. Vu le lien entre désactivation de telnet et changement du mot de passe de root sous OpenWRT, je ne préfère pas désactiver l'authentification par mot de passe dans le code mais plutôt dans le fichier de configuration de dropbear, une fois que j'aura importer ma clé publique dans le routeur. J'ai également conservé les deux algorithmes liés à l'authentification par clé publique, RSA et DSA car il m'arrive d'utiliser l'un ou l'autre.

Les autres options possibles (désactiver la résolution des IP en nom de domaine et créer un binaire qui combine le serveur et le client) sont déjà activées par OpenWRT : c'est l'objet des deux premières lignes de la rubrique Build/Configure.

Compiler le nouveau dropbear

Avant de compiler quoi que ce soit, fermez puis rouvrez votre session. Si vous ne le faites pas, vous aurez des erreurs sans queue ni tête (CDPATH ...). Ceci n'est à faire que la première fois, à la suite de l'installation des paquets prérequis. Certainement un problème de variables d'environnement mais je n'ai pas plus d'informations.

Quelles que soient les modifications que vous effectuez sur le Makefile, pensez à incrémenter la variable "PKG_RELEASE" de celui-ci avant de lancer la compilation. C'est une bonne pratique à prendre et ça évite des erreurs.

Vous ne pouvez pas compiler un seul paquet sans avoir compilé le toolchain d'abord. Nous allons utiliser la commande suivante afin d'avoir une interface semi-graphique nous permettant de régler les options de la compilation :

~/backfire_10.03$ make menuconfig

Dans "Target system", nous choisirons "Broadcom BCM947xx/953xx" qui correspond à la déclinaison brcm47xx. Vous pouvez choisir la déclinaison brcm2.4 ("Broadcom BCM947xx/953xx [2.4]"). Votre choix n'affectera que très peu la suite de ce billet, tout au plus quelques chemin/noms de fichiers qui changeront.

À noter que les binaires des deux branches (brcm47xx et brcm2.4) sont compatibles. En tout cas, c'est ce que j'ai pu constater.

Nous ne toucherons à rien dans "Target profile". Ni dans "Target images" ni dans" Global build settings" ni dans "Advanced configuration options" ni dans "Image configuration". Nous ne nous occuperons pas non plus des options qui permettent de compiler les trucs spécifiques (SDK, toolchain, image builder). Et dans les rubriques qui restent, nous décocherons tout (touche "n") sauf dropbear. Cela dans le but d’alléger le téléchargement et la compilation des sources.

Ensuite, lançons la compilation avec la commande :

~/backfire_10.03$ make

Si une erreur survient, vous pourrez tentez de debugger la compilation en la relançant avec le paramètre "V=99", comme cela :

~/backfire_10.03$ make V=99

Si vous compilez sur un processeur multicoeur, vous pouvez exploiter au mieux la puissance de celui-ci en utilisant le parametre "-j <nombre de coeur + 1>". Exemple pour un processeur quad core :

~/backfire_10.03$ make -j 5

Le système va télécharger les sources du toolchain et le compiler. Puis il téléchargera les sources de dropbear, les modifiera et les compilera. Enfin, il fabriquera le package ipkg de dropbear ainsi que les images des firmwares au format squashfs.

C'est le moment d'aller se chercher un deuxième café voir plus 😉 .

À la fin de la compilation, vous retrouverez le package de dropbear dans le dossier ./bin/brcm47xx/package.

Si jamais vous effectué des modifications, vous n'aurez pas besoin de tout recompiler : il vous suffira d'incrémenter la variable "PKG_RELEASE" présente dans le Makefile de dropbear et de lancer la commande suivante :

~/backfire_10.03$ make package/dropbear/compile

Les options précédemment évoquées ("-j" et "V=99" restent réutilisables).

Remplacer le binaire sur votre routeur

Ici, plusieurs méthodes sont encore possibles. Nous en exposerons deux.

Utiliser opkg

Il suffit de transférer le package sur le routeur avec la commande :

~/backfire_10.03$ scp ./bin/brcm47xx/packages/dropbear_0.52-5_brcm47xx.ipk root@192.168.1.1:/tmp

Puis de se connecter en SSH sur le routeur et d'y installer le package :

root@OpenWrt:~# opkg install /tmp/dropbear_0.52-5_brcm47xx.ipk

Vous n'avez plus qu'à relancer le serveur :

root@OpenWrt:~# /etc/init.d/dropbear restart

Cela devrait suffire mais, par prudence, je préfère rebooter le routeur.

Remplacer directement le binaire

Le package ipkg n'est qu'un fichier compressé avec gzip comme nous en informe la commande file :

file ./bin/brcm47xx/packages/dropbear_0.52-5_brcm47xx.ipk
./bin/brcm47xx/packages/dropbear_0.52-5_brcm47xx.ipk: gzip compressed data, from Unix, last modified: Sat Aug 13 15:34:30 2011

Il suffit donc de le décompresser :

~/backfire_10.03$ mkdir dropbear_uncompress && cd dropbear_uncompress
~/backfire_10.03/dropbear_uncompress$ tar -xf ../bin/brcm47xx/packages/dropbear_0.52-5_brcm47xx.ipk

Puis de décompresser le fichier data.tar.gz :

~/backfire_10.03/dropbear_uncompress$ tar -xf data.tar.gz

Votre binaire se trouve donc dans le dossier ~/backfire_10.03/dropbear_uncompress/usr/sbin. Il vous suffit de le transférer en utilisant SCP :

~/backfire_10.03/dropbear_uncompress$ scp ./usr/sbin/dropbear root@192.168.1.1:/tmp

Il ne vous reste plus qu'à remplacer le binaire en vous connectant par ssh :

root@OpenWrt:~# mv /tmp/dropbear /usr/sbin/dropbear
root@OpenWrt:~# chmod ugo+x /usr/sbin/dropbear

La deuxième ligne sert à rendre le binaire exécutable pour tout le monde. C'est les droits qui sont définis sur le fichier d'origine.

Vous n'avez plus qu'à relancer le serveur :

root@OpenWrt:~# /etc/init.d/dropbear restart

Cela devrait suffire mais, par prudence, je préfère rebooter le routeur.

Si vous venez de réussir votre première compilation croisée en suivant ces explications, félicitations 😀 .

Intégrer notre dropbear modifié dans une image de firmware au format squashfs (= créer un firmware personnalisé)

Cela permet de ne pas avoir à réinstaller votre version modifiée de dropbear (en supposant que vous ayez gardé le binaire que vous avez compilé) lorsque vous réinstallez le firmware suite à une erreur trop importante. Nous évoquerons ce point dans un prochain billet. Néanmoins, pour ceux qui veulent avoir un aperçu : Fonera 2 : Personnaliser, compiler, régénérer OpenWRT sur KubuntuBlog.

Néanmoins, la recompilation de dropbear n'est toujours pas suffisante. Combinée à la première solution, elle permet de réduire à 3 le nombre d'essais de mot de passe par connexion. Donc, 6 essais par jour pour les meilleurs bots (et toujours 2mdp/jour pour les plus mauvais). C'est toujours mieux que 20 mais ces 6 essais consomment toujours des ressources inutiles et m'énervent toujours.

Utiliser le port knocking

Présentation du concept

Encore un concept logiciel qui, à l’instar des sémaphores/jetons, prouve qu'on n’invente rien en informatique : on s'inspire de la réalité. Qui n'a jamais joué à l'espion avec un toc-toc secret pour rentrer dans le QG durant son enfance ? 😀 Comment ça je suis seul ? 😮 Menteurs !

Si vous ne savez pas ce qu'est le port knocking, voir : port knocking sur Wikipedia en.

Le port knocking est une technique que je connais depuis pas mal de temps mais que je n'avais jamais mis en pratique. Par contre, ce que je ne savais pas, c'est que le concept avait évolué pour être plus sécurisé : on a maintenant le Single Packet Authorization qui permet de transmettre la séquence de manière chiffrée. Cela empêche une attaque de l'homme du milieu qu'il est possible de faire avec un port knocking classique. A savoir aussi, une adaptation du port knocking peut également servir à dissimuler un point d’accès WiFi beaucoup plus efficacement que par le simple fait de cacher le SSID. Pour plus d'informations à ce sujet, voir : Sécuriser un réseau WiFi avec Wknock (Laurent Oudot - Blackhat 2005) - secuobs.com.

Bien que l'auteur de knockd s'en défendent, je vois le port knocking comme une sécurité par l'obscurité : on masque les ports en espérant que personne ne voit la porte d'entrée derrière le voile. C'est pour cela qu'il ne faut pas se reposer uniquement sur un logiciel de port knocking. Mais ces logiciels peuvent être utiles pour rajouter une couche de protection (et donc de failles (rappelez-vous : un logiciel sans bugs/failles est un logiciel insuffisamment testé)).

Quoi qu'il en soit, seuls les paquets wknock et knockd sont disponibles en package pré-compilés pour OpenWRT. Nous ne verrons donc pas de Single Packet Authorization à moins que quelqu'un compile le paquet pour OpenWRT, bien entendu. Pour ceux qui se le demande, knockd est évidemment sous licence libre (GNU GPL).

Édit du 25/08/2011 à 2h35 :
Attention : knockd a tendance à faire planter mon routeur lors de son démarrage. Cela arrive environ 3 fois sur 4. Cela peut être énervant donc je préfère vous prévenir. Je ne me suis pas penché sur l'origine de ce problème. Mais ne vous inquiétez pas, si vous utilisez la déclinaison brcm47xx, le watchdog se chargera de redémarrer le système pour arrêter le plantage. Mais cela prend un peu de temps (par défaut : 1 minute + le temps du boot).
Fin de l'édit

Installation

Vous devriez être habitué maintenant :

opkg update && opkg install knockd

Configuration de knockd

La configuration s'effectue depuis le fichier /etc/knockd.conf. Voici le contenu que je vous propose :

[options]
	UseSyslog
	interface	= eth0.1
 
[opencloseSSH]
	sequence		= 2222:tcp,3333:udp,4444:tcp
	seq_timeout		= 2
	tcpflags		= syn,ack
	command			= /usr/sbin/iptables -t filter -I INPUT -i eth0.1 -s %IP% -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
	cmd_timeout		= 5
	stop_command		= /usr/sbin/iptables -t filter -D INPUT -i eth0.1 -s %IP% -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT

Explications :

• UseSyslog permet d'envoyer le journal (les tentatives) au démon syslog. Cela permet donc de grouper le journal de knockd avec les autres journaux du système, ce qui les rend plus faciles à lire et à exporter. Si vous préférez écrire le journal de knockd dans un autre fichier, utilisez la directive "logfile". À noter que rien ne vous empêche d'utiliser les deux méthodes d'enregistrement du journal en même temps.
• interface permet de spécifier l'interface sur laquelle knockd doit écouter. Par défaut, il tente d'écouter sur toutes les interfaces et bloque sur eth0 avec le message d'erreur suivant : "could not get IP address for eth0". Ce qui est normal puisque eth0 ne peut pas être utilisé directement mais par le biais d'eth0.1 ou de br-lan puisqu'elle fait partie d'un bridge.
• [opencloseSSH] permet de définir un service. Mettez le nom que vous voulez.Évidemment, vous pouvez définir plusieurs services, avec des séquences différentes.
• sequence permet de définir les ports auxquels nous frapperons et dans quel ordre nous les frapperons. Comme vous le constatez, vous pouvez mixer des ports tcp et udp. Vous pouvez également mettre le nombre de ports que vous souhaitez. Je vous conseille vivement de mettre une combinaison plus robuste que celle de cet exemple.
• seq_timeout définit le délai après lequel la séquence est abandonnée si elle n’a pas été menée à terme. Vous devriez la régler en fonction de l'activité réseau de votre routeur. En effet, s’il y a trop d'activité, les paquets du knock pourraient être dispersés et traiter trop tard.
• tcpflags permet de spécifier à knockd de ne prêter attention qu'aux paquets marqués avec les drapeaux définis.
• command est la commande qui sera lancée lors de la réussite du knock. Ici, elle ouvre le port SSH, seulement pour l'IP ayant réussi le knock. Si votre routeur à une IP fixe sur l’interface WAN, vous pouvez rendre la règle plus spécifique en ajoutant le paramètre "-d <ip_wan>".
• cmd_timeout est le temps après lequel le knock n'est plus considéré comme étant valide. Ici, il faut juste spécifier assez de temps pour lancer une connexion sur le port ouvert par le knock.
• stop_command est, bien entendu, la commande qui sera exécutée dès que le knock ne sera plus valide. Ici, elle ferme le port.

Note : j'ai honteusement pompé et adapté ce fichier de configuration depuis le man knockd.

Configuration d'iptables

Regardons la règle qui nous ouvre le port SSH : elle accepte une nouvelle connexion dans l'état NEW, en provenance d'une machine bien définie, à destination du port tcp/22 du routeur à condition que le paquet provienne de l'interface WAN. Cela signifie que les paquets suivants seront ignorés et donc la connexion perdue. Évidemment, nous considérons que la politique par défaut de la chaine INPUT est DROP. De plus, après le timeout, knockd refermera cette porte d'entrée.

Il faut donc ajouter une règle dans la chaine INPUT qui autorise les connexions établies et à destination du port tcp/22 du routeur :

iptables -t filter -I INPUT -i eth0.1 -p tcp -m state --state ESTABLISHED -m tcp --dport 22 -j ACCEPT

Même combat si vous filtrer les sorties (ce qui est une bonne pratique) : il faudra créer, dans la chaine OUTPUT, une règle qui accepte les connexions établies provenant du port tcp/22 du routeur et qui sont à destination de l'interface WAN :

iptables -t filter -I OUTPUT -o eth0.1 -p tcp -m state --state ESTABLISHED -m tcp --sport 22 -j ACCEPT

Je suis au courant que mes règles ne respectent pas les chaînes introduites par OpenWRT. Mais, n'utilisant plus ces chaines, je vous mets les chaines par défaut plutôt que de vous imposer les miennes. Libre à vous de les remplacer pour convenir à votre configuration.

Script d'init

Nous allons créer un script d'init (sous /etc/init.d). Ces scripts sont toujours pratiques pour relancer rapidement un démon (/etc/init.d/knockd restart est quand même plus pratique que les commandes kill `pidof knockd|sed "s/$$//g"` + knockd -d & ou équivalents). OpenWRT n'en intègre pas pour l'instant pour knockd. Néanmoins, nous ne créerons pas de lien symbolique vers ce script dans le répertoire /etc/rc.d/ afin que knockd ne soit pas lancé deux fois de suite (voir ci-dessous).

Voilà le script que je vous propose (/etc/init.d/knockd) :

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

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

DAEMON=/usr/sbin/knockd
NAME=knockd
DESC="Port knocking"
 
start() {

	echo "Starting $DESC: $NAME"
	logger Starting $DESC: $NAME
	`$DAEMON -d &`

}
 
stop() {
	echo "Stopping $NAME"
	logger Stopping $NAME
	kill `pidof $NAME|sed "s/$$//g"` > /dev/null 2>&1

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

	start
}

J'ai pompé et adapté ce script sur celui fourni par/pour dnscache.

Si vous avez configurer knockd pour utiliser syslogd, alors les commandes logger, qui, pour rappel, permettent d'enregistrer un message dans les logs du système, ne sont pas utiles puisque knockd écrira de lui-même des messages lors de ses démarrages/arrêts.

Il faudra penser à rendre ce script exécutable :

chmod ugo+x /etc/init.d/knockd

Démarrage automatique

Tout comme dnscache, knockd est inefficace après une déconnexion qui surviendrait sur l'interface WAN. Nous allons donc créer un script pour hotplugd. Pour ceux qui ne comprennent pas, voir le billet sus-linké.

C'est pour cela que l'on ne devait pas faire de lien symbolique vers /etc/init.d/knockd dans /etc/rc.d toute à l'heure : hotplud lancera knockd automatiquement au démarrage de la machine, pas besoin de le lancer une deuxième fois par erreur (voir le billet sus-linké pour des explications détaillées).

Voici donc le script pour hotplugd que je vous propose (/etc/hotplug.d/iface/30-dknock) :

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

then
	KNOCKD_RUNNING=`ps  | grep knockd | grep -v grep`

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

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

	esac
fi

Ouvrir le port ssh sur un client GNU/linux Debian

Il faut installer le logiciel knock :

# apt-get install knockd

Puis, lorsque vous voudrez vous connecter en SSH à votre routeur, il faudra exécuter la commande :

$ knock <séquence> && ssh root@OpenWRT

Par exemple, pour l'exemple configuré ci-dessus, il faudrait exécuter :

$ knock 2222 3333:udp 4444 && ssh root@OpenWRT

Pour aller plus loin

C'est ici que je m'arrête : je pense que la configuration actuelle de knockd couplée à l'utilisation d'une authentification par clé publique/privée suffira à protéger mon accès ssh. De plus knockd empêchera les attaques par bruteforce. Et si un jour la séquence est découverte, vous en serez informé dans les logs (= vous verrez les tentatives de connexions frauduleuses au démon SSH) et vous pourrez la changer.

Mais si vous voulez plus de sécurité, vous pouvez utiliser la fonctionnalité one time sequence de knockd. Il s'agit d'un fichier qui contient autant de séquences que vous voulez. Chaque fois qu'une séquence est validée, elle n'est plus acceptée. Ainsi, une séquence n'est valable qu'une seule fois (sauf exceptions). Voir l'exemple dans le man knockd. Pour vous simplifier l'utilisation de cette fonctionnalité, je vous conseille l'utilisation des knockd-utils (GNU GPL). Rien ne vous empêche dès lors d'imaginer une cron qui génère régulièrement un fichier de séquence sur l'ordinateur depuis lequel vous souhaitez accéder à votre routeur puis qui vous en stocke un exemplaire dans votre home et qui en upload une copie, via scp, sur votre routeur et relance le démon knockd pour qu'il prenne en compte ce fichier.

Rien ne vous empêche également de porter, sur OpenWRT, un démon qui fait de l'encrypted port knocking tels que fwknop (GNU GPL) ou cryptknock (flou sur la licence mais sources disponibles).

Authentification par clé publique/clé privée

C'est une fonctionnalité de base de SSH et elle permet d'éviter de la manière la plus simple du monde le problème du bruteforçage de votre mot de passe. On n'utilise plus un mot de passe mais une clé privée et une clé publique. Cette méthode permet, via les agent ssh de s'authentifier en toute sécurité sans
pour autant saisir un mot de passe à longueur de journée. Elle permet également l'automatisation de tâches (puisque la connexion ne requiert plus de mot de passe). On peut même faire de l'administration à travers plusieurs machines (voir : ssh agent forwarding).

Je ne vous expliquerai pas comment mettre en place une telle authentification puisque les gars d'openWRT l'ont déjà fait : Dropbear Public Key Authentication - OpenWRT Wiki. Si vous êtes un peu perdu, je vous conseille cette lecture : La connexion sécurisée à distance avec SSH - Site du Zéro.

Je préciserai juste que vous pouvez très bien utiliser des clés RSA d'une longueur supérieure à 1024 bits (ex. : 2048 bits). Il suffit d'utiliser un paramètre supplémentaire lors de la génération :

ssh-keygen -t rsa -b 2048

Les clés DSA doivent en revanche, avoir une longueur strictement égale à 1024 bits pour respecter le FIPS 186-2.

Si vous générer votre clé depuis puttygen, n'oubliez pas de copier le début (ex. : "ssh-rsa") sinon cela ne fonctionnera pas.

ÉDIT du 16/08/2011 à 14h50 :
Je précise également que si vous créez des comptes invités/non-root/sans droits d'administration, les clés publiques permettant de se connecter avec ces comptes devront se trouver dans le fichier ~/.ssh/authorized_keys de chacun. Exemple : vous créez un compte "toto" dont le home directory est /home/toto. La clé publique de toto devra donc se trouver dans le fichier /home/toto/.ssh/authorized_keys pour que l'authentification par clé publique soit acceptée. Source : Dropbear PublicKey Authentication for multiuser setup sur forum.openwrt.org.

Fin de l'édit

Ressources

Voici les sites sur lesquels j'ai honteusement appris, pompé, adapté mais que je n'ai pas encore cité dans ce billet :

• Port knocking et spa:Port knocking - Aldeid
• Le PortKnocking - Université Paris-Est Marne la Vallée
• Port Knocking : sécuriser l'accès à un port - Documentation Ubuntu Francophone
• Is port knocking an obscurity hack? - portknocking.org

Table des matières

Un article rapide sur comment utiliser le protocole NTP sur OpenWRT.

Pourquoi ?

Cette question en cache plusieurs :

Pourquoi synchroniser son routeur avec un serveur de temps ?

Comme pour le reste des équipements : si vous hébergez un serveur, cela peut-être utile pour constater l'heure d'une connexion (notamment en cas de problème). Vous pouvez aussi avoir des traces plus fiables d'une compromission du système grâce à cette synchronisation.

Mon routeur est déjà à jour, pourquoi utiliser NTP ?

En effet, OpenWRT utilise le vénérable rdate qui est inclus dans Busybox. Ce logiciel utilise le vénérable Time Protocol. Mais rdate change l'heure de manière abrupte, ce qui n'est pas forcement une bonne idée notamment en ce qui concerne les sessions. Dans notre cas, nous pouvons citer les sessions suivantes qui seront perdues dans le cas d'un changement brutal de l'heure : luci, SSH, le drop pendant x temps de iptables, les connexions actives et j'en passe. De plus, NTP est plus précis que TP.

Deux modes possibles

En effet, vous pouvez choisir d'être seulement un client NTP ou d'être un client et un serveur NTP. Dans le second cas, vous utiliserez ntpd (aussi disponible sous OpenWRT). Dans le premier cas, vous utiliserez, de préférence ntpclient. Même s'il y a moyen de bloquer l'accès à votre démon ntpd, il vaut mieux avoir un programme qui fait que ce que l'on attend de lui (pour des raisons maintes fois évoquées dans ce blog) et donc utiliser ntpclient si l'on souhaite n'avoir qu'un client.

ÉDIT du 24/08/2011 à 16h30 : Si vous voulez comprendre les motivations qui peuvent vous amener à installer un serveur NTP plutôt qu'un client et/ou si vous voulez installer un serveur NTP, reportez-vous à ce billet : Installer un serveur NTP sur OpenWRT.

Fin de l'édit

Dans la suite de ce billet, je souhaite avoir uniquement un client et j'installe donc ntpclient.

Let's go !

D'abord on installe le client NTP

[opkg update]
opkg install ntpclient

Ensuite on le configure

Le logiciel est déjà configuré mais je souhaite utiliser des serveurs NTP plus reconnus que ceux d'OpenWRT.

uci set ntpclient.@ntpserver[0].hostname=ntp-p1.obspm.fr
uci set ntpclient.@ntpserver[1].hostname=0.fr.pool.ntp.org
uci set ntpclient.@ntpserver[2].hostname=2.fr.pool.ntp.org
uci delete ntpclient.@ntpserver[3]

J'indique que le premier serveur à interroger est celui de l'observatoire de Paris (strate 1), que le deuxième et le troisième serveur à interroger sont ceux du pool ntp.org. Enfin, je supprime le quatrième serveur proposé par OpenWRT. Je pense que 3 serveurs sont déjà de trop alors un quatrième ...

Le reste des paramètres conviennent très bien :
ntpclient.@ntpclient[0].interval=600 -> on check la synchronisation toutes les 10 minutes. Comme on n'est pas sur un serveur en production, on peut même réduire cette valeur si on le souhaite.

Pour les options du drift, on ne touche à rien. Voir à quoi sert le driftfile.

Ensuite, on désactive rdate

La manière la plus propre de le faire serait de compiler busybox sans le support de rdate. Je vous laisse chercher plus de détails sur notre ami Google.

Moi, je choisis une méthode plus brutale et plus sale :

find / -name "*rdate*" -exec rm -f {} \;
uci delete system.@rdate[0]

Dans un premier temps, je recherche tous les fichiers qui contiennent rdate dans leur nom et je les supprime. 4 fichiers sont trouvés dont 2 uniques : l’exécutable et son script de lancement (/etc/hotplug.d/iface/40-rdate). Les deux autres fichiers sont des copies dans /rom, le système en lecture seule donc la suppression va échouer.

Ensuite, je supprime les informations de configuration de rdate.

Vous pouvez rebooter votre routeur, en changeant l'heure auparavant, juste pour voir :

date -s 201106082300
reboot

Au reboot, vous pouvez constater que l'heure est correcte (commande date sans paramètres) et que le démon tourne (commande ps | grep ntpclient).

Toutes les 10 minutes, l'horloge de votre routeur sera synchronisée.

Enjoy 😛