Renommer une interface Ethernet sous GNU/Linux Debian

Vous est-il déjà arrivé de cloner un système sous GNU/Linux Debian et de vous rendre contre que la numérotation de vos interfaces Ethernet (eth<n>) sur le système cible ne débutaient plus à 0 ? La faute à udev !
En effet ce gestionnaire de périphériques se base notamment sur des règle de gestion, sous la forme de fichiers ASCII se trouvant sous /etc/udev/rules.d/. Dans le cadre de la gestion de nos interfaces Ethernet, il s’agit plus particulièrement du fichier /etc/udev/rules.d/70-persistent-dev.rules.
Afin de retrouver une numérotation cohérente sur votre système cible, deux choix s’offrent à vous :

  • Effacer complètement le fichier /etc/udev/rules.d/70-persistent-dev.rules et redémarrer votre système afin que udev se charge de régénérer ce même fichier
  • Modifier à la main le fichier /etc/udev/rules.d/70-persistent-dev.rules en faisant correspondre le nom de l’interface désirée avec l’adresse MAC correspondante tout en démontant/montant chacune de ces interfaces.

Pour information, voici à quoi ressemble le référencement d’une interface Ethernet au sein du fichier /etc/udev/rules.d/70-persistent-dev.rules sous un système sous GNU/Linux Debian :

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Cloner un disque dur virtuel sous VirtualBox

VirtualBox s’appuie sur des Virtual Disk Image ou VDI. Il s’agit de fichiers comportant l’extension “.vdi” représentant des disques durs virtuels pouvant être mis à disposition de vos machines virtuelles. Il peut être parfois intéressant de cloner un disque virtuel afin, par exemple, de le mettre à disposition d’une seconde machine virtuelle.

Dans le cas où votre système hôte tourne sous Microsoft Windows, ouvrez un invité de commandes et utilisez les commandes suivantes :

cd %programfiles%\Sun\VirtualBox
VBoxManage clonehd <disque1>.vdi <disque2>.vdi

Remarques : <disque1> et <disque2> correspondent respectivement au fichiers de vos disques durs virtuels source/destination. Nul besoin de préciser le chemin complet de chaque VDI ; il s’agit par défaut du répertoire de stockage des VDI configuré au sein de VirtualBox.

Le “Multiposte” derrière un routeur : un exemple concret

J’ai donc une Freebox v5 (boîtier ADSL et boîtier HD) et suis dégroupé. Est rattaché à mon boîtier ADSL, un routeur Asus WL-500g : celui-ci est en mode “Home gateway” afin de pouvoir faite du NAT car c’est lui qui détient mon adresse publique, sur une interface rattaché à la Freebox, et une adresse privé sur l’autre. De plus, il contient une route statique vers le sous-réseau dans lequel se trouve mon ordinateur. Sur ce même routeur est connecté un second routeur, un Linksys WRVS4400N : il est configuré avec deux adresses privées ; l’interface WAN est connectée sur le WL-500g. Mon boîtier ADSL fait seulement office de modem (il n’est pas en mode routeur). Enfin mon système d’exploitation n’est autre que la distribution GNU/Linux Ubuntu 8.10 (Intreprid).

2009.02.06 - Multiposte Free - Architecture logique

J’ai décidé d’installer le paquet FreetuxTV en ajoutant le dépôt adéquat :

 $ sudo wget http://packages.freetuxtv.org/ubuntu/intrepid.list -O /etc/apt/sources.list.d/freetuxtv.list
 $ wget -q http://packages.freetuxtv.org/freetux.gpg -O- | sudo apt-key add -
 $ sudo apt-get update
 $ sudo apt-get install freetuxtv

Il est désormais possible de lancer FreetuxTV via le menu Applications > Sound & Video > FreetuxTV Television Channels Player. Le groupe FreeboxTV existe déjà mais il faut le “rafraichir” afin d’obtenir la liste de chaines disponibles. Un simple clic droit sur le groupe puis je sélectionne “Refresh from the playlist” : toutes les chaines sont à présent listées. Je lance alors BFM TV en double cliquant dessus et là… Et bien ça ne marche pas : rien ne s’affiche.

Je vérifie la configuration de mes routeurs, scrute les fichiers de logs, effectue un tcpdump ainsi qu’un netstat sur mon ordinateur… Mais c’est bien sûr ! Certains flux ne passent pas 🙂

Voici les flux nécessaires au bon fonctionnement du “Multiposte” :

 Flux sortant vers 212.27.38.253 sur port TCP/554
 Flux entrant depuis 212.27.38.253 sur les ports UDP/1024-65535

Pour le flux sortant, pas de soucis : on “ouvre” le tout sur les deux routeurs (si ces derniers font du filtrage en sortie). Concernant le flux entrant, je me suis appuyé sur le service Virtual Server proposé par le WL-500g : il s’agit ni plus ni moins que de translater l’adresse IP de destination (notre adresse publique) vers l’adresse IP de mon ordinateur pour tout flux entrant UDP appartenant à la plage de ports 1024 à 65535, en provenance de l’adresse IP 212.27.38.253 ; et bien sûr d’autoriser ces flux.

Une fois la configuration effectué, je tente de visionner BFM TV via FreetuxTV : cela ne fonctionne toujours pas…. Mais pourquoi ? J’effectue de nouveau quelques vérifications et je m’aperçois qu’une partie seulement des paquets UDP arrive jusqu’à mon ordinateur : le reste se retrouve bloquer au niveau du routeur WL-500g. Deny of Service (DoS) ? En effet, un nombre constant et important de paquets UDP transite entre freeplayer.freebox.f (212.27.38.253) et mon ordinateur : mes routeurs ne chercheraient-ils pas à limiter ces flux ? Je me rends donc sur mes deux routeurs puis désactive l’option DoS. Je tente de nouveau regarder BFM TV via FreetuxTV : cela fonctionne !

Je tiens cependant à revenir sur quelques points :

  • Le fait de désactiver l’option DoS n’est pas des plus rassurante… Cependant, via les interfaces Web de configuration de mes routeurs, il n’est pas possible d’ajouter des contraintes de type adresse et/ou port pour l’activation ou la désactivation de cette option. SI vous avez la chance d’avoir un accès SSH/Telnet sur votre équipement et que ce dernier utilise Netfilter, je vous conseille de mettre en place vos propres règles de filtrage en matière de DoS.
  • Le fait de rediriger tous les flux UDP appartenant à la plage de ports 1024 à 65535 vers une machine n’est pas vraiment appréciable : problème de sécurité d’une part mais aussi de configuration dans un environnement où plusieurs ordinateurs utilisent l’option “Multiposte”.

Une envie de PKI : EJBCA sous Debian Etch

Tout d’abord, un petit bonjour à toutes et à tous. J’en profite car cela faisait bien longtemps que je n’étais pas repassé par ici. Abordons à présent les choses “sérieuses” :p Vous avez un serveur sous GNU/Linux Debian Etch ? Vous désirez mettre en place une PKI (Public Key Infrastructure) pour divers raisons ? Dans ce cas, je vous invite à vous rendre sur http://ejbca.org/ afin de découvrir cette autorité de certification.
Venons-en à l’installation de cette dernière. Pour ce faire, nous allons utiliser le paquet mis à disposition sur les dépôts de http://han.pp.se/ Nous allons tout d’abord ajouter deux dépôts dans nos sources APT (Advanced Packaging Tool) :

 $ sudo echo -e "\n# EJBCA\n\
 deb http://debian.han.pp.se/debian/ stable main\n\
 deb-src http://debian.han.pp.se/debian/ stable main\
 " >> /etc/apt/sources.list

Installons à présent le clef d’archive GnuPG du dépôt nouvellement ajouté pour ensuite mettre à jour notre cache :

 $ sudo apt-get update
 $ sudo apt-get install debian-han-pp-se-keyring
 $ sudo apt-get update

Assurons-nous de pouvoir récupérer des paquets dans la catégorie non-free pour les dépôts de notre système puis installons le paquet EJBCA :

 $ sudo apt-get install ejbca

Vérifions alors que ce dernier “tourne” :

 $ sudo netstat -lataupen | grep -i java

Vous devriez voir plusieurs processus java écouter sur divers port TCP, dont les pots 8080 et 8443. Si vous avez un pare-feu sur votre serveur, tel que NetFilter, ouvrez les ports TCP 8080 et 8443 vers votre serveur depuis chez vous par exemple :

 $ sudo iptables -A INPUT -i <ETHX> -s <MY_HOME_IP> -p tcp -m tcp --dport 8080 -m comment --comment "EJBCA access" -j ACCEPT
 $ sudo iptables -A INPUT -i <ETHX> -s <MY_HOME_IP> -p tcp -m tcp --dport 8443 -m comment --comment "EJBCA access" -j ACCEPT

Lançons le paramétrage de EJBCA à l’aide d’un script fournit avec le paquet précédemment installé :

 $ sudo sh /usr/share/ejbca/ejbca-setup

Répondons aux questions qui nous sont posées afin de lancer la configuration de la CA.
Une fois la configuration terminée nous pouvons récupérer le certificat du SuperAdmin, certificat que nous importons ensuite dans notre navigateur préféré. Nous pouvons dès à présent nous rendre sur la page “publique” de notre EJBCA, puis cliquer sur le lien “Administration”. Un certificat nous est demandé : choisissons celui du SuperAdmin et nous voilà sur la plage d’administration de EJBCA !

L’après Halloween

Bonjour à toutes et à tous,

La nouvelle du jour ? La mise à jour de ce Weblogue sous DotClear 2.1. Au menu de cette nouvelle mouture, des thèmes et templates plus souples, la gestion de sous-catégories, l’amélioration de l’interface XML-RPC ainsi que le support des vidéos HD.
Je profite d’ailleurs de l’amélioriation de l’interface XML-RPC afin de tester le client externe ScribFire qui semble très bien fonctionner.
La prochaine étape ? Personnaliser un peu le thème en place et afiner le paramétrage de mon Weblogue. Je vous dis donc à très bientôt 😉

Network bridging avec VirtualBox 1.5.6 sous GNU/Linux Ubuntu 8.04

Par défaut, VirtualBox configure l’interface réseau de votre machine virtuelle à l’aide d’un mécanisme de translation d’adresses plus communément appelé NAT (Network Address Translation).
Cependant, dans le cas où vous possédez un serveur DHCP au sein de votre réseau, il pourrait être appréciable que cette machine virtuelle, comme tout autre machine de votre réseau, puisse acquérir une adresse IP par ce biais.
Nous allons, dans ce cas, faire appel à la technique de pont réseau (Network bridge), afin que l’interface réseau de votre machine virtuelle soit rattachée à celle de votre machine hôte (Les produit VMWare Server et VMWare Workstation doivent, si je ne raconte pas de bêtises, proposer ce choix par défaut).

Dans un premier temps il nous faut installer deux paquets sur la machine hôte :

 $ sudo apt-get install uml-utilities bridge-utils

Ensuite, toujours sur la machine hôte, il nous faut modifier le fichier de configuration de nos interfaces réseaux :

 $ sudo nano /etc/network/interfaces

Dans le cas où vous n’avez qu’une seule interface Ethernet et que celle-ci récupère une adresse auprès d’un serveur DHCP, cela devrait ressembler à ceci :

 auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

Nous venons en effet d’ajouter une nouvelle interface br0, notre Network bridge agissant sur notre interface eth0.
Afin que ces modification soient prises en compte, démontez puis remontez vos interfaces réseau :
sudo /etc/init.d/networking restart

Il s’agit à présent de configurer VirtualBox afin de lui ajouter une nouvelle interface virtuelle se basant sur le pont que nous venons de mettre en place :

 $ sudo VBoxAddIF vbox0 `whoami` br0
$ VBoxManage modifyvm "Nom de ma machine virtuelle" -hostifdev1 vbox0

Remarque : “Nom de ma machine virtuelle” correspond au nom de la machine virtuelle que nous désirons configurer. Afin de récupérer les noms de vos machines virtuelles : $ VBoxManage list vms | grep Name

Pour finir, au sein de l’interface graphique de VirtualBox, assurez-vous de paramétrer correctement votre machine virtuelle : “Nom de ma machine virtuelle” > Settings > Network. Votre interface réseau doit être attachée à l’interface de votre hôte et le nom de cette interface doit être celle que nous avons enregistré précédemment, à savoir vbox0.

Pour la suite, je vous laisse vérifier que votre machine virtuelle a bien récupéré une adresse IP de façon dynamique 😉

Une touche de renouveau en ce début de printemps

Voici un petit moment que je désirais passer à DotClear 2 : C’est donc chose faite !

La migration de DotClear 1.2.x vers DotClear 2 ne fût pas vraiment contraignante, et cela grâce notamment au plugin flatExport. Pour le reste, un brin de patience afin de tout remettre en forme ; cela suffira.

L’interface d’administration a été retravaillée mais on s’y retrouve assez rapidement ; tout est clair et intuitif. J’ai d’ailleurs remarqué que, par défaut, une extension dite “Antispam” était installée, extension permettant de filtrer les commentaires. Nous verrons dans la pratique si cela est fonctionnel mais c’est déjà une bonne chose que de retrouver une telle option surtout après un nombre de spams conséquent, sur mon précédent weblogue, qui m’a obligé dans un premier temps à fermer les commentaires pour ensuite mettre en place une CaptchaBox.

Enfin j’en ai finalement profité pour changer de thème, en m’orientant cette fois-ci sur des couleurs plus sombres. Je tâcherai par la suite d’y apporter ma petite touche personnel mais cela, comme toute chose, demande du temps 🙂

Bon weekend de Pâques à toutes et à tous !

Gestion du FTP avec NetFilter

Il est sûrement arrivé à plus d’un de vouloir laisser passer un flux FTP sur leur pare-feu NetFilter : Quoi de plus normal ?

Survient alors le fameux épisode du module ip_conntrack_ftp, voir en prime ip_nat_ftp dans le cas d’une translation d’adresse. On se renseigne sur la différence entre active mode et passive mode côté FTP, on rajoute quelques lignes dans NetFilter, puis on finit par tester le tout : ça ne fonctionne pas … Ou tout du moins qu’en partie.

On épluche les logs et on se rend finalement compte que l’authentification s’est correctement effectuée, mais que cela bloque dès lors qu’une commande est envoyée : Mais pourquoi donc ? Vient alors la découverte du module ip_conntrack_ftp, la solution à tous nos soucis. Un suivi de connexion effectué par iptables rien que pour le FTP : n’est ce pas merveilleux ? On s’empresse alors de charger ce fameux module :

# modprobe ip_conntrack_ftp

Puis on relance notre test afin de s’assurer que tout fonctionne.

Cependant nous aimerions bien mettre en place une petite translation de destination. Dans ce cas, nous pensons à bien charger le module adéquat :

# modprobe ip_nat_ftp

Il nous vient soudain une idée : Pourquoi ne pas changer le port par défaut de notre serveur FTP ? 45 au lieu de 21, ça semble pas mal ça ? Sachant qu’en plus de cela nous avons un autre serveur FTP qui est à l’écoute sur le port 44.

On se rend finalement compte que cela ne fonctionne plus, de nouveau. En effet il faut indiquer à ce cher module ip_conntrack_ftp le(s) port(s) que ce dernier doit gérer. Pour ceci, l’option ports est des plus remarquable :

# modprobe ip_conntrack_ftp ports=44,45

Si le module en question était déjà chargé, il est bien sûr nécessaire de le décharger avant de le charger avec la commande précédente :

# rmmod ip_conntrack_ftp

Il peut être enfin appréciable de faire en sorte que tout cela se charge au démarrage de la machine. Sur une distribution telle que GNU/Linux Debian Etch, deux fichiers s’avèrent nécessaires :

  • Le fichier /etc/modules contenant les modules à charger, ligne par ligne, tels que ip_conntrack_ftp et ip_nat_ftp
  • Le fichier /etc/modprob.d/arch/i386 contenant des aliases et options pour les modules à charger. Dans le cas du module ip_conntrack_ftp, il s’agirait d’ajouter la ligne suivante : options ip_conntrack_ftp ports=44,45

On redémarre notre machine et voilà que tout semble fonctionner du premier coup : Que du bonheur !

Détente près du toit de l’Europe

La voici enfin venue, la semaine tant attendue : ma semaine de vacances !
Avec ma chérie, nous voici depuis samedi dernier dans le petit village de Samoëns, au pied du domaine skiable du Grand Massif.

http://maps.google.fr/maps?q=Samo%C3%ABns,+France&ie=UTF8&ll=46.137977,6.760712&spn=0.217117,0.466919&z=11&om=0&output=embed&s=AARTsJrje2O7QD8xR3RIJBNWMGrazRhljw
Agrandir le plan

A défaut de vous raconter tout cela, je fonce sur les pistes !