Quelques bonnes pratiques de sécurisation d’un serveur Linux, partie 2

Cet article a été publié il y a 8 ans 11 mois 26 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

On a déjà vu comment verrouiller la principale porte d’entrée de notre machine, le serveur SSH. Aujourd’hui, on va s’attaquer à des points certes moins directs, mais potentiellement aussi sensibles.

Rappel : il est évident qu’on ne saurait être exhaustif quand il s’agit de sécurité. Que ce soit le contexte d’installation du serveur ou son utilisation, je ne saurais couvrir tous les besoins. Aussi, il ne faut pas hésiter à me corriger quand je dis une énorme connerie 🙂

Bien gérer les paquets

Si votre machine est destinée à un seul usage, arrangez-vous pour garder un nombre de paquets aussi restreint que possible. Par exemple, pour le blog, il faut un serveur Web, un serveur MySQL/MariaDB, et PHP (et quelques extensions php au passage). Dans cette optique, on évitera d’installer des logiciels qui n’ont rien à faire avec la gestion d’un blog (du genre un démon transmission, bande de pirates).

Si vous avez fait des tests avant d’arrêter vos choix de logithèque, il se peut que certains paquets dits orphelins traînent encore, souvent des dépendances qui ne servent plus à personne. Dans ce cas, on fera appel à deborphan sous Debian/Ubuntu pour détecter ces paquets qui n’ont plus de raison d’être, afin de les supprimer.

En parlant de paquets supprimés, à l’image d’un logiciel sous Windows laissant sa pourriture dans la base de registres, il est possible que des fichiers de configuration traînent encore. Au niveau de dpkg, ces paquets qui n’ont pas supprimé leur configuration sont dans l’état rc. On peut les lister avec la commande suivante :

Une fois la liste définie, si vous êtes d’accord avec ce qu’il vous dit, vous pouvez ajouter une commande à la chaîne pour les supprimer :

Des mises à jour automatiques ?

Personnellement je n’aime pas ça, parce que si jamais une mise à jour déconne malgré le soin apporté à leur qualité (ça arrive souvent chez Microsoft), c’est la misère. Je préfère simplement surveiller les annonces de sécurité Debian, et me donner le temps ensuite de mettre à jour manuellement.

Un autre moyen d’obtenir des alertes de mises à jour sur tous les paquets (parfois un bug corrigé n’est pas une faille de sécurité, et ne fait donc pas l’objet d’une alerte), l’utilitaire cron-apt sera votre serviteur. Son fichier de configuration /etc/cron-apt.conf sera à adapter suivant vos besoins :

Par défaut il fait une recherche tous les jours à 4h du matin, vous pouvez modifier l’horaire dans le fichier /etc/cron.d/cron-apt.

Si jamais d’aventure les mises à jour auto/silencieuses vous bottent, il faut ajouter un fichier nommé 5-install dans le répertoire /etc/cron-apt/action.d/ avec le contenu suivant :

Limiter les services en écoute

C’est un point accessoire certes, et qui sera à rapprocher d’un futur point que je n’aurais pas besoin de beaucoup aborder, parce que je l’ai déjà fait. La plupart des services réseau n’ont pas besoin d’accepter d’autres connexions que celles provenant d’applications installées sur la même machine. Lorsque c’est le cas, on fera donc plutôt écouter ces services sur l’interface « loopback ». C’est un fonctionnement qu’on retrouve souvent par défaut dans les services installés sous Debian, et qu’il faudra éventuellement considérer de près sous d’autres distributions.

Un exemple parfait est, dans le cadre d’une plateforme web, le serveur MySQL. Installé sous Debian, il n’écoute sur le port 3306 qu’en local (adresse 127.0.0.1, dite loopback). De cette manière, seuls les processus locaux pourront appeler leur base de données, tel MySQL. Cela n’entravera pas le bon fonctionnement d’un site Web, puisque vous-même n’appelez que le chef d’orchestre, le serveur Web, qui exécutera le PHP (ou le fera exécuter par FPM ou HHVM), qui lui appellera la base de données. On remarquera dans mon article sur l’utilisation d’FPM que lorsque je le configure (par le biais du réseau, contrairement à Nicolas Simond l’amoureux des sockets), la configuration réseau se fait aussi sur l’interface loopback. De cette façon, seul le serveur Web installé sur la même machine peut lui envoyer les fichiers PHP à exécuter.

Le pare-feu

Lorsqu’on ne veut pas ou ne peut pas configurer une application pour qu’elle n’écoute que ce qu’elle a à écouter, on peut alors se tourner vers le pare-feu. J’ai déjà décrit sur le Wiki Homeserver.diy comment le paramétrer de base.

Un moyen alternatif pour verrouiller les communications tout en autorisant le minimum entre services, c’est justement d’interdire tout puis d’autoriser finement les connexions au moyen du pare-feu.

Fail2ban

J’ai déjà abordé le cas Fail2ban dans le cadre de la sécurisation de WordPress. Mais Fail2ban dispose d’emblée, du moins sous Debian, d’une palette assez large de filtres couvrant notamment les tentatives de connexion SSH, Apache (qu’on pourra compléter avec des règles personnalisées), le serveur DNS, mail…

Notamment, par défaut Fail2ban ne fera que bannir d’SSH les attaquants de connexions sur le port SSH, laissant à ceux-ci la possibilité d’essayer alors les autres services. Et pareil pour d’autres services. L’idée sera donc de donner comme comportement par défaut de cesser de répondre à tout demande provenant d’une IP qui a tenté d’accéder frauduleusement à l’un des services. C’est la suggestion que m’a donné un commentateur dont le message a été mangé lors du gaufrage de Disqus.

Pour ça, on peut directement modifier l’action par défaut, paramétrée sur iptables-multiport, par iptables-allports dans /etc/fail2ban/jail.conf :

Attention, récemment avant d’appliquer cette règle je me suis fait avoir par de multiples erreurs 404 sur Apache, donc si vous voulez vous garder un accès, vous pouvez ajouter une adresse IP à ignorer, toujours dans le même fichier :

Le banaction, le bantime (réglé sur une heure, soit 3600 secondes), et le maxretry peuvent être changés pour chaque jail configurée. Une fois tout ça modifié, vous pouvez redémarrer fail2ban :

Pourquoi pas simplement un restart ? Chez moi, ça bug, allez savoir pourquoi, donc je préfère couper complètement, puis relancer.

Il est possible de définir d’autres règles qui ne sont pas fournies par défaut, par exemple qui ont aussi trait aux serveurs Web. Comme ce sont des règles plus spécifiques, je les aborderais au besoin dans les futurs articles. Si vous êtes assez doué, vous pouvez définir des règles personnalisées pour vos propres applications.

On a même pas encore abordé les usages spécifiques

Et ça sera pas encore pour le prochain numéro, qui traitera de ce magnifique monde des malwares et virus qu’on rencontre aussi sous Linux, contrairement à la légende, même s’il sont bien moins nombreux. Et encore, il sera aussi question de protéger vos utilisateurs, à l’image de la plupart des fournisseurs de webmail qui passent vos messages et leurs pièces jointes à l’antivirus avant de vous les présenter.