Archives mensuelles : octobre 2008

Falling back to PORT instead of PASV mode

Raaah, je me trainais ce truc là depuis longtemps ; pourtant je sais parfaitement que le FTP est un de ces protocoles un peu pourris vis-à-vis des firewalls (et proxies), mais j’avais jamais rien fait pour m’arranger la situation.
Bref, l’occasion de faire un rappel – je passe la théorie car je donnerais dans l’à peu près, mais j’explique l’aspect pratique pour régler le problème titre de cet article.

Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau 🙂

La configuration

J’ai un serveur avec :

  • un FTP – restreints à certaines IP, rappelez-vous que FTP n’est pas du tout sûr (mot de passe en clair) et qu’il vaut mieux privilégier SFTP (du FTP par dessus SSH),
  • un shorewall ouvrant les ports 20 et 21
  • Bref que du bonheur en apparence.

    Le problème

    Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
    Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :

    Falling back to PORT instead of PASV mode

    En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode « PORT » justement. Soit environ 19,8 secondes de trop.

    Comment on le règle ?

    On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
    ./kernel/net/netfilter/nf_conntrack_ftp.ko
    ./kernel/net/ipv4/netfilter/nf_nat_ftp.ko

    Point besoin de rebooter, rien.
    Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.

    Excusez-moi pour l »à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.

    Priver son WordPress : LDAP, accès membres uniquement…

    WordPress est un outil de blog (un CMS diront certains) que je trouve assez sympa. Son premier but est de pouvoir publier facilement un blog, c’est-à-dire publier du contenu. Il n’est cependant pas trop prévu pour publier du contenu à accès restreint.

    Dans les dernières versions, on voit des options pour protéger par mot de passe un article (ou une page). Mais ça s’arrête là, mais ça peut suffire dans bien des cas.
    J’avais besoin de monter un site rapidement avec quelques pages statiques et des news, facilement éditables. WordPress convenait donc, mais dans un contexte entreprise, il fallait priver l’intégralité de l’accès.
    En cherchant un peu, on trouve donc 2 plug-ins parfaits pour ça.
    Voici ce retour d’expérience : installer WordPress avec authentification LDAP et contenu complètement privé (members-only).

    Installation

    Je suis parti sur une version SVN (la 2.6.2) car elle permet d’utiliser des plug-ins récents, qui ne fonctionnent pas pour ma version “stable” Debian (2.0.x). J’ai donc tout fait à la main, je vous résume ceci.

    Préparation de la base MySQL

    En console mysql, vous taperez par exemple :

    CREATE DATABASE wordpress;
    CREATE USER ‘wpadmin’@'localhost’ IDENTIFIED BY ‘mon_passwd’;
    GRANT ALL ON wordpress.* TO ‘wpadmin’@'localhost’;
    

    Ceci vous crée la base vide et un utilisateur d’administration.

    Installation et configuration de l’application

    Je schématise, côté OS et téléchargement de l’application :

    mkdir /srv/www/wordpress
    cd /srv/www/wordpress
    svn co http://svn.automattic.com/wordpress/trunk/ 
    

    Vous éditerez alors votre fichier /srv/www/wordpress/trunk/wp-config.php pour y renseigner au moins les champs suivants :

    define(’DB_NAME’, ‘wordpress’);
    define(’DB_USER’, ‘wpadmin’);
    define(’DB_PASSWORD’, ‘mon_passwd’);
    define(’DB_HOST’, ‘localhost’);
    

    Vous ajouterez la conf Apache qui va bien (VirtualHost ou non), avec au moins ceci :

    < Directory> # sans l'espace
        Options FollowSymLinks
        AllowOverride Limit Options FileInfo
        DirectoryIndex index.php
    < /Directory> # sans l'espace

    Du classique, je ne détaille pas trop, je me concentre sur WordPress, pas Apache2.

    Lancement de l’installeur

    Ensuite, vous irez sur http://votre_site/votre_blog/wp-admin/install.php pour lancer l’installation en 2/3 clics.
    Vous voilà avec un wordpress tout vide et opérationnel.
    Je passe sur le tour du propriétaire, j’enchaîne directement sur le choix et l’installation des plug-ins qui vont bien.

    Les plug-in LDAP

    Il y en a plusieurs, plus ou moins suivi, plus ou moins compatibles avec votre version de WordPress. J’ai trouvé sur le site notamment celui-ci (wpDirAuth) compatible avec plein de LDAP, notamment OpenLDAP.
    Après 2 heures de galère, on apprend que la version officielle sur ce site (1.2) n’est pas compatible avec WordPress 2.6+.
    Vous utiliserez donc la version 1.3 disponible ici.
    L’installation est classique, en gros :

    cd /srv/www/wordpress/trunk/wp-content/plugins
    wget http://www.royal.wednet.edu/~ayearout/wpDirAuth-1.3.zip
    unzip wpDirAuth-1.3.zip

    Puis activation du plugin dans l’interface d’administration de WordPress. Classique. Son paramétrage ressemble à ceci, très complet :

    plug-in LDAP pour WordPress

    Plug-in “members-only”

    Enfin, ce plug-in permet de faire en sorte qu’il faille être connecté pour accéder au moindre contenu. Par défaut, vous êtes donc redirigé vers la page d’authentification.

    plug-in \"members-only\" pour WordPress

    Et voilà le travail

    Pense-bête pour migrer « sympa », l’outil de mailing-lists

    Salut,

    J’ai eu à déplacer l’outil sympa – très bien pour gérer des mailings-lists avec modération – d’un serveur à un autre.
    L’outil était sur le backend de mail, avec la conf apache de sympa, la base de données de sympa et évidemment les binaires (le package sympa).
    Le but était de déplacer la partie binaire, apache et base de données ; en conservant les boîtes mails et alias sur le backend de départ.

    Je vous livre un petit retour d’expérience car c’est un poil plus compliqué que de déplacer une application LAMP classique.
    Je partais d’une version Debian/stable, donc package sympa 5.2.3-1.2+etch1 et la cible était la même.

    Je considère que vous avez déjà un Apache2 et MySQL sur la machine cible – et une machine cible capable de relayer des mails (recevoir et envoyer) sur postfix

    La migration classique

    La base reste la même :
    1) Sur la machine cible, installez l’application – même version évidemment, packagée.
    2) Reprenez (à la main ou en écrasant) la conf /etc/apache2/conf.d/sympa d’un serveur à l’autre
    3) Reprenez ou adaptez /etc/sympa
    4) Exportez/importez la base de données « sympa », comme une brute, par exemple :

    machine_depart:$> mysqldump -u votre_user_qui_va_bien -p -B sympa > migr_sympa.sql
    puis
    machine_cible:$> mysql -u user -p < migr_sympa.sql

    5) Assurez-vous d'avoir les bons identifiants de login de l'application sympa dans les tables "mysql" de Mysql (= les tables du schéma mysql. Pigé ? il doit y avoir notamment une ligne dans la table mysql.user concernant le User sympa) :

    use mysql ; SELECT * from user where User = 'sympa';

    La partie spécifique "sympa"

    Ce qui est ci-dessus est ce que vous auriez à faire avec une appli LAMP typique qui stocke tout en base.
    Manque de chance, sympa - au moins dans la version 5.2 (actuellement 5.4 dispo, pas essayé) - stocke tout un tas d'informations dans /var/lib/sympa, /usr/lib/sympa etc. Sans compter les alias mails qui permettent de transmettre les mails aux processus de gestion de sympa.
    Donc il vous reste à faire :

    La redirection des alias mail

    Normalement, sur votre serveur de départ, vous devriez avoir tout un tas d'alias de mail dans /etc/aliases, genre :

    sympa:             "| /usr/lib/sympa/bin/queue sympa"
    listmaster:        "| /usr/lib/sympa/bin/queue listmaster"
    sympa-request:     postmaster
    sympa-owner:       postmaster
    maliste1:          "| /usr/lib/sympa/bin/queue maliste1"
    maliste1-request:  "| /usr/lib/sympa/bin/queue maliste1-request"
    maliste1-owner:    "| /usr/lib/sympa/bin/bouncequeue maliste1"
    maliste2.....
    

    Il faut reprendre cette configuration telle quelle sur la machine cible et s'assurer sur la première - qui reste la machine de backend de mail (mon MX en gros), donc celle qui reçoit le mail - qu'elle sache faire suivre tout ça à la machine cible qui est devenue celle qui gère sympa.
    Donc dans la machine de départ, vous trafiquerez tout de la sorte :

    sympa:             "sympa@machinecible.com"
    listmaster:        "listmaster@machinecible.com"
    sympa-request:     postmaster (j'ai laissé tel quel, c'est un choix)
    sympa-owner:       postmaster (j'ai laissé tel quel, c'est un choix)
    maliste1:  "maliste1@machinecible.com"
    maliste1-request:  "maliste1-request@machinecible.com"
    maliste1-owner:  "maliste1-owner@machinecible.com"
    maliste2.....
    

    A la recherche du bordel éparpillé partout

    Ensuite, je m'étais arrêté là - ahahah, erreur.
    Sur l'interface web (la nouvelle), je ne voyais plus mes listes. La raison est que "sympa" stocke les listes, les archives etc hors de la base, dans des répertoires comme /usr/lib/sympa et /var/lib/sympa.
    Donc, il faut reprendre tout ça sur la machine cible (des bêtes "tar" avec conservation des permissions suffisent).
    Finalement, j'ai opté pour un joli :

    dpkg -L sympa | less

    De là, je suis passé dans tous les répertoires nommés (sauf les doc, le "man" etc - faut pas pousser) et je me suis assuré qu'il n'y ait pas de différence - attention à certains droits en setuid/setgid au nom de "sympa:sympa".

    Ensuite, vous envoyez la purée auprès de vos utilisateurs pour leur indiquer que le système est à nouveau dispo, sur une liste modérée tant qu'à faire, afin de bien faire tous les tests.
    Si rien n'arrive, c'est pas grave, vous avez raté un truc.
    Si vous recevez la demande de modération, c'est que ça semble bien parti 🙂

    Le nettoyage

    Lorsque vous ferez le DROP DATABASE sympa sur l'ancienne machine et le aptitude purge sympa, ça vous confirmera ce que je vous racontais sur le stockage des archives, des listes etc :