GuiGui's show

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 😛

Table des matières

J'ai décidé de m'équiper afin de recevoir les chaînes de la TNT sur mon ordinateur portable (dans un premier temps), puis sur un ordinateur de bureau (un peu plus tard).

Expression des besoins

• Je veux recevoir la télévision sur un ordinateur portable et sur un ordinateur de bureau. Cela exclu donc les cartes pci/pcmcia. Il reste donc les tuners USB ou les tuners firewire à ma disposition. Ne disposant pas de prise firewire sur les deux ordinateurs, il ne me reste plus que l'USB.
• Je veux un périphérique compatible GNU/Linux.
• Je veux recevoir la TNT.
• Je veux deux tuners.
• Je veux aussi recevoir les chaines en haute définition. Cela n'est pas un problème en soit : même les cartes qui ne sont pas estampillées "TNT HD ready" sont compatibles. Je vous laisse comprendre pourquoi : Quid de la réception TNT HD sur PC ?

Trouver un tuner TNT USB

Pour cela, il faut :

1. Consulter les sites des distributeurs de ce genre de matériel : Hauppauge, Terratec, Leadtek, etc. et trouver un modèle qui répond aux critères ci-dessus.
2. Consulter la section consacrée aux tuners USB compatible DVB-T sur le wiki du projet LinuxTV et vérifier que le tuner choisit en 1 dispose d'un pilote sous GNU/Linux.
3. Vérifier sur des sites marchands que le produit est toujours commercialisé.

Personnellement, j'ai choisis la Terratec T5.

S'équiper du matériel supplémentaire

Généralement, les tuners USB sont fournis avec une/des antenne(s) d'intérieur. Comme au temps de l'analogique, ces antennes sont clairement insuffisantes, même si vous comptez vous en servir dans une ville où il y a un émetteur TNT. Après essais, je peux confirmer que la T5 n'échappe pas à cette règle. Il vaut mieux la brancher sur une antenne extérieure (de toit).

Comme la T5 est équipée de deux tuners, et à moins que vous n'ayez deux prises TV murales, il vous faut un té de répartition coaxial que vous brancherez à votre prise murale.

Attention : regardez bien le format de votre prise murale avant d'acheter votre té car celui-ci a changé il y a quelques années pour passer à un connecteur mâle. Dans mon cas, mes prises murales sont récentes et ont un connecteur mâle dans les deux endroits où je souhaite regarder la TV donc j'ai pris un té avec une entrée femelle et deux sorties mâles.

Ensuite, il vous faut deux câbles coaxial qui serviront à relier le té aux deux tuners de la T5. Du côté de la T5, il faut que le câble dispose d'un connecteur mâle. De l'autre côté, cela dépend de votre té. Le mien a deux sorties mâles, donc mes câbles doivent avoir un connecteur femelle de ce coté là. Après, il faut savoir que des adaptateurs sont généralement fournis avec le câble et donc qu'il y a moins de chance que vous ne puissiez pas brancher le câble. Concernant le diamètre des connecteurs : du côté de la T5, nous avons des connecteurs d'un diamètre de 9.5mm.

C'est tout ce dont vous aurez besoin.

S'équiper des logiciels nécessaires

Terratec ne fournit ni pilote ni logiciel pour GNU/Linux pour sa T5. Nous n'avons pas besoin de pilote sous GNU/Linux car il est déjà intégré au noyau depuis la version 2.6.29 (voir le wiki LinuxTV), mais, en revanche, il nous faut un logiciel. J'avoue que je n'ai pas été très original sur ce coup : j'utilise KDE et j'ai souvent entendu parler de Kaffeine en bien donc j'ai décidé d'essayer ce logiciel. L'essai a été convaincant : il fait ce que je veux. Je vous le recommande.

Si il vous intéresse :

sudo apt-get install kaffeine

Ouvrez Kaffeine, ouvrez le module dédié à la télévision. Un message de notification vous informera si des paquets supplémentaires sont à installer. Si c'est le cas, installez-les puis fermez Kaffeine.

C'est finit pour la partie logicielle.

Installation

Je vous laisse réaliser les branchements physiques car je ne pense pas que vous ayez besoin d'aide.

Au préalable

Connectez ensuite la T5 à votre ordinateur. Ouvrez Kaffeine et son module télévision numérique. Cliquez sur l'icône "Configurer la télévision". Vous remarquez qu'il y a deux onglets : "Périphérique 1" et "Périphérique 2" qui correspondent aux deux tuners de la clé. Je vous conseille de leur donner un nom différent comme par exemple "Tuner 1" et "Tuner 2" afin de les différencier par la suite. Valider les modifications.

Recherche automatique des chaînes

Cliquez sur le bouton "Canaux" qui se situe à coté de celui de la configuration. Choisissez le premier tuner et lancez la recherche automatique des chaînes. A la fin de celui-ci, sélectionnez les chaines que vous voulez dans la liste de droite et cliquez sur le bouton "Ajouter les sélectionnés". Cliquez sur le bouton "OK" sinon les chaines ne seront pas mémorisées.

Pour profiter du double tuner

Dans la liste des chaines, et pour chaque chaine, changez son nom pour indiquer le tuner de provenance. Par exemple : "TF1" devient "TF1 T1" si vous avez obtenu la liste des chaînes via le premier tuner. Vous savez ainsi que cette chaîne est TF1 et qu'elle est reçue via le tuner 1 de la carte. Ce renommage des chaines peut être effectué plus facilement depuis la fenêtre "Canaux" (celle où vous lancez la recherche des chaînes).

Refaites une recherche des chaines mais en utilisant cette fois-ci le deuxième tuner. Renommez les chaînes de la même façon pour indiquer que celle-ci viennent du deuxième tuner. Vous obtenez une liste dans laquelle chaque chaîne apparaît en double : une via le tuner 1, une via le tuner 2.

Cette méthode n'est peut-être pas la meilleure mais elle me convient parfaitement. Libre à vous d'en trouver une meilleure.

Classer les chaînes

Retournez dans la fenêtre "Canaux". Dans la liste de gauche, vous pouvez glisser-déplacer une chaine. Un message vous informera qu'un tri sera effectué : approuvez. Continuez votre classement en faisant glisser-déplacer les chaînes. N'oubliez pas de cliquer sur le bouton "OK" sinon le classement est perdu.

Enregistrement et double tuner

Pour réaliser un enregistrement immédiat et continuer à regarder la même chaîne : cliquez simplement sur le bouton représentant une disquette.

Pour réaliser un enregistrement immédiat puis regarder une autre chaîne : cliquez sur l'icône représentant une disquette puis changez de chaîne en prenant le tuner inutilisé (d'où l'intérêt d'avoir nommé les chaînes en fonction du tuner qui la reçoit).

Pour réaliser un enregistrement immédiat de deux chaînes : enregistrez la première chaîne en cliquant sur le bouton en forme de disquette. Cliquez ensuite sur le bouton "Programmation d'un enregistrement" (le calendrier) et ajoutez un nouvel enregistrement en choisissant une chaîne du tuner inutilisé. Vous pouvez bien entendu regarder l'une ou l'autre des chaîne que vous enregistrez.

Pour programmer un ou plusieurs enregistrements : vous savez faire : utilisez le bouton "Programmation d'un enregistrement".

Cas de la haute définition

Sur les chaînes du multiplex R5 (TF1 HD, France 2 HD, M6 HD), le codage du son est réalisé grâce au codec E-AC3 et son extension spectrale. Cela pose un soucis dans un certain nombre de logiciels qui ne proposent donc pas le son sur ces chaînes.

Arte HD, diffusé sur le R4, n'a pas ses pistes audio encodées en E-AC3 et fonctionne sans aucun problème.

Personnellement, j'utilise la T5 principalement dans une région dans laquelle le R5 n'est pas encore en service et avec un ordinateur portable dont la puissance est insuffisante pour décoder un flux haute définition donc je n'ai pas encore cherché comment faire.

Malgré tout je vous donne des tuyaux : MythTV semble être capable de décoder l'E-AC3. FFmpeg aussi. La propagation aux logiciels se basant sur ffmpeg ne devrait plus être longue.

Forcer le 16/9 sur les chaînes qui n'y sont pas encore passé

Il suffit de cliquer droit sur la vidéo, d'aller dans "Vidéo" puis "Rapport hauteur/largeur" puis de mettre "16:9".

Et si je voyage dans plusieurs régions ?

Hé oui, les fréquences ne sont pas les mêmes. Il vous suffit d'appliquer la méthode que nous avons vu pour le double tuner : faire une recherche et nommer les chaînes en fonction de la région.

EDIT 14/02/2011 à 22h30 : La solution ci-dessus n'est pas bonne car Kaffeine supprime automatiquement les chaines identiques d'un même tuner. Je ne sais toujours pas sur quoi il se base pour faire la comparaison vu que les fréquences ne sont pas identiques entre les régions. Néanmoins, si la méthode ci-dessus fonctionnait, elle supposerait d'avoir une liste des chaînes contenant le nombre de chaînes*le nombre de tuners*le nombre de régions. Autrement dit : cela ne serait pas pratique pour zapper.

Le mieux est de procéder ainsi :

1. Chercher les chaines de la première région.
2. Sauvegarder le fichier /home/votrelogin/.kde/share/apps/kaffeine/sqlite.db
3. Chercher les chaines de la deuxième région.
4. Sauvegarder le fichier /home/votrelogin/.kde/share/apps/kaffeine/sqlite.db avec un nom différent du premier, évidemment.

Ensuite, quand vous changez de région, vous n'avez plus qu'à copier le bon fichier et à lancer Kaffeine.

Et la télécommande de la T5, elle fonctionne sous GNU/Linux ?

Aucune idée, cela ne m'intéresse pas.

Fin

Mon seul regret à propos de la T5, c'est son packaging. Une boite en ferraille entourée d'un emballage en plastique rigide, cela a un coût qui hausse inutilement le prix de vente. De plus, ce n'est pas très "planète attitude" ;).

Mon seul regret concernant Kaffeine est le fait qu'il se définit comme application par défaut pour tous les fichiers multimédia et ce, sans me demander mon accord.

Pour conclure : si vous êtes le possesseur d'une Terratec 2400i DT, sachez qu'elle fonctionne sous GNU/Linux depuis environ 1 an : TerraTec Cinergy 2400i DVB-T sur LinuxTVWiki. Je vous ferai un petit billet lorsque j'aurais sortit l'ordinateur qui la contient des cartons.

Récemment, j'ai dépanné des Moldus de l'informatique. J'ai du :

• Faire reconnaitre une carte PCI Wifi achetée d'occasion par un Windows XP. Rien de bien sorcier ... sauf quand la carte en question n'a pas été vendue avec ses pilotes et que le nouveau propriétaire ignore sa marque/son modèle. Quand en plus la carte prend en charge uniquement le WEP, on se retrouve à expliquer pourquoi ce n'est pas une bonne idée de remplacer une clé USB Wifi qui gère le WPA2 par une carte PCI Wifi qui ne gère que le WEP et les conséquences que cela a sur la sécurité du réseau domestique. Mais, en étant un tout petit peu pédagogue, on s'en sort :).
• Faire en sorte que le lecteur/graveur CD/DVD reprenne du service. Là aussi, rien de bien compliqué : le lecteur/graveur fonctionnait au boot de l'ordinateur et le gestionnaire des périphériques indiquait un code d'erreur 19 "Windows ne peut pas démarrer ce périphérique matériel car ses informations de configuration (dans le registre) sont incomplètes ou endommagées. (Code 19)". Il suffit ensuite de suivre l'aide de Microsoft et notamment la méthode n°1. Toutefois, je n'ai pas supprimé la clé mais toutes les valeurs s'y trouvant.
• Faire (encore) un peu de pédagogie et expliquer pourquoi ce n'est pas une bonne idée de fusionner les deux partitions qui étaient crées à l'origine sur le disque dur mais, au contraire, s'en servir pour séparer documents et système d'exploitation.

Mais surtout, et c'est le point principal de ce billet : comment définir une musique (au format MP3), transférée via Bluetooh, en tant que sonnerie sur un Samsung Galaxy S. Par défaut, on peut choisir la sonnerie parmi une liste restreinte. L'appareil est évidemment équipé avec un Android "untouched"/ "unrooted", si j'ose dire.

Comme à chaque fois que je ne sais pas, je me retourne vers le nain Ternet et son ami Google. J'apprend que, contrairement à ce qu'on m'avait dit, il ne faut pas un ordinateur pour transférer la sonnerie sur le mobile. Je sélectionne un tutoriel qui explique tout cela parmi tans d'autres : Mettre un MP3 en sonnerie/alarme/notification.

Il suffit de créer les dossiers depuis l'application de gestion des fichiers du téléphone puis de déplacer la musique voulue du répertoire "bluetooh" vers le répertoire créé. Il faut néanmoins adapter la dernière partie de ce tutoriel puisque les menus ne sont pas identiques entre un HTC et un Samsung. De plus, les sonneries peuvent faire plus de 30 secondes sans problème.