lundi, janvier 23, 2012

Donne moi l'heure, je te dirai qui tu es.

Je suis un peu un maniaque de l'heure, et j'aime bien à l'occasion ou professionnellement vérifier que les sites Web renvoient une heure correcte dans l'entête HTTP Date. C'est bien souvent un signe intéressant (mais ni nécessaire, ni suffisant) de la qualité de l'administration d'une plateforme.

Il y a en effet de multiples raisons pour que les serveurs Web soient tenus correctement synchronisés avec l'heure légale :
  • L'horodatage des journaux (HTTP, mais aussi applicatifs) afin de pouvoir déboguer ou enquêter après un incident de sécurité. Il n'y a rien de plus frustrant lors d'une enquête forensique d'être obligé de jongler avec les décalages horaires de systèmes entre eux (web, firewall, base de données, ...).
  • Le fonctionnement des caches Web, de l'expiration des sessions et parfois de la cryptographie peut nécessiter d'avoir une horloge pas trop désynchronisée entre serveur et clients.
  • Il peut y avoir des nécessités légales, notamment sur les sites marchands ou bancaires.

L'examen du champ Date envoyé par le serveur doit être fait avec prudence : en effet, le RFC 2616 sur HTTP 1.1 explique que ce champ est inséré par le serveur lors de la création du document, mais pas forcément celui de son envoi. Pour être raisonnablement sûr que la date renvoyée soit bien celle de l'horloge système du serveur, il faut donc :
  • Demander un document dynamique, par exemple avec un paramètre variable dans l'URL ;
  • Positionner les entêtes Cache-Control et Pragma pour demander à un cache éventuel de récupérer le document original ;
  • Tester que cela fonctionne en examinant les entêtes et vérifiant que la date varie convenablement avec le paramètre !
On peut alors comparer l'heure présente dans la réponse du serveur avec celle du serveur, en essayant de tenir compte du temps de transfert du réseau et de la préparation de la requête (résolution DNS, connexion TCP). Il faut noter que le champ Date n'offre qu'une précision à la seconde. Afin de garantir des transferts les plus courts possibles, il est quand c'est possible préférable d'utiliser la méthode HEAD afin de ne lire du réseau que les entêtes de la réponse.

J'ai voulu vérifier la bonne synchronisation d'un nombre raisonnable (80) de sites français, en le faisant sur la durée (plusieurs semaines) et de manière automatisée. J'ai divisé les sites cibles en 8 catégories un peu arbitraires : 
  • Les sites de l'Etat (Présidence de la République, ministères, assemblées) ;
  • Les sites des "Hautes Autorités" ou agences associées à l'Etat, florissantes depuis une dizaine d'années ;
  • D'autres services publics (Sécurité Sociale, Météo, ...) ;
  • Les sites des principaux partis politiques qui seront représentés à la prochaine élection présidentielle ;
  • La presse quotidienne nationale et régionale ; 
  • Les chaînes de télévision ayant une diffusion sur la TNT ;
  • Les opérateurs télécoms, FAI, l'AFNIC et quelques hébergeurs parmi les plus connus (liste un peu arbitraire) ;
  • Les principales banques de dépôt.
Les URLs des sites sont disponibles ici en format texte.

Le programme écrit en C utilise libcurl pour les requêtes HTTP et une base de données MySQL pour le stockages des sites, des paramètres et des résultats. Le programme et la base de données utilisée (sans les résultats) sont disponibles ici en licence WTFPL

Les résultats bruts peuvent être obtenus en interrogeant la base de données, en utilisant la requête SQL select sites.url,abs(avg(delta_time)),stddev(delta_time) from sites,results where sites.sites_id=results.sites_id group by results.sites_id order by 2. Les résultats sont bien meilleurs que ce à quoi je m'attendais : la plupart des sites ont un écart de moins de deux secondes avec l'heure du serveur effectuant les essais (lui même bien synchronisé par ntpd). 


Les sites les moins précis sont donnés ci-dessous. Les écarts de temps sont donnés en millisecondes :

| left(sites.url,40) | abs(avg(delta_time)) | stddev(delta_time) |
...
| http://www.prosodie.fr/?id={TS}          |            1085.8544 |           812.5083 |
| http://www.direct8.fr/actu-info/         |            1267.8511 |          2870.3213 |
| http://www.nrj12.fr/?id={TS}             |            1446.9191 |          1429.6998 |
| http://www.liberation.fr/?id={TS}        |            1540.4272 |           933.0153 |
| http://www.has-sante.fr/portail/jcms/j_5 |            1989.6861 |          1360.3114 |
| http://www.defense.gouv.fr/?id={TS}      |            2566.4304 |          1786.1356 |
| http://www.sante.gouv.fr/?id={TS}        |            2817.6602 |          1687.9689 |
| http://www.frontnational.com/?id={TS}    |            3022.6440 |          1720.3847 |
| http://www.humanite.fr/?id={TS}          |            4042.3495 |          5538.7156 |
| http://www.csa.fr?id={TS}                |            4681.3819 |          3369.7041 |
| http://www.hadopi.fr/?id={TS}            |            5691.7120 |          5018.6053 |
| http://www.afnic.fr/?ts={TS}             |            7170.0154 |          8571.1347 |
| http://www.gandi.net/?id={TS}            |            9327.2589 |          2562.1840 |
| http://www.industrie.gouv.fr/?id={TS}    |           17408.0421 |          1659.7796 |
| http://www.banquepopulaire.fr/scripts/gr |           46421.9612 |         29731.3730 |
| https://www.lcl.fr/?id={TS}              |          138442.5890 |         15340.1387 |
| http://www.online.net/?id={TS}           |          227520.5761 |         71500.8101 |
| http://www.cnil.fr/?tsid={TS}            |          233297.6472 |        113715.0501 |

On peut remarquer que deux banques figurent parmi les sites les moins synchrones ! Deux grands hébergeurs figurent également parmi les moutons noirs, ainsi que la CNIL (233s de décalage quand même) et l'Hadopi. Tous ces sites n'utilisent probablement pas de synchronisation NTP ...

Des observations également intéressantes peuvent être faites, notamment sur le site AFNIC, ou un serveur non synchronisé (sur 2 ou 3 serveurs cachés derriere www.afnic.fr) pollue la moyenne, ainsi que cela peut être vu dans le graphe obtenu grâce à l'exportation des données :
2586 > export site 87 afnic.txt
259 results exported to afnic.txt



On peut aussi observer la dérive sur 10 jours du serveur de la CNIL, ou là aussi deux serveurs (l'un en avance de 12 secondes, l'autre de 35) se mélangent probablement :


La dérive est également importante sur le serveur Prosodie, ou visiblement une synchronisation nocturne par tâche programmée remet les choses en l'ordre (ce qui n'est pas optimal et peut causer des problèmes système puisque non monotone) :

Il sera intéressant de constater comment les sites les plus synchrones vont digérer la seconde intercalaire (leap second) qui sera insérée le 30 Juin à minuit (si tant est que le serveur effectuant la mesure la gère bien ...).

Si vous êtes un des administrateurs des sites testés et que vous désirez être enlevés de cette étude (qui va continuer encore quelques semaines), ou que vous vouliez récupérer les données brutes vous concernant, écrivez moi à timesurvey at rominet dot net .



jeudi, novembre 03, 2011

Sponsors du G20 ??

Ce matin je découvre grâce à twitter que le G20 est sponsorisé (on parle de "partenaires") par une ribambelle d'entreprises françaises , dont certaines ont du payer plus que d'autres puisqu'elles ont le statut de "soutien officiel" .


Sur le même site Web, on rappelle fort judicieusement les objectifs de la présidence française , parmi lesquels :
2 - Renforcer la régulation financière
La présidence française veillera à la mise en œuvre effective des règles décidées par le G20 pour renforcer durablement le contrôle du secteur financier. Elle s'emploiera aussi à renforcer la régulation financière dans les domaines où elle reste insuffisante, par exemple en matière de régulation du « secteur bancaire fantôme » (activité bancaire parallèle non régulée à ce jour) et d'intégrité et de transparence des marchés financiers.
6 - Agir pour le développement
Le G20, qui représente 85% de l'économie mondiale et les deux tiers de la population de la planète apparaît aujourd'hui comme une enceinte pertinente pour apporter des solutions concrètes aux problématiques du développement.
Comment peut-on être hyprocrite à ce point ? Comment ne pas voir le conflit d'intérêt gigantesque causé par la présence parmi les sponsors d'une banque, notamment connue pour son activité sur les marchés de futures ? Et parler de développement sous la bannière d'une entreprise qui vit de la privatisation de l'eau ?

Les conférences de presse officielles se feront-elles bientôt, a l'instar des sportifs, devant le panneau des sponsors ? Imagine-t-on De Gaulle, Mitterrand (pour ne citer que des personnalités françaises) venir débattre de l'avenir du monde (ou faire semblant) dans un sommet sponsorisé par Dior ou Bic ?

C'est tout simplement hallucinant (je découvre cela, peut être la dérive dure t-elle depuis des années).

On va me dire que grâce à ça, le contribuable est moins sollicité ... Je réponds que ça n'a aucune importance, et que la compromission est bien pire que l'impôt.

Comme le dit quelqu'un : "Tous dehors !".


vendredi, octobre 14, 2011

Référé contre FAI (2)

Bon, je suis allé à l'audience de délibéré, sauf que ce n'était pas dans la même salle que la dernière fois (je pense que c'était dans le bureau du juge en fait), et donc que je n'ai pu qu'écouter ce qu'ont dit les avocats à la sortie ...

Mme le Juge des référés a donc demandé aux 6 FAI de bloquer le site complet par filtrage IP ou DSN (sic).

Cette décision est tout sauf une surprise pour moi :
  • Le blocage par URL n'était pas possible, d'abord parce que le site n'est accessible qu'en HTTPS (argument peu développé à l'audience et pas repris dans le jugement) et, nonobstant cette particularité, parce que le filtrage par URL demanderait l'installation de systèmes DPI que les FAI affirment ne pas posséder ;
  • Le délit est constitué (Injures, Collectes de données personnelles) au vu de la loi (1881 pour l'injure, loi du 6 Janvier 1978 pour les données) ;
  • La LCEN prévoit depuis 2004 que les fournisseurs peuvent être requis dans le cas ou l'hébergeur ne peut pas l'être.
Le juge n'avait donc pas beaucoup de raisons de refuser la demande à mon sens, et donc d'imposer la mesure la plus limitée techniquement possible : bloquer l'accès complet. La mesure est temporaire, en attendant l'issue des plaintes déposées par le Ministère de l'Intérieur. Ce qui est très intéressant, c'est que le jugement reconnait que les FAI seront indemnisés pour le blocage (c'est le moment de faire développer le DPI dans les *BOX avec les sous de l'État !). Il n'y a pas d'astreinte, considérant que les FAI ne sont pour rien dans le délit initial et qu'ils sont de bonne volonté.

Bien sûr tout le monde sait que le site va changer de domaine, d'adresse IP, qu'on peut utiliser des serveurs DNS qui ne sont pas ceux du FAI, que des dizaines de mirroirs existent, qu'on peut utiliser Tor ou un proxy au Belouchistan, ... et donc que cette mesure n'empêchera pas complètement l'accès au site. Je pense simplement que le Ministère ne pouvait pas donner l'impression de laisser tomber les policiers, surtout vu les échéances à venir, et que cette préoccupation est sans doute la principale motivation de cette action.

Plusieurs questions et réflexions :
  • Pourquoi attaquer ces 6 FAI et pas d'autres, même s'ils sont plus petits (Nerim, FDN, ...) ?
  • Ce blocage n'affectera évidemment que les FAI résidentiels, les accès en entreprise ne sont, pour la plupart, pas concernés (il aurait fallu imposer un blocage IP au niveau de tous les opérateurs de transit IP en France) et je suis notamment sûr qu'il restera accessible depuis beaucoup d'administrations bien après que les FAI aient appliqué la demande ^^ ;
  • Je n'ai toujours pas compris pourquoi Gandi, bureau d'enregistrement du domaine, n'a pas été assigné, alors qu'il était le plus à même de faire cesser l'infraction de manière plus définitive ;
  • Est-ce que ce jugement peut en amener d'autres avec des requérants moins régaliens ? Pour ma part, je pense que l'effet "Streisand" déjà en cours et les contournements possibles sont de puissants freins, et je ne le pense donc pas ;
  • On m'a demandé si les miroirs étaient visés : la Justice a pris déjà une décision en une semaine, elle ne peut pas juger quelque chose qui est apparu hier ... Mais j'espère pour eux que les gens qui font des miroirs ont l'intelligence d'être très bien cachés et sont courageux, parce que le Ministère n'a pas l'air de plaisanter...

Une dernière réflexion personnelle : quand les gens d'un bord politique précis, élus sans discontinuité depuis 2002, disent qu'ils veulent "réguler" et "civiliser" l'Internet, et bien au final, contre toute attente, ils le font ! Ils ont certainement tort, mais ils ont une certaine légitimité pour faire la loi, et la Justice l'applique. Dans une République, le peuple fait changer la loi en élisant des députés et un exécutif, d'abord en votant, et, pour les plus courageux, en militant dans de vrais partis politiques, et pas seulement des groupes de pression ne luttant que pour "la neutralité du Net" ou "Hadopi caca ..". Quand nous aurons de nouveau compris cela, collectivement, alors beaucoup de choses iront mieux.


mercredi, octobre 12, 2011

Référé contre les FAI.

Comme je l'ai narré sur twitter, je suis allé ce matin à l'audience publique du référé intenté par Claude Guéant, Ministre de l'Intérieur contre 6 Fournisseurs d'accès internet (France Telecom Orange, SFR, Free, Numéricable, Bouygues Telecom et Darty Telecom) afin de faire interdire l'accès par leurs abonnés à certaines pages du site Copwatch.

Ce site (dont l'hébergeur est américain ainsi que le montre Spyou, et dont le domaine a été fourni par le bureau d'enregistrement français Gandi) diffuse des photos de policiers en civils, ainsi que pour certain d'entre eux, leur identité complète. Le site est clairement anti-flics, voire franchement haineux. Je n'ai pas de raison particulière d'aimer la police, ni de la détester d'ailleurs, et je trouve ces méthodes au moins aussi lamentables que les actions qu'elles prétendent dénoncer.

A vrai dire, s'il n'y avait pas eu cette assignation ni les plaintes pénales que le Ministère a formé, je pense que ce site serait passé inaperçu, au moins du grand public.

Ce qui m'intéressait, c'était de voir comment la Justice allait se débrouiller avec une énorme contradiction technique :
  • Afin de ne pas apparaître trop comme un censeur, le Ministre demandait le filtrage de certaines pages seulement (les pages injurieuses et celles contenant des coordonnées de policiers) ;
  • Le site n'est accessible qu'en HTTPS.
Même le meilleur système de DPI ne saurait résoudre directement cette équation, puisque l'analyse des URLs demandées par le navigateur nécessiterait de déchiffrer le trafic SSL et donc de pouvoir générer des certificats validés par le navigateur. Ce n'est évidemment pas impossible, l'attaque récente sur les internautes iraniens après le piratage de DigiNotar le montre, mais cela impliquerait évidemment qu'une autorité reconnue par un nombre suffisants de navigateurs, par exemple l'autorité de certification IGC/A du SGDN soit implantée dans le système DPI chez chaque FAI et génère des certificats à la volée. Inutile de dire que ce n'est pas son rôle (mais si on a des doutes on peut toujours la désinstaller de son navigateur).

Etonnament, cet argument a été peu utilisé par les avocats de la Défense, qui ont plaidé à tour de rôle. Seul l'avocat d'Orange qui a parlé en premier l'a abordé, mais en étant presque incompréhensible (dur pour moi de ne pas intervenir à ce moment, ceux qui ont travaillé avec moi voient de quoi je parle ^^).

Ils ont tous mis en avant évidemment l'impossibilité technique de filtrer par URL sans installer de coûteux systèmes DPI (qu'ils jurent tous ne pas avoir, alors qu'on sait qu'au moins pour les accès smartphone, c'est faux), et ont expliqué qu'ils pouvaient si on les forçait, filtrer par DNS ou par IP (et SFR a eu l'intelligence d'expliquer que c'était très inefficace) en utilisant le rapport rédigé par la FFTCE à l'occasion je crois de la loi LOPSI2.

L'avocat du Ministère a répondu par avance dans son exposé que ce n'était pas son problème, et que la loi LCEN de 2004 obligeait les fournisseurs d'accès à filtrer si l'hébergeur n'est pas contactable ou n'est pas facilement sanctionnable : "Peu me chaut" a-t-il répété.
En étant tellement éloigné de la réalité (je ne peux pas croire qu'aucun expert du Ministère n'a pu l'aider, j'en connais), on peut même se demander si son but final n'était pas de faire passer le message "Nous voulions filtrer seulement certaines pages, ces crétins d'informaticiens ne peuvent pas, alors maintenant tout le site est bloqué".
L'avocate du syndicat de policiers "Alliance" a tenu le même propos, en expliquant qu'un policier avait reçu une cartouche dans sa boîte à lettres et que la montée de la haine contre la Police inquiétait les fonctionnaires.

Le reste de l'audience était très intéressant, avec des différences subtiles entre les FAI :
  • chez Bouygues on explique qu'on peut pas filtrer l'URL mais qu'on est prêt si on le demande à faire du blocage DNS ;
  • chez SFR on explique qu'on est prêt à bloquer l'adresse IP du serveur ;
  • chez Orange on explique rien mais évidemment on est prêt à bloquer si la justice demande ;
  • chez Free on explique que la France n'est pas la Chine et qu'on veut pas de DPI (mais évidemment sans le dire ils mettront une route vers Null0 si on leur demande) ;
  • chez Darty on explique "C'est pas nous !" puisque le réseau est sous traité et que toutes les fois que la police judiciaire demande quelque chose, on se défausse (^^).
Free a eu l'intelligence de demander pourquoi GANDI n'avait pas été assigné : si les coordonnées données lors de l'enregistrement du domaine sont fausses, comme semble le penser la police, alors il viole la charte ICANN et peut être suspendu. C'est effectivement bizarre, d'autant qu'il y a des précédents et que les Registrars bloquent chaque jour beaucoup de domaines pour spam, escroquerie, malware sans aucune décision de justice !

En revanche ils étaient tous d'accord pour demander une indemnisation en cas d'ordre de blocage, et certains (SFR, Darty, Free) à passer par la case de la Question Préalable de Consitutionnalité si elle n'était pas accordée, en invoquant par exemple la Déclaration des Droits de l'Homme de 1789 (arguant le fait qu'un tiers aidant la justice doit être rémunéré). Ils étaient également tous très très mécontents de la demande d'astreinte de 2000 euros par jour de retard, en expliquant qu'ils n'étaient coupables de rien et collaboraient avec la Justice toutes les fois qu'elle le demandait ...

Le procureur après avoir expliqué que l'infraction initiale semblait constituée et que les dommages (pour les policiers visés par le site) étaient réels, a expliqué qu'il était inutile de demander une mesure ne pouvant être appliquée (le filtrage des URLs) mais qu'elle demandait un filtrage par IP ou par DNS (ce qui revient à bloquer tout le site). Elle était en revanche opposée à l'astreinte qui ne peut s'appliquer qu'en cas de mauvaise foi et de résistance, et pensait également que les FAI devaient être défrayés.

Le jugement a été placé en délibéré et sera rendu le Vendredi 14/10 (après demain) à 17h. J'essaierais d'y aller également.

Je pense que le juge va suivre le procureur (après tout la loi a été votée il y a 7 ans et elle prévoit ce cas), mais qu'on en a pas fini avec cette histoire ... Je pense que le Ministère a bien manoeuvré en demandant "le retrait de quelques pages" en sachant très bien que ce n'était pas faisable ...

Je serais les FAI, je commencerais à faire une annonce BGP bidon pour plein de /32 allant dans Null0 (enfin ils l'ont certainement déjà) et/ou une procédure pour mettre des trous noirs dans les serveurs DNS.

En attendant, le site CopWatch a déjà au moins 25 miroirs ...





lundi, janvier 31, 2011

Les Hackers dans l'espaaaaaaaaaaaaace !

Il y a 40 ans exactement aujourd'hui, Apollo 14 était lancé vers la Lune. Alan Shepard et Edgar Mitchell devaient se poser près du cratère Fra Mauro, déjà sélectionné pour la mission précédente Apollo 13 qui se termina comme on le sait.

La mission se déroula relativement normalement jusqu'à la préparation de la descente (PDI, Powered Descent Initiation), pendant laquelle les contrôleurs de vol (notamment le GUIDO) détectèrent que l'ordinateur de bord du LM recevait un signal électrique indiquant que le bouton ABORT était enfoncé.



Ces deux boutons jouent un rôle fondamental : ils permettent au commandant de terminer la descente en cas de problème grave ne permettant pas un alunissage en sécurité : le premier effectue un abandon avec le moteur de descente, le second (ABORT STAGE) sépare l'étage de descente et allume le moteur de remontée.

Evidemment avec une indication que le bouton est enfoncé, dès le début de la descente, elle allait être arrêtée sans possibilité de continuer ... Les contrôleurs demandèrent alors à l'équipage d'effectuer la plus vieille manoeuvre de l'informatique : tapoter sur le panneau de contrôle ... Et miracle le bit correspondant (Channel 30, Bit 1) à ABORT s'effaça ... pour revenir quelques minutes plus tard : il y avait bien un faux contact (non détecté sur terre mais probablement lié à l'apesanteur) dans l'interrupteur.

Il fallait donc trouver rapidement (les trajectoires et les réserves du LEM imposaient d'atterrir apres au maximum deux orbites complètes en parking autour de la lune) une procédure afin de permettre :
  • d'ignorer le bouton ABORT pendant la descente ;
  • pouvoir effectuer un abandon manuel rapidement en cas de problème.
L'ordinateur des vaisseaux Apollo (AGC : Apollo Guidance Computer) avait été conçu et programmé par une équipe du MIT. Il était utilisé dans le CSM et dans le LM, avec des logiciels légèrement différents. C'était un ordinateur très avancé pour son temps, utilisant des circuits intégrés, équipé de 36 kilomots de 15bits de mémoire morte et 2048 mots de mémoire vive, avec une horloge de 2MHz. Il était surtout équipé d'un séquenceur temps réel et gérant des priorités, capable de se redémarrer sans perte, ce qui sauva le premier alunissage.
Il faut bien comprendre que les programmes étant stockés en ROM, il était impossible de les modifier en vol, et que la très faible mémoire vive disponible ne permettait pas d'implémenter un patch logiciel. Enfin le fonctionnement de la télémétrie ne permettait pas au MCC d'envoyer autre chose que des données de vol (principalement positions et constantes d'équations de trajectoire).

Aujourd'hui, grâce à quelques fous, il est possible de simuler l'AGC sur n'importe quel micro, et surtout les codes sources des programmes utilisés par la NASA sont disponibles (ils ont été scannés) et compilables (les programmes sont écrits dans un assembleur d'assez haut niveau). La documentation "utilisateur" est disponible pour le logiciel utilisé sur Apollo-15.

Les signaux issus des boutons ABORT sont gérés par la routine R10, appelée 4 fois par seconde, et ne sont gérés évidemment que quand un "BURN" est en cours, ce qui correspond lors de l'alunissage aux programmes P63 (Descente), P64 (Freinage final) et P66 (Vol manuel lors de l'alunissage). Pour cela, un flag LETABRT autorisant l'abandon est positionné dans la mémoire. A l'époque, tout le monde était root , y compris les astronautes, et ils pouvaient donc repositionner n'importe quel bit dans la mémoire de l'AGC : il était donc tentant de vider simplement ce flag. Malheureusement, la routine de démarrage du moteur (appellée BURNBABY) la positionne dès que le moteur est allumé : quelque soit la rapidité des astronautes, il y avait donc un risque d'une race condition si le petit bout de métal probablement dans l'interrupteur se manifestait à ce moment là ...

Heureusement, R10 effectue également un autre test : elle vérifie qu'il n'y a pas dejà un ABORT en cours en vérifiant avant de les placer dans le séquenceur que les programmes P70 ou P71 ne sont pas déjà lancés. Pour celà, elle vérifie que la variable MODREG contenant normalement le programme principal en cours n'a pas la valeur 70 ou 71.

Don Eyles, un des programmeurs du MIT, a alors eu la bonne idée de proposer un gros hack à la NASA : demander à l'équipage, après l'initiation du programme P63, lancé quelques minutes avant la descente et qui va se charger d'allumer le moteur, de changer MODREG en mémoire par 71 : ainsi la routine R10 sera bypassée. Dès que le moteur sera démarré, la variable LETABRT sera remise à 0 par l'équipage, puis MODREG repositionné sur 63.

Malheureusement rien n'est simple en informatique, et la routine BURNBABY vérifie elle même si le programme actuel est P63 : si oui, alors elle programme la mise en route à 100% du moteur après 26 secondes, et place un bit (ZOOMFLAG) indiquant que les données venant du radar d'alunissage doivent être prises en compte pour la suite des calculs de trajectoires. Avec P71 dans MODREG, pas de THROTTLE UP ni de calcul de trajectoire !

Pas grave : l'homme étant, comme disait Von Braun, « le meilleur ordinateur pouvant être mis dans un vaisseau spatial et le seul pouvant être produit par une main d'oeuvre non qualifiée », les astronautes sont capables de positionner manuellement le moteur à 100% après 26 secondes, puis de positionner rapidement ZOOMFLAG dans la mémoire de l'AGC.

La méthode finale fut donc la suivante :
  • Après que le programme P63 soit lancé mais avant l'allumage, placer MODREG sur 71 ;
  • A l'allumage du moteur, compter 26" avec un chronomètre ;
  • Pousser le moteur à 100% ;
  • Mettre ZOOMFLAG à 1 ;
  • Mettre LETABRT à 0;
  • Remettre 63 dans MODREG.
Pour cela, les astronautes ont utilisé le DSKY (clavier de l'AGC) , dont l'interface basique reposait sur la notion de VERB (action) et de NOUN (objet) ainsi VERB 01 permet d'afficher une donnée, NOUN 01 indique que c'est une adresse en mémoire qui est demandée, alors que NOUN 35 indique que l'on veut lire l'horloge.

La séquence ci-dessus est donc la suivante :
  • VERB 21 NOUN 01 ENTER 1010 ENTER 107 ENTER (1010 est l'adresse de MODREG, 107 = 71 en octal)
  • Démarrage et poussée
  • VERB 25 NOUN 7 ENTER 101 ENTER 200 ENTER, 1 ENTER (101 est l'adresse du mot contenant ZOOMFLAG, 200 le masque octal, 1 la valeur finale)
  • VERB 25 NOUN 7 ENTER 105 ENTER 400 ENTER, 0 ENTER (105 est l'adresse du mot contenant LETABRT, 400 le masque octal, 0 la valeur finale)
  • VERB 21 NOUN 01 ENTER 1010 ENTER 77 ENTER (remise dans MODREG de 77 = 63 en octal)




Pour remettre en place le flag LETABRT en cas d'abandon réel demandé, il suffisait donc de rentrer VERB 25 NOUN 7 ENTER 105 ENTER 400 ENTER, 1 ENTER. Cela peut prendre quelques secondes, ce qui peut suffire à tuer les astronautes en cas d'abandon très près de la lune, mais cela a été jugé comme étant un risque acceptable.

Tout se passa comme prévu, et Alan Shepard put finalement aller taper quelques balles de golf sur la lune ("Miles and miles ...").

Le fait que les astronautes puissent écraser n'importe quelle valeur dans l'AGC n'était pas forcément connu, et cela a d'ailleurs posé problème lors du retour d'Apollo 11 quand Michael Collins, en oubliant de taper un NOUN a écrasé (temporairement) les valeurs envoyés par la plate-forme inertielle (descendre à 158:20:40).

Je ne suis pas sûr du tout qu'aujourd'hui un contournement serait aussi facile à implémenter sur un système d'exploitation moderne (et donc plus sécurisé) et des programmes utilisant des langages de haut niveau.

L'exploration des logiciels d'Apollo et leur simulation est en tout cas passionnante, notamment parce qu'elle montre comment programmer dans un environnement restreint, et il faut remercier les tarés qui ont scanné le code source et l'ont sauvé de l'oubli.

Apollo Surface Journal : http://www.hq.nasa.gov/office/pao/History/alsj/frame.html
Apollo Flight Journal : http://history.nasa.gov/afj/
Virtual AGC : http://www.ibiblio.org/apollo

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 !"