lalahop
Categorie: Administration réseau

VirtualBox : configurations réseau possibles

Pour mes expériences diverses, j'adore utiliser des machines virtuelles. Je suis fan de VirtualBox OSE (et bientôt de KVM/Qemu 😉 ). Ce billet se propose de résumer les différentes configurations réseau possibles avec VirtualBox.

Avant tout, je vous conseille la lecture de la documentation de VirtualBox qui a le mérite d'être bien fournie sur le sujet : Chapter 6. Virtual networking.

Réseau interne : permet de créer un réseau virtuel, limité aux machines virtuelles qui y ont été explicitement ajoutées. Sous GNU/Linux, la sécurité est encore plus grande puisque seules les machines virtuelles crées par le même utilisateur (la comparaison est faite sur l'UID) peuvent être reliées entre elles. Les machines virtuelles peuvent communiquer entre elles sans restrictions mais elles ne peuvent pas communiquer avec l'hôte. Ce mode permet de tester des configurations réseau sans dommages sur le vrai réseau. On peut aussi imaginer un petit laboratoire permettant d'étudier les vers (disséquer sans risque, voir la propagation sur un réseau ...).

NAT : je me sers de ce mode quand je souhaite accéder seulement à Internet ou à d'autres services fournis sur mon réseau (exemple : un serveur web). L'hôte et l'invité partage la même adresse IP : la machine virtuelle est donc transparente sur le réseau : il n'y a pas de nouvelle machine. Par défaut, il est impossible de joindre l'invité depuis l'hôte. Cependant, on peut utiliser le port forwarding afin d'accéder à un ou plusieurs ports de l'invité. Voir la doc concernant le port forwarding. Cette idée du port forwarding m'a été donnée, pour la première fois, lors de la lecture du blog de Gauthier Garnier.

Cependant, le port forwarding n'est pas toujours la meilleure solution lors de simulation réseau. Pour cela, il existe un autre mode :

Accès par pont : VirtualBox bypass la pile réseau de l'hôte et accède directement à la carte réseau choisie. Vu du réseau, une nouvelle machine apparait. L'invité à accès au reste du LAN, à internet (comme avec le mode NAT quoi). Mais en plus, l'hôte (et les autres machines du LAN) peut avoir accès à la machine virtuelle sans port forwarding.

Je me sers de ce mode pour faire des expériences plus complexes entre l'invité et l'hôte et/ou mon LAN réel. Mais, parfois, je n'ai pas de routeur ni de commutateur connecté a mon hôte mais juste un modem. Dans ce cas précis, je n'arrive pas à faire communiquer mon invité et mon hôte en mode "accès par pont". Cela fonctionne en mode "NAT" mais je ne peux pas accéder comme je veux à l'invité via le réseau (comprendre : le port forwarding a des limites). Pour cela, il existe encore un autre mode :

Réseau privé hôte : Il s'agit d'un mix entre le mode "réseau interne" et le mode "accès par pont" : une ou plusieurs machines virtuelles peuvent communiquer entre elles et avec l'hôte sans limites. Néanmoins, les machines virtuelles n'ont pas accès au LAN réel ni à Internet. Cela peut néanmoins s'arranger :

Étape 1 : Transformer votre hôte en passerelle.

$ sudo -i
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# exit

Si vous voulez conserver l'ip forwarding après un reboot de l'hôte, pensez à décommenter la ligne "net.ipv4.ip_forward=1" dans le fichier /etc/sysctl.conf. Pour remettre les actions par défaut dans la table NAT, pensez à la commande :

sudo iptables -t nat -P POSTROUTING ACCEPT

Etape 2 : Ajoutez une route par défaut à l'invité :

sudo route add -net default gw IPHote

N'oubliez pas de remplacer IPHote par l'adresse IP de l'interface créée par VirtualBox sur l'hôte.

Il ne vous reste plus qu'a configurer les DNS (/etc/resolv.conf) et c'est terminé.

Remarque : je n'ai traité que le cas où le système hôte et le système invité sont des Unix. Je n'ai pas testé les cas avec un Windows comme invité ou comme hôte mais voici quelques pistes vers lesquelles chercher si ça vous intéresse.

  • Si votre hôte est un Windows et votre invité est un Unix, il faudra suivre ceci (marche aussi pour les dernières versions de Windows d'après ce qu'on m'a dit) pour l'étape 1. L'étape 2 ne change pas.
  • Si votre hôte est un Unix et votre invité un Windows, seul l'étape 2 change. La ligne de commande doit être quelque chose comme :
    route add 0.0.0.0 mask 0.0.0.0 IPHote
  • Si votre système hôte et votre système invité sous tous les deux des Windows, il faudra suivre les deux points ci-dessous.

Réseau VDE : ce mode apparait dans la liste quand le logiciel VDE est installé sur l'hote. Virtual Distributed Ethernet (VDE) est un commutateur virtuel. Il permet de relier les machines virtuelles (et même l'hôte selon la manière dont il est configuré) entre elles et offre les fonctions supplémentaires d'un commutateur (VLAN, STP, etc.). Il permet de faire un réseau encore plus réaliste. Allez sur le wiki du projet VDE pour avoir plus d'informations.

Sinon, pour cloner un disque dur virtuel (.vdi) afin de l'utiliser dans une autre machine virtuelle (par exemple), c'est par là : http://www.mdl4.com/2010/05/how-to-copy-clone-a-virtualbox-vdi-in-ubuntu/

ÉDIT du 07/08/2011 à 0h45 : Et pour accéder aux dossiers partagés avec GNU/Linux comme système invité, il suffit de faire :

mount -t vboxsf sharename mountpoint

Où "sharename" est le nom du partage tel que vous l'avez défini lors de sa création. "mountpoint" doit bien éviter exister dans le système de fichiers. Exemple :

mount -t vboxsf docs /mnt/docs

Source :Documentation officielle de Virtualbox.
Fin de l'édit

Mettre en place un résolveur DNS sur un WRT54GL équipé d’OpenWRT

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

Protéger le cache ARP de vos machines

Table des matières

Pour comprendre cet article, il est nécessaire de connaitre les bases du protocole réseau ARP.

Quel est l'intérêt de protéger la table ARP ?

La modification, par un acteur malveillant, de la table ARP peut conduire à des attaques réseau très efficaces telle que l'attaque de l'homme du milieu (in english : man of the middle attack 😀 ) qui permet de voir les flux échangés. Vu le nombre de flux qui circulent en clair sur un réseau informatique, on comprend mieux le problème. Si vous voulez tester, chez vous évidemment, la mise en place et les effets d'une attaque de l'homme du milieu, je vous recommande le logiciel ettercap.

Cette attaque est efficace car elle est difficile à contrecarrer. En effet, ils faut faire en sorte que chaque équipement relié au réseau connaisse, de manière statique l'adresse MAC de tous les autres équipements du réseau. Pour un petit réseau, c'est encore gérable. Mais pour un grand réseau, cela devient vite la galère a gérer (nombre d'associations, hétérogénéité des systèmes d'exploitations, etc.). C'est encore plus ingérable avec des périphériques mobiles car la même IP sur deux réseaux distincts n'aura pas la même MAC. Exemple pour comprendre : sur le réseau A, l'IP 192.168.1.1 est associée à la MAC aa:bb:cc:dd:ee:ff. Sur le réseau B, la même IP est aussi utilisée et a pour adresse MAC gg:hh:ii:jj:kk:ll. Il faudra changer l'association IP <=>MAC selon le réseau sur lequel vous êtes. Cela peut se révéler pénible selon la fréquence à laquelle vous changez de réseau.

Il existe des solutions que nous n'aborderons pas telle que le logiciel arpwatch, qui permet d'être prévenu dans le cas où une nouvelle machine se connecterait au réseau ou changerait d'adresse. Dans la même veine, les système de détection d'intrusion (qui a parlé d'élever un cochon ? 😉 ) permettent de s'apercevoir qu'une attaque de type corruption du cache ARP est en cours d'exécution.

L'intérêt de protéger le cache ARP est faible pour le réseau local d'un particulier. En effet, à moins que le wifi soit activé et insuffisamment protégé, le seul moyen de vous nuire est de rentrer chez vous et de placer un équipement minimaliste sur votre réseau. Mais si un acteur malveillant parvenait à s'introduire chez vous, il aurait surement plus intéressant à faire car le monde des attaques physiques s'ouvrirait alors à lui.

Nous allons quand même voir comment protéger le cache ARP dans un but de connaissance.

Quelle est la problématique ?

Il faut, pour chaque système d'exploitation, pour chaque interface réseau, pour chaque machine reliée au réseau, enregistrer, de manière statique, toutes les correspondances entre toutes les adresses IP et les adresses MAC qui circulent sur le réseau. Deux problèmes se posent alors :

  • le cache ARP est vidé à chaque arrêt d'une machine. Il nous faut donc trouver un procédé pour le remplir à chaque démarrage
  • les systèmes d'exploitation, que ce soit Windows ou GNU/Linux, refusent que l'on modifie l'adresse de la passerelle (sur le réseau local d'un particulier, il s'agit en général du routeur) en cours de route. C'est justement là que se trouve le plus gros vecteur d'attaque : pour avoir une vue intégrale des flux échangés entre une machine et les autres machines (y compris celles sur internet), l'attaquant se placera entre la machine et sa passerelle. Il va donc falloir ruser.

Comment faire sous Windows

D'abord, renommez votre interface (dans le panneau de configuration) afin d'enlever le "é" dans "Connexion au réseau local". Le nouveau nom n'a pas d'importance : il doit juste ne pas contenir d'accent. Nous aurons besoin de deux scripts batch.

Il n'y a pas de retour à la ligne. Le premier script configurera la connexion sur une plage d'adresse que nous n'avons pas. Ce qui donne :

netsh interface ip set address "Connexion au reseau local" static 10.0.0.20 255.0.0.0 10.0.0.50 1

Ici on configure la connexion pour être sur le réseau 10.0.0.0/8 avec la passerelle 10.0.0.50. Bien sûr, si vous utilisez cette plage au quotidien, prenez-en une autre car il ne faut pas que la plage que vous utilisez au quotidien soit la même que celle que vous déclarez dans ce script.

Le deuxième script devra vider puis remplir la table ARP et basculer la configuration de l'interface réseau sur la bonne plage d'adresse. Ce qui nous donne :

timeout 15
arp -d *
arp -s 192.168.1.1 95-49-e5-79-4e-09
netsh interface ip set address "Connexion au reseau local" dhcp

N'oubliez pas d'adapter la dernière ligne si vous n'utilisez pas DHCP. Le timeout 15 n'est pas nécessaire : un timeout 5 peut suffire. Mais je joue la prudence dans cet exemple. D'autant plus que cela ne nous gêne pas : le temps d'ouvrir votre session, le réseau sera quand même configuré.

Maintenant, il s'agit de lancer le premier script à l'arrêt de Windows et le deuxième au démarrage de Windows. Attention, je dis bien au démarrage de Windows, pas à l'ouverture d'une session. Tout cela se fait dans gpedit.msc. Ouvrez-le. Sous "configuration de l'ordinateur", allez dans "Paramètres Windows" puis dans "Scripts (démarrage/arrêt)". Il ne vous reste plus qu'à ajouter les scripts dans la bonne catégorie.

Comment faire sous GNU/Linux

J'utiliserai Ubuntu. Tout ce qui suit devra être réaliser avec le compte root. Il faut créer un script dans le dossier /etc/init.d dont voici le contenu :

#!/bin/sh
arp -s 192.168.1.1 95:49:e5:79:4e:09

Le squelette de ce script est inspiré de celui de ce site.

Notes :

  • Vous pouvez utiliser la commande ip à la place de la commande arp. Sa syntaxe : ip neigh add IP lladdr MAC nud permanent dev INTERFACE.
  • Vous pouvez aussi utiliser un fichier pour remplir le cache ARP. Cela allégera votre script. Généralement, on utilise le fichier /etc/ethers. Il faut remplir le fichier avec une association par ligne, en respectant cette mise en forme :
    95:49:e5:79:4e:09 192.168.1.1

    Ensuite, il faut remplir le cache ARP en se servant de ce fichier avec la commande :

    arp -f /etc/ethers

    C'est donc cette commande que vous mettrez dans le script que vous avez créé dans /etc/init.d si vous choisissez cette méthode.

Ensuite vous devez rendre le script créé exécutable avec un bon vieux :

chmod +x /chemin/vers/le/script

Il ne reste qu'à demander à exécuter le script au boot avec la commande :

update-rc.d SCRIPT defaults 20

SCRIPT est le nom que vous avez donné au script. 20 désigne l'ordre de démarrage.

Cas d'OpenWRT

Sous OpenWRT, la commande arp ne sert qu'à visionner la table ARP. Vous devez donc utiliser la commande ip.

La première étape consiste à installer cette commande :

opkg install ip

La deuxième étape consiste à créer un script dans /etc/init.d dont voici le contenu :

#!/bin/sh /etc/rc.common
START=40
boot() 
{
	ip neigh add 192.168.1.1 dev br-lan lladdr 95:49:e5:79:4e:09 nud permanent

}
 
start() 
{
	ip neigh add 192.168.1.1 dev br-lan lladdr 95:49:e5:79:4e:09 nud permanent
}

Il n'y a toujours pas de retour à la ligne. Ce code est inspiré du code des autres scripts de démarrage fournis par défaut avec OpenWRT.

La troisième étape, tout comme sous Ubuntu est de rendre le script exécutable :

chmod +x /chemin/vers/le/script

La dernière étape est de faire un lien symbolique de /etc/init.d/Script vers /etc/rc.d/SxxScript (où Script est le nom du script et xx l'ordre de démarrage du script dans le boot) :

ln -s /etc/init.d/eviterARPCachePoisoning /etc/rc.d/S40eviterARPCachePoisoning

Toujours pas de retour à la ligne 😉

Il ne vous reste plus qu'à redémarrer toutes vos machines et à contrôler le résultat avec la commande suivante :

arp -a

Toutes les adresses que vous avez configuré doivent apparaitre, complétées par le terme "PERMANENT" sous les systèmes *nix.

Si tout est en place, vous pouvez retenter une attaque de l'homme du milieu. Vous ne parviendrez pas à capturer le moindre flux, cette fois-ci.

Pour illustrer le fait que toutes les machines du réseau doivent connaitre, de manière statique, toutes les autres associations IP/MAC du réseau, faites l'expérience suivante : sur une machine, ne fixez pas l'association IP/MAC de la passerelle. Sur la passerelle, fixez l'association IP/MAC de la machine. Tentez maintenant une attaque de l'homme du milieu et surprise : vous aurez la moitié des flux : la machine vous enverra bien les paquets mais la passerelle ne se laissera pas berner puisqu'elle connais la véritable MAC de votre machine et répondra à cette adresse MAC. Même si les réponses de la passerelle lui parviennent, la machine ne sait pas les interpréter car ce n'est pas la passerelle qu'elle a interrogé mais ce qu'elle croit être la passerelle mais qui est en fait la machine de l'attaquant. Dans ce cas de figure, l'attaque n'est pas invisible pour la victime car le traffic réseau est paralysé.

Enjoy 😀

Adieu DG834G, bonjour WRT54GL et OpenWRT

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 :

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" &gt; /proc/diag/led/ses_orange

Allumons la LED wifi :

echo "1" &gt; /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.