Durcissement et vulnérabilités

Bloquer les attaques ne fait que la moitié du travail ; l'autre moitié consiste à fermer ce qui les a laissées entrer. Chaque serveur lance une vérification du durcissement et un audit des logiciels 10 minutes après le démarrage de l'agent, puis une fois par jour. Vérifier maintenant et Vérifier les logiciels maintenant, dans l'onglet Sécurité du serveur, les lancent immédiatement.

La vérification du durcissement#

Elle examine :

• SSH : connexion root, authentification par mot de passe, port par défaut, redirection X11, nombre maximal de tentatives d'authentification ;
• fichiers : permissions de /etc/shadow, /etc/passwd, sshd_config et du authorized_keys de root ;
• ports : services à l'écoute sur le réseau public ;
• utilisateurs : comptes d'UID 0 autres que root, comptes sans mot de passe ;
• pare-feu et processus (zombies) ;
• identifiants : fichiers .env lisibles par tous, répertoires .git exposés dans les racines web, permissions des répertoires .ssh ;
• serveur web : divulgation de version, listage des répertoires, méthode TRACE, protocoles TLS, en-têtes de sécurité, limitation de débit, taille du corps des requêtes et réglages de performance ;
• versions : système d'exploitation en fin de vie, noyau, mises à jour de sécurité en attente, PHP, MySQL, OpenSSH et le serveur web.
• PHP : la configuration de chaque runtime PHP et de chaque pool PHP-FPM (voir Durcissement de PHP plus bas).

Chaque vérification explique ce que c'est, pourquoi c'est important et comment corriger.

Les vérifications SSH lisent la configuration que sshd utilise vraiment : sshd -T ou, quand il ne peut pas s'exécuter, les fichiers dans l'ordre de sshd lui-même (agent 1.0.35 ou plus récent). sshd garde la première valeur qu'il lit, et sur les distributions actuelles sshd_config inclut les drop-ins de /etc/ssh/sshd_config.d/ tout en haut : c'est donc un drop-in qui l'emporte. Sur un serveur cloud tout juste créé, le 50-cloud-init.conf de cloud-init réactive souvent la connexion par mot de passe. Le résultat indique le fichier et la ligne qui fixent la valeur, par exemple /etc/ssh/sshd_config.d/50-cloud-init.conf:1 : modifiez-la à cet endroit.

Le nombre de vérifications dépend du serveur : de 40 à 50 sur la plupart. Les vérifications du serveur web dépendent de ce qui est installé, nginx, Apache ou les deux, et les vérifications PHP (de six à neuf) portent sur chaque runtime PHP et chaque pool PHP-FPM : un serveur avec beaucoup de pools en a donc davantage.

Corrections en un clic#

Dix vérifications peuvent être corrigées avec Corriger automatiquement :

InfraFence écrit chaque modification dans un fichier dédié (/etc/ssh/sshd_config.d/00-infrafence-hardening.conf, ou zz-infrafence-hardening.conf pour nginx et Apache), teste la configuration (sshd -t, nginx -t, apachectl configtest) et recharge le service : les sessions et connexions ouvertes ne sont pas coupées. Annuler la correction revient en arrière.

Certaines vérifications ne sont jamais automatiques, car mal faites elles pourraient vous bloquer l'accès ou modifier le comportement de vos sites : connexion root, authentification par mot de passe, port SSH, listage des répertoires, protocoles TLS et en-têtes de sécurité. Leur page explique comment les corriger à la main. Sur un serveur dont la configuration est gérée par un panneau d'hébergement ou un outil de gestion de configuration, seules les corrections de permissions sont automatiques.

Durcissement de PHP#

La vérification lit la configuration effective de chaque runtime PHP du serveur : le PHP de la distribution, ondrej, remi, cPanel EA4, Plesk et CloudLinux alt-php. Elle suit php.ini et le répertoire d'analyse dans l'ordre de PHP, et vérifie chaque pool PHP-FPM avec ses surcharges php_value et php_admin_value. Le PHP en ligne de commande n'est pas vérifié.

« Avec approbation » exige l'authentification à deux facteurs. Les corrections de cgi.fix_pathinfo et disable_functions ne sont appliquées que par un propriétaire ou un administrateur connecté avec l'authentification à deux facteurs : avec Examiner et appliquer dans l'onglet Sécurité du serveur, ou dans Approbations quand AutoMode le demande. Sans 2FA, le tableau de bord ne les applique pas. Activez-la dans Paramètres › Sécurité.

Chaque constat indique le runtime, le pool, la valeur et le fichier et la ligne d'où elle vient. Avant que vous approuviez un correctif disable_functions, le tableau de bord liste les fichiers des sites qui appellent ces fonctions (jusqu'à 20).

Les correctifs vont dans un fichier qui appartient à InfraFence, zz-infrafence-hardening.ini dans le répertoire d'analyse du runtime ; php.ini et vos fichiers de pool ne sont jamais modifiés. Quand un pool définit la valeur dans son propre fichier, un drop-in ne peut pas la remplacer : le constat donne alors la ligne exacte à changer à la main dans ce fichier. L'agent teste la configuration (php-fpm -t), vérifie que la nouvelle valeur est bien celle qui s'applique, recharge PHP-FPM en douceur (jamais de redémarrage) et fait la même vérification des sites que pour les autres correctifs : si un site cesse de répondre, le changement est annulé. Un correctif dans le fichier du runtime s'applique à chaque pool de ce runtime qui ne définit pas lui-même la valeur.

L'agent surveille aussi ces fichiers. Quand allow_url_include ou display_errors est activé, l'événement Paramètre PHP risqué apparu indique le fichier, une fois par changement. Si quelqu'un d'autre modifie le fichier d'InfraFence (un panneau, un paquet, une personne), vous recevez aussi un événement.

Sur cPanel, Plesk et CloudLinux, la configuration de PHP est signalée, jamais modifiée, et les fichiers par site (le php.ini de Plesk, le .user.ini de cPanel) sont seulement signalés.

C'est du durcissement et de la surveillance de configuration. Rien n'est chargé dans PHP et cela n'arrête pas une attaque à l'intérieur de votre application : le pare-feu web et le scanner de malwares s'en chargent.

Vérification et annulation#

Avant une correction, l'agent note quels ports SSH acceptent les connexions et quels sites répondent sans erreur serveur, en HTTP et HTTPS (jusqu'à 20 sites). Après le rechargement, il les vérifie de nouveau pendant 20 secondes au plus. Si l'un d'eux ne répond plus, il annule la modification de lui-même et le résultat indique Annulée par le serveur. Les corrections de permissions n'ont pas d'annulation : un mode plus strict ne casse pas un service.

La même vérification protège la fermeture de ports, les blocages sortants et les patchs virtuels.

Vulnérabilités (CVE)#

L'audit des logiciels envoie la liste des paquets installés au tableau de bord, qui la compare à la base OSV. Cela fonctionne sur Debian, Ubuntu, AlmaLinux et Rocky Linux. Le panneau Vulnérabilités (CVE) liste les paquets pour lesquels un correctif existe, et signale ceux qui figurent sur la liste CISA des vulnérabilités dont l'exploitation est connue (Exploitée activement (CISA KEV)) : mettez ceux-là à jour en premier.

Mises à jour de sécurité#

Tout mettre à jour ou Mettre à jour ce paquet installe les versions corrigées. L'agent ne met à niveau que ces paquets (rien n'est installé ni supprimé en plus), conserve vos fichiers de configuration, refuse de démarrer pendant qu'une autre opération sur les paquets est en cours, et ne redémarre jamais le serveur. La mise à niveau d'un paquet peut redémarrer brièvement son service. Quand un redémarrage est nécessaire, ou qu'un service exécute encore l'ancien code, le résultat le signale.

Score de sécurité#

Les résultats alimentent le score de sécurité du serveur, de 0 à 100, avec les principales corrections en tête de liste. Voir Serveurs.