Comment préparer la protection DDoS et la réponse aux incidents de FiveM

Protégez la connexion TCP et UDP FiveM réelle en amont avec votre hébergeur ou fournisseur de réseau. Un pare-feu local aide à contrôler l'exposition, mais il ne peut pas restaurer un lien déjà saturé par le trafic.

Cartographier les chemins de connexion

Enregistrez le point de terminaison de connexion HTTP, le point de terminaison de jeu, l'origine publique et l'accès de gestion. Incluez les anciennes adresses qui atteignent toujours le serveur. La documentation officielle du proxy distingue les chemins de trafic de connexion et de jeu.

Demandez au fournisseur quels protocoles et ports sa protection couvre, comment il détecte les incidents, quelles limites de fonctionnement s’appliquent et comment solliciter une intervention supplémentaire. Une protection limitée au site web ne prouve pas que le point de connexion du jeu est couvert.

Restreindre l'exposition sans vous bloquer

1. Sauvegardez la configuration actuelle du pare-feu et du réseau. Conservez un chemin de récupération de gestion indépendant avant de modifier les règles d'accès.
2. Exposez uniquement les ports de jeu que vous utilisez ; restreignez les services SSH, RDP, de base de données et d'administration aux chemins d'accès autorisés. Testez à partir d'un client de gestion autorisé.
3. Si vous utilisez un proxy de jeu pris en charge, acheminez chaque chemin de connexion public via celui-ci et restreignez l'origine au réseau de mitigation requis et aux sources de gestion. Vérifiez les plages d'adresses et les vérifications de santé du fournisseur.
4. Testez une connexion client réelle et une connexion administrateur avant de fermer la fenêtre de maintenance. Restaurez immédiatement les règles sauvegardées si le trafic requis échoue.

Préparer un plan d'intervention

Relevez le débit normal de paquets, la bande passante, les échecs de connexion et l’état de FXServer. Définissez des seuils d’alerte exploitables à partir de ces valeurs de référence. Gardez à disposition la procédure d’escalade du fournisseur, l’identifiant du service et un canal indépendant pour informer les joueurs de son état.

Pendant un incident, relevez les heures UTC, les points de connexion touchés, les mesures de trafic et les identifiants d’incident du fournisseur. Ne partagez pas publiquement d’identifiants de joueurs, de secrets ou de captures de paquets non filtrées. Distinguez un plantage de ressource d’une saturation du réseau avant de modifier les ressources.

Récupérer et apprendre

Confirmez que les clients légitimes peuvent se connecter et que les services de jeu et de gestion sont sains avant de déclarer la récupération. Vérifiez si le trafic a atteint un ancien chemin d'origine et si la mitigation du fournisseur a couvert le protocole réel.

Conservez des sauvegardes restaurables pour la récupération des données, mais ne présentez pas les sauvegardes comme une mitigation DDoS. Aucune configuration ne peut promettre un service ininterrompu.

Documentation de référence

Source : developers.cloudflare.com