Accélérer vos applications PHP à l’aide d’APC
Le PHP est un langage compilé à la volée, à chaque appel d'une page il y a compilation du code PHP en un code intermédiaire que l'on nomme opcode. Ce mécanisme de compilation systématique est lourd et rallonge sensiblement la durée de traitement des pages PHP.
APC (Alternative PHP Cache) est ce qu'on appèle un cache d'OPCodes. Celui-ci permet donc de stocker en mémoire vive le code compilé des pages PHP et nous épargne ainsi la fastidieuse phase de compilation, les performances générales se retrouvent de ce fait nettement améliorées.
En plus d'être une solution fiable et robuste, APC est gratuit, opensource et relativement simple à installer et à utiliser. Alors pourquoi s'en priver ?
Tout d'abord commençons par préparer l'environnement :
# Installation des paquets nécessaires à la compilation d'APC sudo apt-get install php5-dev php-pear apache2-prefork-dev # Création d'un lien symbolique pour éviter un message d'erreur sur certains environnements sudo ln -s /usr/bin/apxs2 /usr/bin/apxs
Maintenant que nous avons l'ensemble des paquets requis, procédons à l'installation d'APC :
sudo pecl install apc # Répondez 'yes' à la question qui vous sera posée
Maintenant créons le fichier de configuration d'APC :
sudo nano /etc/php5/apache2/config.d/apc.ini
Et mettez y ceci :
[APC] # Permet de charger le module APC extension=apc.so # Permet d'activer le module APC apc.enabled=1 # Taille de l'espace mémoire alloué à APC (en Mo) apc.shm_size=30 # Taille maximale des fichiers mis en cache apc.max_file_size=1M # Vérification des modifications de fichiers apc.stat=0
Il est important de s'attarder un peu sur l'option apc.stat. Si sa valeur est à 1, APC vérifiera à chaque appel d'une page si celle-ci a été modifiée depuis sa mise en cache, ces vérifications systématiques affaiblissent les performances. Sur un serveur de production sur lequel les fichiers sont modifiés rarement, il est préférable de désactiver cette option pour gagner en performances. Dès lors, si un fichier est modifié il faudra vider le cache pour que les modifications soient prises en compte.
Vous pouvez trouver la description complète des options disponibles sur cette page.
Il reste maintenant à redémarrer Apache pour achever l'installation d'APC.
sudo /etc/init.d/apache2 restart
Une fois APC installé, son cache se remplira au fur et à mesure des chargements des pages PHP améliorant ainsi progressivement les performances générales.
Il est possible d'obtenir des informations sur l'état de ce cache via une page web spéciale. Celle-ci n'est pas déployée par défaut sur votre serveur, pour se faire il suffit de la rendre accessible depuis le répertoire de votre serveur web :
# Le répertoire de destination peut différer selon la configuration de votre serveur web sudo cp /usr/share/php/apc.php /var/www/apc.php
Finissons ce billet avec un petit benchmark histoire d'avoir un aperçu du gain réel apporté par l'utilisation d'APC. Sur la même machine je vais tester, à l'aide de l'utilitaire ab fourni avec apache, les performances d'accès à la page d'accueil d'un site sous Joomla sans puis avec APC d'activé.
# Je simule dix utilisateurs qui effectuent dix requêtes chacun ab -n 10 -c 10 http://127.0.0.1/joomla/
Le résultat obtenu avant l'activation d'APC :
Sans APC il est possible de traiter près de 14 requêtes par seconde.
Le résultat obtenu après l'activation d'APC et le chargement de la page dans le cache :
Avec APC activé (avec la page mise en cache ce qui implique une première visite de celle-ci), il devient possible de traiter près de 31 requêtes par seconde soit un gain de performance de facteur deux.
Vous l'aurez compris, APC apporte une véritable amélioration des performances tout en restant simple à déployer. De plus, il offre aussi une fonctionnalité de cache utilisateur que je n'ai pas traité dans ce billet.
Géolocalisation d’adresses IP sous Apache2
L'une des forces du serveur web Apache est la panoplie de modules qu'on peut lui greffer, enrichissant ainsi ses fonctionnalités. Aujourd'hui, je vais vous présenter un module permettant d'effectuer de la géolocalisation d'adresses IP.
Tout d'abord commençons par installer ce fameux module :
# Valable pour Debian et Ubuntu uniquement sudo aptitude install libapache2-mod-geoip # On redémarre le serveur Apache sudo /etc/init.d/apache2 restart
Voilà, dès à présent, il vous est possible d'obtenir le pays ainsi que le code du pays des personnes qui visitent votre site. Pour ce faire, il suffit d'intérroger les variables de serveur, en PHP cela donne :
// Code du pays echo $_SERVER[GEOIP_COUNTRY_CODE]; // Nom du pays echo $_SERVER[GEOIP_COUNTRY_NAME];
Ce module peut être utile par exemple pour concevoir un algorithme qui modifie la langue de votre site selon la provenance des visiteurs.
Notes :
- Ce module est également disponible pour le serveur web Cherokee.
- La base de données inclut dans les paquets Debian/Ubuntu n'est pas très à jour, il est possible de la remplacer par celle de MaxMind :
cd /usr/share/GeoIP/ # On sauvegarde la base de données actuelle mv GeoIP.dat GeoIP.dat.backup # On télécharge la nouvelle base de données wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz # On la décompresse zcat GeoIP.dat.gz > GeoIP.dat
SANDCAT : Scanner de vulnérabilités web
J'ai créé ce petit billet pour vous présenter un logiciel vraiment très utile dans le domaine de la sécurité informatique, il s'agit de Sandcat.
Sandcat est un scanner de failles sur 3 niveaux :
- Failles d'applications web (notamment le TOP 10 des failles OWASP et OWASP PHP).
- Failles du serveur (IIS, apache, configuration de PHP...etc).
- Analyses des fichiers "Log" (traçage des attaques et violations...Etc).
Ce logiciel est donc complet et couvre un large éventaille de failles (SQL Injection, CRLF Injection, DoS, XSS...), sa version gratuite est téléchargeable à cette adresse : http://www.syhunt.com/?section=sandcat.download
La version Pro qui est plus complète et plus puissance est payante, je regrète aussi le fait que cette application ne soit disponible que sous Windows.
{Sécurité} Acunetix WVS Free Edition
Acunetix WVS Free Edition est la version gratuite du scanneur de failles Acunetix Web Vulnerability Scanner. Comme vous vous en doutez cette version gratuite a des limitations par rapport à la version payante, elle est en effet "bridée" à la vérification des failles XSS, néanmoins ce genre de failles étant répandu et critique, cela est toujours une bonne chose de scanner son site web.
Pour télécharger gratuitement l'application, rendez-vous à cette adresse : http://www.acunetix.com/cross-site-scripting/Copy-scanner.htm
{Sécurité} Faille des .htaccess
[youtube=http://www.youtube.com/v/Ooqi_iZnAT0&hl]
Les fichiers .htaccess sont des fichiers de configuration pour les serveurs apache permettant, entre autres, de restreindre à l'accès à certaines parties d'un site ou à sa totalité. Certains webmaster utilisent donc ces fichiers pour protéger les zones sensibles de leur site à l'aide d'un identifiant et d'un mot de passe.
Le hic, c'est qu'une mauvaise configuration de ces fichiers couplée à une mauvaise configuration du serveur apache (une configuration par défaut par exemple) créé une brèche de sécurité permettant de contourner les restrictions mises en place, c'est une de ces failles qui a été exploitée pour hacker le site d'Algérie Poste¹.
Généralement, les gens se contentent de faire un copier/coller des exemples de code qu'ils trouvent sur le net pour mettre en place leur protection via htaccess, malheureusement certaines versions des codes qu'on peut trouver sur le net sont erronés.
Voici par exemple un code que l'on peut aisément trouver sur la toile :
AuthUserFile /home/web/privé/.htpass AuthName "Identification obligatoire" AuthType Basic <limit GET POST> require valid-user </limit>
Alors expliquons un peu le contenu de ce fichier :
- La première ligne indique l'emplacement du fichier contenant les identifiants et mots de passe pour l'accès à la zone protégée.
- La seconde ligne est juste le titre de la fenêtre d'authentification qui s'affiche.
- La troisième ligne indique le type d'authentification.
- Les lignes 4 à 6 indiquent une balise LIMIT.
Le problème dans ce fichier vient, en partie, de cette fameuse balise LIMIT justement, celle-ci est sensée limiter les conditions d'accès aux requêtes POST et GET du protocole HTTP (C'est les types de requêtes utilisés lorsqu'on navigue sur un site internet). Hors, dans certaines configuration (notamment celle par défaut) les serveurs APACHE ont tendance a essayer d'interpréter les requêtes HTTP incorrectes comme des requêtes GET.
Par exemple en temps normal pour obtenir maPage.php votre navigateur envoi une requête du style :
GET /maPage.php HTTP/1.1
Host : www.monsite.com
Ce n'est qu'un exemple, d'ailleurs je n'ai pas retenu la syntaxe exacte des requêtes HTTP pour imiter parfaitement votre navigateur lol. Bref ! Imaginez que maPage.php est protégée par un htaccess, il m'est donc impossible d'y accéder sans m'identifier car ma requête GET sera traitée... par contre si on s'amuse à envoyer une requête erronée du style :
envoi une requête du style :
jeveux /maPage.php HTTP/1.1
Host : www.monsite.com
et bien comme cette requête n'est ni un GEt ni un POST le htaccess ne va pas appliquer la restriction sur elle, et comme apache va l'interpréter comme une requête GET et bien vous allez recevoir le page en question (y accéder quoi) sans aucune authentification.
Voilà le principe utilisé pour contourner donc les fameux fichier htaccess. Pour vous protéger de cette failles veillez à :
- Retirer les balises <LIMIT> de vos fichiers .htaccess.
- Configurer votre serveur apache de façon à ce qu'il n'accepte et ne traite que les requêtes HTTP valides (vous pouvez utiliser mod_security pour ça).
Voilà, j'espère vous avoir proposé un article intéressant, celui-ci inaugure la nouvelle catégorie "Sécurité" de mon blog, je compte vous proposer d'autres articles sur la sécurité informatique, si vous avez des compléments d'information ou des suggestions n'hésitez surtout pas.
¹ Information que j'ai pu lire à droite à gauche sur le net, je n'ai pas pris le temps de vérifier moi-même si ces affirmations étaient justes.