Meilleures pratiques de sécurisation des serveurs dédiés

Commence par l'inventaire des surfaces d'attaque

Avant de changer quoi que ce soit, regarde ce qui tourne :

# All listening ports

ss -tlnp

# Running services

systemctl list-units --type=service --state=running

# SUID/SGID files (privilege escalation candidates)

find / -perm /6000 -type f 2>/dev/null

# World-writable directories

find / -xdev -type d -perm -0002 2>/dev/null

Documente à quoi sert chaque port ouvert et chaque service en cours d'exécution. Si tu ne peux pas dire tout de suite « pourquoi ce port est ouvert », c'est la première chose à vérifier.

Renforcement de la sécurité SSH

SSH est le principal moyen d'accès administratif sur les serveurs Linux, et c'est aussi la cible principale des attaques par force brute. Renforcer la sécurité de SSH, c'est bloquer la voie d'attaque la plus courante avant toute autre configuration.

Modifie le fichier /etc/ssh/sshd_config et applique ces paramètres :

# Disable password authentication entirely

PasswordAuthentication no

ChallengeResponseAuthentication no

# Disable root login over SSH

PermitRootLogin no

# Use a non-standard port (reduces automated scan noise)

Port 2222

# Limit SSH to specific users

AllowUsers deploy_user admin_user

# Reduce authentication timeout window

LoginGraceTime 30

MaxAuthTries 3

# Disable legacy protocol features

Protocol 2

X11Forwarding no

AllowAgentForwarding no

AllowTcpForwarding no

# Keep-alive settings to terminate idle sessions

ClientAliveInterval 300

ClientAliveCountMax 2

L'authentification par clé est obligatoire une fois que l'authentification par mot de passe est désactivée. Génère des clés sur ta machine locale avec ssh-keygen -t ed25519 et copie la clé publique dans ~/.ssh/authorized_keys sur le serveur avant de désactiver les mots de passe.

Applique les changements : systemctl restart sshd. Vérifie que tu peux toujours te connecter via la clé avant de fermer ta session actuelle.

La publication spéciale 800-123 du NIST donne des conseils complets sur comment configurer SSH dans les environnements de production, y compris les bonnes pratiques de gestion des clés.

Configurer un pare-feu avec nftables

Les distributions Linux modernes utilisent nftables comme framework de pare-feu préféré. Voici un ensemble minimal de règles pour un serveur web :

#!/usr/sbin/nft -f

flush ruleset

table inet filter {

    chain input {

        type filter hook input priority 0; policy drop;

        # Accept established/related connections

        ct state established,related accept

        # Accept loopback

        iif lo accept

        # Accept ICMP (ping) - limit rate

        icmp type echo-request limit rate 5/second accept

        icmpv6 type echo-request limit rate 5/second accept

        # SSH on custom port

        tcp dport 2222 ct state new limit rate 10/minute accept

        # HTTP and HTTPS

        tcp dport { 80, 443 } accept

        # Log and drop everything else

        log prefix "Dropped: " drop

    }

    chain forward {

        type filter hook forward priority 0; policy drop;

    }

    chain output {

        type filter hook output priority 0; policy accept;

    }

}

Enregistre dans /etc/nftables.conf et active : systemctl enable –now nftables. La politique par défaut est de bloquer le trafic entrant — seul le trafic explicitement autorisé passe.

Pour les serveurs qui utilisent cPanel, cPanel ses propres règles de pare-feu. Utilisez ConfigServer Security & Firewall (CSF), qui s'intègre à WHM et offre une interface utilisateur pour gérer les règles sans passer outre les ports requis cPanel.

Gestion des comptes utilisateurs

Chaque compte utilisateur peut être un moyen de piratage. Fais gaffe à :

Désactive les comptes système qui ne servent pas: regarde dans /etc/passwd s'il y a des comptes avec des shells de connexion qui ne devraient pas en avoir. Mets leur shell sur /sbin/nologin :

usermod -s /sbin/nologin compte_inutilisé

Supprime les privilèges sudo inutiles: utilise visudo pour vérifier /etc/sudoers. Chaque ligne qui autorise NOPASSWD sudo est un chemin d'escalade des privilèges si ce compte est piraté. Demande un mot de passe pour toutes les opérations sudo en production.

Utilisez des comptes utilisateurs basés sur les rôles: les services d'application doivent être exécutés en tant qu'utilisateurs système dédiés avec des autorisations minimales. Le serveur web ne doit pas être exécuté en tant que root. MySQL ne doit pas être exécuté en tant que root. Créez des utilisateurs spécifiques à l'application :

useradd -r -s /sbin/nologin -d /var/www/app appuser

chown -R appuser:appuser /var/www/app

Vérifie régulièrement les dernières connexions: lastlog | grep -v. Ça ne montre jamais les comptes qui ont été utilisés pour se connecter. Les comptes que tu ne t'attendais pas à voir dans cette sortie méritent d'être examinés.

Renforcement du noyau via sysctl

Plusieurs paramètres du noyau réduisent la surface d'attaque pour les exploits au niveau du réseau :

# /etc/sysctl.d/99-hardening.conf

# Disable IP source routing (used in some spoofing attacks)

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.default.accept_source_route = 0

# Disable ICMP redirect acceptance

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

# Enable reverse path filtering (anti-spoofing)

net.ipv4.conf.all.rp_filter = 1

# Disable ping broadcasts

net.ipv4.icmp_echo_ignore_broadcasts = 1

# Log martian packets (packets with impossible source addresses)

net.ipv4.conf.all.log_martians = 1

# Disable IPv6 if not in use

net.ipv6.conf.all.disable_ipv6 = 1

# Kernel pointer hiding

kernel.kptr_restrict = 2

kernel.dmesg_restrict = 1

Appliquez avec sysctl -p /etc/sysctl.d/99-hardening.conf.

Sécurité du système de fichiers

Mets les bons droits d'accès sur les dossiers sensibles :

chmod 750 /root

chmod 644 /etc/passwd

chmod 640 /etc/shadow

chmod 600 /etc/ssh/sshd_config

Options de montage qui réduisent les risques d'escalade des privilèges:

Modifie le fichier /etc/fstab pour ajouter noexec, nosuid et nodev aux partitions qui ne devraient pas avoir de fichiers exécutables :

/dev/sdb1 /var/tmp ext4 par défaut, pas d'exécution, pas de SUID, pas de périphérique 0 2

Vérifie l'intégrité des fichiers avec AIDE: AIDE (Advanced Intrusion Detection Environment) crée une base de données des sommes de contrôle des fichiers et peut te prévenir si des fichiers changent de façon inattendue. Lance aide –init pour commencer, puis utilise aide –check de temps en temps ou via cron. Si des fichiers binaires, des bibliothèques ou des fichiers de configuration du système changent de façon inattendue, ça veut dire qu'il y a un problème.

Gestion des logiciels et des paquets

Gardez vos paquets à jour: les failles non corrigées dans le noyau, OpenSSL, glibc et d'autres bibliothèques système sont le moyen le plus courant de compromettre un serveur après des identifiants faibles.

# CentOS/AlmaLinux/Rocky Linux

dnf update --security -y

# Ubuntu/Debian

apt-get upgrade -y

Automatisez les mises à jour de sécurité : dnf-automatic (famille RHEL) ou unattended-upgrades (famille Debian) peuvent être configurés pour appliquer automatiquement les correctifs de sécurité tout en laissant les mises à niveau majeures à votre appréciation.

Vérifie les paquets installés: enlève ceux qui ont été installés pour des tests et qui n'ont jamais été supprimés. Chaque paquet installé représente une vulnérabilité potentielle. rpm -qa (RHEL) ou dpkg -l (Debian) te montre tout ce qui est installé.

Supprimez les outils de développement des serveurs de production: les compilateurs, les débogueurs et les outils de création de paquets n'ont pas leur place sur les serveurs de production. Un pirate informatique qui obtient un accès limité peut les utiliser pour compiler du code d'exploitation. Supprimez gcc, make et les outils similaires s'ils sont présents.

Détection des intrusions et surveillance des journaux

Fail2Ban surveille les fichiers journaux et bloque les adresses IP qui montrent des comportements bizarres, comme des échecs répétés de connexion SSH, des erreurs Nginx à répétition et d'autres signes d'abus. Fail2Ban peut être installé via le gestionnaire de paquets sur toutes les principales distributions Linux et fonctionne avec n'importe quel format de fichier journal.

Centralisation des journaux: envoyer les journaux vers un serveur syslog distant, ça veut dire que même si le serveur est piraté et que les journaux locaux sont effacés, tu gardes la piste d'audit. rsyslog prend en charge la journalisation à distance de manière native. Pour les équipes qui utilisent déjà une pile ELK (Elasticsearch, Logstash, Kibana) ou un service d'agrégation de journaux géré, configure le fichier rsyslog.conf du serveur pour transférer les journaux vers le récepteur central.

Détection des logiciels malveillants Monarx: le pack Premier Care d'InMotion inclut Monarx, un moteur de détection des logiciels malveillants qui scanne les fichiers et est fait spécialement pour les environnements d'hébergement web. Monarx repère les téléchargements de shells web, les injections PHP malveillantes et les mineurs de cryptomonnaie, qui sont les logiciels malveillants les plus courants qui ciblent les serveurs Linux dans les contextes d'hébergement web. Il tourne au niveau du noyau sans ralentir les performances comme les antivirus classiques.

Planifier des audits réguliers

Le renforcement des mesures de sécurité au moment de l'approvisionnement perd de son efficacité avec le temps s'il n'est pas maintenu. Mettez en place un cycle de révision trimestriel couvrant :

• Vérifie les ports ouverts par rapport aux besoins actuels des applications.
• Vérifie les comptes utilisateurs et les clés SSH autorisées pour tout le monde.
• Vérifie si la base de données d'intégrité AIDE a été modifiée de façon bizarre.
• Vérifie les autorisations sudo et supprime celles dont tu n'as plus besoin.
• Installe tous les correctifs de sécurité qui n'ont pas été installés automatiquement.
• Vérifie les journaux Fail2Ban et pare-feu pour voir s'il y a eu des changements dans les modèles d'attaque.

Les serveurs avec les meilleurs antécédents en matière de sécurité ne sont pas ceux qui ont été sécurisés une fois pour toutes et oubliés. Ce sont ceux où quelqu'un vérifie régulièrement le travail effectué.

À lire aussi: Stratégies de protection contre les attaques DDoS pour les infrastructures dédiées | Sécurité Zero Trust sur Bare Metal