Depuis quelques jours, je suis l’heureux locataire d’un serveur Kimusfi 16G, qui vient remplacer mon ancien Kimsufi 8G : 10€ de moins par mois pour deux fois plus de RAM et un CPU deux fois plus puissant, difficile de résister… J’en profite donc pour vous proposer un petit guide de configuration et de sécurisation pour pouvoir exploiter sereinement une telle machine.

Attention, je précise quand même que par « sécurisation », je n’ai pas la prétention de dire que la machine sera à toute épreuve. Les quelques réglages de sécurité que je vous propose ici sont à voir comme un strict minimum à mettre en place, pour un serveur n’hébergeant pas de sites commerciaux. Une sécurité plus poussée est recommandée pour des usages commerciaux, notamment en isolant chaque site avec un utilisateur « virtuel » (n’ayant pas d’accès shell) dédié.

Dans de futurs articles, je vous proposerais également divers scripts utiles pour la gestion quotidienne du serveur.

Les paramétrages à effectuer nécessitent souvent d’aller modifier des fichiers de configuration. Dans cet article, je vous indiquerais autant que possible dès commandes permettant d’aller effectuer directement ces modifications, sans ouvrir manuellement les fichiers concernés.

Choix de l’OS

La première étape de l’installation (au moment de la commande, mais ça peut être changé par la suite) est le choix de l’OS. Sur mes premiers serveurs dédiés, en 2006, j’utilisais des systèmes faits pour de l’hébergement de site web, avec une interface web permettant de déclarer des sites, des comptes FTP, de créer des comptes mails, etc… Mais depuis qu’une faille dans un de ces outils (VHCS2) a été le point d’entrée d’un pirate pour effacer tout le contenu de mon serveur, je suis plutôt devenu un adepte des distributions « nues », quitte à faire les choses un peu moins proprement sur certains points (par exemple, je ne crée plus un accès FTP par site, je transfère mes fichiers via un accès SCP/SFTP, et je n’héberge plus mes mails sur le même serveur). Je trouve également l’administration d’une distribution « nue » plus intéressante, car plus souple, même si en contrepartie c’est un peu plus chronophage.

Ce guide s’adresse essentiellement à ceux qui auront également opté pour une distribution « nue ».

Parmi la quinzaine de distributions proposées par OVH, mon choix s’est porté sur une Ubuntu 12.04 LTS, comme sur mon serveur précédent, par habitude. Si vous préférez une autre distribution, les grandes lignes de ce guide s’appliqueront tout de même, mais pourront nécessiter quelques adaptations (par exemple, pour les chemins d’accès des fichiers de configuration).

Création d’un compte utilisateur

Par défaut, le serveur est livré avec simplement un compte root. Pour éviter de se connecter en root quand les droits ne sont pas nécessaires, créez un compte utilisateur :

Ajoutez le ensuite au groupe admin, ce qui lui donnera le droit d’utiliser sudo pour exécuter des commandes avec les droits root :

Si le groupe admin n’existe pas, vous pouvez le créer avec cette commande :

Installation de LAMP

La base classique d’un serveur Linux destiné à héberger des sites web, c’est le trio Apache–MySQL–PHP. Personnellement, j’ai décidé depuis quelques temps de remplacer MySQL par MariaDB. Il s’agit d’un fork non contrôlé par Oracle de MySQL, entièrement compatible avec ce dernier.

Installation de MariaDB

Par défaut, Ubuntu est prévu pour utiliser MySQL. Pour installer MariaDB, il faut donc tout d’abord ajouter à APT un dépôt contenant MariaDB :

Si tout va bien, la dernière commande devrait vous avoir répondu quelque chose comme ça :

Il n’y a alors plus qu’à procéder à l’installation avec apt-get :

Installation d’Apache 2

En plus du serveur Apache de base, je vous recommande d’installer le module suEXEC. Celui-ci permet de demander à Apache d’exécuter les scripts CGI d’un utilisateur avec les droits de cet utilisateur plutôt qu’avec les droits standards d’Apache, pour améliorer un peu la sécurité.

Installation de PHP5

Il existe une version de PHP optimisée pour une meilleur sécurité, baptisée Suhosin. La plupart des applications PHP fonctionnent sans problème avec cette version, donc sauf besoin particulier, installez Suhosin plutôt que le PHP standard. Installez également les extensions MySQL, XCache (pour améliorer les performances) et toutes les extensions dont vous pourriez avoir besoin. Par exemple, j’installe également cURL, qui permet d’effectuer des requêtes vers des serveurs distants et GD, pour manipuler des images. Ces deux extensions sont très couramment nécessaires pour les CMS en PHP.

Outils de sécurité

Outre la sécurisation « passive » de votre serveur, qui se fait via une configuration adaptée, une sécurisation « active » ne peut pas faire de mal. Pour ce faire, installez Fail2ban et RKHunter :

RKHunter est un scanner anti-malware, qui vérifie de nombreux fichiers systèmes pour y traquer des anomalies.

Fail2ban se charge pour sa part de surveiller différents fichiers journaux pour bloquer les attaques en bruteforce. Il peut par exemple détecter qu’une IP distante fait de nombreuses tentatives de connexion SSH, et il bloquera alors cette IP au niveau du pare-feu iptables.

Si cette installation déclenche l’installation de postfix, laissez le en configuration par défaut (Internet site).

Autres outils

En vrac, quelques autres outils utiles que j’installe sur mes serveurs :

Aucun de ces outils n’est lié à la sécurité.

mailx permet d’envoyer des mails en ligne de commande (je l’utilise pour l’envoi de rapports avec certains de mes scripts d’administration).

ProFTPD est un serveur FTP. J’utilise principalement SCP/SFTP pour mes transferts de fichiers, mais FTP peut parfois être nécessaire (par exemple, depuis un réseau bloquant le SSH, ou encore pour les mises à jours et les installations d’extensions dans WordPress).

OptiPNG et jpegoptim sont utilisés par mon script d’optimisation du poids des images.

YUI Compressor est utilisé par mon script d’optimisation du poids des fichiers JS et CSS.

7-Zip me sert notamment pour la création de backups compressés.

dos2unix permet de convertir les retours à la ligne CR/LF d’un fichier texte au format DOS en retours à la ligne LF au format Unix.

links est un navigateur web en mode texte.

Sécurisation de SSH

La configuration par défaut de SSH manque souvent un peu de sécurité… Voici quelques règles à appliquer pour la renforcer.

• Interdire la connexion directe en root.
  ATTENTION : n’interdisez pas la connexion en root si vous n’avez pas encore créé d’autre compte utilisateur !
  Pour ce faire, passez la valeur de PermitRootLogin à no dans /etc/ssh/sshd_config :

• Modifier le port par défaut (22). Pour ce faire, modifiez la valeur de Port dans /etc/ssh/sshd_config (222 dans cet exemple) :

Pour encore plus de sécurité, vous pouvez également générer des clés d’authentification et désactiver l’authentification par mot de passe, mais sauf gros impératif de sécurité, je ne vous le conseille pas, car cette solution est parfois un peu trop contraignante (impossible de vous connecter depuis un autre ordinateur que le votre si vous n’avez pas pensé à emmener votre clé avec vous…). Si vous y tenez quand même, je vous laisse chercher comment faire dans votre moteur de recherche favori 🙂

Une fois la configuration effectuée, redémarrez le serveur SSH, mais NE VOUS DÉCONNECTEZ PAS. Il est en effet important de tester si la nouvelle configuration fonctionne correctement avant de vous déconnecter, sinon vous risquez de perdre l’accès au serveur.

Pour vérifier que tout fonctionne correctement, ouvrez simplement une autre session SSH. Si vous y arrivez, vous pouvez sereinement fermer la première.

Configuration et sécurisation d’Apache

Note : ce paragraphe traite uniquement de la configuration globale du serveur, je traiterais plus loin la configuration d’un site.

Par défaut, Apache indique dans les en-têtes des réponses qu’il renvoie aux clients diverses informations, dont son numéro de version (Server: Apache/2.0.0 (Ubuntu)). Ces informations peuvent aider un pirate à mieux cibler ses attaques, en visant les failles connues pour une version donnée. Pour remplacer ces informations par un simple Apache, sans plus de précision, passez la valeur de ServerTokens à Prod dans /etc/apache2/conf.d/security :

Désactivez également la signature en bas des pages d’erreur 404 et cie, en passant la valeur de SeverSignature à Off dans ce même fichier :

Pour finir, activez les modules suEXEC et rewrite. Ils serviront plus tard pour la configuration des sites.

Configuration et sécurisation de PHP

PHP Suhosin est normalement suffisamment sûr dans sa configuration de base, si ce n’est que, comme Apache, il est un peu bavard dans les en-têtes HTTP (X-Powered-By: PHP/5.0.0-1ubuntu1.0). Faites le taire en passant expose_php à Off dans /etc/php5/apache2/php.ini :

Il peut également être utile de modifier trois paramètres de PHP dont les valeurs par défaut sont parfois un peu faibles :

• la taille maximale d’une instance de script (memory_limit, 128 Mo par défaut) en mémoire. Les 128 Mo peuvent être insuffisants pour certaines applications un peu lourdes (n’est ce pas Ptit_boeuf ? :p).
• la taille maximale d’un fichier uploadé (upload_max_size, 2 Mo). Vraiment trop petit si vous hébergez par exemple un CMS sur lequel vous publiez des photos en haute qualité.
• la taille maximale des données passées en POST (post_max_size, 2 Mo). Comme les fichiers uploadés passent par la méthode POST, post_max_size doit valoir au moins autant que upload_max_size.

Pour ma part, je les positionne respectivement à 512 Mo, 32 Mo et 32 Mo :

Il faut également créer pour PHP un répertoire temporaire appartenant à www-data, qui servira notamment pour les uploads de fichier, puis renseigner son emplacement dans upload_tmp_dir :

Pour aller encore un peu plus loin, on pourrait également installer le module Apache suPHP, qui permet de spécifier le couple utilisateur/groupe sous lequel vont s’exécuter les scripts PHP, mais l’impact de cette solution est non négligeable (PHP ne s’exécute alors plus en tant que module Apache, mais en tant que CGI) et me semble personnellement un peu lourd compte tenu de mon usage.

Sécurisation de ProFTPd

Par défaut, ProFTPd donne à chaque utilisateur l’accès à l’ensemble du système de fichier, dans la limite des droits Unix définis à ce niveau. Il est préférable de restreindre chaque utilisateur à son répertoire home. Ça se passe du côté de /etc/proftpd/proftpd.conf en dé-commentant la ligne DefaultRoot :

Voir aussi cette page pour vous prémunir d’une faille de sécurité avec la configuration par défaut de ProFTPd sous Ubuntu.

Configuration de RKHunter

Au niveau de RKHunter, il n’y a pas grand chose à faire. Commencez par mettre à jour sa base de signatures :

Cette opération devra être effectuée après chaque installation ou mise à jour de paquet.

Ensuite, modifiez simplement le fichier /etc/default/rkhunter pour activer l’exécution quotidienne (CRON_DAILY_RUN), la mise à jour hebdomadaire de la base de données (CRON_DB_UPDATE) et l’adresse mail de destination des rapports (REPORT_EMAIL) :

En configuration par défaut, RKHunter produira systématiquement quelques warning, que vous pouvez éliminer en ajoutant quelques lignes à /etc/rkhunter.conf :

Configuration de Fail2ban

La configuration de Fail2ban se fait dans le fichier /etc/fail2ban/jail.conf. Il faut y activer les « jail » que vous souhaitez. De mon côté, j’ai activé les jail ssh, ssh-ddos, apache, apache-noscript, apache-overflows et proftpd. Pour activer ces jail, cherchez leur nom entre crochets dans le fichier jail.conf et assurez vous que la section correspondante contient une ligne « enabled = true« . Pensez également à modifier le paramètre port des jails ssh et ssh-ddos, pour y mettre le numéro de port que vous avez affecté à votre serveur SSH.

Je vous recommande également de changer l’adresse mail de destination des rapports et d’activer l’envoi systématique de rapports détaillé lorsqu’un comportement suspect est bloqué (c’est toujours bien de savoir ce qu’il se passe, et au pire, si vous trouvez que ça vous fait trop de mail, vous pourrez toujours le désactiver plus tard). L’adresse mail se règle avec le paramètre destemail et l’action par défaut avec le paramètre action (%(action_)s pour un simple ban sans mail, %(action_mw)s pour un mail simple et %(action_mwl)s pour un mail contenant en plus l’extrait de fichier journal qui a déclenché le ban).

Configuration du firewall

Ça peut paraitre surprenant, mais par défaut, les pares-feu iptables (IPv4) et ip6tables (IPv6) ne bloquent absolument rien, et ses règles de filtrage sont perdues à chaque redémarrage de la machine.

Pour le configurer, il faut donc créer un script exécutant toutes les commandes nécessaires à la mise en place des filtres. Voici le script que j’utilise (inspiré de celui de Zemanta) :

Copiez le dans un fichier iptables.sh (en modifiant éventuellement le port SSH à la seconde ligne) puis exécutez le :

Ouvrez une nouvelle session SSH (sans fermer la première !) pour vous assurer que la connexion fonctionne. Si ce n’est pas le cas, revenez à la première session et réinitialisez iptables :

Si ça ne marche toujours pas, pas de panique : comme iptables perd les règles au démarrage, il suffit de faire un hard reboot de la machine depuis la console de gestion de votre hébergeur.

Une fois que vous aurez un fichier de règles pleinement fonctionnel, il ne vous restera plus qu’à configurer son activation en cas de redémarrage de la machine. Pour ce faire, il y a deux possibilités :

• l’exécuter automatiquement au démarrage :

•  l’exécuter automatiquement à intervalles régulier via cron (les règles ne seront appliquées que si elles ne l’ont pas encore été) :

Puis ajoutez cette ligne, pour une exécution toutes les heures :

La première solution est bien entendu la plus propre et la plus sûre, puisque le serveur démarre directement avec le firewall actif. Par contre, en cas de problème, il faudra démarrer le serveur en mode rescue pour aller éditer le fichier…

La seconde solution permet de se contenter d’un simple hard reboot, car après le démarrage les règles n’entreront pas en vigueur immédiatement.

Une fois le fichier en place, vous pourrez également l’enrichir au fil du temps, par exemple pour bloquer « définitivement » une IP au comportement indésirable. Voici les commandes à exécuter puis ajouter au fichier pour bloquer respectivement une IPv4 et une IPv6 :

Voilà, normalement si vous êtes arrivés jusque là, vous avez désormais un serveur prêt à héberger vos sites avec un minimum de sécurité. Il ne reste donc plus qu’à configurer votre Apache pour vos sites.

Configurer un site dans Apache

Pour ce faire, commencez par créer un répertoire pour chacun des sites que vous comptez héberger. Par exemple, vous pouvez créer dans le répertoire home de votre utilisateur un dossier www qui contiendra un sous-dossier pour chaque site hébergé :

Pour chaque site, créez un fichier dans /etc/apache2/sites-available sur le modèle suivant, à adapter éventuellement si vous avez des besoins spécifiques :

Ce fichier permet de déclarer un VirtualHost associé à un nom de domaine ou de sous-domaine (ServerName) et dont les scripts seront exécutés avec les droits de user.

L’instruction ServerAlias permet d’accepter également les sous-domaine du ServerName. Dans cet exemple, le site sera accessible aussi bien via http//monpremiersite.fr que via http://www.monpremiersite.fr ou http://nimporteque.monpremiersite.fr (à condition bien sûr que la configuration DNS de ces sous-domaines pointe vers l’IP du serveur).

Le bloc suivant utilise le module rewrite pour rediriger les accès faits via tous les domaines autorisés par ServerName et ServerAlias vers une adresse principale. Un utilisateur se rendant sur http://nimporteque.monpremiersite.fr sera automatiquement redirigé vers http://www.monpremiersite.fr. Ceci permet d’éviter que le contenu de votre site soit référencé par des moteurs de recherche sous les deux adresses différentes, ce qui pourrait être néfaste pour le classement (le moteur pouvant considérer qu’il s’agit de contenu dupliqué).

Le bloc Directory définit les droits pour les accès aux fichiers du site. Dans cet exemple, on interdit le listing des répertoires (se rendre sur http://www.monpremiersite.fr/dossier/ renverra une erreur 403 si dossier ne contient pas de fichier index.php ou index.html, au lieu de lister le contenu de dossier), on autorise les liens symboliques, on interdit la surcharge des options (les fichiers .htaccess ne seront pas pris en compte, si vous en avez besoin utilisez AllowOverride All, mais ceci réduit légèrement les performances) et on autorise l’accès à tous les fichiers.

Enfin le dernier bloc permet de restreindre les droits d’accès des scripts PHP, pour ne les autoriser à ouvrir que des fichiers présents dans l’arborescence du site ou dans l’arborescence partagée de PHP.

Une fois les fichiers de tous les sites en place, activez les :

 

Voilà, c’est tout pour ajourd’hui. Merci à vous si vous d’être allé jusqu’au bout de cet article et rendez-vous pour la suite (mes scripts en tous genres pour la gestion du serveur) dans les prochains jours ou semaines.