GuiGui's show

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

• "NTP, une simple histoire de temps" - GNU/Linux Magazine/France numéro 126 - Avril 2010.
• man ntp.conf.
• Quick HOWTO : Ch24 : The NTP Server - Linux Home Networking.
• Manuel d'Openntpd.
• FAQ Chrony.
• ntpdate from cron -- DON'T DO THAT!
• La documentation officielle du serveur ntp de ntp.org

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 :

• Debugging Linux Kernel Lockup / Panic / Oops : echo -n V > /dev/watchdog pour stopper le watchdog .
• Pastbin : echo f > /dev/watchdog .

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) :

• watchdog script for openwrt - Desra Blog : un script qui redémarre un routeur sous OpenWRT en cas de coupure de la connexion internet. Pour cet usage, je pense qu'il vaut mieux utiliser hotplugd.
• Asterisk18SurOpenWRT - Le Wiki Koumbit : un script qui tente de redémarrer le serveur Asterisk si jamais le processus venait à être stoppé.

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 🙂 .

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

Comme vous le savez si vous suivez ce blog, j'ai installé un résolveur DNS sur mon WRT54GL équipé d'OpenWRT. Néanmoins, je rencontre un souci.

Problème

Dés qu'une déconnexion d'internet survient, dnscache n'est plus en mesure de résoudre les noms de domaine : il tourne encore, mais ne répond plus aux requêtes. Bien sûr, ce comportement est normal durant la coupure mais plus dès que la connexion a été rétablie. Mon routeur obtient son adresse IP WAN auprès de mon modem via le protocole DHCP.

Si vous êtes sur votre LAN quand la déconnexion survient, pas de problèmes : il suffit de se connecter au routeur via SSH et de lancer la commande suivante pour que dnscache reprenne son service :

/etc/init.d/dnscache restart

C'est déjà très ennuyeux de faire cette manipulation à chaque fois, même si on n'a pas non plus une déconnexion du net tous les jours. Mais imaginez maintenant que vous ne soyez pas sur votre LAN et que votre FAI vous attribue une IP dynamique... Hé oui, le plantage de dnscache entraine les scripts de dynamic DNS dans sa chute. En effet, ceux-ci utilisent une résolution DNS pour comparer l'IP attribuée actuellement à l'interface WAN et celle enregistrée dans le nom de domaine afin de la mettre à jour éventuellement. Cela provoque un blocage total : l'IP n'étant plus à jour dans le nom de domaine, vous ne pouvez plus vous connecter à votre routeur depuis l'extérieur.

Chercher une solution à ce problème est sur ma TODO list depuis un moment ... Vous connaissez la suite. Quoi qu'il en soit, je me suis enfin attaqué à ce problème et voici la solution que je vous propose.

Recherche d'une solution

Vous pensez à une cron qui relancerait dnscache à intervalle régulier ? Ce n'est pas une bonne idée : outre les ressources que cela consommerait, cela provoquerait la perte des associations nom de domaine <=> IP enregistré en mémoire et obligerait donc dnscache à refaire les résolutions des noms de domaine que vous avez pourtant déjà demandés. Vous perdrez ainsi un peu de réactivité.

Vous pensez à une cron qui lancerait un script qui vérifierait (avec nslookup ou dig) que le serveur ne répond plus avant de le relancer ? On progresse : vous avez éliminé le problème le plus important. Mais il reste encore le problème des ressources consommé inutilement par chaque vérification.

En fait, ce qu'il nous faudrait, c'est quelque chose qui relance le résolveur dès qu'une déconnexion est détectée. Ha ! On tient une piste. Sur OpenWRT, comme sur d'autres OS, il existe un démon qui est capable d'effectuer des actions dès qu'il capte un événement matériel (un bouton est pressé, un périphérique USB est branché, ...). Il se nomme hotplugd et il est également capable de lancer une action quand une interface réseau est activée (ifpup) ou désactivée (ifdown). "Et alors ?" vous demandez vous. La déconnexion du net provoquera un changement d'IP de l'interface WAN du routeur. Celui-ci est assimilé à une désactivation puis à une activation de la carte réseau. C'est d'ailleurs avec cette méthode qu'est lancé le script pour le dynamic dns (ddns) ou bien encore ntpclient.

Mise en place d'une solution

Vous l'avez compris, il suffit de créer un script qui relance le résolveur dns avec la commande /etc/init.d/dnscache restart dès que le statut de l'interface WAN change.

Deux méthodes sont possibles :

• On lance la commande /etc/init.d/dnscache restart dès que le statut de l'interface passe à "activée".
• On lance la commande /etc/init.d/dnscache stop dès que le statut de l'interface WAN devient "désactivée" puis on lance la commande /etc/init.d/dnscache start dès que l'interface WAN est réactivée

Il n'y a probablement aucune différence entre ces deux méthodes. Mais pour ma part, j'ai choisi la deuxième méthode.

Il suffit de placer le script suivant dans le dossier /etc/hotplug.d/iface/ :

#!/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

Ce script est un mélange entre celui proposé par/pour ntpclient et celui proposé par/pour le script ddns.

Lecture : si l'interface ayant provoqué l'appel à ce script est bien l'interface WAN, alors on vérifie que le processus dnscache est bien présent sur la machine. Si l'interface vient de s'activer et que la chaine $DNS_RUNNING est vide (sous-entendu que le processus dnscache n'est pas présent sur le routeur), alors on lance le résolveur DNS. Si l'interface vient d'être désactivée, et que la chaine $DNS_RUNNING n'est pas vide (sous-entendu le processus tourne), alors on stoppe le résolveur DNS.

Quel nom donner à ce script ? Cela dépend de votre configuration. En effet, le nom du script détermine l'ordre dans lequel il sera appelé par hotplugd. Il est nécessaire de relancer le résolveur avant qu'un programme dépendant de lui ne soit relancé. Dans mon cas, ntpclient et ddns ont besoin de lui. ntpclient est relancé vers la fin ("20-ntpclient") et ddns est relancé en dernier ("25-ddns"). C'est pour cela que j'ai appelé mon script "15-dnsd".

Attention à ne pas appeler votre script "15-dnscache" par exemple. Sinon, $DNS_RUNNING contiendra toujours quelque chose puisque la commande "grep dnscache" retournera toujours au moins un élément : votre script. Ainsi, les conditions ne fonctionneront pas et dnscache ne sera pas relancé.

ÉDIT du 11/08/2011 à 23h17 : Le fait d'avoir créé un script pour que le démon hotplug démarre et arrête dnscache en fonction des déconnexions survenant sur l'interface WAN provoque le fait que dnscache sera lancé par hotplug au démarrage du routeur. Mais, étant donné qu'un lien est toujours présent dans le dossier /etc/rc.d, dnscache pourrait être lancé une deuxième fois. En effet, notre script hotplug vérifie que le démon n'est pas déjà lancé mais le script d'init ne le vérifie pas. Il suffit donc que dnscache soit démarré par hotplug puis par init pour risquer de voir apparaître des problèmes. Pour l'instant, je n'ai eu aucun problème mais il vaut mieux prévenir que guérir. Plusieurs solutions sont possibles, la plus simple étant :

/etc/init.d/dnscache disable

Ainsi, dnscache ne sera lancé que par hotplugd.

Fin de l'édit

ÉDIT du 13/08/2011 à 19h30 : Si vous voulez modifier ce script et que vous souhaitez le tester sans provoquer une déconnexion physique de l'interface WAN, vous pouvez simuler l'action de hotplugd de la manière suivante :

~# ACTION=ifdown
~# INTERFACE=wan
~# export ACTION
~# export INTERFACE
~# /bin/sh /etc/hotplug.d/iface/15-dnsd
~# ACTION=ifup
~# /bin/sh /etc/hotplug.d/iface/15-dnsd

Fin de l'édit

Bonus : faire en sorte que dnscache inscrive ses démarrages et ses arrêts dans le journal système

Certains démons (ntpclient par exemple) écrivent des informations dans le journal du système (accessible via la commande "logread" ou depuis l'interface web LuCI ("Status -> Journal système")) afin d'indiquer leur lancement/arrêt. Cela est pratique en cas de problème. dnscache ne fait pas ceci : il affiche un message uniquement lors de son premier lancement par le système. Nous allons remédier à cela.

Pour écrire un message dans le journal système, il suffit d'utiliser la commande "logger". Exemple :

root@OpenWRT:~# logger test de l\'écriture dans le journal système
root@OpenWRT:~# logread
[...]
Aug  8 09:54:04 OpenWRT user.notice root: test de l'écriture dans le journal système

Il suffit donc de modifier le script de démarrage de dnscache (/etc/init.d/dnscache) pour faire inscrire un message dans le journal système.
À la fin de la fonction start(), il suffit de rajouter :

logger starting dnscache

Et à la fin de la fonction stop(), il suffit de rajouter :

logger stopping dnscache

Cette modification m'a été inspirée par le script de démarrage/arrêt de ntpclient.

Enjoy 8)

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 😛