Administrateur & Développeur système UNIX/Linux

htscanner est une extension PHP permettant de parser les fichiers .htaccess d’Apache, afin d’y récupérer les variables d’exécution fixées par php_flag et php_value. Cette extension est indispensable dans le cadre d’une exécution PHP par CGI car ni le serveur Web ni php-cgi ne peuvent les récupérer.

Ayant déjà soumis un patch pour fixer la récupération des valeurs entre simple/double quotes, en voici un nouveau pour la version 0.9.0 qui n’est toujours pas exempte de problèmes avec son parseur.

patch-htscanner-parser-20090401

- interprétation correcte des retours à la ligne (EOL) quelque soit la plateforme.
- restriction du parsing pour les php_flag, seules les valeurs on/off sont acceptées (cf documentation PHP).

Mise à jour du 2009-04-05 : j’ai intégré ce patch dans la version CVS ; vivement la release 0.9.1 !

suPHP est un programme permettant de limiter l’exécution des scripts PHP à un UID spécifique afin de protéger le serveur d’hébergement de toute attaque de vulnérabilité. L’UID est modifié pour correspondre par exemple à celui du serveur Web, du propriétaire du fichier PHP ou encore un UID spécifique.

suPHP s’intercale entre Apache et PHP par le biais d’un handler spécifique, qui mappe l’extension d’un fichier au binaire suphp chargé de modifier les permissions UID puis d’appeler l’interpréteur CGI déclaré pour ledit fichier. Ce mécanisme permet d’exécuter des scripts PHP 4 / 5 / 6 depuis la même instance Apache, ce qui est fort utile dans le cas d’un serveur mutualisé.

Seul bémol : dans le cas d’un serveur Web de développement, il peut perturber les utilisateurs normaux qui ne peuvent modifier les droits d’accès des scripts PHP. Cela touche en particulier le répertoire parent car suPHP vérifie que son propriétaire correspond bien à l’UID configuré. A moins de pouvoir modifier ces droits, une erreur d’exécution est générée lors de la navigation :

Internal Server Error
Directory /var/www/site.fr/html/test is not owned by apache

Afin de contourner ce problème (plutôt marre d’entendre « je peux pas, j’ai pas les droits Apache »), j’ai donc fait un petit patch ajoutant l’option check_directory_owner à suPHP afin de désactiver ce test. L’option est à fixer dans le fichier de configuration :

; Security options
check_directory_owner=false # par défaut true
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

Le patch est à appliquer sur la version 0.7.1 de suPHP : patch-suphp-checkownerdirectory-20090328.

Argh faut installer le paquet manquant : xserver-xorg-input-kbd. C’est certes très bête mais fallait juste lire l’output de  startx !

Il est parfois utile de mettre en cache des fichiers, telles que des sessions PHP ou des logs (ce qui évite le réveil du disque dur). Le système de fichiers tmpfs (temporaray file system) permet à juste titre de créer un cache RAM. Les données y sont stockées jusqu’au prochain démarrage du serveur. Si aucune taille disque n’est précisée, tmpfs se charge de mettre en swap les données, ce qui peut être problématique.

Exemple de création d’un cache limité à 64 Mo, monté dans /home/cache :

# mount -t tmpfs -o size=128M /dev/shm /home/cache/
shm on /home/cache type tmpfs (rw,size=64M)
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/shm               64M     0   64M   0% /home/cache

Les fichiers / répertoires à stocker peuvent ensuite être copiés.

Il existe plusieurs manières de forcer le passage en mode sécurisé d’un site hébergé sous Apache. Cependant, la plupart sont faites en dures : le port 443 est forcé voire également le domaine du site.

Voici donc la manière la plus propre et élégante que j’ai pu faire :

# Force HTTPS mode
<IfModule mod_ssl.c>
  <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteCond %{HTTPS} off
      RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
   </IfModule>
</IfModule>

Celle-ci fonctionne quelque soit le port sécurisé déclaré dans la configuration du serveur,  le domaine ou les alias utilisés par le VirtualHost considéré, et ne provoque pas l’arrêt du serveur si un des 2 modules nécessaires n’est plus activé. Pour limiter la redirection à une certaine partie du site, il ne reste plus qu’à restreindre la RewriteRule.

Dans le cadre de l’utilisation de serveurs virtuels Xen, il est utile de créer un fichier de swap  disque  (et non sur une partition dédiée). L’avantage est que le fichier de swap peut être redimensionné dynamiquement.

Par exemple, pour créer un fichier swap de 256 Mo, il faut procéder ainsi :

# dd if=/dev/zero of=/var/swap bs=1024 count=262136
# mkswap /var/swap
# swapon /var/swap

La dernière ligne doit être exécutée à chaque boot pour activer le fichier de swap. Sous Gentoo, vous pouvez l’ajouter dans /etc/conf.d/local.start. Sous Debian, tout est plus simple avec le package dphys-swap qui permet une gestion automatique. Ce dernier est configuré par le fichier /etc/dphys-swapfile dont voici un exemple :

# /etc/dphys-swapfile - user settings for dphys-swapfile package
# where we want the swapfile to be, this is the default
CONF_SWAPFILE=/var/swap
# size we want to force it to be, default (empty) gives 2*RAM
CONF_SWAPSIZE=256

Une faille de sécurité (CVE-2008-5314) a été découverte dans la dernière version de l’antivirus ClamAV 0.94 :

Stack consumption vulnerability in libclamav/special.c in ClamAV
before 0.94.2 allows remote attackers to cause a denial of service
(daemon crash) via a crafted JPEG file, related to the
cli_check_jpeg_exploit, jpeg_check_photoshop, and
jpeg_check_photoshop_8bim functions.

Une bien belle attaque DoS, exploitable avec un simple fichier JPEG à joindre en mail, destination serveur à dégommer.

J’en ai fait les frais vendredi dernier avec les mails de mes clients. Seule solution pour empêcher la charge et le crash du serveur à cet instant : désactiver l’antivirus et attendre la disponibilité du package version 0.94.2.

Et dire que j’avais probablement le client qui me faisait trimer le serveur au téléphone…

Pour tout ceux et celles qui administrent des serveurs Linux Gentoo, une petite surprise va leur arriver : 4 dépendances croisées qui bloquent ladite mise à jour.

Alors on s’arme de patience car si on fait pas bien les choses, on se retrouve sans emerge, sans SSH, sans wget, sans mount… bref de quoi aller chercher son livecd comme un grand.

[ebuild     U ] sys-fs/e2fsprogs-1.41.2 [1.40.9]
[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE="nls"
[blocks B     ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/

Voici la solution praticable en mode tout-terrain :

# emerge -fud world
# emerge -C ss com_err e2fsprogs
# emerge --oneshot e2fsprogs-libs
# emerge e2fsprogs

Pour être certain que le système est consistant, on finit par çà :

# revdep-rebuild

Une grosse prise de tête en moins. Vive le packaging Gentoo !

Voici un pense-bête perso dans le cadre de l’utilisation de Xen depuis un terminal Mac. Je parle du raccourci-clavier qui permet de se détacher de la console Xen : le fameux Ctrl + [ du monde PC.

Eh bien, le raccourci sous Mac devient Ctrl + Option + 6

Ah là tout de suite c’est mieux.