Aller au contenu
PEERYXNETWORK
Preuves de mitigation | Attaques réellement filtrées | Peeryx
Preuves de mitigation

De vraies attaques, de vrais relevés

Annoncer une capacité ne prouve rien. Voici ce que nos serveurs de filtrage ont réellement traité, mesuré par leur propre télémétrie, avec la méthode de comptage et les limites de l’exercice.

Le relevé

27 699Attaques mitigées
3,12 GppsPic traité
93attaques au-delà de 100 Mpps
46 sDurée médiane

Période du relevé : → (95 jours)

La détection ne s’arrête pas

Répartition horaire des détections sur la période. Aucune des vingt-quatre heures n’est vide — c’est ce qui rend crédible une détection continue, pas une affirmation.

heure de la journée · attaques détectées

Ce que nous voyons passer

Vecteurs identifiés, en part des attaques qualifiées. Les attaques dont le vecteur n’a pas pu être qualifié sont exclues de ce calcul, et leur nombre est indiqué.

  • udp 53,6 % 12 030
  • tcp_ack 17,2 % 3 866
  • tcp_syn 15,8 % 3 545
  • tcp_other 5,4 % 1 203
  • tcp_syn_ack 5,0 % 1 122
  • icmp 2,2 % 501
  • gre 0,5 % 117
  • tcp_rst 0,2 % 44

5 267 attaques dont le vecteur n’a pas été qualifié.

Attaques marquantes

Les plus fortes volumétries de la période. Aucun préfixe, aucune adresse, aucun nom de client : seule la taille du bloc visé est indiquée, parce qu’elle a un sens technique.

Détection Pic paquets Pic débit Vecteur Durée Bloc visé État
2026-08-20 15:04 934 Mpps 598 Gbps unknown 485 min 52 s — Résolue
2026-08-23 10:00 905 Mpps 2,81 Tbps unknown 18 min 45 s — Résolue
2026-08-24 21:59 848 Mpps 542 Gbps unknown 695 min 39 s — Résolue
2026-08-24 21:59 816 Mpps 522 Gbps unknown 695 min 39 s — Résolue
2026-08-25 11:31 808 Mpps 517 Gbps unknown 545 min 38 s — Résolue
2026-08-25 11:31 776 Mpps 496 Gbps unknown 545 min 38 s — Résolue
2026-08-20 15:04 772 Mpps 494 Gbps unknown 485 min 52 s — Résolue
2026-08-20 12:00 678 Mpps 434 Gbps unknown 172 min 57 s — Résolue
2026-08-24 21:59 670 Mpps 429 Gbps unknown 695 min 39 s — Résolue
2026-08-24 06:15 555 Mpps 14 Mbps unknown 31 min 37 s — Résolue

Méthode et limites

Ce que nous comptons

Une attaque est un épisode enregistré par la télémétrie de nos serveurs de filtrage : horodatage de détection, pic de paquets par seconde, pic de débit, vecteur lorsqu’il est qualifiable, et horodatage de résolution. Le pic retenu est la valeur maximale observée sur l’épisode, pas une moyenne.

Ce que nous écartons

Les valeurs aberrantes isolées. Un relevé unique situé plus de trois fois au-dessus du 99,9ᵉ centile n’est pas traité comme une preuve tant qu’il n’a pas été confirmé : c’est plus probablement une anomalie de mesure. Un tel relevé existe sur la période et n’apparaît pas dans ces chiffres.

Ce que nous ne publions pas

Aucun préfixe, aucune adresse IP, aucun identifiant de client ou de service. La taille du bloc visé est conservée parce qu’elle informe sur la nature de l’attaque sans identifier personne. Aucun nom de client n’apparaîtra ici sans autorisation écrite.

Les limites de ce relevé

Ces chiffres décrivent ce que nos serveurs ont vu et traité. Ils ne mesurent pas un taux de faux positifs, ni la qualité perçue par l’utilisateur final, ni un temps de mitigation : la date de début de mitigation n’est horodatée que sur une petite partie des épisodes, nous ne la publions donc pas. Nous préférons le dire plutôt que de calculer une moyenne sur un échantillon non représentatif.