Protéger son serveur : sauvegardes, griefs et comptes pirates

Un serveur meurt rarement d'un manque de joueurs. Il meurt d'un monde perdu, d'un grief irréparable, ou d'un administrateur improvisé qui a donné l'opérateur à la mauvaise personne. Les quatre parades qui suivent coûtent une soirée à mettre en place et vous épargneront la seule erreur dont on ne revient pas.

1. Les sauvegardes, et leur restauration

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde : c'est une intention.

La règle des trois exemplaires tient en une ligne : trois copies, deux supports différents, une hors du serveur. Une copie sur la même machine ne protège de rien, ni de la panne de disque, ni de la commande malheureuse, ni du compte compromis.

En pratique :

• Une sauvegarde automatique quotidienne du dossier du monde et du dossier plugins. Les configurations perdues coûtent autant de temps que le monde perdu.
• Une copie envoyée ailleurs chaque nuit : autre machine, espace de stockage distant, peu importe, mais ailleurs.
• Une restauration d'essai tous les trois mois. Montez la sauvegarde sur un serveur de test et connectez-vous. C'est le seul moyen de savoir qu'elle fonctionne.

Et sauvegardez avant chaque mise à jour, sans exception.

Une panne passée inaperçue la nuit coûte des joueurs : une fois le serveur référencé sur CubeVote, activez l'alerte hors ligne dans votre tableau de bord pour être prévenu par Discord et par e-mail dès qu'il cesse de répondre.

2. Le journal des blocs

CoreProtect enregistre qui a posé et cassé quoi, où et quand. Il permet d'annuler un grief en une commande : /co rollback u:pseudo t:2h r:50.

Sans lui, un grief se répare à la main ou pas du tout, et « pas du tout » signifie souvent la fin du serveur, parce que les joueurs lésés partent.

Installez-le le premier jour, avant d'ouvrir. Il ne journalise que ce qui se passe après son installation : posé après coup, il ne sert à rien pour ce qui vient d'arriver.

Pour les zones à protéger absolument (spawn, boutiques, arènes) WorldGuard empêche le grief plutôt que de le réparer. Les deux sont complémentaires : l'un prévient, l'autre rattrape.

3. Les permissions minimales

Le principe tient en une phrase : chacun reçoit ce dont il a besoin, rien de plus.

• L'opérateur, c'est vous et personne d'autre. op contourne toutes les permissions, y compris celles que vous croyez avoir retirées, et donne accès à des commandes qui peuvent effacer un monde.
• Les modérateurs reçoivent un groupe LuckPerms avec les commandes de modération, et rien qui touche au monde ni aux plugins.
• Les commandes dangereuses : /stop, /op, /ban-ip, les commandes de WorldEdit à grand rayon, restent hors des groupes intermédiaires.

Un modérateur qui a besoin d'une commande de plus la demandera. Un modérateur à qui on a tout donné « pour simplifier » finira par faire une bêtise, et vous ne saurez pas laquelle.

4. La console et les ports

La console de votre serveur est un accès complet à la machine. Traitez-la comme tel.

• Fermez RCON si vous ne l'utilisez pas (enable-rcon=false). S'il vous sert, changez le mot de passe par défaut et n'exposez jamais son port sur Internet.
• N'exposez que 25565. Tout le reste (base de données, panneau d'administration, RCON) passe par un réseau privé ou un tunnel.
• Mettez à jour. La faille Log4Shell de fin 2021 a touché des dizaines de milliers de serveurs Minecraft précisément parce qu'ils tournaient sur des versions anciennes. Une version en retard d'un an est une version vulnérable.

Le cas des comptes non authentifiés

Un serveur en mode online-mode=false accepte les clients qui ne se sont pas authentifiés auprès de Mojang. C'est un choix légitime (il ouvre le serveur à des joueurs qui ne peuvent pas acheter le jeu) mais il a une conséquence qu'il faut regarder en face : n'importe qui peut se connecter sous n'importe quel pseudo, y compris le vôtre.

Si vous faites ce choix, AuthMe ou un équivalent n'est pas optionnel : sans plugin d'authentification, le premier venu se connecte sous le pseudo de votre administrateur et obtient ses droits. Même chose pour une whitelist : en mode non authentifié, elle ne vérifie qu'un pseudo.

Et pensez à l'annoncer clairement sur votre fiche : les joueurs qui cherchent un serveur en comptes non authentifiés le cherchent explicitement, et ceux qui ne le veulent pas préfèrent le savoir avant.

Les attaques par saturation

Un serveur qui grandit finit par attirer une attaque. Deux mesures suffisent au début :

• Ne publiez pas l'adresse IP réelle de la machine. Annoncez un nom de domaine, et faites-le pointer vers un filtre ou un proxy. Une IP publiée ne se dépublie pas.
• Choisissez un hébergeur qui annonce une protection anti-DDoS. Elle est désormais courante, y compris sur les offres à dix euros.

La checklist du premier jour

• CoreProtect installé avant l'ouverture
• Sauvegarde automatique quotidienne, avec une copie hors machine
• Une restauration d'essai réussie
• LuckPerms, groupes définis, op réservé à vous
• WorldGuard sur le spawn
• RCON fermé ou protégé
• Serveur et plugins à jour
• Un plugin d'authentification si online-mode=false

Huit lignes, une soirée. C'est la différence entre un incident et une fermeture.

---

Un serveur bien tenu se voit : disponibilité régulière, pas de coupure inexpliquée. Référencez le vôtre, la page de statut publie sa disponibilité mesurée, et c'est un argument.