Un serveur dédié est livré nu, avec une adresse IP publique et un accès root complet. À la différence d'un hébergement mutualisé, où l'hébergeur verrouille l'essentiel à votre place, tout ce qui tourne sur la machine relève désormais de vous. C'est précisément ce qui fait l'intérêt du serveur dédié, et ce qui rend les premières heures décisives : une machine fraîchement livrée est scannée en continu, et les tentatives de connexion automatisées commencent bien avant que votre premier site ne soit en ligne.
Les réglages ci-dessous ne demandent ni compétence rare ni infogérance. Ils se font en une petite heure et couvrent l'essentiel de ce qui remonte en ticket quelques semaines plus tard.
Pourquoi tout se joue le premier jour
Entre la livraison de la machine et sa mise en production, il existe une fenêtre où le serveur est joignable, avec une configuration par défaut, et souvent sans surveillance. Les balayages automatisés d'adresses IP ne visent personne en particulier : ils testent des ports ouverts et des mots de passe courants sur des plages entières. Un serveur qui passe une nuit dans cet état avec un accès SSH par mot de passe a déjà encaissé plusieurs milliers de tentatives au matin.
Rien de tout cela ne suppose que quelqu'un vous en veut. C'est du bruit de fond, et c'est justement pour cela qu'il est simple à écarter.
Durcir l'accès SSH
L'accès SSH est la porte d'entrée de la machine. Trois changements suffisent à en retirer l'essentiel du risque.
- Passer aux clés plutôt qu'au mot de passe. Une clé ne se devine pas par force brute. Générez-la sur votre poste, copiez la partie publique sur le serveur, vérifiez que la connexion par clé fonctionne, et seulement ensuite désactivez l'authentification par mot de passe.
- Interdire la connexion directe en root. Créez un compte utilisateur classique disposant de
sudo, puis refusez la connexion root directe. Un attaquant doit alors deviner un nom de compte en plus du reste. - Limiter les sources autorisées. Si vous administrez toujours depuis les mêmes adresses IP, restreignez l'accès au port d'administration à ces seules adresses.
Une précaution vaut tous les conseils de configuration : gardez une seconde session SSH ouverte pendant que vous modifiez la configuration, et testez la nouvelle connexion depuis un autre terminal avant de fermer la première. Une règle mal écrite qui vous verrouille dehors se répare sinon par une intervention sur la console physique, quand elle est disponible.
Fermer tout ce qui n'a pas besoin d'être ouvert
Par défaut, un système fraîchement installé écoute parfois sur plus de ports que nécessaire. Le principe tient en une phrase : tout fermer, puis rouvrir uniquement ce qui sert.
Un firewall correctement posé n'autorise que l'administration, le trafic web et les services que vous exposez réellement. Le reste (bases de données, outils d'administration, services de fichiers) n'a presque jamais de raison d'être joignable depuis l'internet entier.
Deux erreurs reviennent souvent. La première consiste à exposer MySQL publiquement alors que l'application qui l'utilise tourne sur la même machine : la base n'a alors besoin d'écouter que sur l'interface locale. La seconde consiste à laisser un FTP en clair, mots de passe compris, là où SFTP passe par le canal SSH déjà sécurisé.
Mises à jour : la partie ennuyeuse qui évite le reste
La majorité des compromissions observées n'exploitent pas une faille inédite mais une faille connue, corrigée depuis des mois, sur une machine jamais mise à jour. Appliquez les mises à jour du système dès la livraison, puis activez au minimum les mises à jour de sécurité automatiques.
Cela vaut aussi pour ce qui tourne au-dessus : un panneau de contrôle comme Plesk, un serveur web, un langage applicatif, un CMS. Une machine parfaitement durcie qui héberge une application obsolète reste vulnérable par l'application.
Vérifier ce que la machine expose vraiment
Après configuration, listez les ports en écoute et confrontez la liste à ce que vous croyez avoir ouvert. L'écart entre les deux est presque toujours instructif : un service installé en dépendance d'un autre, un outil de test laissé actif, un panneau de contrôle accessible publiquement alors qu'il pourrait être réservé à quelques adresses IP.
Si vous hésitez entre gérer cela vous-même ou déléguer, la comparaison entre housing et serveur dédié managé détaille où s'arrête la responsabilité de l'hébergeur et où commence la vôtre.
Qui sécurise quoi, selon le type d'hébergement
La charge de sécurisation varie énormément d'une formule à l'autre. C'est souvent la source du malentendu : un utilisateur habitué au mutualisé découvre sur un serveur dédié une liberté dont il hérite aussi des obligations.
| Formule | Ce que l'hébergeur verrouille | Ce qui reste à votre charge |
|---|---|---|
| Hébergement mutualisé | Système, serveur web, panneau de contrôle, mises à jour, isolation entre comptes. | Vos applications et vos mots de passe, rien de plus. |
| VPS (serveur virtuel) | L'hyperviseur et le matériel hôte. La virtualisation isole les machines virtuelles entre elles. | Tout l'intérieur de la machine virtuelle : système d'exploitation, SSH, firewall, services. |
| Serveur dédié | Le matériel et le réseau. Aucun autre client sur la machine. | Le serveur physique dans son intégralité logicielle, accès root compris. |
| Serveur cloud | La couche d'infrastructure et sa flexibilité de redimensionnement. | L'instance elle-même, exactement comme un serveur virtuel classique. |
Autrement dit, ni le cloud ni la virtualisation ne réduisent votre part du travail : ils déplacent seulement la frontière du matériel. La comparaison entre serveur dédié et VPS détaille cet arbitrage côté performances.
Choisir son système, et ne pas le laisser dériver
La distribution installée conditionne le rythme des correctifs. Les distributions à support long comme Debian ou les dérivées d'entreprise privilégient la stabilité et des mises à jour de sécurité prolongées ; d'autres livrent des versions plus récentes au prix de montées de version plus fréquentes. Aucune n'est meilleure dans l'absolu, mais une distribution arrivée en fin de support ne reçoit plus de correctifs, ce qui annule l'essentiel des réglages décrits ici.
Le même raisonnement vaut pour ce qui tourne au-dessus : un panneau de contrôle comme Plesk gère ses propres mises à jour, distinctes de celles du système. Vérifiez les deux.
Surveiller la machine, pas seulement la protéger
Une part des incidents attribués à la sécurité sont en réalité des saturations. Un espace de stockage plein empêche l'écriture des journaux et des sauvegardes, une RAM épuisée fait tuer des processus au hasard, une bande passante saturée ressemble à s'y méprendre à une attaque.
Un monitoring minimal couvre quatre indicateurs : charge CPU, occupation RAM, remplissage du SSD, et bande passante consommée. Ajoutez-y une alerte sur les échecs d'authentification répétés et vous couvrez l'essentiel de ce qui se voit venir.
Mise en service : DNS et nom de domaine
Une fois la machine durcie, reste à l'exposer proprement. Faire pointer un nom de domaine vers l'adresse IP du serveur passe par les enregistrements DNS du domaine. Le certificat TLS se demande ensuite, une fois la résolution effective.
Deux précautions : vérifiez que la résolution est bien propagée avant de demander le certificat, et évitez de laisser des sous-domaines pointer vers d'anciennes adresses IP qui ne vous appartiennent plus.
Mettre en place les sauvegardes avant d'en avoir besoin
Une machine sécurisée peut quand même perdre un disque, subir une erreur de manipulation ou un effacement accidentel. Les sauvegardes ne relèvent pas de la sécurité au sens strict, mais elles constituent le seul filet réellement fiable, et le premier jour est le bon moment pour les poser.
Le point à vérifier tout de suite : une sauvegarde stockée sur le même espace disque que les données d'origine ne protège de presque rien. Le sujet mérite d'être traité pour lui-même, et c'est l'objet de notre guide sur les sauvegardes et la haute disponibilité sur un serveur dédié.
La checklist du premier jour
- Connexion SSH par clé validée, authentification par mot de passe désactivée.
- Connexion root directe refusée, compte administrateur dédié créé.
- Firewall actif, en refus par défaut, avec la liste des ports réellement nécessaires.
- MySQL et les services internes en écoute locale uniquement.
- FTP en clair remplacé par SFTP.
- Mises à jour système appliquées, mises à jour de sécurité automatisées.
- Ports en écoute listés et confrontés à ce qui est censé être ouvert.
- Première sauvegarde effectuée hors de la machine, et restauration testée.
Si vous n'avez pas encore choisi votre machine, la checklist à vérifier avant de louer un serveur dédié couvre le matériel, le réseau et le SLA. Et si l'arbitrage entre ressources dédiées et ressources virtualisées reste ouvert, la comparaison entre serveur dédié et VPS pose les critères. Nos serveurs dédiés comme nos VPS Linux sont livrés avec un accès root complet, à vous de décider ce que la machine expose.