Soit un réseau informatique sur lequel nous n'avons pas la main, nous sommes juste root sur une machine (que nous nommerons sonde ci-dessous) dans ce réseau.
En IPv4, aucun problème : on peut ping/traceroute/mtr. En IPv6, c'est plus compliqué : un ICMPv6 echo-request arrive à destination mais l'echo-reply n'arrive jamais jusqu'à la machine sondeuse. traceroute et mtr ne fonctionnent pas du tout dans le sens où aucun nœud réseau n'apparaît alors que les paquets sondeurs sortent pourtant bien de la machine. Aucun paquet ne parvient à la destination.
Plus étrange, un ssh -6 -p 22
, un telnet -6 22
et un nmap -6 -p 22
fonctionnent, la machine qui sonde obtient bien un SYN-ACK. En revanche, un mtr -6 -T -P 22
ne fonctionne pas. Les paquets sont perdus sur le réseau et n'arrivent jamais à destination.
Les ports source sont identiques dans les deux cas : pris au pif dans la plage des ports éphémères.
Blusky m'a indiqué que cela pouvait être dû à une protection contre les scans de ports silencieux (nmap -sS
), c'est-à-dire un scan qui contourne la poignée de main TCP : nmap envoie un SYN, la destination répond l'habituel SYN-ACK et la pile TCP de la sonde répond RST au lieu du drapeau ACK, ce qui montre que cette connexion n'était vraiment pas sérieuse donc scan "silencieux". Un scan "normal" (nmap -sT) est le défaut de nmap s'il n'est pas exécuté en root, sinon un scan silencieux sera réalisé. Certaines protections réseaux peuvent détecter les scans silencieux et les bloquer. Un tel blocage se détecte facilement : les premiers paquets passent puis, ho, pouf, plus rien. Or, dans mon cas, aucun paquet, même pas les premiers, ne parviennent à destination. De plus, nmap -sT -p 22
et nmap -sS -p 22
produisent le même résultat. Il ne s'agit donc pas de cela.
En comparant les paquets IP capturés avec Wireshark, je me dis que l'une des différences entre un traceroute/mtr et un ssh/telnet/nmap est le hop limit (le nom IPv6 du TTL IPv4). Il est positionné à au moins 64 pour ssh/telnet/nmap alors qu'il est positionné à 1 puis 2 puis 3 puis 4 puis… par traceroute/mtr dans l'optique que les routeurs renvoient des messages ICMPv6 « Time Exceeded » et dévoilant ainsi qu'ils sont sur le chemin de la communication. Pour tester cette hypothèse : ping6 -t 5
: rien n'arrive à destination. ping6 -t 10
: rien n'arrive à destination : ping6 -t 15
: hooo, les echo-request arrivent à destination !
On peut aussi mettre cela en évidence avec Scapy :
#!/usr/bin/python
#coding=utf-8
from scapy.all import *
import random
monPaquet = IPv6(dst="2a00:5881:8110:1000::1", hlim=15) / TCP(dport=22, flags="S")
monPaquet.payload.sport = random.randint(32768,61000)
send(monPaquet, verbose=0)
En faisant varier le hlim, on met clairement en évidence un filtrage basé sur le hop limit.
J'ignorais que des admins infos s'ennuyaient au point d'avoir le temps de mettre en place ce genre de craderies, et uniquement en IPv6. :(