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

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

Après avoir abordé SSH, puis la gestion des paquets et Fail2ban, avant de s’attaquer aux cas pratiques, on va s’attarder sur la sécurité, non seulement de la machine mais aussi de ses visiteurs, face aux virus et autres malwares.

La robustesse de Linux due à son design hérité d’UNIX n’en fait pas non plus un système exempt de problèmes. Tout logiciel peut être affecté d’un bug ou d’une faille qu’un contrevenant pourrait exploiter à son avantage, avec ou sans une malencontreuse intervention de votre part (sous Windows, ouvrir un mail vérolé qui installe un logiciel malveillant, ce qui est arrivé à TV5 bien que nos « gouvernants » plus gouvernés par leur peur que par leur peuple aie qualifié ça d’attaque terroriste–cherchez les morts…). Et c’est d’autant plus vrai au pays du froid, même si les bactéries et autres infections sont moins à l’aise.

Mais il ne faudrait pas non plus négliger le fait que le système peut faire office de porteur sain. Si vous hébergez un service qui permet à vos utilisateurs de partager des fichiers avec du public (par exemple, une application de stockage cloud), il n’est pas impossible que les fichiers soient infectés, sans incidence pour la machine, mais dangereux pour les destinataires des fichiers (un comportement qu’on retrouve aussi dans le mail). Il peut donc être nécessaire de faire une vérification préalable, afin de garantir non pas la sécurité de la machine pour le coup, mais bien celle des utilisateurs.

Ce sont les deux principaux cas de figures qui seront traités après.

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 🙂

ClamAV/Freshclam, l’antivirus open-source

Ce n’est certes probablement pas le plus efficace, mais il n’a pas non plus une armée de chercheurs/ingénieurs en sécurité payés pour participer à son évolution. Ceci dit, notamment dans le cadre de la gestion d’une plateforme mail, il est souvent conseillé de l’utiliser (ou un autre antivirus, mais c’est l’idée). En effet, le mail, en tant que moyen de communication sur Internet toujours populaire, reste un vecteur de choix pour tous les concepteurs de virus et autres chevaux de troie de tous poils. Idem si vous opérez un stockage cloud public, il est préférable de s’assurer une certaine curation en la matière.

Pour installer clamav et freshclam (qui sert à sa mise à jour), sous Debian c’est extrêmement simple :

On vérifiera vite fait le fichier de configuration /etc/clamav/freshclam.conf, histoire de régler notamment la fréquence de recherche de mises à jour, la journalisation de ces mises à jour, le miroir permettant de les récupérer :

Avant de finir de configurer clamav, on appelera tout simplement freshclam sans paramètres pour faire une première mise à jour manuelle (les suivantes seront automatiques).

Le fichier de configuration clamav sera à adapter à votre convenance, voici ce que j’ai sur mon serveur perso OpenMediaVault :

On voit donc qu’ils conseillent de passer par dpkg-reconfigure clamav-base pour modifier la configuration, faites comme  vous le sentez. Dans tous les cas, si vous modifiez, il faut redémarrer l’antivirus.

Avant d’attaquer le scan à proprement parler, on va lui ajouter un petit extra.

Linux Malware Detector

À l’instar de Windows, il n’existe pas que des virus classiques, et d’autres logiciels tout aussi malveillants mais moins intrusifs (encore que) existent sous la banquise. En effet, sous Windows j’utilise sur ma machine le couple Kaspersky Internet Security, avec Malwarebytes Antimalware (j’en avais parlé dans la procédure de désinfection, son efficacité est toujours d’actualité). Car ce dernier s’occupe de certaines classes de logiciels publicitaires qu’ignore KIS, qui en contrepartie est mieux armé contre les gros velus.

Linux Malware Detector ne vise donc que ces saloperies à destination du Manchot, mais on peut ajouter sa base de connaissances à clamav pour augmenter un peu son efficacité malgré tout. Ça tombe bien, maldet de son petit nom utilise le même format de base de données que clamav, l’opération sera des plus simples.

Par contre, il faudra accepter d’installer un logiciel en dehors du gestionnaire de paquets (rappelez vous ma réflexion sur la sécurité des paquets à l’ère des conteneurs). En effet, l’archive se trouve sur le site du développeur, et elle contient le script d’installation :

On lance ensuite maldet -u pour mettre à jour la base de connaissances de malwares. Pour affiner les réglages de maldet seul, on s’attardera sur son fichier de configuration, qui ne se trouve pas dans le répertoire /etc, mais dans le chemin /usr/local/maldetect/conf.maldet (oui ça fait tout à l’envers en plus).

Pour ajouter la base de maldet à clamav, on se rend dans le dossier kivabien, et il suffit d’ajouter des liens symboliques vers les fichiers de maldet :

En effet, il faut redémarrer l’antivirus pour que les nouvelles signatures soient prises en compte.

On pourra dès lors lancer un scan récursif sur l’arborescence, ou sur un dossier en particulier pour du scan ponctuel. La commande dans les deux cas sera la suivante :

–infected permet de n’afficher que les résultats positifs, et –log de définir dans quel fichier enregistrer les opérations.

Attention : clamav n’est pas un antivirus résident, il faut donc lancer régulièrement un scan, en tâche planifiée, de préférence quand l’activité de la machine est au plus faible (le scan peut être très long). Sur une de mes machines j’avais opté pour une fois par semaine à 3h du matin.

Détection des rootkits

Les rootkits sont des menaces bien plus pernicieuses, car leur principale caractéristique est de se cacher du système, y compris de l’antivirus. On se souviendra de Sony qui embarquait un rootkit pour Windows avec leurs CDs audio pour en empêcher la copie. Rootkit qui s’avérait vulnérable, et donc devenant un possible vecteur d’attaque sur les machines qui étaient infectées. Leur nom vient du fait que pour se cacher, ils cherchent à tout prix à disposer des droits administrateurs, dits « root » dans l’univers du manchot.

Mais si l’on sait où chercher, il est tout de même possible de les détecter et de les supprimer. rkhunter et chkrootkit sont deux outils qui sont conçus pour cette tâche.

rkhunter

rkhunter s’installe et se met à jour très simplement sous Debian :

On se tournera vers le fichier de configuration /etc/rkhunter.conf pour ajouter notamment son adresse mail afin de pouvoir recevoir les alertes. Pour lancer un test, on utilisera la commande suivante :

Il parait qu’rkhunter peut générer des faux positifs, et la documentation d’Ubuntu permet de s’en prévenir.

chkrootkit

Si chkrookit commence à se faire vieux sous Debian Wheezy (la version date de 2008, c’est corrigé dans Jessie), il reste malgré tout utilisable. Là encore, l’installation est très difficile :

On passera une fois de plus dans le fichier de configuration /etc/chkrootkit/chkrootkit.conf pour notamment ajouter sa boite mail, ou paramétrer un check quotidien et silencieux.

Pour le lancer manuellement :

Amavis, pour les mails

Dernier point que j’ai failli oublier, et qui sera utile dans le cas d’un hébergement maison de boites mail. Si clamav permet de faire le ménage manuellement à intervalles réguliers, il est moins adapté pour des messages arrivant à n’importe quelle heure du jour et de la nuit.

Amavis, pour A MAil VIrus Scanner, capture les mails à la réception pour en vérifier le contenu avant de les transmettre au reste de l’infrastructure. Je vous conseille de lire le site officiel, très fourni, pour son utilisation, car c’est un des composants que je maitrise le moins pour l’instant. Couplé à SpamAssassin, vous devriez pouvoir conserver une boite propre assez facilement (enfin, tout est relatif).

« Voilà, c’est tout pour aujourd’hui »

J’ai probablement terminé tout ce qui concerne la sécurité de base « générique ». On va donc maintenant pouvoir aborder des cas plus pratiques, plus liés à des usages. Au prochain numéro, on s’attardera sur la plateforme Web. Stay Tuned 😉

PS : Comme toujours, les commentaires sont à votre disposition pour compléter/corriger les âneries que je pourrais avoir écrite.