Avant de commencer
Relevez les endpoints annoncés aux clients, les allocations TCP et UDP, les destinations de fichiers et les accès d’administration. Identifiez l’origine et les éventuels proxies. Conservez les versions des artifacts et des ressources, une sauvegarde des fichiers et une copie cohérente de la base de données. Préparez une fenêtre de maintenance et un accès de secours avant toute restriction de l’origine.
Cartographier les flux de votre installation
Partez de la configuration réelle et des ports attribués par le panel. Distinguez le port de jeu, txAdmin, les services de fichiers et les éventuels services externes. Notez les protocoles et les destinations au lieu de recopier une liste de ports habituels. Une allocation personnalisée reste la référence pour votre instance.
Vérifiez également les adresses de votre domaine, les anciennes adresses publiques et les endpoints annoncés par FXServer. Un service secondaire peut exposer l’origine même lorsque le lien principal passe par un proxy. Cette liste devient la base du périmètre à faire confirmer par le fournisseur.
Associer le proxy HTTP et la protection du jeu
Le reverse proxy HTTP de connexion et les téléchargements ont un rôle distinct du transport du jeu. La documentation Cfx distingue ces chemins ; un proxy web accessible ne certifie pas une protection du trafic UDP. Faites préciser ce qui est filtré, ce qui est relayé et les services qui restent directs.
Si vous utilisez un cache de fichiers, contrôlez ses destinations et les conditions d’accès. Les paramètres relatifs aux proxies et aux fichiers dépendent de la version de FXServer. Une option trouvée dans une documentation récente peut être absente d’un artifact plus ancien : vérifiez sa disponibilité avant de modifier la configuration.
Restreindre l’origine avec un retour arrière
Une origine directement accessible peut laisser un chemin de contournement. Avant de la restreindre, validez les sources légitimes, les routes de retour et les protocoles de chaque service. Prévoyez les téléchargements, la voix et la supervision. Testez une connexion complète avec une configuration de secours disponible.
Conservez des listes de confiance précises et documentées. Une autorisation globale ou une adresse de proxy incorrecte peut annuler le bénéfice attendu ; une interdiction mal placée peut bloquer les joueurs. La rotation d’une IP ou d’un port ne remplace pas la protection de l’origine et ne doit pas être annoncée comme automatique sans mécanisme effectivement livré.
Sécuriser txAdmin et les accès sensibles
Utilisez des comptes d’administration individuels, des secrets forts et les permissions nécessaires au rôle de chacun. Révoquez les anciens accès et évitez de partager un compte principal. Les sauvegardes, les fichiers de configuration et les journaux peuvent contenir des identifiants : leur protection fait partie de celle du serveur.
Ne rendez pas une base de données ou un outil d’administration publiquement accessible sans besoin identifié et contrôle adapté. Le panel d’hébergement et txAdmin sont des environnements différents ; une protection de l’un ne garantit pas la sécurité de l’autre. Maintenez les logiciels et contrôlez les accès après chaque changement d’équipe.
Contrôler les événements et les scripts côté serveur
Le filtrage réseau ne corrige pas un événement de jeu qui fait confiance à une valeur envoyée par le client. Les ressources doivent vérifier côté serveur les permissions, les états attendus et les valeurs utiles avant de réaliser une action sensible. Évitez les calculs ou écritures coûteux déclenchables sans contrôle.
Surveillez les erreurs répétées et les opérations qui deviennent coûteuses sous charge. Testez les changements sur une copie, conservez les versions précédentes et traitez les dépendances. Les frameworks et ressources ont leurs propres obligations de maintenance ; installer une protection ne rend pas automatiquement tous les scripts sûrs.
Préparer la validation et le traitement d’un incident
Après une modification, testez une connexion normale, le téléchargement des ressources, l’entrée dans le jeu et les fonctions essentielles depuis plusieurs réseaux représentatifs. Comparez les journaux et les mesures aux horaires correspondants. Fixez à l’avance le moyen de revenir à une configuration fonctionnelle.
En cas d’incident, conservez l’heure, les réseaux touchés, les messages et les événements de mitigation disponibles. Distinguez une saturation, un faux positif, un problème de ressource et une erreur d’administration. Coordonnez les tests actifs avec le fournisseur ; n’envoyez pas de trafic de charge improvisé vers un service de production.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Hébergement FiveM géré | Utiliser les ports et outils effectivement fournis par le panel. Faire préciser les protocoles protégés et garder vos ressources et accès à jour. |
| Protection FiveM distante | Valider les chemins HTTP et UDP, les fichiers, la voix et les restrictions de l’origine. Confirmer les prérequis du proxy ou du tunnel. |
| Scripts ou événements coûteux | Corriger les contrôles côté serveur et mesurer les opérations concernées. Une protection réseau ne remplace pas la validation des actions de jeu. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.