J'ai lu un certain nombre de choses sur le sujet, notamment
l'article d'Oracle, mais c'est
celui de Korben qui m'a fait réagir, j'ai donc rédigé rapidement ce que j'avais constaté.
Il ne faut pas voir le mal partout. Quand on regarde d'un peu plus près ce qui s'est passé, ça ne ressemble pas à un hijack bgp intentionnel, il a été très peu discret, et plutôt maladroit si c'était réellement voulu. Pas de ré-écriture de l'as-path (le prepend de 21217 n'a même pas été supprimé), pas de modification du ttl (les traceroutes montrent bien des hops chez CT - as4134).
Au niveau du contexte :
- SafeHost (as21217 - @swisscolo) a pour transitaires Level3 (as3356), UPC Cablecom(AS6830), EUnetworks(AS13237) et ChinaTelecom (AS4134)
- Tous les préfixes leakés ont un path cohérent avec une redistribution d'un transitaire ou d'un peer à un autre (CT ici)
- CT peer massivement, c'est possiblement un tier-1.
- CT ne filtre pas correctement les préfixes annoncés par un client, même pas de max-prefix a priori (ou trop haut).
Il est relativement compliqué pour un tier-1 de filtrer les préfixes reçus d'un autre tier-1. Les préfixes sont très nombreux (de l'ordre de dizaines de milliers) et avec beaucoup d'as downstreams (clients). Ici même CT ne filtrait pas les préfixes reçus de ses clients.
Il reste la question des préfixes "more-specific", désaggrégés, comme par exemple 176.171.75.0/24 annoncé normalement par Bouygues Telecom (as5410) en tant que 176.128.0.0/10. Etant more-specific cela permet d'attirer du traffic, ce qui n'aurait pas été le cas sans désagrégation au vu de l'as-path très long (règles de routage basique : l'annonce la plus précise gagne, ensuite l'as-path le plus court l'emporte).
Cela peut correspondre à plusieurs choses, légitimes :
1) un équipement d'optimisation de routage, tels que ceux de noction. Cela désagrège les préfixes pour faire passer par exemple un /24 sur un lien, et l'autre /24 du /23 sur un autre lien. Ces préfixes ne doivent normalement jamais sortir du réseau de l'opérateur qui a cet équipement, mais on a déjà vu des cas (cf ATE AS35625 -
https://www.bgpmon.net/accidentally-stealing-the-internet/)
2) une mauvaise redistribution de bgp vers un autre protocole, lui-même redistribué en bgp (cf as7007 - mais un tel cas ne devrait normalement plus se produire aujourd'hui)
3) une panne d'un équipement, sale, qui ne filtre plus rien, et leak des routes potentiellement internes générées par un bug ou un outil du point 1).
Les bugs, ça arrive. Les boulettes humaines, également. Ici l'absence de filtrage de la part de CT envers son client SafeHost n'est pas excusable, ça aurait permis d'éviter tout cela.
Quelques liens :
https://x.com/swisscolo/status/1138418158698663937https://bgp.he.net/AS21217#_irr import: from AS4134 accept ANY ==> transit
https://bgp.he.net/AS4134#_peers => très bien connecté
Si vous avez une autre analyse, je suis tout ouïe.