Depuis le temps je m’étais fait une raison, je trouvais presque normal d’avoir ce genre de ligne dans mon interface web Nagios :

SMTP OK - 0,012 sec. de temps de réponse

Je suis tombé au hasard du web sur LA solution simple et efficace pour résoudre le problème, un grand merci à Silverlake:

1. S’assurer que dans le fichier /etc/apache2/conf.d/charset la ligne « AddDefaultCharset UTF-8 » soit bien décommentée.
2. Dans le fichier /etc/nagios3/cgi.cfg rechercher la ligne « escape_html_tags » et passer la valeur de 1 à 0.

Redémarrer apache et nagios

SMTP OK - 0,012 sec. de temps de réponse

C’est plus joli comme ça, non?

Objectif : Réaliser l’authentification basique Apache pour un Webdav avec une base d’utilisateurs en MySQL, et le mot de passe stocké avec un cryptage non réversible dans la base. J’ai un peu galéré dans cette affaire, les infos qu’on trouve ne sont pas forcément d’actualité, voici donc un petit topo.

On commence par installer le paquet qui va bien pour qu’Apache puisse causer gentiment à MySQL via dbd :

aptitude install libaprutil1-dbd-mysql

Ensuite on active le module d’authentification dbd :

a2enmod authn_dbd
apache2ctl restart

Création de la base sous MySQL. Pour faire simple la table utilisateurs ne comprend que 2 champs, login et pass:

CREATE DATABASE mabase CHARACTER SET UTF8;
CREATE TABLE IF NOT EXISTS `utilisateurs` ( 
      `login` varchar(255) NOT NULL,  
      `pass` varchar(255) NOT NULL,  
      UNIQUE KEY `login` (`login`)) 
      ENGINE=MyISAM DEFAULT CHARSET=utf8;

Toujours sous MySQL on crée un utilisateur « apache » avec des droits limités à la table :

CREATE USER 'apache'@'localhost' IDENTIFIED BY  'secret';
GRANT SELECT ON  `mabase`.`utilisateurs` TO  'apache'@'localhost';

Ensuite on remplit la table MySQL et c’est là qu’il faut faire les bons choix pour le cryptage du mot de passe et ne pas se gourer. Apache reconnait 4 formats de mots de passe : PLAIN TEXT, CRYPT, SHA1 et MD5.
PLAIN TEXT est clairement à éviter, SHA1 et MD5 sont les plus robustes. Entre les deux SHA1 serait potentiellement le meilleur sauf que l’implémentation Apache est à priori faiblarde (pas de « grain de sel ») donc j’ai retenu MD5, mais ça reste un choix qu’on peut discuter le soir au coin du feu.

En tout cas, et quel que soit le cryptage choisi, la première chose à ne pas faire c’est d’utiliser les fonctions de cryptage de MySQL (password, MD5, SHA1), c’est complètement incompatible avec l’authentification Apache. Une fois qu’on a compris ça on a fait un grand pas!

On va donc générer en bash le hash MD5 du mot de passe avec l’utilitaire htpasswd fourni par Apache et l’enregistrer dans la base (la fonction htpasswd a surement été portée dans votre langage préféré).

Le cryptage est en MD5 par défaut, les options -n et -b permettent respectivement de rediriger le résultat vers la sortie standard et d’utiliser le mode batch :

mysql -u admin -p -e "INSERT INTO utilisateurs (login, pass) VALUES ( \
     "\""robert"\"", \
     "\""$(htpasswd -nb robert secret |cut -d ':' -f 2)"\"")" mabase

On met ensuite à jour le Virtual Host pour qu’Apache puisse aller chercher les infos d’identification dans la base :

<VirtualHost *:80>
	ServerName webdav.mondomaine.org
	DocumentRoot /var/www/webdav
	...
	DBDriver mysql
	DBDParams "socket=/var/run/mysqld/mysqld.sock dbname=mabase user=apache pass=secret"
	DBDMin  4
	DBDKeep 8
	DBDMax  20
	DBDExptime 300
	...
	<Directory /var/www/webdav>
		...
		AuthName "Webdav"
		AuthType Basic
		AuthBasicProvider dbd
		# Requete SQL pour l'authentification
		AuthDBDUserPWQuery "SELECT pass FROM utilisateurs WHERE login = %s" 
		Require valid-user
	</Directory>
	...
</VirtualHost>

et on redémarre Apache :

apache2ctl restart

Liens

PHP : Comparaison MD5 / SHA-1

Le problème est lié au type d’authentification utilisé par Apache, l’authentification basique (AuthType Basic) n’est pas supportée par Windows 7. En http on pourrait comprendre pour des raisons de sécurité, le mot de passe est transmis en clair, mais en https c’est pareil alors que la connexion est cryptée dans un tunnel SSL. Il y avait déjà eu le même problème avec Vista, réglé par un patch, mais pour l’instant rien ne s’annonce pour Windows 7.

Que peut-on faire?

Côté poste client

Si on n’a pas accès à la configuration du serveur, il y a des clients Webdav qui permettent de contourner le problème, Bitkinex semble avoir la cote actuellement mais je ne l’ai pas testé.

Sur le poste client Windows 7 on peut aussi autoriser l’authentification basique en donnant la valeur 2 à la clé de registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel

Coté serveur

Apache propose un autre mode d’authentification, digest, basé sur les condensés MD5, à priori plus sécurisé et accepté par les clients intégrés à Windows 7, Vista et XP. Par contre cette méthode d’authentification n’est pas forcément implémentée dans les anciens navigateurs.

Activation du module auth_digest :

a2enmod auth_digest
apache2ctl restart

Un exemple de config Apache :

Dav on
<Location /webdav/>
AuthType digest
AuthName "monwebdav"
AuthDigestDomain /webdav/ http://mondomaine/webdav/
AuthDigestProvider file
AuthUserFile /www/auth/webdav
Require valid-user
</Location>

Pour créer le fichier des utilisateurs, ici /www/auth/webdav avec le premier utilisateur toto, on utilise htdigest :

htdigest -c /www/auth/webdav monwebdav toto

Le « realm » de htdigest doit correspondre à la directive AuthName, ici c’est « monwebdav ».

Pour les utilisateurs suivants on enlèvera le -c :

htdigest /www/auth/webdav monwebdav turlututu

Liens

How to fix Windows 7 64 bits Webdav
Using Basic Authentication with Windows 7 and Windows Vista WebDAV Client

Un certificat ssl avec passphrase (phrase de passe selon l’Académie Française) sous Apache, au premier abord ça semble bien pour la sécurité mais dans les faits c’est un très bon moyen d’avoir un serveur en rade sans savoir pourquoi: la passphrase est demandée à chaque redémarrage d’Apache, il faut donc une intervention humaine. Si Apache est redémarré par un script ou un reboot du serveur il restera à attendre cette fichue passphrase qui a peu de chance d’arriver comme ça…

La solution est de supprimer la passphrase de la clé privée, qu’on aura sauvegardée au préalable :

cp -a mondomaine.key mondomaine.key.sav
openssl rsa -in mondomaine.key.sav -out mondomaine.key
chmod 400 mondomaine.key

Lien

How can I get rid of the pass-phrase dialog at Apache startup time?

En migrant mon serveur Nagios sur une nouvelle machine j’ai à nouveau rencontré un problème que j’avais eu lors de la première installation : impossible de forcer la vérification d’un service par l’interface Nagios (commande Re-schedule the next check of this service).

Le message d’erreur que j’avais était « Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’! », certaines personnes signalent le message « Error: No command was specified » sur le même sujet.

C’est un problème de droits d’accès entre Nagios et Apache sur le répertoire des commandes externes, voilà comment régler le problème :

Dans /etc/nagios3/nagios.cfg :

check_external_commands=1

Exécuter ensuite les commandes suivantes en tant que root :

dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
chmod 2770 /var/lib/nagios3/rw
/etc/init.d/nagios3 stop
apache2ctl restart
/etc/init.d/nagios3 start

Et hop, c’est reparti!

Liens:

OSSIM : Nagios => Nagios – External Command
Le tuto de Lolo sur l’installation de Nagios
Man page dpkg-statoverride

Plus ça va plus je trouve que subversion (svn) est un outil génial, et pas seulement pour les développeurs. Une fois qu’on connait l’adresse du dépot svn d’une application, ça devient très facile de l’installer, sous ses différentes versions si besoin, et les mises à jour deviennent très simples.

Par exemple Typo3. Cet excellent CMS n’a qu’un petit défaut, les mises à jour sur un site existant sont parfois délicates, il faut prendre son temps. Du coup c’est intéressant d’avoir plusieurs plusieurs versions installées, les sites n’ayant pas encore été migrés utilisant leur version d’origine. Avec svn, c’est tout simple.

L’adresse du dépot svn pour typo3 est https://typo3.svn.sourceforge.net/svnroot/typo3. A partir de là CoreDocs/ donne accès à la documentation, et TYPO3core/ aux sources. Classiquement, on a ensuite trunk/ pour la dernière version de développement, branches/ pour les versions principales (4.0, 4.1, 4.2, etc…) et tags/ pour les différentes releases (4.0.1, 4.0.2, etc…). Pour un serveur de production le choix de tags/ est plus raisonnable, branches/ est plus pratique sur une machine de test pour faire des mises à jour avec svn update. Quant à trunk/, c’est pour les développeurs et les grands joueurs.

Edit du 3/5/2010 :
Le dépot svn typo3 est maintenant à l’adresse https://svn.typo3.org/
Créer le répertoire typo3 :

mkdir /usr/share/typo3
cd /usr/share/typo3

On télécharge les version 4.0.8 et 4.2.0 :

svn co https://typo3.svn.sourceforge.net/svnroot/typo3/TYPO3core/tags/TYPO3_4-0-8 4.0.8
svn co https://typo3.svn.sourceforge.net/svnroot/typo3/TYPO3core/tags/TYPO3_4-2-0 4.2.0

On crée des liens symboliques, latest pour la dernière et éventuellement des liens personnalisés pour les sites qui utilisent les anciennes versions :

ln -s 4.2.0 latest
ln -s 4.0.8 mesvieuxsites

S’ils ne sont pas encore là on installe les paquets nécessaires à typo3 et on recharge la config Apache :

aptitude install php5-gd imagemagick libttf-dev
/etc/init.d/apache2 reload

Pour un nouveau site, il faut télécharger le package dummy (que je n’ai pas trouvé sur svn), si comme moi c’est pour migrer un site sur une nouvelle machine il faut créer le fichier typo3conf/ENABLE_INSTALL_TOOL :

touch monsite/typo3conf/ENABLE_INSTALL_TOOL

A la racine du site, on crée le lien symbolique qui va pointer sur la version appropriée de typo3 :

ln -s /usr/share/typo3/latest typo3_src

ensuite se rendre sur http://monsite/typo3/install pour exécuter l’assistant d’installation et de mise à jour.

Ce memo me sert pour configurer WebDAV avec cryptage SSL sur un serveur Apache. J’utilise WebDAV pour offrir un accès fichiers aux webmasters des sites que j’héberge, c’est plus souple et plus sûr que le FTP. Cette config est très basique, Webdav permet un paramétrage très fin des autorisations, notamment avec la directive <Limit …>

Une des contraintes de Webdav est que le serveur Apache doit avoir les droits en lecture-écriture sur tous les répertoires et fichiers partagés. Il faut donc veiller à ce que le user sous lequel s’exécute Apache (www-data dans mon cas) en reste propriétaire. C’est pourquoi les concepteurs de Webdav recommandent de ne pas utiliser d’autre protocole pour accéder à ces fichiers. C’est à mon humble avis un peu excessif, mais il faut y faire attention, un upload fait par SSH ou FTP n’aura probablement pas les bons droits.

Requis

• Apache 2
• Openssl
• Un compte sur cacert.org

Installer les modules Apache

a2enmod ssl
a2enmod dav
a2enmod dav_fs
a2enmod dav_lock
a2enmod rewrite
/etc/init.d/apache2 force-reload

Générer le certificat SSL

Dans le répertoire /etc/ssl/private :

openssl req -nodes -new -keyout mondomaine.key -out mondomaine.csr

On peut passer toutes les questions sauf « Common Name (eg, YOUR name) », où il ne faut surtout pas mettre son nom mais le nom du domaine.

cat mondomaine.csr

Copier la sortie dans le presse-papier
Sur le site cacert.org aller sur Certificat de domaine / Nouveau
Demander un certificat de classe 3
Coller le csr
Récupérer le certificat dans le presse-papier et le coller dans /etc/ssl/private/mondomaine.crt

finir par :

chmod 600 mondomaine.*

Recopier le certificat racine CACert Classe 3 dans le magasin de certificats /etc/ssl/certs sous le nom cacert_class3.crt

Il est aussi possible d’utiliser un certificat autosigné, comme expliqué ici par exemple. L’avantage du certificat CACert est qu’il est issu d’une autorité certes non commerciale mais reconnue. Si le certificat racine de CACert n’est pas présent sur les postes clients on peut le télécharger ici

Configurer Apache

Attention, un seul serveur virtuel SSL par adresse IP!

Hors serveur virtuel, ajouter les directives :

NameVirtualHost *:80
NameVirtualHost *:443
DAVMinTimeout 600
DAVDepthInfinity On

Dès qu’on a mis en place le SSL, il faut que tous les serveurs virtuels soient assignés à un port, 80 pour http ou 443 pour https.

ex :

<VirtualHost *:80>
...
</VirtualHost>

Déclarer le serveur virtuel

On crée le fichier /etc/apache2/sites-availables/webdav :

<VirtualHost *:80>
ServerName mondomaine
# Force SSL
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
</VirtualHost>
<VirtualHost *:443>
ServerName mondomaine
ServerAdmin webmaster@mondomaine
SSLEngine On
SSLCACertificateFile /etc/ssl/certs/cacert_class3.crt
SSLCertificateFile /etc/ssl/private/mondomaine.crt
SSLCertificateKeyFile /etc/ssl/private/mondomaine.key
DocumentRoot /var/www
<Directory />
Options -Indexes FollowSymLinks
AllowOverride none
</Directory>
<Directory /var/www/site1>
Options Indexes
AllowOverride none
Order allow,deny
allow from all
DAV on
AuthName "Administration site Site 1"
AuthType Basic
AuthUserFile /etc/apache2/htpasswd-webdav
<Limit GET POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user utilisateur1
</Limit>
</Directory>
<Directory /var/www/site2>
Options Indexes
AllowOverride none
Order allow,deny
allow from all
DAV on
AuthName "Administration site Site 2"
AuthType Basic
AuthUserFile /etc/apache2/htpasswd-webdav
<Limit GET POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user utilisateur2
</Limit>
</Directory>
ErrorLog syslog
LogLevel warn
CustomLog /var/log/apache2/access_dav.log combined
</VirtualHost>

Créer la base utilisateurs

htpasswd -c /etc/apache2/htpasswd-webdav utilisateur1
New password:
Re-type new password:
Adding password for user utilisateur1
htpasswd /etc/apache2/htpasswd-webdav utilisateur2
New password:
Re-type new password:
Adding password for user utilisateur2

Donner les droits d’accès à Apache

chown www-data /etc/apache2/htpasswd-webdav
chmod 660 /etc/apache2/htpasswd-webdav

Configurer le firewall

Ouvrir le port TCP 443

Le moment de vérité!

on active le site :

a2ensite webdav
/etc/init.d/apache2 reload

S’il n’y a pas d’erreur il ne reste plus qu’a tester le partage avec un client Webdav : Dossiers Web sous Windows, le kio webdavs:// avec Konqueror (attention webdav:// ne fonctionne pas en SSL), le client intégré à Mac OS X, etc…

Liens

Le site officiel webdav

Et alors? Ben j’avais une directive AllowOverride None dans mon fichier de configuration apache, et les instructions rewrite du .htaccess étaient superbement ignorées.

Avec un AllowOverride All tout est rentré dans l’ordre. On est bien peu de chose…