Avant de commencer
Dressez la liste des adresses publiques, des ports et des protocoles utilisés : jeu, site, fichiers, voix et administration. Notez où se trouvent l’origine, les proxies et les bases de données. Précisez les services qui doivent rester accessibles et les accès réservés. Conservez une configuration réseau connue et un moyen de retour arrière avant de changer un routage ou des restrictions.
Comprendre les trois niveaux sans simplifier à l’excès
La couche réseau L3 concerne notamment l’acheminement IP. La couche transport L4 concerne des protocoles comme TCP et UDP et leurs échanges. Le traitement L7 s’appuie sur le fonctionnement d’une application ou d’un protocole applicatif. Ces niveaux peuvent se combiner dans une architecture de protection.
Une attaque peut chercher à remplir un lien, à épuiser des états de connexion ou à consommer le travail de l’application. Plusieurs effets peuvent se produire ensemble. Il faut identifier la ressource menacée et les flux concernés avant de choisir entre filtrage en amont, contrôle de connexion ou règles applicatives.
Lire les capacités et les limites annoncées
La capacité globale d’un opérateur ou d’un ensemble de points de mitigation n’est pas le débit réservé à un serveur. Demandez ce que mesure le chiffre : volume agrégé, capacité d’un site, débit du port ou limite contractuelle. Les unités de débit, de paquets et de requêtes décrivent des contraintes différentes.
Vérifiez également le trafic propre autorisé, les protocoles couverts, les adresses protégées et les conditions d’intervention. Une protection peut avoir des limites de couverture ou des mesures de confinement. Une promesse « sans limites » ne remplace pas une description des conditions techniques et du contrat.
Vérifier ce que L7 signifie pour votre jeu
Une protection HTTP vise des échanges HTTP. Elle ne remplace pas automatiquement la protection du protocole d’un serveur Minecraft, du trafic UDP d’un jeu ou d’un service vocal. Pour chaque application, demandez quel composant est analysé, quelles connexions sont terminées par un proxy et quels flux restent transportés directement.
FiveM illustre cette distinction : l’entrée HTTP, les téléchargements et le trafic de jeu demandent une architecture cohérente. Un site web protégé peut rester accessible alors que le jeu échoue. Une capacité L7 doit être définie par son périmètre réel plutôt que présentée comme une protection de toutes les applications.
Éviter les chemins qui contournent la protection
Une protection distante est utile seulement si les flux concernés passent par elle. Inventoriez les anciennes adresses, les DNS, les services secondaires et les endpoints annoncés par l’application. Si une origine reste directement joignable, un trafic peut éviter le point d’entrée protégé.
Restreindre l’origine exige de connaître les sources et services légitimes. Faites valider les routes, les retours, la voix, les fichiers et l’administration avant de filtrer. Une liste d’autorisation trop large expose l’origine ; une liste trop étroite peut provoquer une panne. Ne copiez pas une règle générique sans connaître votre architecture.
Évaluer la stabilité pendant et après un incident
Comparez les mesures avant, pendant et après l’incident : latence jusqu’au service, pertes observées, connexions réussies et temps de réponse applicatif. Une mesure ICMP ou un test TCP sur le site ne valide pas à lui seul le protocole du jeu. Privilégiez les connexions normales depuis les réseaux de vos utilisateurs.
Demandez des événements horodatés et une explication du filtrage quand une connexion légitime échoue. Les faux positifs, les détours de route et la charge de l’application doivent être distingués. Un test de charge non coordonné peut lui-même dégrader le service ; organisez toute validation active avec le fournisseur et une limite précise.
Choisir à partir d’un périmètre documenté
Préparez un cahier des charges court : services, protocoles, adresses, localisation de l’origine, trafic normal et contraintes de maintenance. Faites préciser l’installation, les responsabilités, les statistiques accessibles et les étapes d’escalade. Pour une protection distante, ajoutez les exigences de tunnel, de proxy ou de routage.
Comparez ensuite les offres disponibles et le prix correspondant au périmètre demandé. Le choix doit associer la capacité réseau, le traitement adapté à l’application et la possibilité de diagnostiquer un incident. Aucun système ne dispense de maintenir les logiciels, les comptes et les sauvegardes de votre serveur.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Lien ou paquets saturés | Étudier le filtrage en amont et les limites de trafic. Faire confirmer la couverture de l’adresse et du protocole touchés. |
| Application épuisée | Identifier les requêtes et les opérations coûteuses. Demander une protection adaptée au protocole, puis corriger les faiblesses de l’application. |
| Protection distante | Vérifier le trajet du trafic, les retours et l’exposition de l’origine. Documenter les services secondaires avant toute restriction. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.