traceroute fuzzing

[darcosion]

Actuellement, le traceroute permet la découverte de réseaux locaux et distants affiliés à l'infrastructure ainsi scanné.

Il a été plusieurs fois dans l'issue #45 question de traceroute fuzzing pour découvrir potentiellement de nouvelles routes et de nouveau CIDR/équipements dans le réseau local.

Pour cela, il est intéressant de s'appuyer sur la documentation de l'IETF. En effet, selon la RFC 1918, les CIDR d'IP privées sont :

     10.0.0.0        -   10.255.255.255  (10.0.0.0/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16.0.0/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168.0.0/16 prefix)

Si on s'appuie plus loin sur l'ensemble des plages d'adresses qui ne sont pas utilisés sur internet, on a également :

0.0.0.0/8 | 0.0.0.0–0.255.255.255 | 16777216 | Software | Current network[3]
100.64.0.0/10 | 100.64.0.0–100.127.255.255 | 4194304 | Private network | Shared address space
127.0.0.0/8 | 127.0.0.0–127.255.255.255 | 16777216 | Host | Used for loopback addresses to the local host.
169.254.0.0/16 | 169.254.0.0–169.254.255.255 | 65536 | Subnet | Used for link-local addresses
192.0.0.0/24 | 192.0.0.0–192.0.0.255 | 256 | Private network | IETF Protocol Assignments
192.0.2.0/24 | 192.0.2.0–192.0.2.255 | 256 | Documentation | Assigned as TEST-NET-1, documentation and examples
192.88.99.0/24 | 192.88.99.0–192.88.99.255 | 256 | Internet | Formerly used for IPv6 to IPv4 relay
198.18.0.0/15 | 198.18.0.0–198.19.255.255 | 131072 | Private network | Used for benchmark testing of inter-network communications between two separate subnets.
198.51.100.0/24 | 198.51.100.0–198.51.100.255 | 256 | Documentation | Assigned as TEST-NET-2, documentation and examples.
203.0.113.0/24 | 203.0.113.0–203.0.113.255 | 256 | Documentation | Assigned as TEST-NET-3, documentation and examples.
224.0.0.0/4 | 224.0.0.0–239.255.255.255 | 268435456 | Internet | In use for IP multicast. (Former Class D network.)
233.252.0.0/24 | 233.252.0.0-233.252.0.255 | 256 | Documentation | Assigned as MCAST-TEST-NET, documentation and examples.
240.0.0.0/4 | 240.0.0.0–255.255.255.254 | 268435455 | Internet | Reserved for future use. (Former Class E network.)
255.255.255.255/32 | 255.255.255.255 | 1 | Subnet | Reserved for the "limited broadcast" destination address.

Ce qui laisse à penser que d'autres ranges disponibles pourraient offrir des possibilités de routage intéressante.

En plus de ces plages privés, une solution de fuzzing intéressante serait d'avoir un ensemble d'IP de l'internet sur lesquelles aucun opérateur n'est susceptible de faire du peering et/ou qui seraient les plus silencieuses possibles pour obtenir un résultat technique intéressant sans risque de rattacher des réseaux d'opérateurs faisant du peering direct au graph, sans que cela ai du sens.

Au final, il faut peut-être imaginer plusieurs solutions de fuzzing traceroute suivant les besoins (local, ip privées, internet).

[darcosion]

Le traceroute fuzzing local a été réalisé, avec une légère subtilité : les IP à scanner sont mises dans l'interface front : 17a1cceb9154147f32db84ed2ef08be64faa8cde

La raison est purement itérative, si la liste des IP à scanner est mise en backend, il faut implémenter un parralélisme de scan en backend. Si elle est mise en front, alors c'est Flask qui va paralléliser chaque CIDR scan. Cela permet également de limiter le nombre de route car les routes CIDR scan sont réutilisés.

Par contre, mon pc à crash à un moment sans raison, j'espère que les scans n'ont pas engendrés d'effet de bord.

Pour le scan internet, une idée comme ça : alexa propose un top site mondial, peut-être que si on trouve un AS "top" par pays, on prend chaque pays dans les 80 premiers et on se retrouve avec un CIDR par défaut pour chaque pays ? ça semble toutefois être une DB à constituer, peut-être alors une liste d'IP par continent, bien séparés ?

[darcosion]

A priori, on pourrais utiliser les IP des root servers, car elle sont extrêmement légitimes à contacter et un peu réparties dans le monde. Le risque d'être acheminé là bas par un accord de peering transparent (BGP route reflector) est largement amoindri :

; 
; OPERATED BY RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1
; 
; OPERATED BY ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:9f::42
; 
; OPERATED BY WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35

Il faut donc voir comment récupérer cette liste d'IP et la solution devrait être correcte.

[darcosion]

Le scan de traceroute vers internet a été effectué : 827dd0c3c9a6ca50bfed2e27d2036ea4f4060b14

Même fonctionnement que pour le traceroute local, sauf que c'est des IP et non des CIDR.

Toutefois, les IP sont inscrites en dur, je parie sur la stabilité des IP de root server. :S