Aller au contenu

Wiki

Révision #857

Enregistrée le 15 août 2026 à 8:22

Auteur: vyrriox Type: Création « Réglages vérifiés sur la documentation Minecraft et sur le guide d'installation livré avec le pack »
Cette révision #857

Sécuriser son serveur

Un serveur Minecraft ouvert sur internet, c'est une porte publique. La bonne nouvelle, c'est que la sécurité d'un serveur privé tient en trois questions simples: qui peut entrer, qui peut donner des ordres, et que peux tu restaurer si ça tourne mal. Cette page répond aux trois, avec les réglages exacts et leurs valeurs par défaut.

La ligne à ne jamais franchir

online-mode doit rester sur true
Ce réglage de server.properties vérifie chaque connexion auprès des serveurs de comptes Minecraft. Sa valeur par défaut est true, et elle doit le rester. Passé à false, n'importe qui peut se connecter avec n'importe quel pseudo, y compris le tien. Un inconnu se nomme comme toi, entre, et récupère tes droits d'administrateur. Il n'existe aucune parade côté serveur une fois ce réglage désactivé.

La seule raison de le passer à false est d'accepter les comptes non officiels, et ce choix rend l'usurpation triviale. Si tu y tiens malgré tout, il faut alors un plugin d'authentification par mot de passe, ce que le pack ne fournit pas.

Deux réglages voisins méritent un coup d'œil.

RéglagePar défautÀ quoi il sert
enforce-secure-profiletrueN'accepte que les joueurs dont le profil est signé par Mojang
prevent-proxy-connectionsfalseRefuse les connexions dont le fournisseur d'accès ne correspond pas au serveur d'authentification

Le second bloque une partie des connexions passant par un proxy, mais il gêne aussi des joueurs légitimes sous VPN. À n'activer que si tu as un vrai problème d'intrusion.

La liste blanche, ta meilleure amie

Pour un serveur entre amis, c'est la protection la plus efficace et la plus simple: personne n'entre s'il n'est pas sur la liste.

  1. 1
    Dans server.properties, mets white-list=true. La valeur par défaut est false.
  2. 2
    Ajoute tes joueurs depuis la console: whitelist add Pseudo, puis whitelist reload.
  3. 3
    Mets aussi enforce-whitelist=true, par défaut à false. Sans lui, un joueur retiré de la liste reste connecté jusqu'à ce qu'il parte de lui même.
whitelist off ne vide pas la liste, il la met juste en pause. C'est pratique pour ouvrir ton serveur le temps d'une soirée sans tout retaper ensuite.

Les niveaux d'opérateur

Donner l'op à quelqu'un, ce n'est pas un simple badge: c'est un niveau de pouvoir, de 1 à 4. Le réglage op-permission-level décide du niveau attribué par la commande /op, et sa valeur par défaut est 4, c'est à dire le maximum.

NiveauCe qu'il ouvre
1Ignorer la protection du spawn
2Les blocs de commande et une bonne partie des commandes de jeu
3La gestion des joueurs: bannir, expulser, donner l'op
4Tout, y compris l'arrêt du serveur
Un modérateur n'a pas besoin du niveau 4
Baisse op-permission-level à 3 avant de donner l'op à quelqu'un qui doit seulement modérer. Tu peux aussi éditer directement le niveau de chaque joueur dans ops.json, serveur arrêté. Et garde en tête que function-permission-level, par défaut à 2, décide de ce que les fonctions et les datapacks ont le droit de faire.

Pour une gestion plus fine que le simple op, avec des grades et des permissions par commande, la marche à suivre est sur Administrer son serveur.

RCON et query, à laisser fermés

Ce sont les deux portes qu'on oublie. Toutes les deux sont désactivées par défaut, et il n'y a aucune raison de les ouvrir sur un serveur entre amis.

ServicePar défautCe qu'il expose
enable-rconfalse, port 25575Un accès complet à la console du serveur, à distance
enable-queryfalse, port 25565 en UDPLes informations du serveur: version, joueurs connectés, carte
Un RCON ouvert, c'est la console entière dans les mains d'un inconnu
Le mot de passe RCON est vide par défaut et circule en clair sur le réseau. Activer RCON sans mot de passe, ou avec un mot de passe faible, revient à donner la commande op à qui sait taper une adresse IP. Si tu as vraiment besoin d'un accès distant, passe par SSH avec une clé, et laisse le serveur dans un screen ou un tmux comme expliqué sur Lancer et configurer son serveur.

Un dernier détail utile: broadcast-console-to-ops et broadcast-rcon-to-ops sont à true par défaut. Les opérateurs connectés voient donc passer les commandes lancées depuis la console. C'est une bonne chose, ça rend les abus visibles.

Un seul port ouvert

Côté réseau, la règle tient en une phrase: ouvre le port 25565 en TCP, et rien d'autre. C'est le seul dont les joueurs ont besoin.

  • Si tu héberges chez toi, n'ouvre pas la redirection de ports au delà de 25565, et surtout pas celle de ta box ou de ton NAS.
  • Si tu loues une machine, laisse le pare-feu bloquer tout le reste. Le panneau d'administration et SSH ne doivent pas être accessibles depuis n'importe où.
  • Le port 25575 de RCON ne doit jamais être joignable depuis internet, même avec un mot de passe.

Changer le port de jeu ne protège de rien de sérieux, les robots scannent toute la plage. En revanche, un port différent réduit un peu le bruit dans les journaux.

Les sauvegardes, la seule vraie assurance

Aucune des protections précédentes ne répare un monde détruit. La sauvegarde, si.

  1. 1
    Arrête le serveur avec la commande stop avant de copier quoi que ce soit. Copier un monde en cours d'écriture donne une sauvegarde corrompue.
  2. 2
    Copie le dossier du monde en entier, plus ops.json, whitelist.json, les listes de bannis et server.properties.
  3. 3
    Garde plusieurs générations et au moins une copie ailleurs que sur la machine du serveur. Un disque qui lâche emporte les sauvegardes posées à côté.

La routine complète, avec la fréquence conseillée, est sur Maintenir son serveur. Et si le monde refuse de charger, Réparer un monde corrompu détaille la marche à suivre.

Ce qui change avec un pack moddé

Un pack de plus de quatre cents mods, c'est aussi quatre cents sources possibles de problème. Trois catégories reviennent tout le temps.

RisqueCe qu'on fait
Objets qui donnent trop de pouvoirOn retire la recette et on surveille les inventaires, comme sur Les objets bannis
Duplication d'objetsOn corrige la recette fautive avec KubeJS plutôt que d'attendre la mise à jour du mod
Blocs qui ignorent les protectionsOn ajoute une vérification maison, comme pour les protections décrites sur Protéger son terrain

C'est exactement la démarche suivie sur Arcadia, et elle vaut pour n'importe quel serveur privé: tenir le pack à jour, lire les notes de version, et corriger soi même ce qui traîne. La procédure de montée de version est sur Mettre à jour son serveur.

Une protection de terrain n'est pas un gadget de confort, c'est ta première barrière anti-casse. Sur un serveur entre amis, active la dès le premier jour plutôt qu'après le premier incident.

Si le mal est fait

  1. 1
    Arrête le serveur proprement. Tant qu'il tourne, les dégâts continuent et la sauvegarde automatique écrase du bon état.
  2. 2
    Mets la sauvegarde de côté avant toute manipulation, même si elle te semble déjà abîmée.
  3. 3
    Lis les journaux du dossier logs: ils datent les connexions et les commandes. La lecture est expliquée sur Dépanner son serveur.
  4. 4
    Retire l'op à tout le monde avec deop, remets la liste blanche, puis change le mot de passe de ton hébergement.
  5. 5
    Restaure la dernière sauvegarde saine, et repars de là plutôt que de réparer bloc par bloc.

Sur Arcadia même, tu n'as rien de tout ça à gérer: un comportement suspect se signale au staff, comme expliqué sur Signaler un joueur.

Où continuer

Pour l'installation de zéro, va voir Installer son serveur, puis Lancer et configurer son serveur pour le reste des réglages. Les performances sont traitées sur Optimiser son serveur et Arguments JVM et RAM, et l'ouverture aux copains sur Jouer entre amis.

Version actuelle

Sécuriser son serveur

Un serveur Minecraft ouvert sur internet, c'est une porte publique. La bonne nouvelle, c'est que la sécurité d'un serveur privé tient en trois questions simples: qui peut entrer, qui peut donner des ordres, et que peux tu restaurer si ça tourne mal. Cette page répond aux trois, avec les réglages exacts et leurs valeurs par défaut.

La ligne à ne jamais franchir

online-mode doit rester sur true
Ce réglage de server.properties vérifie chaque connexion auprès des serveurs de comptes Minecraft. Sa valeur par défaut est true, et elle doit le rester. Passé à false, n'importe qui peut se connecter avec n'importe quel pseudo, y compris le tien. Un inconnu se nomme comme toi, entre, et récupère tes droits d'administrateur. Il n'existe aucune parade côté serveur une fois ce réglage désactivé.

La seule raison de le passer à false est d'accepter les comptes non officiels, et ce choix rend l'usurpation triviale. Si tu y tiens malgré tout, il faut alors un plugin d'authentification par mot de passe, ce que le pack ne fournit pas.

Deux réglages voisins méritent un coup d'œil.

RéglagePar défautÀ quoi il sert
enforce-secure-profiletrueN'accepte que les joueurs dont le profil est signé par Mojang
prevent-proxy-connectionsfalseRefuse les connexions dont le fournisseur d'accès ne correspond pas au serveur d'authentification

Le second bloque une partie des connexions passant par un proxy, mais il gêne aussi des joueurs légitimes sous VPN. À n'activer que si tu as un vrai problème d'intrusion.

La liste blanche, ta meilleure amie

Pour un serveur entre amis, c'est la protection la plus efficace et la plus simple: personne n'entre s'il n'est pas sur la liste.

  1. 1
    Dans server.properties, mets white-list=true. La valeur par défaut est false.
  2. 2
    Ajoute tes joueurs depuis la console: whitelist add Pseudo, puis whitelist reload.
  3. 3
    Mets aussi enforce-whitelist=true, par défaut à false. Sans lui, un joueur retiré de la liste reste connecté jusqu'à ce qu'il parte de lui même.
whitelist off ne vide pas la liste, il la met juste en pause. C'est pratique pour ouvrir ton serveur le temps d'une soirée sans tout retaper ensuite.

Les niveaux d'opérateur

Donner l'op à quelqu'un, ce n'est pas un simple badge: c'est un niveau de pouvoir, de 1 à 4. Le réglage op-permission-level décide du niveau attribué par la commande /op, et sa valeur par défaut est 4, c'est à dire le maximum.

NiveauCe qu'il ouvre
1Ignorer la protection du spawn
2Les blocs de commande et une bonne partie des commandes de jeu
3La gestion des joueurs: bannir, expulser, donner l'op
4Tout, y compris l'arrêt du serveur
Un modérateur n'a pas besoin du niveau 4
Baisse op-permission-level à 3 avant de donner l'op à quelqu'un qui doit seulement modérer. Tu peux aussi éditer directement le niveau de chaque joueur dans ops.json, serveur arrêté. Et garde en tête que function-permission-level, par défaut à 2, décide de ce que les fonctions et les datapacks ont le droit de faire.

Pour une gestion plus fine que le simple op, avec des grades et des permissions par commande, la marche à suivre est sur Administrer son serveur.

RCON et query, à laisser fermés

Ce sont les deux portes qu'on oublie. Toutes les deux sont désactivées par défaut, et il n'y a aucune raison de les ouvrir sur un serveur entre amis.

ServicePar défautCe qu'il expose
enable-rconfalse, port 25575Un accès complet à la console du serveur, à distance
enable-queryfalse, port 25565 en UDPLes informations du serveur: version, joueurs connectés, carte
Un RCON ouvert, c'est la console entière dans les mains d'un inconnu
Le mot de passe RCON est vide par défaut et circule en clair sur le réseau. Activer RCON sans mot de passe, ou avec un mot de passe faible, revient à donner la commande op à qui sait taper une adresse IP. Si tu as vraiment besoin d'un accès distant, passe par SSH avec une clé, et laisse le serveur dans un screen ou un tmux comme expliqué sur Lancer et configurer son serveur.

Un dernier détail utile: broadcast-console-to-ops et broadcast-rcon-to-ops sont à true par défaut. Les opérateurs connectés voient donc passer les commandes lancées depuis la console. C'est une bonne chose, ça rend les abus visibles.

Un seul port ouvert

Côté réseau, la règle tient en une phrase: ouvre le port 25565 en TCP, et rien d'autre. C'est le seul dont les joueurs ont besoin.

  • Si tu héberges chez toi, n'ouvre pas la redirection de ports au delà de 25565, et surtout pas celle de ta box ou de ton NAS.
  • Si tu loues une machine, laisse le pare-feu bloquer tout le reste. Le panneau d'administration et SSH ne doivent pas être accessibles depuis n'importe où.
  • Le port 25575 de RCON ne doit jamais être joignable depuis internet, même avec un mot de passe.

Changer le port de jeu ne protège de rien de sérieux, les robots scannent toute la plage. En revanche, un port différent réduit un peu le bruit dans les journaux.

Les sauvegardes, la seule vraie assurance

Aucune des protections précédentes ne répare un monde détruit. La sauvegarde, si.

  1. 1
    Arrête le serveur avec la commande stop avant de copier quoi que ce soit. Copier un monde en cours d'écriture donne une sauvegarde corrompue.
  2. 2
    Copie le dossier du monde en entier, plus ops.json, whitelist.json, les listes de bannis et server.properties.
  3. 3
    Garde plusieurs générations et au moins une copie ailleurs que sur la machine du serveur. Un disque qui lâche emporte les sauvegardes posées à côté.

La routine complète, avec la fréquence conseillée, est sur Maintenir son serveur. Et si le monde refuse de charger, Réparer un monde corrompu détaille la marche à suivre.

Ce qui change avec un pack moddé

Un pack de plus de quatre cents mods, c'est aussi quatre cents sources possibles de problème. Trois catégories reviennent tout le temps.

RisqueCe qu'on fait
Objets qui donnent trop de pouvoirOn retire la recette et on surveille les inventaires, comme sur Les objets bannis
Duplication d'objetsOn corrige la recette fautive avec KubeJS plutôt que d'attendre la mise à jour du mod
Blocs qui ignorent les protectionsOn ajoute une vérification maison, comme pour les protections décrites sur Protéger son terrain

C'est exactement la démarche suivie sur Arcadia, et elle vaut pour n'importe quel serveur privé: tenir le pack à jour, lire les notes de version, et corriger soi même ce qui traîne. La procédure de montée de version est sur Mettre à jour son serveur.

Une protection de terrain n'est pas un gadget de confort, c'est ta première barrière anti-casse. Sur un serveur entre amis, active la dès le premier jour plutôt qu'après le premier incident.

Si le mal est fait

  1. 1
    Arrête le serveur proprement. Tant qu'il tourne, les dégâts continuent et la sauvegarde automatique écrase du bon état.
  2. 2
    Mets la sauvegarde de côté avant toute manipulation, même si elle te semble déjà abîmée.
  3. 3
    Lis les journaux du dossier logs: ils datent les connexions et les commandes. La lecture est expliquée sur Dépanner son serveur.
  4. 4
    Retire l'op à tout le monde avec deop, remets la liste blanche, puis change le mot de passe de ton hébergement.
  5. 5
    Restaure la dernière sauvegarde saine, et repars de là plutôt que de réparer bloc par bloc.

Sur Arcadia même, tu n'as rien de tout ça à gérer: un comportement suspect se signale au staff, comme expliqué sur Signaler un joueur.

Où continuer

Pour l'installation de zéro, va voir Installer son serveur, puis Lancer et configurer son serveur pour le reste des réglages. Les performances sont traitées sur Optimiser son serveur et Arguments JVM et RAM, et l'ouverture aux copains sur Jouer entre amis.