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
Je n’expliquerai pas ici dans le détail comment créer une paire de clés ssh. Il existe d’excellents tutoriaux à ce sujet ailleurs sur le web (Google est ton ami). On peut 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_keys2
-> 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 22022, 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 !
- 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



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é).