GuiGui's show

Par malheur, j'ai supprimé (pas formaté !) une partition du disque dur de mon ordinateur portable. Il s'agit de la partition qui contient Kubuntu et donc tous mes logiciels et tous mes réglages. Comme le stage 2 de GRUB 2 est aussi stocké sur cette partition, je ne peux plus booter, que ça soit sur Windows ou sous GNU/Linux. Le temps presse, je n'ai pas le temps de tout réinstaller et pourtant, j'ai besoin de mon GNU/Linux.

Évidemment, j'ai 4 copies de tous mes documents dans 4 disques de 1 To chacun, disposés dans des lieux géographiques différents mais pas une seule image disque de mes partitions ... Conclusion : Clonezilla c'est bon, mangez-en plus souvent !

La perte éventuelle de mes réglages me fait peur mais j'essaie de réfléchir ... Eurêka ! Je me souviens à présent ! Les données sont encore sur le disque. Ce qui a été effacé, c'est juste l'entrée décrivant la partition dans la table des partitions, elle-même contenue dans le MBR. Il suffit de restaurer cette entrée dans la table des partitions et on retrouvera notre partition.

Reste à savoir quel logiciel utiliser. Google n'est pas trop bavard. Mais je me souviens que TestDisk (dont j'ai déjà parlé dans ce blog) propose plein de fonctionnalités différentes.

Je cherche sur le wiki officiel de TestDisk (lien plus haut) et je trouve même un tutoriel : TestDisk Step By Step.

Je ressors mon LiveCD Backtrack 4 R1 du placard, je me connecte à internet dans l'intention d'installer TestDisk avec apt-get. Mais apt-get me signale que TestDisk est déjà installé. Cela confirme ce que je dis souvent : y'a tout dans Backtrack.

Je suis le tutoriel donné plus haut et je retrouve l'accès à ma partition qui contient Kubuntu.

Par contre, TestDisk a cru que la partition contenant mes documents était en FAT32 et a, de ce fait, corrigé la table des partitions. Au reboot, Kubuntu n'a pas pu monter la partition et j'ai dû appuyer sur S pour passer. La réaction de Kubuntu est normale : il n'y avait pas de cohérence entre ce qui est annoncé dans le fichier /etc/fstab (partition NTFS) et la réalité (signature FAT32 dans la table des partitions).

J'ai jonglé entre TestDisk et cfdisk mais je n'ai pas réussit à restaurer cette partition.

Néanmoins, étant donné qu'il me restait 3 copies de cette partition sur d'autres disques, je n'ai pas été jusqu'au bout et il y a obligatoirement une solution pour ceux qui chercheront jusqu'au bout.

À quoi peut bien servir la création d'un compte utilisateur sans droits mais avec un mot de passe sur OpenWRT ? Imaginons par exemple que vous utilisez votre routeur afin de réaliser des tunnels SSH ou plus si affinités : vous restez longtemps connecté à votre routeur, tout en étant authentifié avec le compte root, sans avoir besoin des droits que vous octroie ce compte. Côté sécurité, même Microsoft fais mieux. 😉

Cela peut aussi servir pour distribuer quelques comptes à des amis afin qu'ils puissent profiter des joies du port forwarding et du contournement d'un pare-feu sans tout casser.

Maintenant que je vous ai convaincus avec ces arguments subtils et percutants 😉 , voici la marche à suivre pour un compte nommé "guest" :

Créons un "home directory" pour ce compte (ça fais moins porchou que de lui donner /var) :

~# mkdir -p /home/guest

Éditons le fichier qui contient les utilisateurs autorisés à ce connecter au système :

vi /etc/passwd

A la fin du fichier, rajoutez une ligne comme celle-ci :

guest:*:65533:65533:guest:/home/guest:/bin/ash

Vérifiez que l'UID n'existe pas déjà. Changez le shell d'arrivé si besoin.

Créons un groupe pour cet utilisateur. Oui, on pourrait utiliser le group "nogroup/daemon" mais il vaut mieux créer un nouveau groupe afin de bien séparés les privilèges (droits d'accès à certains fichiers, etc.).

vi /etc/group

A la fin du fichier, rajoutez une ligne comme celle-ci :

guestg:x:65533:

Le g à la fin de guest signifie "group", ce n'est pas une coquille, c'est pour différencier le groupe du login. Vérifiez que le GID n'existe pas déjà et qu'il correspond au GID que vous avez donné au compte utilisateur.

Maintenant donnons un mot de passe à ce compte :

~# passwd guest

Donnons l'autorisation au compte guest d'écrire dans son home directory :

~# chown -R guest:guestg /home/guest

C'est terminé.

Pour vous connecter à votre routeur via SSH :

• Si vous voulu effectuer une tâche de maintenance :

  ssh root@ip-du-routeur

• Si vous n'avez pas besoin d'effectuer une tâche de maintenance (exemple du tunnel SSH) :

  ssh guest@ip-du-routeur

Si vous voulez utiliser l'authentification par clé publique avec ce compte utilisateur, sa clé publique ne devra pas être mise dans /etc/dropbear/authorized_keys mais dans /home/guest/.ssh/authorized_keys .

Table des matières

Pour suivre cet article, je vous conseille de connaitre les bases de l'administration sous OpenWRT (GNU/Linux quoi) et les bases du DNS. Pour le Domain Name System, je vous recommande Wikipédia et un cours vidéo sur lalitte.com.

Pourquoi vouloir un résolveur DNS à la maison ?

Il y a plusieurs raisons qui peuvent amener à mettre en place un résolveur DNS at home. Je vais vous donner les miennes :

• le "défi" technique.
• éviter les DNS menteurs.
• améliorer la réactivité de vos applications internet : les réponses étant mises en cache sur un périphérique à l'intérieur du réseau local, les temps de réponses sont excellents lorsque vous demandez plusieurs fois la même résolution (1 à 2 msec(s)).

Avec quel logiciel ?

Le facteur limitant sera ici la taille du logiciel : il doit loger dans l'espace libre (233 kb) qui reste sur mon routeur (il faudra que je vois pour ajouter une carte MMC/SD). Faisons le tour des logiciels que je connais :

• Bind : un standard de fait. Mais je voulais quelque chose de plus exotique. De plus, le paquetage nécessite 1868kb pour être installé : il est donc trop gros pour mon WRT54GL.
• MaraDNS : lui aussi est trop lourd : 612kb sont réclamés.
• Dnsmasq : il est installé par défaut sur OpenWRT. Mais comme l'indique son man : "Dnsmasq is a DNS query forwarder: it it not capable of recursively answering arbitrary queries starting from the root servers but forwards such queries to a fully recursive upstream DNS server which is typically provided by an ISP.". En clair : ça va pas être possible.
• DjbDNS. Celui-là répond à tous les critères. Après son installation sur mon routeur, il reste encore 188kb d'espace libre.

Avant l'installation

Comme nous l'avons vu, le paquetage dnsmasq est installé par défaut sous OpenWRT. C'est un logiciel multi-fonctions : DHCP, TFTP et "résolveur" DNS (enfin ... pas tout à fait puisqu'il se contente de transférer les requêtes DNS vers un vrai résolveur DNS sur internet).

Rappel : il ne peut pas y avoir deux logiciels qui utilisent un même port sur une même interface réseau.

Il va donc falloir soit désinstaller dnsmasq et donc se priver d'un serveur DHCP, soit lui demander d'abandonner uniquement sa fonction de "résolveur" DNS. Réponse 2, Jean-Pierre !

Nous allons donc installer dnscache, le configurer puis désactiver la fonctionnalité dns de dnsmasq.

Installation de dnscache

Rien de compliqué ici :

root@OpenWRT:~# opkg update
root@OpenWRT:~# opkg install djbdns-dnscache

Configuration de dnscache

Si vous lancez dnscache maintenant et que vous faisez un netstat -lep, vous verrez que dnscache écoute sur le port 53 en UDP et TCP mais sur l'interface WAN. Or, ce que nous voulons, c'est un résolveur qui écoute uniquement sur le réseau local. Il va donc falloir configurer dnscache.

C'est ici que j'ai pas mal galéré. En effet, si vous cherchez de la documentation sur internet, vous trouverez qu'il faut créer des comptes utilisateur, ajouter ou modifier des fichiers dans /etc/dnscache. J'ai essayé : ça ne fonctionne pas. J'ai donc décidé de lire le readme qui se trouve dans le paquetage. Il est disponible à cette adresse : https://dev.openwrt.org/browser/packages/net/djbdns/README. Tout devient alors clair : il faut utiliser uci pour configurer dnscache.

Allons-y pour la configuration :

root@OpenWRT:~# uci set djbdns.@dnscache[0].interface=lan
root@OpenWRT:~# uci set djbdns.@dnscache[0].defaultallowif=lan
root@OpenWRT:~# uci set djbdns.@dnscache[0].forwardonly=0
root@OpenWRT:~# uci set djbdns.@tinydns[0].interface=lan
root@OpenWRT:~# uci set djbdns.@axfrdns[0].interface=lan
root@OpenWRT:~# uci set djbdns.@rbldns[0].interface=lan
root@OpenWRT:~# uci set djbdns.@walldns[0].interface=lan

Commentons un peu ces lignes. Dans l'ordre :

• on demande à dnscache d'écouter que sur le réseau local.
• on demande à dnscache de ne répondre qu'à des périphériques membres du réseau local
• on demande à dnscache de résoudre lui-même les noms de domaine en partant des serveurs qui gèrent la racine.
• on demande aux autres composants de djbdns d'écouter que sur sur le réseau local. Même si nous ne les avons pas installés, cela est plus prudent : si vous souhaitez les installer, vous pourrez les configurer tranquillement sans les exposer directement sur internet. Il vaut mieux prévoir le coup plutôt que de s'en remettre à la bonne configuration du firewall.

Note : pour voir l'intégralité des variables de configuration propres à djbns présentent dans le système, vous pouvez taper :

root@OpenWRT:~# uci show | grep "djbdns"

Test de la configuration

Comme nous l'avons dit, on ne peut pas avoir deux logiciels qui écoutent sur le même port. Donc on arrête dnsmasq temporairement :

root@OpenWRT:~# /etc/init.d/dnsmasq stop

Lançons dnscache :

root@OpenWRT:~# /etc/init.d/dnscache start

Pour tester le serveur, il suffit de lui envoyer une requête. Sous GNU/Linux, je préfère utiliser dig alors que sous Windows, nslookup fera l'affaire.

Sous GNU\Linux :

dig @192.168.1.1 www.guiguishow.info.

Vous devez obtenir une réponse dont le status est "NOERROR".

Sous Windows :

nslookup www.guiguishow.info. 192.168.1.1

Vous devez obtenir aucune erreur.

Note : 192.168.1.1 est à remplacer par l'adresse IP LAN de votre routeur.

Ensuite, vous pouvez vous demandez "comment être sûr que mon serveur ne se contente pas de transférer ma requête à un autre DNS ?" Il y a manière simple de vérifier cela.

Il suffit de capturer le trafic réseau qui sort du routeur sur l'interface WAN (eth0.1).

Si vous avez encore assez d'espace libre dans la mémoire de votre routeur, vous pouvez installer tcpdump (660kb) ou tcpdump-mini dessus. Il suffit alors de lancer le sniffer :

tcmpdump -n -i eth0.1 port 53

Sinon, vous pouvez brancher un autre ordinateur sur le port WAN du WRT54GL et capturer le trafic réseau avec un logiciel comme Wireshark. Pour que cela fonctionne, l'ordinateur que vous avez branché au port WAN doit prendre la même adresse IP que le modem qui est habituellement branché à votre routeur (ou redéfinir la route pas défaut sur le routeur, mais c'est une autre histoire). Si vous ne la connaissais pas, regardez la capture réseau : vous verrez des trames ARP "Who has x.x.x.x tell y.y.y.y". Il vous suffit de donner à votre ordinateur l'adresse IP x.x.x.x . Vous pouvez ensuite lancer la capture.

Dans tous les cas, une fois cela fait, revenez sur l'ordinateur qui est toujours connecté sur un des ports LAN du routeur. Lancez un dig/nslookup en direction de votre résolveur personnel. Dans la capture réseau, vous devez voir des adresses IP qui appartiennent à l'un des serveurs qui gèrent la racine DNS ou les TLD comme 192.26.92.30 ou 192.54.112.30.

Pour savoir si une adresse IP appartient à l'un des serveurs en charge de la racine ou des TLD, vous pouvez utiliser la commande host sous GNU/Linux ou nslookup sous Windows. Dans le cas de 192.54.112.30, nous obtenons "30.112.54.192.in-addr.arpa domain name pointer h.gtld-servers.net.". Il s'agit donc d'un des serveurs qui gère le domaine de premier niveau .net. .

Si tout va bien, vous pouvez passer à l'étape suivante.

Changer l'adresse du résolveur DNS sur les machines grâce à DHCP et sur le routeur

Les Unixiens se seront précipités pour éditer le fichier /etc/resolv.conf 😉 . C'est un bon réflexe en temps normal mais, dans le cas présent, ce fichier est généré à chaque démarrage du routeur, ou plus précisément à chaque démarrage de dnsmasq.

Il faut donc éditer le script de démarrage : /etc/init.d/dnsmasq. A la 5éme ligne, vous pouvez lire :

DNS_SERVERS= ""

Saisissez ici l'adresse ip LAN de votre routeur.

Note : dnsmasq ajoutera le résolveur 127.0.0.1 automatiquement à la fin de la liste. Si vous trouvez ça inconcevable, que ça vous empêche de dormir la nuit, supprimez la 5eme ligne du fichier puis cherchez cette ligne dans la fonction start :

DNS_SERVERS= "$DNS_SERVERS 127.0.0.1"

Enlevez tout ce qu'il y a entre guillemets et mettez la ou les adresse(s) IP de votre(vos) résolveurs, séparés par un espace.

Il ne reste plus qu'a redémarrer dnsmasq :

root@OpenWRT:~# /etc/init.d/dnsmasq restart

Notez que les modifications ne prendront effet sur vos périphériques que lors du renouvellement du bail DHCP. Vous pouvez le forcer (ipconfig /renew sous windows, désactiver/activer l'interface réseau, reboot, etc.).

Désactiver la fonctionnalité DNS de dnsmasq

A présent, nous pouvons désactiver la partie DNS de dnsmasq. Le man de dnsmasq nous dis ("Listen on <port> instead of the standard DNS port (53). Setting this to zero completely disables DNS function, leaving only DHCP and/or TFTP.") qu'il suffit de configurer le port à 0 pour désactiver la fonction DNS. Pour mettre cela en application, il suffit d'aller dans l'interface web, dans "Services", "Dnsmasq", d'ajouter un champ "port DNS", de le configurer à 0 et d'appliquer les changements.

Pour les True Warrior qui veulent le faire depuis le shell, ça donne :

root@OpenWRT:~# uci set dhcp.@dnsmasq[0].port=0
root@OpenWRT:~# /etc/init.d/dnsmasq restart

Mettre en place durablement notre résolveur

En effet, dans l'état actuel, djbdns ne se relancera pas au prochain reboot du routeur et les paramètres seront perdus 🙁 .

Pour que le serveur se lance tout seul au démarrage du routeur vous pouvez créer un lien de /etc/init.d/dnscache vers /etc/rc.d/Sxxdnscache (ou xx représente l'ordre de boot) avec la commande ln ou plus simplement taper la commande :

root@OpenWRT:~# /etc/init.d/dnscache enable

Pour enregistrer les paramètres que nous avons donnés à uci, il faut taper ceci dans ash (le shell par défaut d'OpenWRT) :

root@OpenWRT:~# uci commit network.lan
root@OpenWRT:~# uci commit dhcp
root@OpenWRT:~# uci commit djbdns
root@OpenWRT:~# uci commit

Détaillons un peu, toujours dans l'ordre :

• On enregistre le changement de serveur DNS pour le réseau local.
• On enregistre le fait que dnsmasq ne doit plus faire office de résolveur DNS ainsi que le changement de serveur DNS pour le réseau local, le cas échéant.
• On enregistre toutes les modifications faites à djbdns.
• On enregistre tout. Pas utile mais je le fais par mesure de précaution.

Et voila, votre résolveur DNS personnel est en place sur votre routeur équipé avec OpenWRT.

Si dnscache plante lorsqu'une déconnexion survient sur l'interface WAN (ÉDIT du 08/08/2011 à 14h00 )

J'ai rédigé un billet à ce sujet : OpenWRT : relancer automatique dnscache en cas de déconnexion du net

Table des matières

Mon fidèle modem-routeur Netgear DG834Gv3 m'a lâché récemment. Comment ? Bah il a tout simplement grillé alors que tous les appareils qui lui sont connectés directement ou indirectement étaient éteint. Il n'y avait pas non plus d'orage ce jour là mais un beau soleil. Un problème d'origine électrique est aussi à exclure car il était raccordé au secteur via une alimentation sans interruption en interaction avec le réseau (ce que certains appellent "onduleur" in-line) qui a fait ses preuves. Bref : une mort mystérieuse.

Hommage au DG834Gv3

Ce modem-routeur répondait à la plupart de mes besoins exceptés la QdS et une gestion assez chaotique des VPN.

Il permettait entre autre de gérer le Wake On Lan qui est une technique permettant d'allumer un ordinateur à "distance", via le réseau, via l'ajout d'un "module". Voir à cette adresse pour le CGI et les fichiers HTML : Wake on lan utility for DG834(G) routers by Alessandro Soggia. J'avais compilé à la fois l'utilitaire et le firmware afin de :

• pouvoir utiliser la dernière version du firmware Netgear (4.01.40) alors que l'image pré-compilée disponible sur le site utilise le firmware 4.01.19
• mettre à jour la page "menu.html" afin que les options ajoutées avec le nouveau firmware (exemple : WDS) ne disparaissent pas du menu et aussi pour que le menu affiche "Wake On Lan" et pas un énigmatique "WOL"
• faire en sorte que le formulaire soit pré-rempli avec l'adresse de diffusion de mon réseau et l'adresse MAC de l'ordinateur à allumer
• traduire un peu les messages affichés, tant qu'à faire

Je met à votre disposition :

• le fichier source wol.c légèrement traduit
• le toolchain pour le Linksys WRT54G
• le firmware que j'ai compilé

Attention si vous utilisez le firmware que j'ai compilé : d'une part, le formulaire est pré-rempli avec l'adresse de diffusion de mon réseau, qui ne sera peut-être pas la même chez vous et avec l'adresse MAC d'un de mes ordinateurs, qui ne sera pas, à coup sûr, l'adresse MAC de votre ordinateur. Ensuite, je n'ai mis que les fichiers HTML de la version française. Si vous utilisez une autre langue, vous n'aurez pas accès à l'utilitaire via l'interface web, à moins de taper l'URL directe dans votre navigateur.

Le remplaçant

Le premier remplaçant fût un DG834Gv5. Malheureusement le hardware et le software ont bien changés et Netgear a compliqué les tentatives de bricolage.

En effet, les modules CGI semblent être compilés directement dans le démon HTTPD. Difficile donc d'utiliser l'ancien CGI. Si encore j'avais pu trouver un "how to".

J'imagine une autre solution : activer le serveur telnet présent sur le routeur, utiliser la commande arp pour fixer l'association entre l'adresse IP du PC à réveiller et son adresse MAC de manière permanente. Ainsi, il me suffirait de rediriger le port 9 vers l'adresse IP du PC à réveiller et cela fonctionnerait. Malheureusement, la version de busybox intégrée dans le DG834Gv5 ne contient pas la commande arp. Qu'à cela ne tienne : utilisons la commande ip ... qui est aussi indisponible.

Je regarde alors les sources et je tombe sur le fichier product/U12L060_RETAIL_ST/open-src/applications/busybox-1.2.1/.config. Je remarque que toutes les commandes qui sont disponibles sur busybox sont à "yes" dans ce fichier (ex : CONFIG_IFCONFIG=y et la commande ifconfig est disponible). Je pense donc qu'il suffirait de passer CONFIG_ARP à "y" pour que la commande soit disponible. Il ne me reste donc plus qu'à compiler le firmware avec ce changement.

C'est là que commencent les problèmes. D'abord, le script cxnt_setenv.sh qu'il faut lancer avant le make, selon les instructions (qui datent de 2008 : "Date : 2008 Nov. 21th") se termine en erreur. Ensuite la commande make trébuche sur quelques labels introuvables dans les makefile. Difficile de recréer les sections des makefile que nous n'avons pas. Entêté, je continue néanmoins à chercher.

Mais l'interface web d'administration du routeur est souvent inaccessible et il faut redémarrer le routeur pour y avoir de nouveau accès. Sur le modèle de Dodo, il arrive que le net se coupe, sans raison et seul un redémarrage du routeur peut faire revenir le net. En revanche, aucun souci du côté de l'administration. Devant un tel fail de Netgear, et surtout parce que quand j'achète un routeur que je configure souvent je ne souhaite pas avoir une administration souvent inaccessible, je décide de retourner le DG834Gv5 au magasin et de m'acheter autre chose.

Finalement, le remplaçant sera un Linksys WRT54GL v1.1 couplé à un Netgear DM111P. L'ensemble est plus cher (quelle surprise !) mais bien plus bidouillable.

Choix d'un firmware alternatif pour le WRT54GL v1.1

Afin de ne pas partir dans tous les sens, je décide de ne comparer que les firmwares alternatifs que je connaissais (uniquement de nom) avant : OpenWRT et DD-WRT.

Il apparait que les fonctionnalités sont les mêmes, offertes de manières différentes. Je n’ai pas réussi à séparer les deux firmwares sur les fonctions qui me sont nécessaires.

En cherchant un peu, je trouve des informations subjectives selon lesquelles OpenWRT serait plus bidouillable que DD-WRT, que OpenWRT est moins "user friendly", que OpenWRT est vraiment fait pour les geeks/bidouilleurs. C'est cela qui m'a convaincu d'utiliser OpenWRT : après le fail du Netgear devenu bien moins bidouillable en même pas deux versions, il était hors de questions que je n'aie pas le contrôle.

Installation

Parmi les différentes "versions" d'openWRT, j'ai décidé de prendre la plus récente, Backfire 10.03 qui a été diffusée le 6 avril 2010. Après, il faut choisir entre brcm-2.4 ou brcm47xx. La différence notable est que brcm-2.4 contient un noyau Linux 2.4 alors que brcm47 contient un noyau 2.6. L'autre différence, si j'ai bien compris, vient du fait que la déclinaison brcm47 ne contient plus de code propriétaire de Broadcom en ce qui concerne la gestion du wifi. Aprés, il y a des petits détails : on ne peut pas utiliser le filtrage par adresse MAC des stations Wifi ni définir le rôle de chaque antenne du WRT54GL sur la déclinaison bcrm47xx. Voir la fin de ce billet et les commentaires pour plus d'informations.

ÉDIT 26/08/2011 15h05 : Évidemment, la déclinaison brcm47 occupe plus de place dans la mémoire du routeur, ce qui fait qu'il reste moins de place pour vos applications. Pour vous donner un ordre d'idée : sur mon WRT54GL, il reste 1.2M après l'installation de la déclinaison bcrm-2.4 de Backfire 10.03 alors qu'il ne reste que 820k après l'installation de la déclinaison bcrm47xx.

Personnellement, j'ai d'abord commencé par installer la déclinaison brcm 2.4 depuis l'interface web de Linksys. D'une part car on disait que le wifi ne fonctionnait pas avec le noyau 2.6 et que la commande nvram n'existait plus et ne permettait plus d'activer le boot_wait, c'est à dire l'option qui permet au bootloader de recevoir un firmware propre via TFTP si jamais le firmware interne est endommagé. Mais étant passé ensuite à la déclinaison brcm47, je peux vous dire que le wifi fonctionne très bien et que la commande nvram est disponible et fonctionnelle. Preuve :

root@OpenWRT:~# uname -a
Linux OpenWRT 2.6.32.10 #20 Tue Apr 6 15:53:48 CEST 2010 mips GNU/Linux
root@OpenWRT:~# nvram get boot_wait
off
root@OpenWRT:~# nvram set boot_wait=on
root@OpenWRT:~# nvram get boot_wait
on
root@OpenWRT:~# nvram commit

Vous pouvez donc installez directement une déclinaison brcm47xx sans problèmes.

Dans la suite de ce tutoriel/guide, je considère que vous avez choisi le même firmware que moi, à savoir :
OpenWRT Backfire 10.03 brcm47xx pour le WRT54G au format squashfs.

Que faire si vous avez endommagé le firmware interne

Avant de continuer, il me paraît évident d'en parler. OpenWRT propose deux modes : le failsafe mode et le flashage en récupérant l'image via TFTP.

Si les dommages ne sont pas trop importants, vous pouvez utiliser le failsafe mode (= mode sans échec). Comme je l'ai dit dans les commentaires, je n'ai jamais réussi à utiliser ce mode. En effet, je reçois le paquet en broadcast, j’appuie sur le bouton "reset" mais je ne reçois pas de paquet "Entering failsafe". La led DMZ clignote rapidement et la led "on" clignote à un débit normal. Le routeur ne répond à rien, pas même les requêtes ARP. Difficile dans ces conditions d'utiliser le mode sans échec.

Si les dommages sont plus importants ou que vous n'avez pas accès au failsafe mode, vous pouvez utiliser le flashage du firmware. Pour que cela fonctionne, la variable boot_wait doit être à "on" ! (voir ci-dessus). Celle-ci permet de mettre en pause le processus de boot pour attendre une éventuelle connexion TFTP. Il suffit de changer sa valeur une fois et de faire un commit pour qu'elle soit conservée indéfiniment, même si vous flasher votre routeur.

Sous GNU/Linux, il faut installer l'utilitaire atftp, si ce n'est pas déjà fait, puis suivre le tutoriel officiel.

Sous Windows, j'utilise le client TFTP de Linksys.

Quel que soit votre système d'exploitation, la marche à suivre est très simple : il faut lancer l'envoi du firmware, que ce soit avec l'outil TFTP de Linksys ou avec atftp, pile 3 secondes après avoir mis le routeur sous tension. En tout cas, il faut procéder comme cela avec un WRT54GL v1.1.

Voici quelques conseils pour la route :

• N'oubliez pas de désactiver temporairement votre pare-feu ou d'y autoriser le protocole TFTP. Si vous ne le faites pas et si vous êtes sous GNU/Linux, vous aurez une erreur "Operation not permitted".
• Vu le timing serré, il vaut mieux utiliser une configuration statique de la pile réseau. En clair : pas de DHCP.
• Placer un intermédiaire (switch, hub, ...) entre le routeur et le PC qui servira à remettre le firmware permet d'éviter de manquer le moment pendant lequel le routeur est disposé à recevoir le nouveau firmware à cause d'un système d'exploitation qui annonce que le câble réseau est débranché.
• Enfin, je vous recommande de lancer la commande "ping" en direction du routeur (sous Windows pensez à ajouter le paramètre -N 100 pour que le ping dure plus longtemps). Cela permet à l'ordinateur et au routeur d'échanger leur adresse MAC via le protocole ARP ce qui permet de gagner du temps lors de l'envoi TFTP.

Configurer OpenWRT

Deux modes sont disponibles : l’interface web (LuCi) ou la ligne de commande (uci). Avec le temps, vous préférerez uci 😉 .

Quelques correspondances générales entre LuCi et uci

Afin de vous faire aimer Luci, je vous met ici les correspondances entre LuCi et uci. VOus n'avez donc plus d'excuses pour ne pas manipuler uci.

Status -> Interface

Mélange entre la commande ifconfig, brctl show et /proc/switch .

Status -> Firewall

iptables -t filter -L -n && iptables -t nat -L -n && iptables -t mangle -L -n

Status -> Connexions actives

arp && netstat -taupn

Status -> Routes

route -n

Status -> Journal système

logread

Pour écrire quelque chose dans ce journal, utilisez la commande :

logger <votre message>

Status -> Journal du noyau

dmesg

Système -> Système -> Nom d’hôte

uci set system.@system[0].hostname="Nouveau_nom"

Système -> Système -> Fuseau horaire

uci set system.@system[0].zonename=Europe/Paris 2>/dev/null
uci set system.@system[0].timezone=CET-1CEST,M3.5.0,M10.5.0/3 2>/dev/null

Pour les timezones, voir le wiki d'OpenWRT

Système -> Logiciels

Éditez la liste des paquets et le répertoire de destination

vi /etc/opkg.conf

Mettre à jour la liste des paquets

opkg update

Télécharge et installe le paquet

opkg install <nom du paquet>

Filtrer

opkg search *nom du paquet*

ou

opkg list | grep *nom du paquet*

Installed packages

opkg list-installed

Available packages

opkg list

Système -> Mot de passe administrateur

passwd

Système -> Clés SSH

vi /etc/dropbear/authorized_keys

Système -> Processus

Mélange entre la commande ps et la commande top.

Signal (HUP)

Plutôt que d'utiliser la commande kill (kill -s SIGHUP pid ou kill -1 pid), on préférera utiliser /etc/init.d/processus restart.

Terminer

Même remarque que ci-dessus. kill -s SIGTERM pid ou /etc/init.d/processus stop

Tuer

kill -9 pid

Système -> Configuration des leds

Voir à la fin de ce billet.

Système -> Flash firmware

Méthode TFTP (voir ci-dessus) ou :

cd /tmp/
wget http://downloads.openwrt.org/backfire/10.03/brcm47xx/openwrt-brcm47xx-squashfs.trx
mtd write /tmp/openwrt-brcm47xx-squashfs.trx linux && reboot

Système -> Redémarrage

reboot

Services -> initscripts

/etc/init.d/script enable/disable/start/restart/stop

Services -> dropbear SSHd

Pour voir les valeurs de chaque paramètre associè à dropbear :

uci show | grep dropbear

Pour modifier la valeur d'un paramètre :

uci set <nom complet du parametre>

Services -> dnsmasq

Même raisonnement que pour dropbear SSHd

Services -> Taches régulières

Voir : OpenWrt Scheduling Jobs With cron on OpenWrt.

Réseau -> Interfaces

Tout se configure en éditant le fichier /etc/config/network

Les bridges peuvent être configurés avec l'utilitaire brctl

Réseau -> Wi-Fi

Il suffit d'éditer le fichier /etc/config/wireless

Réseau -> Switch

Les VLANs se cofnigurent depuis le fichier /etc/config/network

Réseau -> DHCP

Pour voir les valeurs de chaque paramètre associè au dhp:

uci show | grep dhcp

Pour les éditers, vous connaisez déjà la procédure. Pour ajouter des associations statiques, ajoutez des entrées dhcp.@host[x] avec uci set. Exemple :

dhcp.@host[0]=host
dhcp.@host[0].name=Serveur_NFS
dhcp.@host[0].mac=00:11:22:33:44:55
dhcp.@host[0].ip=192.16.1.25

Réseau -> Nom d'hotes

Ajoutez des entrées dhcp.@domain[x] avec uci set. Exemple :

dhcp.@domain[0]=domain
dhcp.@domain[0].name=NFS_SERVER
dhcp.@domain[0].ip=192.168.1.25

Réseau -> Routes statiques

Tout se configure avec l'utilitaire route.

Réseau -> Pare-feu

Tout se règle avec iptables.

Activer SSH et désactiver implicitement telnet

Il faut changer le mot de passe pour le compte root, soit via l'interface web, soit via telnet (avec la commande passwd).

Avoir l'interface web en français

Il faut installer le package luci-i18n-french :

root@OpenWRT:~# opkg update
root@OpenWRT:~# opkg install luci-i18n-french

Note : opkg update doit être lancé après chaque reboot du routeur si vous souhaitez installer un package et/ou obtenir la liste des packages disponibles (commande opkg list).

Normalement, la langue doit s'activer toute seule. Néanmoins, si ce n'est pas le cas, il faut aller dans le menu "Overwiev" => "User Interface" et choisir la langue française dans la liste déroulante.

Utiliser un service de DNS dynamique (exemple : DynDNS.com)

Il faut installer le package ddns-scripts et le package luci-app-ddns si vous souhaitez configurer cela depuis l'interface web. Chez moi, l'option n'est apparue dans l'interface web qu'après un reboot complet de la machine. Un reboot du démon uhhtpd (démon HTTP) n'a pas suffit.

Utiliser la QdS

Si vous voulez configurer la QdS à la main avec iptables et Traffic Control, vous avez seulement besoin du package tc. Sinon, vous pouvez installer le package qos-scripts et luci-app-qos et configurer la QdS depuis l'interface web. Remarquons que les règles pré-écrites sont incomplètes : il manque par exemple la priorisation des flags ACK de TCP.

Gagner du temps au démarrage

J'empêche, via l'interface web, le démon USB de démarrer en même temps que le routeur car le WRT54GL ne possède pas de ports USB. Puis je m'assure que telnet ne se relancera jamais, même par erreur, au démarrage, dans le but d'accroitre la sécurité (oui, telnet n'est pas un protocole sécurisé) :

rm /etc/rc.d/S50telnet

Configurer SSH

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

Pour le fun vous pouvez aussi changer le message qui s'affiche quand vous vous connectez via SSH. Pour cela, il faut modifier le fichier /etc/banner. Mettez un message original. 😉 Notez que le fichier /etc/banner est appelé automatiquement par défaut par dropbear, le démon SSH et qu'il ne sert à rien de dé-commenter la ligne "option BannerFile '/etc/banner'" dans le fichier /etc/config/dropbear à moins que vous ne vouliez que le message s'affiche deux fois : une fois lors de l'ouverture de la connexion, l'autre fois après une validation réussit d'un mot de passe.

Vous pouvez maintenant rebooter le démon SSH ainsi que le firewall afin que les modifications soient prises en compte:

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

ÉDIT du 09/07/2011 à 0h05 : Pour apporter plus de sécurité lors de vos connexion SSH depuis l'extérieur (par exemple pour faire des tunnels 😉 ), vous pouvez créer un compte utilisateur qui ne possédera pas les droits d’administration. Pour cela, voir ce billet : Créer un compte utilisateur sans droits sur OpenWRT. Fin de l'édit

ÉDIT du 26/08/2011 à 17h30 : Pour améliorer la sécurité de votre démon SSH et limiter l'impact des attaques par bruteforce sur vos ressources, reportez vous à ce billet : OpenWRT : sécuriser l’accès SSH. Fin de l'édit

Bloquer les pings en provenance d'internet

Je bloque les echo request du protocole ICMP (vulgairement appelés "ping") en provenance d'internet. Le routeur peut toujours être interrogé depuis le LAN sans problèmes.

Contrairement à ce que l'on voit sur certains sites et forums, il ne faut pas bloquer tout le protocole ICMP car il ne prend pas en charge que le ping : c'est aussi via ce protocole que le réseau avertit votre ordinateur qu'un serveur n'est pas accessible (Host Unreachable) ou qu'un port n'est pas accessible (bien que normalement, en TCP, le flag RST soit fait pour cela)

Il ne faut pas non plus bloquer les echo reply du protocole ICMP, sinon vous ne recevrez jamais les réponses des pings que vous envoyez à un serveur sur internet.

Pour mettre cela en place, il faut d'abord supprimer la règle présente par défaut dans OpenWRT qui autorise le ping :

­root@OpenWrt:~# uci delete firewall.@rule[1]
­root@OpenWrt:~# uci commit firewall
root@OpenWrt:~# uci commit

Ensuite, il ne reste plus qu'a déclarer notre régle personnelle dans le fichier /etc/firewall.user :

iptables -A input_wan -p icmp --icmp-type 8 -j DROP

Note : Oui, je sais que j'aurais pu changer la règle présente par défaut grâce à un simple

root@OpenWrt:~# uci set firewall.@rule[1].target=DROP
root@OpenWrt:~# uci commit firewall
root@OpenWrt:~# uci commit

Mais je préfère la supprimer car je ne compte pas utiliser LuCi/uci pour écrire mes règles personnelles et je souhaite donc que toutes mes règles soient regroupées dans le même fichier, à savoir /etc/firewall.user.

En parlant de règle à supprimer, vous pouvez supprimer une autre des règles présente par défaut avec cette commande :

­root@OpenWrt:~# uci delete firewall.@rule[0]
­root@OpenWrt:~# uci commit firewall
root@OpenWrt:~# uci commit

Celle-ci ouvre le port 68 (DHCP) sur le port WAN. Cela n'a pas d'intérêt, même si votre routeur obtient son adresse auprès de votre modem avec DHCP.

Désinstaller quelques packages

Attention à ce que vous faites : ne désinstallez pas n'importe quoi ... J'ai désinstallé la libgcc (car je ne pensais pas en avoir besoin vu que je ne comptais pas compiler quoi que ce soit sur le routeur) et cela m'a valu un petit flashage via la méthode TFTP.

Si vous ne voulez pas de l'interface web allégée (= qui ne contient pas toutes les options et qui est intégrée dans la version complète) :

opkg remove --force-removal-of-dependent-packages luci-admin-mini

Ensuite il faut redémarrer le routeur afin que l'interface web passe automatiquement en version complète. En effet, si vous vous connectez maintenant, vous obtiendrez un message bizarre. Redémarrer le démon uhttpd n'a pas suffit chez moi.

Personnellement, je n'ai rien désinstallé d'autre.

ÉDIT du 26/08/2011 à 17h35 : Vous pouvez désinstaller le paquet qui contient la traduction anglaise de LuCi si vous ne vous en servait pas :

opkg remove luci-i18n-english

Vous pouvez même désinstaller complétement LuCi/uhttpd si l'interface web ne vous sert pas.
Fin de l'édit

Wake On Lan (WOL)\ Wake On Wan (WOW)

Deux méthodes sont possibles : utiliser un utilitaire dédié, etherwake ou configurer une association statique entre l'adresse IP du PC à réveiller et son adresse MAC. La plus simple et la plus sécurisée étant d'installer etherwake.

Une autre méthode est souvent présentée : il s'agit de rediriger un port choisi (généralement le 9) vers l'adresse de diffusion du réseau (exemple : 192.168.0.255). Cette méthode n'a jamais fonctionné pour moi, même avec iptables.

Utiliser etherwake

Il faut d'abord l'installer :

opkg install etherwake

. Ensuite, pour allumer votre ordinateur, vous devrez vous connectez via SSH à votre routeur (voir plus haut pour ouvrir le port et le protéger) et taper :

etherwake MAC

en remplaçant "MAC" par l'adresse MAC de l'ordinateur à réveiller.

Pour être précis dans les termes, il s'agit ici véritablement de Wake On Lan : vous allumez une machine du même réseau. En effet, le paquet magique part de votre routeur qui se trouve dans le même réseau que l'ordinateur à allumer.

Autre méthode

Pour créer l'association statique entre l'adresse IP du PC à réveiller et son adresse MAC, on peut habituellement utiliser la commande arp. Mais dans OpenWRT on ne peut pas car elle sert uniquement à afficher la table ARP. Il faut donc utiliser la commande ip.

Installation :

opkg install ip

Utilisation :

ip neigh add IP lladdr MAC nud permanent dev br-lan

Évidemment, "IP" est à remplacer par l'adresse IP du PC à réveiller et "MAC" par son adresse MAC. Sur votre routeur, le périphérique ne sera peut-être pas br-lan. Il faut en tout cas indiquer le périphérique (réel ou non (comme br-lan)) qui désigne le réseau local.

Il ne vous reste plus qu'a rediriger, via l'interface web, le port 9 (ou celui de votre choix) vers l'adresse IP du PC à réveiller). Il faut aussi veiller à ce que le serveur DHCP donne toujours la même adresse IP à votre PC ... ou à utiliser une configuration IP statique.

Vous n'avez plus qu'à utiliser un service web (comme Dépicius.com) ou un logiciel dédié. Cette méthode est moins sécurisée car vous dépendez d'un service web. Si vous utilisez un logiciel, il faut que l'endroit depuis lequel vous vous connectez ne bloque pas le port que vous avez choisit. Et n'oubliez pas que le paquet circulera en clair sur le réseau.

Attention : l'association est effacée lors de chaque arrêt du routeur. Nous verrons dans un prochain article comment réaliser un script qui s'exécute au démarrage du routeur et rétablit l'association. ÉDIT du 09/07/2011 à 0h05 : Voici le billet en question : Protéger le cache ARP de vos machines.

Pour être précis dans les termes, il s'agit ici de Wake On Wan (WoW) : vous allumez une machine qui n'est pas sur le même réseau.

Installer un résolveur DNS sur votre routeur (ÉDIT du 09/07/2011 à 0h05)

Voir ce billet : Mettre en place un résolveur DNS sur un WRT54GL équipé d’OpenWRT

Utiliser un client Network Time Protocol (ÉDIT du 09/07/2011 à 0h05)

Voir ce billet : Utiliser NTP (Network Time Protocol) sur OpenWRT.

Installer un serveur Network Time Protocol (ÉDIT du 26/08/2011 à 17h40)

Voir ce billet : Installer un serveur NTP sur OpenWRT.

Comprendre le mécanisme de watchdog (ÉDIT du 26/08/2011 à 17h40)

Voir ce billet : OpenWRT : watchdog - en voilà un bon toutou !

Créez votre image personnalisée d’OpenWRT (ÉDIT du 04/09/2011 à 21h10)

Voir ce billet : Créez votre image personnalisée d’OpenWRT

Jouer avec les LEDs

Le pseudo-système de fichier procfs permet de faire l'interface entre l'utilisateur, le noyau et le matériel. Et il nous permet de jouer.

Listons le contenu de /proc/diag/led :

root@OpenWRT:~# ls /proc/diag/led
dmz         power       ses_orange  ses_white   wlan

On remarque qu'il y a un fichier pour chaque LED présente sur la façade du routeur à l'exception des ports LAN et de la LED SES (= le logo Cisco à gauche de la façade) qui est représentée en double pour les deux couleurs qu'elle peut prendre. Dans chacun de ces fichiers, vous pouvez inscrire une valeur :

• 0 : la led correspondante sera éteinte
• 1 : la led correspondante sera allumée
• f : la led correspondante clignotera

Faisons clignoter la LED SES en orange :

echo "f" > /proc/diag/led/ses_orange

Allumons la LED wifi :

echo "1" > /proc/diag/led/wlan

Bref, vous l'aurez compris les possibilités sont importantes.

Vous pouvez par exemple concevoir un script qui fait clignoter la LED SES aux tops horaires : il suffit de réaliser un script shell qui écrit "f" dans le fichier /proc/diag/led/ses_orange, qui se met en pause pendant 30 secondes puis qui écrit "0" dans le même fichier. Ensuite vous demandez au démon cron de lancer le script en début de chaque heure. Pour poursuivre dans cette voie, il est même possible de faire une horloge : vous allumez la LED SES blanche à chaque quart d'heure et la LED SES orange toutes les heures. Inutile donc indispensable 😉 .

Vous pouvez aussi concevoir un script qui allume la LED wifi à chaque fois que vous activez le wifi et qui l'éteint quand vous désactivez le wifi. Cela se faisait tout seul avec le noyau 2.4 mais plus maintenant. Mais il suffit de vérifier si le wifi est activé (l'interface wlan apparait dans le listing de la commande ifconfig si le wifi est activé 😉 ) et d'allumer ou éteindre la LED en conséquence. Bien sûr, le script sera exécuter régulièrement par cron. Une autre méthode est possible : trouver le script qui allume la diode SES quand vous activez le wifi et changer le code de ce script pour qu'il allume la diode wifi à la place.

A vous de trouver d'autres idées 😀

Les "fails" d'OpenWRT

Malgré toutes mes manip', je n'ai remarqué que deux "fails" dans OpenWRT :

1. Il n'est pas possible d'activer le filtrage par adresse MAC pour le wifi sur la déclinaison brcm47. Mais vu la faiblesse de cette "protection", ce n'est pas un gros manque.
2. Quand vous sauvegardez les paramètres du wifi dans l'interface web, même si vous n'activez pas le wifi, vous perdez l'accès à internet sur les PCS branchés sur les ports LAN. En les sauvegardant une deuxième fois, le net revient.

Je pense que j'ai fait le tour de la configuration d'un WRT54GL v1.1 avec OpenWRT.

Table des matières

Vous avez utilisé une clé USB pour installer une distribution GNU/Linux ou un Windows puis vous l'avez formaté pour la vider. Mais voila, au démarrage de l'ordinateur, celui-ci tente de démarrer à partir de la clé. Voici quelques méthodes pour empêcher cela. La liste n'est pas exhaustive 😉 .

Sous Windows

J'utilise TestDisk, un bon logiciel sous licence GPL. On le télécharge, on le lance, on refuse la création de journal, on sélectionne sa clé USB sans se gourer, on choisit le type de la table des partitions : Intel, on choisit l'option "Delete" et on valide deux fois avec "y". Ensuite, il faut recréer une nouvelle partition puisque l'ancienne partition n'est plus référencée dans la table des partitions suite à notre manip'. On peut aussi réécrire la table des partitions, justement avec TestDisk, et ainsi retrouver l'accès à l'ancienne partition et à ces données. Je vous laisse chercher ça 😉 .

À noter que l'option "MBR code" n'a aucun effet dans notre cas ce qui est normal car elle n'est pas prévue pour cela. D'autre part,

Sous GNU/Linux

ÉDIT du 11/08/2012 à 19h30 : J'ai modifié cette partie car elle contenait beaucoup d'âneries. Fin de l'édit

Nous allons utiliser la commande dd . Pour obtenir le même résultat qu'avec TestDisk, il faut, tout comme lui, effacer le MBR. Il s'agit du premier secteur du disque, soit les 512 premiers octets. Pour l'effacer :

sudo dd if=/dev/zero of=/dev/sdb bs=512 count=1

Explication rapide : on écrit sur un secteur (count), sachant qu'un secteur à une taille de 512 octets (bs) en prenant comme source le pseudo-périphérique /dev/zero qui renvoi toujours le caractère "NULL".

Attention : ce ne sera pas forcement sdb chez vous ! Vérifiez avec la commande mount, sans arguments.

Un peu de théorie : pour savoir si un médium (clé USB, disque dur interne/externe, CD, DVD, etc. ) est amorçable ou pas, le BIOS lit le premier secteur (= les 512 premiers octets) du médium, le MBR donc. Celui-ci contient, dans l'ordre, la routine d'amorçage, la table des partitions primaires et deux octets (Pour une meilleure présentation, voir : Master boot record sur Wikipédia en). Pour être sûr qu'il s'agit bien d'un MBR, le BIOS vérifie que les deux derniers octets (le numéro 510 et le numéro 511, soit le 511e et le 512e, n'oubliez pas que l'on compte à partir de 0 😛 ) contiennent bien le nombre "magique" 0xAA55. Si c'est le cas, il charge la routine d'amorçage présente dans les 446 premiers octets (au maximum) du MBR dans la mémoire (à l'adresse 0x7C00, soit segment 7C0 (1984 😉 ), offset 0) et lui donne la main. Donc, en théorie, si l'on écrase ce nombre magique, ce premier secteur du disque ne sera plus reconnu comme un MBR et le BIOS ne chargera pas la routine d'amorçage. Donc lancer la commande suivante revient au même que la commande précédente :

sudo dd if=/dev/zero of=/dev/sdb seek=510 bs=1 count=2

Explication rapide : on écrit sur deux secteurs (count), sachant qu'un secteur à une taille de 1 octet (bs) en partant directement du secteur numéro 510 et en prenant comme source le pseudo-périphérique /dev/zero qui renvoi toujours le caractère "NULL".

Cette méthode invalide la table des partitions. Votre système d'exploitation ne saura plus monter vos partitions.

Si l'on veut être plus précis et conserver la table des partitions et son fonctionnement, il existe au moins 2 méthodes. La première consiste à utiliser parted/gparted pour supprimer le flag "boot" de la partition sur lequel ce drapeau est activé. La deuxième méthode est d'imiter cette fonctionnalité de parted avec dd.

Nous avons vu que le MBR contient la table des partitions c'est-à-dire 64 octets qui décrivent 4 partitions qu'elles soient primaires ou étendues. Nous avons donc 16 octets par partition qui indiquent :

• Un drapeau indiquant si la partition est bootable ou non (un octet).
• L'adresse du premier secteur de la partition en utilisant l'adressage CHS (3 octets).
• Le type de la partition. Voir la liste sur Wikipédia en.
• L'adresse du dernier secteur de la partition en utilisant l'adressage CHS (3 octets).
• L'adresse du premier secteur de la partition en utilisant l'adressage LBA (4 octets).
• Le nombre de secteurs que comportent la partition (4 octets).

Le premier octet indique donc si la partition est bootable (0x80 : bootable, 0x00 : non bootable, autre nombre : non documenté mais souvent considéré comme non bootable). Ce drapeau indique que le File System Boot Sector, c'est-à-dire le premier secteur de la partition (primaire étendue, ...) contient du code ainsi que des informations sur le système de fichier utilisé. Il ne peut y avoir qu'une seule partition marquée comme active dans une table des partitions et donc sur un même médium.

S'il n'y a qu'une partition, le drapeau ne peut se trouver que sur le 447e octet, c'est-à dire, le secteur numéro 446. S'il y a deux partitions, la première ou la deuxième peut avoir ce drapeau. Il se trouve donc soit sur le 447e octet, soit sur le 463e octet (donc numéro 462). En suivant la même logique, on comprend qu'avec 4 partitions, le drapeau peut se trouver au 447e octet, au 463e, au 479e et au 495e.

Pour l'identifier, on utilisera hexdump :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

$  sudo dd if=/dev/sdb bs=512 count=1 of=sortie
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets (512 B) copiés, 0,000203902 s, 2,5 MB/s
 
$ hexdump -vC sortie 
00000000  eb 63 90 d0 bc 00 7c 8e  c0 8e d8 be 00 7c bf 00  |.c....|......|..|
00000010  06 b9 00 02 fc f3 a4 50  68 1c 06 cb fb b9 04 00  |.......Ph.......|
00000020  bd be 07 80 7e 00 00 7c  0b 0f 85 0e 01 83 c5 10  |....~..|........|
00000030  e2 f1 cd 18 88 56 00 55  c6 46 11 05 c6 46 10 00  |.....V.U.F...F..|
00000040  b4 41 bb aa 55 cd 13 5d  72 0f 81 fb 55 aa 75 09  |.A..U..]r...U.u.|
00000050  f7 c1 01 00 74 03 fe 46  10 66 00 80 01 00 00 00  |....t..F.f......|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 be 80 7d  |. ..d|<.t...R..}|
00000090  e8 17 01 be 05 7c b4 41  bb aa 55 cd 13 5a 52 72  |.....|.A..U..ZRr|
000000a0  3d 81 fb 55 aa 75 37 83  e1 01 74 32 31 c0 89 44  |=..U.u7...t21..D|
000000b0  04 40 88 44 ff 89 44 02  c7 04 10 00 66 8b 1e 5c  |.@.D..D.....f..\|
000000c0  7c 66 89 5c 08 66 8b 1e  60 7c 66 89 5c 0c c7 44  ||f.\.f..`|f.\..D|
000000d0  06 00 70 b4 42 cd 13 72  05 bb 00 70 eb 76 b4 08  |..p.B..r...p.v..|
000000e0  cd 13 73 0d f6 c2 80 0f  84 d8 00 be 8b 7d e9 82  |..s..........}..|
000000f0  00 66 0f b6 c6 88 64 ff  40 66 89 44 04 0f b6 d1  |.f....d.@f.D....|
00000100  c1 e2 02 88 e8 88 f4 40  89 44 08 0f b6 c2 c0 e8  |.......@.D......|
00000110  02 66 89 04 66 a1 60 7c  66 09 c0 75 4e 66 a1 5c  |.f..f.`|f..uNf.\|
00000120  7c 66 31 d2 66 f7 34 88  d1 31 d2 66 f7 74 04 3b  ||f1.f.4..1.f.t.;|
00000130  44 08 7d 37 fe c1 88 c5  30 c0 c1 e8 02 08 c1 88  |D.}7....0.......|
00000140  d0 5a 88 c6 bb 00 70 8e  c3 31 db b8 01 02 cd 13  |.Z....p..1......|
00000150  72 1e 8c c3 60 1e b9 00  01 8e db 31 f6 bf 00 80  |r...`......1....|
00000160  8e c6 fc f3 a5 1f 61 ff  26 5a 7c be 86 7d eb 03  |......a.&Z|..}..|
00000170  be 95 7d e8 34 00 be 9a  7d e8 2e 00 cd 18 eb fe  |..}.4...}.......|
00000180  47 52 55 42 20 00 47 65  6f 6d 00 48 61 72 64 20  |GRUB .Geom.Hard |
00000190  44 69 73 6b 00 52 65 61  64 00 20 45 72 72 6f 72  |Disk.Read. Error|
000001a0  0d 0a 00 bb 01 00 b4 0e  cd 10 ac 3c 00 75 f4 c3  |...........<.u..|
000001b0  00 00 00 00 00 00 00 00  b2 17 01 00 00 00 00 20  |............... |
000001c0  21 00 83 aa 28 82 00 08  00 00 00 00 20 00 80 aa  |!...(....... ...|
000001d0  29 82 07 fe ff ff 00 08  20 00 00 00 40 05 00 fe  |)....... ...@...|
000001e0  ff ff 05 fe ff ff fe 0f  60 05 02 f8 3f 05 00 fe  |........`...?...|
000001f0  ff ff 83 fe ff ff 00 08  a0 0a 00 b8 47 04 55 aa  |............G.U.|
00000200

On remarque la marque du MBR (0x55AA), codée ici en little-endian. La table des partitions est donc dans les 64 octets qui précédent : des deux derniers octets (00 20) de la 34e ligne jusqu'au 04 précédent la marque). Nous remarquons la présence de 4 partitions :

1. 00 20 21 00 83 aa 28 82 00 08 00 00 00 00 20 00 (lignes 34-35)
2. 80 aa 29 82 07 fe ff ff 00 08 20 00 00 00 40 05 (lignes 35-36)
3. 00 fe ff ff 05 fe ff ff fe 0f 60 05 02 f8 3f 05 (lignes 36-37)
4. 00 fe ff ff 83 fe ff ff 00 08 a0 0a 00 b8 47 04 (lignes 37-38)

Détaillons :

1. Une partition GNU/Linux (0x83) de 2097152 secteurs (00 00 20 00 => 0x00200000 à cause du little-endian ensuite 0x200000 = 2097152 en décimal).
2. Une partition HPFS ou NTFS ou exFAT (0x07) de 88080384 secteurs (00 00 40 05 => 05400000 pour le little-endian puis conversion). Cette partition est bootable (0x80).
3. Une partition étendue (0x05) de 88078338 secteurs. Pour en savoir plus, il faudra consulter le début de la partition pour avoir une nouvelle table des partitions nous indiquant la nature exacte de la première partition logique et l'adresse de la prochaine partition logique).
4. Une partition GNU/Linux (0x83) de 71809024 secteurs.

Donc, dans notre exemple, le boot flag est sur le 463e octet. Pour l'effacer :

sudo dd if=/dev/zero of=/dev/sdb seek=462 bs=1 count=1

On obtiendra donc :

$ hexdump -vC sortie 
00000000  eb 63 90 d0 bc 00 7c 8e  c0 8e d8 be 00 7c bf 00  |.c....|......|..|
00000010  06 b9 00 02 fc f3 a4 50  68 1c 06 cb fb b9 04 00  |.......Ph.......|
00000020  bd be 07 80 7e 00 00 7c  0b 0f 85 0e 01 83 c5 10  |....~..|........|
00000030  e2 f1 cd 18 88 56 00 55  c6 46 11 05 c6 46 10 00  |.....V.U.F...F..|
00000040  b4 41 bb aa 55 cd 13 5d  72 0f 81 fb 55 aa 75 09  |.A..U..]r...U.u.|
00000050  f7 c1 01 00 74 03 fe 46  10 66 00 80 01 00 00 00  |....t..F.f......|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 be 80 7d  |. ..d|<.t...R..}|
00000090  e8 17 01 be 05 7c b4 41  bb aa 55 cd 13 5a 52 72  |.....|.A..U..ZRr|
000000a0  3d 81 fb 55 aa 75 37 83  e1 01 74 32 31 c0 89 44  |=..U.u7...t21..D|
000000b0  04 40 88 44 ff 89 44 02  c7 04 10 00 66 8b 1e 5c  |.@.D..D.....f..\|
000000c0  7c 66 89 5c 08 66 8b 1e  60 7c 66 89 5c 0c c7 44  ||f.\.f..`|f.\..D|
000000d0  06 00 70 b4 42 cd 13 72  05 bb 00 70 eb 76 b4 08  |..p.B..r...p.v..|
000000e0  cd 13 73 0d f6 c2 80 0f  84 d8 00 be 8b 7d e9 82  |..s..........}..|
000000f0  00 66 0f b6 c6 88 64 ff  40 66 89 44 04 0f b6 d1  |.f....d.@f.D....|
00000100  c1 e2 02 88 e8 88 f4 40  89 44 08 0f b6 c2 c0 e8  |.......@.D......|
00000110  02 66 89 04 66 a1 60 7c  66 09 c0 75 4e 66 a1 5c  |.f..f.`|f..uNf.\|
00000120  7c 66 31 d2 66 f7 34 88  d1 31 d2 66 f7 74 04 3b  ||f1.f.4..1.f.t.;|
00000130  44 08 7d 37 fe c1 88 c5  30 c0 c1 e8 02 08 c1 88  |D.}7....0.......|
00000140  d0 5a 88 c6 bb 00 70 8e  c3 31 db b8 01 02 cd 13  |.Z....p..1......|
00000150  72 1e 8c c3 60 1e b9 00  01 8e db 31 f6 bf 00 80  |r...`......1....|
00000160  8e c6 fc f3 a5 1f 61 ff  26 5a 7c be 86 7d eb 03  |......a.&Z|..}..|
00000170  be 95 7d e8 34 00 be 9a  7d e8 2e 00 cd 18 eb fe  |..}.4...}.......|
00000180  47 52 55 42 20 00 47 65  6f 6d 00 48 61 72 64 20  |GRUB .Geom.Hard |
00000190  44 69 73 6b 00 52 65 61  64 00 20 45 72 72 6f 72  |Disk.Read. Error|
000001a0  0d 0a 00 bb 01 00 b4 0e  cd 10 ac 3c 00 75 f4 c3  |...........<.u..|
000001b0  00 00 00 00 00 00 00 00  b2 17 01 00 00 00 00 20  |............... |
000001c0  21 00 83 aa 28 82 00 08  00 00 00 00 20 00 00 aa  |!...(....... ...|
000001d0  29 82 07 fe ff ff 00 08  20 00 00 00 40 05 00 fe  |)....... ...@...|
000001e0  ff ff 05 fe ff ff fe 0f  60 05 02 f8 3f 05 00 fe  |........`...?...|
000001f0  ff ff 83 fe ff ff 00 08  a0 0a 00 b8 47 04 55 aa  |............G.U.|
00000200

Normalement, la recherche du boot flag incombe à la routine d'amorçage une fois celle-ci chargée en mémoire par le BIOS. Néanmoins, on remarque des comportements différents selon les PCs : certains, ne voyant pas de boot flag sur un médium repassent la main à ce qui doit être le BIOS afin que ce dernier recherche un nouveau média de boot. Sur d'autres PCs, le fait qu'un médium ne soit pas bootable est bloquant (attention : je parle bien pour deux configurations de BIOS identiques et notamment l'ordre de boot). Pour ces derniers, enlever le boot flag sera inutile. Il faudra configurer le BIOS pour ne pas tenir compte du médium ou retirer le medium le temps du boot.