Installer un stack LAMP sur un dédié OVH avec Ubuntu 12.10

Petit mémo pour configurer un serveur web LAMP sur un dédié OVH fraichement livré. La distro choisie est Ubuntu 12.10.

Apache, PHP, MySQL

Commençons par mettre à jour la liste des paquets :

# apt-get update

Puis la distribution elle même :

# apt-get dist-upgrade

Installons Apache, PHP, MySQL, phpMyAdmin et les extensions qui vont bien pour faire tourner Symfony 2, WordPress, Prestashop

# apt-get install phpmyadmin mysql-server php5-intl php5-mcrypt php5-xsl php5-cli php5-sqlite php5-memcached php5-curl php-apc php-pear

L’installateur nous demande de rentrer un mot de passe root pour le serveur MySQL (tant mieux) et le serveur web à configurer pour phpMyAdmin. Choisir apache2.

Donnons ensuite à dbconfig-common les mots de passe nécessaire pour qu’il configure les bases de données utiles à phpMyAdmin.

Beaucoup d’applications PHP utilisent le module rewrite de Apache Activons-le :

# a2enmod rewrite

Notre serveur web est prêt à l’emploi !

Un zeste de sécurité

Commençons par éditer /etc/apache2/conf.d/security pour rendre Apache plus discret. Passons ServerTokens à Prod et ServerSignature à Off.

Au tour de PHP. C’est dans /etc/php5/apache2/php.ini que ça se passe, expose_php doit être à Off. Profitons-en pour régler notre fuseau horraire : date.timezone = Europe/Paris.

Ubuntu 12.10 est fournie avec PHP 5.4. Plus besoin de s’occuper de register_globals et des Magic Quotes, ces “fonctionnalités” ont été supprimées upstream. Bon débarras !

Si vous n’utilisez pas d’applications PHP antédiluviennes, passez short_open_tag à Off .

Redémarrons Apache pour que nos réglages soient pris en considération :

# service apache2 restart

Appliquons les bons conseils de Marion et installons un système de sauvegarde automatisée, disons Backup Manager :

# apt-get install backup-manager

Ajoutons /var/lib aux répertoires sauvegardés quand l’installateur nous le propose (ce répertoire contient entre-autre les base de données binaires MySQL).

Si vous avez opté pour un dédié OVH vous disposez peut-être d’un espace de sauvegarde FTP gratuit (ce service ne semble malheureusement plus exister sur certaines offres Kimsufi). Pour l’activer rendez-vous dans le manager : section Services puis Backup Ftp. Une fois le mail avec les identifiants reçu éditons /etc/backup-manager.conf pour les indiquer à l’utilitaire.

Et le courrier ?

Au cas ou nos applications aient besoin d’envoyer des emails :

# apt-get install postfix

Choisissez le type de configuration “Site internet”.

Note : la configuration d’un serveur mail qui envoi des courriers qui ne finissent pas dans “Spam” nécessiterait un article complet.

De l’inutilité de la fonction PHP sleep pour protéger des attaques brute force (exemple avec Prestahop)

Le couple adresse email / mot de passe est le sésame permettant d’accéder à presque l’ensemble des activités numériques d’un individu : messagerie, réseaux sociaux, documents, extranets, interface client des boutiques en-ligne…

Les applications web se doivent de garantir la sécurité de leurs utilisateurs. En plus du minimum exigible (hachage et salage des mots de passe en base de données, protections contre les injections SQL, les attaques de type XSS et CSRF…), les développeurs tentent souvent de trouver des astuces permettant de protéger mieux les utilisateurs de leurs programmes.

Tenter de se protéger des attaque par force brute…

Ainsi, on trouve le code suivant dans le système de connexion à l’interface client de Prestashop, la très populaire plateforme e-commerce open-source :

Comme le commentaire l’indique, les développeurs de Prestashop tentent de protéger leurs utilisateurs d’une attaque par force brute.
L’idée est que pour obtenir un accès à l’interface client, le pirate va utiliser un robot qui va tester méthodiquement et à très grande vitesse tous les mots de passe possibles (dans les faits, ce types de robots testent dans un premier temps les mot de passe les plus communs grâce à des listes pré-établies).
Bien que le concept soit bon, l’appel à sleep est inutile. Les serveurs web sont multithreads et les robots d’attaque le sont aussi. Ces derniers lanceront de nombreuses connexions parallèles et n’attendront pas de savoir si le mot de passe est correct ou non pour en tester un nouveau.

Pire cette implémentation est dangereuse car, en plus de ralentir l’affichage de la page indiquant une erreur de saisie aux utilisateurs légitimes, elle bloquera le thread le temps du sleep (ici une seconde) et favorisera ainsi les attaques par déni de service. Un attaquant souhaitant engorger le site (ce qui aura pour conséquence de le ralentir voir de le rendre inaccessible) lancera de très nombreuses requêtes de connexion avec un mauvais mot de passe. L’effet sera plus important et l’attaque d’autant plus efficace sur cette page grâce au blocage du à l’appel à la fonction sleep.

Se protéger efficacement

Commençons par supprimer de nos codes sources ces appels à sleep aussi inutiles que dangereux. Les développeurs de Prestashop ont pris les devants et à l’heure ou j’écris ces lignes la version de développement de la plateforme e-commerce ne contient plus le code incriminé.

Adaptons maintenant l’idée d’empêcher les tentatives de connexion trop fréquentes à l’environnement multithreads des serveurs web. Commençons par stocker chaque erreur de connexion ainsi que la date à laquelle elle se produit et l’utilisateur qu’elle concerne dans une base de données ou mieux avec memcached. Si pour un même utilisateur une tentative de connexion arrive trop rapidement après l’une ayant échouée, disons au bout d’une seconde après le premier échec, de 5 après le deuxième, de 10 après le troisième…, exigeons que l’utilisateur prouve qu’il est bien humain (ex. : en ajoutant un CAPTCHA en plus des champs login et password). Si les echecs provenant d’une même adresse IP sont systématiques, on peut blacklister cette adresse car elle est probablement utilisée par un assaillant.

Dernier point, inciter voir exiger que vos utilisateurs optent pour un mot de passe fort diminue drastiquement les risques de compromission par force brute. N’hésitez pas à afficher des jauges de sûretés auprès du champ de saisie de mot de passe du formulaire d’inscription.

jquery.confirmExit : où comment ne plus perdre les données d’un formulaire complété

Je viens de publier un petit plugin jQuery sous license MIT qui affiche une demande de confirmation lorsqu’un l’utilisateur quitte une page web après avoir rempli un formulaire sans l’avoir envoyé.

Perdre toutes les données que l’on vient de saisir en cliquant sur un lien ou en fermant la fenêtre sans avoir appuyer sur “Envoyer”, c’est le genre de détails qui font rager contre les applications web mal finies.

Plus d’excuse avec jquery.confirmExit. Cerise sur le gâteau, le plugin supporte tous les nouveaux champs de formulaires introduits avec HTML5.

Télécharger le plugin sur GitHub

Splash City : notre nouveau jeu Facebook pour NRJ Mobile

Découvrez le nouveau jeu Facebook réalisé par La Coopérative des Tilleuls pour NRJ Mobile ! Splash City : l’Homme Sandwich fait du jet ski dans Paris.

Splash City