vendredi, octobre 29, 2010

Sleep Proxy

Cet article a été rédigé initialement pour la NewsLetter HSC.

Les administrateurs réseaux vigilants observent des changements incessants de correspondance Adresse IP/Adresses MAC dans un réseau Ethernet contenant de nombreux Macintosh sous OSX 10.6.

Ce symptôme est causé par l'activité du "Sleep Proxy Server" présent sur les versions récentes de MacOS X (10.6) et des équipements Apple AirPort et TimeCapsule.

Il a pour but de permettre aux Macs proposant des services (SSH, Prise de contrôle à distance, partage de fichiers AFP ou SMB) de pouvoir passer en veille en l'absence d'activité, mais de revenir sur le réseau quand un autre équipement a besoin de lui.

Le fonctionnement repose sur le protocole Bonjour (appellation Apple du Multicast DNS) et sur l'élection d'un "Sleep Proxy" sur le réseau (un équipement ou un Mac OS X 10.6 avec l'option "Internet Sharing" activée), qui va maintenir une liste des systèmes et des services disponibles, puis, lors de leur passage en veille, répondre _à leur place_ aux requêtes ARP, récupérer le premier paquet de la connexion IP demandée, et s'il correspond à un service présent, envoyer un paquet Wake On Lan au système endormi.

La réponse aux requêtes ARP par le système proxy (qui envoie également des gratuitous ARP quelques secondes apres le passage en veille du système proxié) provoque évidemment une détection par les outils tels qu'ArpWatch ou dans les journaux des systèmes. Elle est également détectée par les fonctionnalités de "DHCP Snooping" des équipements réseaux.

Ci-dessous une trace prise sur un système FreeBSD :

Oct 28 10:13:13 fw kernel: arp: 192.70.106.117 moved from 00:16:cb:8b:8a:45 to 00:25:4b:a7:ea:f6 on vlan0
Oct 28 10:16:34 fw kernel: arp: 192.70.106.117 moved from 00:25:4b:a7:ea:f6 to 00:16:cb:8b:8a:45 on vlan0
Oct 28 13:17:50 fw kernel: arp: 192.70.106.117 moved from 00:16:cb:8b:8a:45 to 00:25:4b:a7:ea:f6 on vlan0
Oct 28 13:41:15 fw kernel: arp: 192.70.106.117 moved from 00:25:4b:a7:ea:f6 to 00:16:cb:8b:8a:45 on vlan0

00:16:cb:8b:8a:45 est l'adresse réelle de la machine 192.70.106.117, 00:25:4b:a7:ea:f6 est celle du Mac élu "Sleep Proxy" (192.70.106.76), qui a généré la trace suivante dans ses journaux :

Oct 28 10:16:31 removed mDNSResponder[18]: Waking host at en0 192.70.106.117 H-MAC 00:16:CB:8B:8A:45 I-MAC 00:16:CB:8B:8A:45 for 33 HSC?s\032MacBook\032Pro\03215"._ssh._tcp.local. SRV 0 0 22 HSCs-MacBook-Pro-15.local.

Le passage en veille du système à 10:13 génère le trafic suivant (les paquets IPv6 ne sont pas montrés) :
  • Recherche du Sleep Proxy et réponse :
10:13:00 192.70.106.117 -> 224.0.0.251 MDNS Standard query PTR _sleep-proxy._udp.local, "QM" question 10:13:00 192.70.106.76 -> 224.0.0.251 MDNS Standard query response PTR 50-37-71-72 MBP XYZ._sleep-proxy._udp.local
  • Annonce par le système de son passage en veille par DNS Cache Flush :
10:13:07 192.70.106.117 -> 224.0.0.251 MDNS Standard query response SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._ssh._tcp.local TXT SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _sftp-ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._sftp-ssh._tcp.local AAAA, cache flush fe80::216:cbff:fe8b:8a45 PTR,cache flush HSCs-MacBook-Pro-15.local A, cache flush 192.70.106.117 PTR, cache flush HSCs-MacBook-Pro-15.local AAAA, cache flush 2001:7a8:1155:0:216:cbff:fe8b:8a45 PTR, cache flush HSCs-MacBook-Pro-15.local

En examinant les TTL dans ce paquet, on verrait que les services sont annoncés avec une durée de vie d'une heure et 15 minutes.
  • Vérification par le Sleep Proxy que la machine ne répond plus :
10:13:11 192.70.106.76 -> 224.0.0.251 MDNS Standard query response SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._ssh._ tcp.local TXT SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _sftp-ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._sftp-ssh._tcp.local A, cache flush 192.70.106.117
  • Envoi des "Gratuitous ARP" afin de prévenir le réseau (les commutateurs et machines ayant gardé l'adresse MAC de 192.70.106.117) que l'adresse change (le changement est d'ailleur détecté par Wireshark) :
10:13:13 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request) (duplicate use of 192.70.106.117 detected!)
10:13:14 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request) (duplicate use of 192.70.106.117 detected!)
10:13:16 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request) (duplicate use of 192.70.106.117 detected!)


Le réveil à 10:16 lors d'une demande de connexion SSH depuis la machine 192.70.106.104 s'effectue ainsi :
  • Recherche de l'adresse MAC de 192.70.106.117 :
10:16:31 00:26:b9:e9:89:15 -> ff:ff:ff:ff:ff:ff ARP Who has 192.70.106.117? Tell 192.70.106.104
  • Réponse par le Sleep Proxy 00:25:4b:a7:ea:f6
10:16:31 00:25:4b:a7:ea:f6 -> 00:26:b9:e9:89:15 ARP 192.70.106.117 is at 00:25:4b:a7:ea:f6
  • Début de connexion SSH vers l'adresse MAC du sleep Proxy :
10:16:31 00:26:b9:e9:89:15 > 00:25:4b:a7:ea:f6, 192.70.106.104.33353 > 192.70.106.117.22: Flags [S], seq 4137326916
  • Paquet Wake On Lan envoyé sur le réseau par le sleep proxy :
10:16:31 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff WOL MagicPacket for 00:16:cb:8b:8a:45 (00:16:cb:8b:8a:45), password 00:00:00:00:00:00
  • Réveil de la machine en veille, requête DHCP et envoi de Gratuitous ARP pour mettre à jour tout le monde :
10:16:34 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - Transaction ID 0x2550f3c9
10:16:34 00:16:cb:8b:8a:45 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request)
10:16:34 00:16:cb:8b:8a:45 -> ff:ff:ff:ff:ff:ff ARP Who has 169.254.255.255? Tell 192.70.106.117
10:16:34 192.70.106.117 -> 224.0.0.2 IGMP V2 Leave Group 224.0.0.251

  • Suite de la connexion SSH vers la machine réveillée (répétition du SYN vers l'adresse MAC réelle, résolution ARP dans l'autre sens, puis réponse) :
10:16:34 00:26:b9:e9:89:15 > 00:16:cb:8b:8a:45, 192.70.106.104.33353 > 192.70.106.117.22: Flags [S], seq 4137326916
10:16:34 00:16:cb:8b:8a:45 -> ff:ff:ff:ff:ff:ff ARP Who has 192.70.106.104? Tell 192.70.106.117
10:16:34 00:26:b9:e9:89:15 -> 00:16:cb:8b:8a:45 ARP 192.70.106.104 is at 00:26:b9:e9:89:15
10:16:34 192.70.106.117 -> 192.70.106.104 TCP 22 > 33353 [SYN, ACK] Seq=1107555458 Ack=4137326917

Le fait que le système en veille se réveille environ toutes les heures pour signaler au Sleep Proxy qu'il est encore connecté au réseau génère même en l'absence d'autre activité des basculements d'adresse MAC détectés par les systèmes ou les sondes de détection d'intrusion.

On peut s'interroger sur la fiabilité, la sécurité et la maintenabilité de tout ce système spontané dans un réseau comportant de nombreuses machines.

Références :

mercredi, octobre 20, 2010

GERAAARD !

Gérard a grandi et il fait de magnifiques présentations !



"Le pinard ca devrait etre obligatoire !"

jeudi, octobre 14, 2010

Avec la technologie .NET ...


... il devient difficile de faire ses courses !

lundi, octobre 11, 2010

On se téléphone et on se fait une bouffe ?

Pas besoin d'aller aux Assises de la Sécurité discuter de la vie privée, du méchant Facebook et des horribles risques que les irresponsables employés font courir à l'entreprise en se connectant aux réseaux sociaux : il suffit d'y envoyer une machine et de sniffer le multicast du WIFI public pour savoir qui y était.

Merci aux Macintosh, iPhone, iPad et aux technologies Apple envoyant régulièrement le nom de machine (et parfois les services ouverts dans des Query SRV) à la terre entière.

jeudi, octobre 07, 2010

mardi, octobre 05, 2010

Et les gars on est en 2010 !

Quand on a des dizaines de millions de clients, on se débrouille pour avoir des infrastructures DNS qui marchent :

Tracing to www.sfr.fr[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ d.ext.nic.fr [fr] (2001:0500:002e:0000:0000:0000:0000:0002) Not queried
|\___ d.ext.nic.fr [fr] (192.5.4.2)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ c.nic.fr [fr] (2001:0660:3006:0004:0000:0000:0001:0001) Not queried
|\___ c.nic.fr [fr] (192.134.0.129)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
| \___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
|\___ a.nic.fr [fr] (2001:0660:3005:0003:0000:0000:0001:0001) Not queried
|\___ a.nic.fr [fr] (192.93.0.129)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ f.ext.nic.fr [fr] (194.146.106.46)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ e.ext.nic.fr [fr] (2a00:0d78:0000:0102:0193:0176:0144:0006) Not queried
|\___ e.ext.nic.fr [fr] (193.176.144.6)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ d.nic.fr [fr] (2001:0678:000c:0001:0000:0000:0000:0001) Not queried
|\___ d.nic.fr [fr] (194.0.9.1)
| |\___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| \___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
|\___ g.ext.nic.fr [fr] (2001:0500:0014:6039:00ad:0000:0000:0001) Not queried
\___ g.ext.nic.fr [fr] (204.61.216.39)
|\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * Got authoritative answer
|\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
\___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *

ns2.sfr.fr (84.96.147.2) www.sfr.fr -> 80.125.163.172
Une réponse sur une trentaine d'interrogations, et ca dure depuis au moins 11h ce matin ...