L'essentiel
Entre le 31 juillet et le 28 octobre 2026, nos systèmes ont enregistré 37 enregistrements d'attaque réseau (couche 4) sur 11 serveurs derrière FIVESHIELD, plus 25 épisodes d'attaque web (HTTP). La plupart étaient courtes : 34 des 37 enregistrements réseau se sont terminés en moins de 30 minutes. Quelques-unes étaient massives : le pic le plus haut a atteint 7,26 millions de paquets par seconde.
Ce sont les enregistrements d'un seul prestataire, pas une enquête sur tout FiveM. Lisez la section « Ce que ces données ne disent pas » plus bas avant de citer un chiffre : un même flood peut produire plusieurs enregistrements, donc 37 enregistrements, c'est plus que 37 floods distincts, et nous ne pouvons pas vous donner un décompte dédoublonné.
Les chiffres
| Mesure | Valeur |
|---|---|
| Période | du 31 juillet au 28 octobre 2026 (90 jours, jours calendaires de Toronto) |
| Serveurs avec au moins une attaque enregistrée, couche réseau ou web | 15 |
| Enregistrements d'attaque réseau | 37, sur 11 serveurs |
| Enregistrements réseau sur les 30 derniers jours (du 29 septembre au 28 octobre) | 12 |
| Épisodes d'attaque web | 25 |
| Durée médiane d'un enregistrement réseau | environ 14 minutes |
| Durée au 95e centile | environ 59 minutes |
| Enregistrement réseau le plus long | 3 heures 26 minutes |
| Pic de trafic bloqué le plus élevé sur un enregistrement | 7 260 430 paquets par seconde |
| Débit de requêtes le plus élevé dans une notification web | 40 320 requêtes par seconde |
Le pic est un débit de paquets. Nous ne l'avons pas converti en gigabits par seconde, car cela suppose une taille de paquet que nos enregistrements ne contiennent pas.
Combien de temps elles ont duré
| Durée d'un enregistrement réseau | Enregistrements |
|---|---|
| Moins de 5 minutes | 9 |
| De 5 à 30 minutes | 25 |
| De 30 minutes à 2 heures | 2 |
| Plus de 2 heures | 1 |
Cela fait 34 sur 37 (92 %) sous la demi-heure. La moitié se sont terminées en moins de 14 minutes. Lecture pratique : le temps qu'une personne remarque que son serveur est tombé, ouvre un tableau de bord et active une protection, une attaque typique de ces données est déjà presque terminée. L'unique enregistrement au-delà de trois heures rappelle que la queue de distribution existe.
Un enregistrement se ferme après environ une minute de calme : chaque durée inclut cette minute.
De quoi il s'agissait
Chaque étiquette sur chaque enregistrement désignait un simple flood de la couche transport. Aucune ne nommait un vecteur de réflexion ou d'amplification.
| Famille d'étiquette | Nombre d'occurrences |
|---|---|
Flood SYN (TCP/SYN flood, TCP_SYN) | 21 |
Flood UDP (UDP flood, UDP) | 21 |
Flood réseau générique (L4 flood) | 6 |
| Flood TCP | 6 |
Ces comptes se recoupent et ne s'additionnent pas à 37. Ils totalisent les étiquettes de nos propres enregistrements et celles des événements signalés par le réseau de nettoyage en amont, et un flood porte souvent deux étiquettes à la fois (UDP et SYN, par exemple). Lisez-les comme « quels types de flood apparaissent », pas comme une part des attaques.
Qui a été touché
Les attaques étaient concentrées. Trois serveurs totalisent 23 des 37 enregistrements (62 %). Quatre des 11 serveurs n'ont eu qu'un seul enregistrement en 90 jours. Quatre autres serveurs n'ont eu aucun enregistrement réseau, seulement des épisodes web.
L'image utile n'est donc pas « chaque serveur est souvent attaqué ». C'est « quelques serveurs sont attaqués à répétition, et la plupart des autres le sont une fois ou jamais sur un trimestre ». Savoir dans quel groupe on se trouve est rarement possible à l'avance.
La couche web
Les attaques web sont des floods HTTP et HTTPS visant les points d'accès web du serveur. Nous avons enregistré 25 épisodes sur la période, avec un pic de 40 320 requêtes par seconde. Un épisode enchaîne les notifications reçues pour un même serveur tant que chacune arrive dans les 30 minutes de la précédente. Cinq des 25 épisodes n'ont pas pu être rattachés à un serveur précis ; ils sont comptés dans le total.
Un flood HTTP n'a pas besoin de volume pour faire mal à un serveur de jeu dont les gestionnaires HTTP coûtent cher à exécuter, ce qui explique qu'un tel débit compte quand même. Le détail du mécanisme est dans Attaques Layer 7 sur FiveM : players.json, info.json et sv_requestParanoia.
Ce que ces données ne disent pas
- Ce n'est pas FiveM en général. Elles couvrent des serveurs qui ont choisi de placer FIVESHIELD devant eux, sur un trimestre. Les serveurs les plus attaqués ont peut-être plus de raisons de s'inscrire, ce qui gonflerait ces chiffres.
- Un même flood peut donner plusieurs enregistrements. Quand un flood est absorbé en amont avant que nos systèmes sachent quel serveur il visait, chaque serveur ayant des joueurs sur ce proxy reçoit un enregistrement. Dans nos données, le même flood apparaît sur deux serveurs avec des pics identiques, à quelques secondes d'écart. Certains enregistrements sont donc collatéraux, pas une attaque visant ce serveur, et 37 dépasse le nombre de floods distincts. Nous ne pouvons pas dédoublonner à partir de ces enregistrements.
- Le pic vient de deux sources. Pour chaque enregistrement, c'est la plus grande valeur entre ce que notre proxy a mesuré et ce que le réseau de nettoyage en amont a signalé. Ce n'est pas une mesure purement faite sur le proxy.
- Aucune information sur les attaquants. Nous ne publions pas d'où venaient les attaques. Le site de proxy qui a porté un flood indique où le trafic d'un client était acheminé, pas où se trouvait l'attaquant.
- Seulement les attaques détectées. Un flood trop petit pour ouvrir un enregistrement n'est pas compté.
- Rien ici n'identifie un client. Ni noms, ni dates, ni sites dans cet article, volontairement.
Comment nous avons compté
- Un enregistrement réseau est ouvert sur le proxy quand le trafic d'un serveur reste au-dessus du seuil d'attaque pendant deux échantillons consécutifs de 5 secondes, et fermé après 12 échantillons calmes (une minute). Il est aussi ouvert pour chaque serveur d'un proxy quand le réseau en amont absorbe un flood si complètement qu'il ne reste rien pour désigner une cible.
- La durée est le temps entre l'ouverture et la fermeture. Elle inclut la minute de fermeture.
- Un épisode web regroupe une ou plusieurs notifications d'attaque HTTP pour un même serveur, enchaînées tant que chacune arrive dans les 30 minutes de la précédente.
- Les jours sont des jours calendaires de Toronto, les mêmes que ceux de la facturation. La période couvre les 90 jours calendaires jusqu'au 28 octobre 2026.
- Les chiffres ont été relevés le 28 octobre 2026 et ne seront pas modifiés sur place. Un relevé ultérieur serait un nouvel article, daté.
Ce que cela implique pour un propriétaire de serveur
Deux choses en découlent, et ce sont deux lectures de notre part, pas des choses que les chiffres démontrent.
- Les attaques sont courtes et reviennent sur les mêmes cibles. Une protection activée après le début d'une attaque n'en couvre que la fin. Si vous avez été attaqué une fois, considérez que c'est un schéma.
- Des débits de plusieurs millions de paquets par seconde dépassent ce qu'un plugin ou un script sur le serveur peut gérer. Il faut les arrêter avant qu'ils atteignent l'hôte. C'est le rôle d'un anti-DDoS FiveM, et la raison pour laquelle il se place devant le serveur, pas dessus.
Si vous êtes attaqué en ce moment, commencez par que faire quand votre serveur FiveM est attaqué. Pour l'explication complète du fonctionnement de ces attaques et de l'échec des solutions classiques, lisez comment stopper les attaques DDoS sur votre serveur FiveM.
Vous pouvez citer ces chiffres avec un lien vers cette page. Citez-en aussi le périmètre : serveurs derrière FIVESHIELD, du 31 juillet au 28 octobre 2026.