La sécurité des serveurs sous Linux
Les bases théoriques pour sécuriser les services d'un serveur sous Linux Debian
La sécurité des serveurs sous Linux n’est pas une chose à prendre à la légère. Certes Linux est un système assez sécurisé de base de part son système de gestion ; il n’en reste pas moins que le système d’exploitation le plus utilisé pour les serveurs dans le monde, soit vulnérable aux attaques.
La gestion de paquets
La gestion des paquets par dépôt est le plus gros des points forts côté sécurité selon moi pour Linux. L’installation de nouveaux logiciels se fait sur des serveurs (sécurisés) en ligne. Debian, comme d’autres distributions proposent ses propres dépôts pour installer ces paquets. Vous pouvez bien entendu installer d’autres dépôts pour charger davantage de logiciels.
Il est aussi possible d’installer manuellement un paquet sous Linux, tout comme sur Windows ou Mac. A la différence de ces derniers, Linux permet ce système d’installation sécurisé via les dépôts, et de ce fait réduit considérablement le risque d’infection.
Les mises à jour et installations (système et paquets)
Les mises à jour et les installations de paquets sous Debian se font par dépôts également
Du fait de la gestion des dépendances, les paquets qui ne servent plus (obsolètes), sont automatiquement désinstallés par le système lors des mises à jour.
mon_paquet_version_1.2 est automatiquement remplacé par mon_paquet_version_1.2.1.
Les droits sur les fichiers
Lorsqu’un fichier est téléchargé, il prend automatiquement l’attribut « -x » ce qui signfie qu’il n’est pas exécutable par le système (la commande ./$path) ne fonctionnera pas. Les accès administrateurs sur le système permettent l’accès à certains répertoires, la modification des droits des fichiers et des utilisateurs.
Par défaut, un utilisateur n’a de droit que sur son propre répertoire :
/home/userLes droits en lecture sont restreints sur les autres répertoires. Si l’utilisateur ne fait pas parti des sudoers (du groupe administrateur), il ne sera en mesure que de toucher aux objects que l’on lui a dit de toucher.
Linux utilise désormais une gestion des droits par ACL, qui est beaucoup plus paramétrable que le simple système (read (r), write (w), execute (x)).
La gestion des utilisateurs et des groupes
Un groupe contient un ensemble d’utilisateurs, chacun d’eux ont des droits.
- u pour user (utilisateur)
- g pour group (groupe)
- o pour other (autre)
dinath@server:~$ ls -l
d rwx r-x r-x 2 root root 4096 oct. 14 17:04 documents
-rw- r-- r-- 1 dinath dinath 421 mai 31 2014 user.xml Voici un exemple de la gestion des droits sous Linux. Cet ensemble de gestion des groupes et des utilisateurs en plus des fichiers permet de restreindre les accès aux ressources non autorisées par l’administrateur.
La gestion des différents répertoires système peut aussi être à configurer, par exemple refuser la compilation avec gcc pour les utilisateurs non root (ce qui permet de bloquer la création d’exécutables malveillants sur le serveur) ; etc.
Serveur de mail (Postfix, Qmail)
Les serveurs de mail sont très utilisés par les CMS (système de gestion de contenu comme les forums, blogs etc) pour notifier les utilisateurs.
Ces serveurs, installés par défaut fonctionnent sans authentification, une simple commande « mail » permet d’envoyer des e-mails sans avoir à être authentifié. Le smtp fonctionne donc sans authentification, n’importe qui se connectant de manière anonyme sur ce dernier pourra envoyer autant de mails qu’il le souhaite, votre serveur de mail pourrait souffrir de spam.
Les serveurs de mails peuvent aussi être vulnérables en surchargeant la queue d’envoi, faisant saturer le service et le faisant s’arrêter.
Serveur Web (Apache, NginX, Glassfish, Tomcat)
Les serveurs web sont assez exposés aux attaques, car ils sont frontaux. Un mauvais code PHP ou Java, et l’on pourrait récupérer les droits utilisateurs sur le serveur. Les plugins ajoutés à apache (libapache-mod-jk) par exemple, sont aussi vulnérables car potentiellement faillés.
Chaque serveur se doit d’être configuré un minimum avant d’être mis en production :
- Limiter la mémoire du serveur à un certain niveau pour éviter de le faire tomber
- Ne pas autoriser la navigation dans tous les répertoires
- Empecher l’exécution de script à certains endroits
- Paramétrer le serveur pour ne donner qu’un minimum d’informations au public
- Bien coder son application pour éviter les failles
- Protéger les accès à PHPMyAdmin, Webmin et autres logiciels de gestion de serveur
- Limiter les accès sur l’extérieur (nom de domaine, adresse ip)
- Protéger le chemin d’accès par htdigest password
- Utiliser des plugins comme mod_security pour accroître la sécurité du serveur web
Les serveurs web peuvent être difficle à protéger, néanmoins de simples procédures de protection comme celles évoquées au dessus peuvent déjà combler les besoins en sécurité de base de votre serveur, comme le propose ce site.
Pensez également qu’un certificat HTTPS reconnu peut améliorer la sécurité de votre serveur en chiffrant les échanges entre le client et le serveur.
Serveur de fichiers (SFTP, FTP, FTPS)
Les services d’échanges de données sont ciblés par les pirates, ces derniers servent à téléverser à distances différents fichiers ; fichiers pouvant être malveillants et exécuté sur le serveur.
La sécurité de ces données peut aussi fonctionner par utilisateur pour délimiter à chacun son répertoire. L’accès CHROOT d’un utilisateur peut le délimiter dans un répertoire spécifique afin qu’il ne voit que ce dernier.
Par exemple pour le répertoire :
/var/www/example.com/users/alexSi alex se connecte au serveur, il ne vera que cela :
/Il ne pourra pas remonter l’arborescence et accéder aux autres fichiers.
SSH
L’accès que tous les pirates voudraient avoir sur votre serveur, il permet de se connecter à distance sur ce dernier et d’administrer le seveur à distance. Un simple accès utilisateur peut alors servir à compromettre tout le serveur.
Un article pour : Sécuriser ses accès SSH
Fail2Ban peut être utilisé pour bannir les utilisateurs qui ont tentés de se connecter trop de fois sur le serveur en ayant échoué.
A noter que désinstaller OpenSSH permet d’éviter de le sécuriser, quand bien même vous ne l’utiliseriez pas et auriez un accès physique ou virtuel ou serveur.
Serveur de base de données (MySQL, PostgreSQL)
Les accès par base de données ne doivent être données qu’à un seul utilisateur, ne jamais connecter ses applications à un compte root (ou superutilisateur). Si votre base de données est corrompue, toutes les bases pourraient l’être aussi ; dans ce genre de cas, il vaut mieux limiter la casse.
Un serveur de base de données peut aussi être mis hors service à la manière d’un serveur web en surchargeant les capacités de ce dernier. Tout comme un serveur web, je vous recommande de chiffrer vos connexions lors de l’authentification pour éviter les attaques MIM.
Je vous incite également à utiliser le script fourni avec MySQL (si vous l’utilisez) : mysql_secure_installation. Ce dernier permet de sécuriser un minimum son installation (à ne pas exécuter sur un serveur en production bien évidemment).
Conclusion
Voici quelques mots sur la sécurisation d’un serveur sous Linux. Je ne suis pas un expert, mais j’en sais suffisamment pour protéger de manière efficace mes différents services sur le serveur dédié. Je n’ai parlé que des points que je connaisse sur le serveur et ses différents services (la liste des serveurs web n’est donc pas exhaustives, par exemple).
Cependant, la sécurisation de manière plus poussée d’un serveur Linux peut être très complexe à mettre en oeuvre, sans parler des différents points de sécurité dont nous n’avons pas parlé comme la sauvegarde des données (je ferais un article dessus avec un script dans les jours à venir).
Lorsque vous faites appel aux services d’un hébergeur, veillez aussi à choisir une solution proposant d’ores et déjà une sécurité renforcées pour ne pas exposer votre serveur aux dangers les plus fréquents.