Configurer un serveur dédié OVH/Kimsufi/Debian pour LAMP
Je retranscris ici un petit memento que je me suis fait pour “remonter” rapidement une configuration opérationnelle sous Debian / Apache2 / PHP5 / Mysql pour héberger des sites sur un serveur dédié type OVH ou Kimsufi. Cette configuration, qui inclut également eAccelerator et des outils de supervision et d’administration de base (Munin, phpsysinfo, mtop, PhpmyAdmin, AWStats) est opérationnelle et suffisamment sécurisée pour une installation standard (à condition de faire régulièrement toutes les mises à jour des packages). En tout cas pour moi c’est bon©®™.
Le memento ci-dessous est une compilation des meilleures recommandations trouvées ailleurs sur le net, remises à jour pour une installation Debian Lenny de Septembre 2009.
Commencer par se connecter au serveur en ssh avec le compte root avec mot de passe fourni dans l’e-mail envoyé par OVH, sur le port 22 (normal quoi…) (depuis un autre linux ce serait simplement : ssh -l root suivi du nom ou de l’ip de votre serveur)
1. Changement du mot de passe root et création d’un utilisateur
Travailler en root c’est mal, encore plus quand ce root utilise un mot de passe qui a circulé par e-mail. On commence donc par créer un compte d’utilisateur non privilégié (auquel on donnera les privilèges nécessaires pour faire de l’administration à distance tout de même !), et par changer le mot de passe root.
passwd
-> changer pass root
adduser <votre login>
adduser <votre login>Â root
adduser <votre login> adm
Vérifiez que vous arrivez à vous connecter avec ce nouvel utilisateur, puis quittez la session root :
exit
2. Configuration de la connexion via une clé ssh
J’explique ici dans le détail (dans un autrez article) comment créer une paire de clés ssh sous Linux. Il existe d’autres excellents tutoriaux à ce sujet ailleurs sur le web (Google est ton ami). On peut également le faire très simplement sous Windows avec Putty par exemple.
Une fois la clé générée et stockée dans un fichier texte localement, se reconnecter en ssh avec l’utilisateur non privilégié créé ci-dessus :
ssh -l <votre login> <hôte>
(toujours par défaut sur le port 22 avec mot de passe choisi pour le nouveau compte ci-dessus)
mkdir .ssh
cd .ssh
vi authorized_keys
-> coller la clé ssh (longue chaine de texte)
exit
On peut maintenant se connecter sans taper de mot de passe grâce à la clé ssh :
ssh -l <votre login> <hôte>
(toujours sur port 22, mais avec clé ssh, donc sans taper de mot de passe)
3. Sécurisation minimum du serveur
su root
rm /root/.ssh/authorized_keys2
rm /root/.p
rm /root/.email
vi /etc/hostname -> changer nom de machine (genre ksXXXXXX.<votre-domaine>.com)
invoke-rc.d hostname.sh stop
invoke-rc.d hostname.sh start
vi /etc/hosts
-> ajouter nom de machine
aptitude update aptitude safe-upgrade
(je laisse “all” pour les histoires d’initialisation de disques RAID au démarrage)
aptitude full-upgrade aptitude install debian-goodies
aptitude install libpam-cracklib wfrench
(utilitaire qui vérifie automatiquement la qualité des mots de passe, avec un dictionnaire de mots français)
vi /etc/pam.d/su
-> On dé-commente la ligne : auth required pam_wheel.so
vi /etc/pam.d/common-password
-> On rajoute à la fin la ligne : password required pam_cracklib.so retry=3 minlen=8
aptitude install sudo
visudo
-> Ajout de la ligne : %root ALL=(ALL) PASSWD: ALL
apt-get install fail2ban
vi /etc/fail2ban/jail.conf
->
[ssh] enabled = true port   = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6 # durée du banissement bantime = 900
/etc/init.d/fail2ban restart vi /etc/ssh/sshd_config
-> Port 22000 (pour déplacer l’écoute du daemon ssh sur un port “non standard”)
/etc/init.d/ssh restart
reboot
4. Désinstallation de trucs inutiles / installation de trucs utiles
Cette fois on se reconnecte en ssh sur le port 22000, toujours avec la clé ssh. Vous pouvez d’ailleurs sauvegarder ces paramètres de connexion qui seront définitifs.
ssh -l <votre login> -p 22000 <hôte> su
aptitude purge bind9 bind9-doc \ dhcp3-client dhcp3-common gcc \ gcc-4.2-base libdns43 libisc44 \ libncurses5-dev manpages-cs \ manpages-de manpages-de-dev \ manpages-es manpages-es-extra \ manpages-it manpages-pl \ manpages-pl-dev manpages-pt manpages-pt-dev \ manpages-ru reiserfsprogs
aptitude install openntpd
aptitude install mailx
5. Installation d’Apache2
apt-get install apache2 php5 libapache2-mod-php5 php5-gd apache2-dev
vi /etc/apache2/conf.d/security -> ServerTokens Prod ; ServerSignature Off
a2enmod rewrite
a2enmod expires
a2enmod headers
/etc/init.d/apache2 restart
6. Installation de Mysql et mtop
apt-get install mysql-server-5.0 php5-mysql
(ne pas spécifier de mdp root mysql à ce stade, sinon l’installation de mtop échouera. On le fera juste après !)
apt-get install mtop
mysql -u root -> exit
mysqladmin -u root password <votre mot de passe>
mysql -u root
-> ne doit plus fonctionner sans mdp
vi /etc/mysql/my.cnf
-> log_slow_queries = /var/log/mysql/mysql-slow.log
/etc/init.d/mysql restart
7. Installation de Munin et phpsysinfo
apt-get install munin
http://ksXXX.ovh.net/munin/
apt-get install phpsysinfo
-> il faut créer le <VirtualDirectory> et l’Alias pour phpsysinfo et sécuriser l’accès à ces deux répertoires en mettant par exemple un mot de passe .htaccess dans la config apache2 du virtualhost default.
8. Installation de PHP et eAccelerator
apt-get install libapache2-mod-php5 php5 \ php5-common php5-dev php5-curl php5-gd \ php-pear php5-imagick php5-mcrypt php5-memcache \ php5-mhash php5-mysql php5-cli
apt-get install re2c
wget http://bart.eaccelerator.net/source/0.9.6/eaccelerator-0.9.6-rc1.tar.bz2
(ou plus récent…)
tar -jxvf eaccelerator-0.9.6-rc1.tar.bz2
cd eaccelerator-0.9.6-rc1
phpize
./configure -enable-eaccelerator=shared
make
make install
vi /etc/php5/apache2/conf.d/eaccelerator.ini
-> créer le fichier contenant ceci :
extension="eaccelerator.so" eaccelerator.shm_size="16" eaccelerator.cache_dir="/var/cache/eaccelerator" eaccelerator.enable="1" eaccelerator.optimizer="1" eaccelerator.check_mtime="1" eaccelerator.debug="0" eaccelerator.filter="" eaccelerator.shm_max="0" eaccelerator.shm_ttl="0" eaccelerator.shm_prune_period="0" eaccelerator.shm_only="0" eaccelerator.compress="1" eaccelerator.compress_level="9"
mkdir /var/cache/eaccelerator chmod 0777 /var/cache/eaccelerator /etc/init.d/apache2 restart
9. Installation de PhpMyadmin, Logwatch et AWStats
apt-get install phpmyadmin
vi /etc/phpmyadmin/apache.conf
-> changer l’Alias par ‘/mon_admin_de_mysql_en_php’ par exemple (beaucoup d’attaques sur ce répertoire sinon)
/etc/init.d/apache2 restart
http://ksXXX.ovh.net/mon_admin_de_mysql_en_php/index.php?lang=fr-utf-8 -> favoris
apt-get install logwatch
apt-get install awstats
Paramétrer /etc/awstats/.
/etc/init.d/apache2 restart
-> ajouter : 15,45Â * * *Â Â *Â Â /usr/share/doc/awstats/examples/awstats_updateall.pl now -awstatsprog=/usr/lib/cgi-bin/awstats.pl >> /var/log/awstats.log
/usr/share/doc/awstats/examples/awstats_updateall.pl now -awstatsprog=/usr/lib/cgi-bin/awstats.pl >> /var/log/awstats.log
vi /etc/logrotate.d/apache2
-> ajouter :
prerotate /usr/share/doc/awstats/examples/awstats_updateall.pl now -awstatsprog=/usr/lib/cgi-bin/awstats.pl >> /var/log/awstats.log endscript
10. Configurer vos sites et vos sauvegardes
Ceci est trop spécifique pour que je donne un guide tout fait ici.
Je recommande de sauvegarder toutes les bases mysql en utilisant l’utilisateur mysqldump,
de faire chaque jour un tar -xvf de tous les répertoires de publications web (en principe dans /var/www)
et de faire également un tar -xvf des répertoires suivants importants à sauvegarder et archiver régulièrement :
/etc
(contient les configs d’Apache, Phpmyadmin, Awstats, …)
/root
/home/<votre login>
/var/lib/awstats
11. Recevoir les alertes d’administration avec exim4
Par défaut, exim4 n’est pas configuré pour envoyer les mails à l’extérieur. il faut donc, après vous être créé un alias vers votre adresse e-mail pour recevoir les messages envoyés à root, activer le routage smtp d’exim :
sudo vi /etc/aliases
-> ajouter la ligne : root: <votre adresse email>
(virer root: ovh si vous l’avez !)
dpkg-reconfigure exim4-config
-> distribution directe par SMTP / écoute sur l’adresse 127.0.0.1 uniquement
/etc/init.d/exim4 restart
mail -s 'test' <votre email>
mail -s 'test2' root
(avec la commande mail, utiliser un point seul sur une ligne pour terminer le mail et sortir)
sudo exim -q -v
12 Fin de l’installation
just to be sure:
aptitude update
aptitude safe-upgrade
aptitude full-upgrade
reboot
13. Liens très utiles
Ce sont mes principales sources (que je remercie au passage) pour le how-to ci-dessus, et il y a sur ces sites remarquables des instructions plus détaillées, mieux présentées, et des suggestions supplémentaires à étudier. A vos signets !
- Utilisation des clés SSH pour se connecter automatiquement sans mot de passe
- securite:securisation_de_la_debian [Serveur RPS d'OVH]
- Mon installation debian chez OVH | Jonathan’s Blog
- Niadomo deuxième épisode : première configuration d’un serveur de courriel – David’s blog
- Apache2 (SSL), Logrotate, and AWStats [Archive] – Ubuntu Forums
- Managing Apache2 modules the Debian way | MDLog:/sysadmin
- Exim Cheatsheet (en anglais)
- [ILUG] Exim…..
- Installing and Configuring Exim4

Epson Stylus SX105 sous Ubuntu Linux : faire fonctionner le scanner
What’s inside a Verbatim JH8626 external USB hard drive?
Taking apart a Sony VAIO to replace the hard disk drive
Disque dur : Comment j’ai perdu et récupéré toutes mes données
WordPress fast page updates. At last.
le 8 October 2009 à 16:33 h
Excellent tuto ! Tout a marché très bien pour moi. Il faut également ajouter que sur un serveur Kimsufi, le répertoire /var/www est sur une “petite” partition de 5Go. Mieux vaut créer un répertoire dans /home (partition de 500Go) et faire un lien symbolique de /var/www vers ce répertoire.
J’ai également un problème qui commence à m’énerver sérieusement : apache2 tourne avec le user www-data et j’upload les fichiers de mon site sous mon user (créé selon le tuto en faisant adduser ). J’ai donc des problèmes de droits en permanence : je suis obligé de faire des sudo chown www-data et des chown monuser sans arrêt. N’y a-t-il pas une meilleure solution ? Merci.
le 8 October 2009 à 17:00 h
@Steph
Tout à fait exact en ce qui concerne l’emplacement de /var/www sur la petite partition -> on peut au choix partitioner le serveur autrement avec l’outil OVH avant de procéder à l’installation ou réinstallation automatique du système. J’ai testé et cela fonctionne très bien; ou bien comme tu le suggères avoir recours à un lien symbolique (attention toutefois certaines configurations de sécurité “poussée” d’Apache n’acceptent pas les liens symboliques).
Pour les droits : dans les liens en bas de l’article, on trouve des tutos d’autres admin système qui installent apache en mode “suexec” pour le faire tourner sous un autre utilisateur. C’est une option. Personnellement, je règle le problème en utilisant les groupes : je place mon user perso ainsi que les autres webmasters éventuels dans le groupe www-data et j’autorise les modifs de fichier par les membres du groupe (chmod g+w). Apache quant à lui accède à tous les fichiers en lecture sans se poser de questions.
le 8 October 2009 à 21:17 h
@Yann
Je vois 1 problème à cette solution (chmod g+w) :
Certaines “appli” web (wordpress, drupal par exemple) ont besoin des droits d’écriture sur quelques répertoires : c’est à dire que le user www-data devra être capable d’écrire dans ces répertoires. Et malheureusement, les fichiers créés par ton user perso ne seront pas accessibles par le user www-data.
On peut toujours mettre le user www-data dans le groupe de ton user perso et faire un chmod g+w sur ces fichiers nouvellement créés, mais ça devient un peu tordu quand même… Je me demandais s’il n’y avait pas plus simple.
Quant à suexec, il me semble que les performances sont moins bonnes.
Je ne suis pas un pro en sécurité, mais est-ce qu’une solution qui consisterait à mettre un mot de passe au user www-data ne serait pas plus simple. Je pourrais me loguer sous ce user en utilisant le mot de passe (ou même avec une clé).
le 25 November 2009 à 1:38 h
Impressionnant ! je crois que c’est le premier tuto qui fonctionne du premier coup, je suis bluffé !
Félicitation pour ce tuto qui fonctionne a merveille, c’est du beau boulot. Il permet de partir sur des bases solides et à le merite d’être clair en plus.
Pour mon cas, j’ai adapté la sécurisation des dossiers munin et phpsysinfo à partir du tuto concernant le RPS d’OVH.
Un grand merci en tout cas…
le 3 April 2010 à 18:54 h
Bravo !!!
Je crois que c’est le premier tuto complet sur le sujet.
Franchement je suis bluffé !!
le 20 August 2010 à 17:29 h
Pas mal,
mais il manque sans doute la config iptables et l’install d’exim4
le 20 August 2010 à 17:41 h
@Teenage:
Concernant iptables, c’est un choix : il y a tellement peu de ports ouverts sur cette machine qui est un serveur web isolé (en fait seuls les ports http, le ssh étant déplacé à une adresse non triviale), et tellement peu de services actifs à l’écoute, qu’on peut se demander si c’est utile. Personnellement, je considère que non. Il y a beaucoup plus de chances d’être attaqué en http sur les applications php, et c’est donc plutôt l’installation de mod-secure pour Apache qui manque.
Bien entendu si on veut ajouter des services sur son Kimsufi, faire du routage, ou faire communiquer des serveurs entre eux par des services privilégiés, iptables peut devenir intéressant. Ce n’est pas l’objet de cette config.
Concernant Exim4, son installation est mentionnée dans le tuto, et la configuration est triviale et se fait en mode interactif pour l’usage qu’on en fait (uniquement relayer en smtp des mails envoyés par les applis web).
Mais n’hésites pas à compléter si tu as des suggestions, ou des liens intéressants pour ces deux aspects : je ne prétends pas être exhaustif, car à la base c’est juste un aide-mémoire à usage personnel
le 20 August 2010 à 18:49 h
Oui, mais ca peut pas faire de mal surtout si l’on ne maitrise pas tout les services (inetd).
Pour exim il n’était pas installé sur ma machine, donc :
sudo /etc/init.d/sendmail stop
sudo apt-get purge sendmail
sudo aptitude install exim4
dpkg-reconfigure exim4-config
Pour ma part je rajouterais bien quel info sur la sécurisation d’apache : droits, mod_secure, analyse de log,…
Apparemment chrooter semble contre-productif, surtout pour un serveur qui ne fait que du http.
Coté performance et sécurité le mod FastCGI PHP parait pas mal…
Sinon je proposerais bien de faire tourner les page web non public : awstats, phpsysinfo, munin, phpmyadmin sur une ip non routable et de n’y accéder que via un tunnel ssh ?
Sinon dans l’ensemble il manque quelque commentaire supplémentaire pour indiquer plus précisément à quoi sert tel package ou tel réglage.
Comme je vais écrire une doc détaillé sur la config de mon serveur, je te l’enevrais, cela te permettra d’enrichir ce post
le 20 August 2010 à 20:32 h
@Teenage :
Avec grand plaisir, et je prendrais le temps de mettre à jour cette page ou d’ajouter des pages complémentaires (et de te créditer pour tes infos). En effet, cette page est pas mal consultée (une dizaine de fois par jour en moyenne), donc j’en conclus qu’elle est utile à beaucoup de monde !
le 25 August 2010 à 14:56 h
[...] Cet article est donc un bon complément de mon autre article sur la configuration de base d’un environnement LAMP sur un serveur Debian du type de …. [...]