Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

echoping

Ève

Recherche dans ce blog :

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


RFC 7203: IODEF-extension for structured cybersecurity information

Date de publication du RFC : Avril 2014
Auteur(s) du RFC : T. Takahashi (NICT), K. Landfield (McAfee), T. Millar (USCERT), Y. Kadobayashi (NAIST)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF mile
Première rédaction de cet article le 22 avril 2014


Le format IODEF permet l'échange de données structurées (et donc analysables par un programme) sur des incidents de sécurité. Ce nouvel RFC étend le format IODEF avec des informations utiles pour le monde de la « cybersécurité ».

Le RFC commence par prétendre que le nombre d'incidents de cybersécurité augmente tous les jours (alors qu'on n'en sait rien). Ce qui est sûr, c'est que la quantité d'informations échangées sur ces incidents augmente et qu'il existe une quantité impressionnante de formats structurés et de référentiels (quelques exemples au hasard, pris dans ceux cités par le RFC : CVSS, OVAL, SCAP, XCCDF...). Notre RFC en ajoute donc un, sous forme, non pas d'un format nouveau mais d'une extension de IODEF, un format fondé sur XML et qui avait été normalisé dans le RFC 5070. Signe des temps : un des auteurs du RFC travaille au ministère de l'intérieur états-unien...

La section 3 du RFC rappelle ses buts, et l'importance de ne pas repartir de zéro, d'agréger les formats cités plus haut au lieu d'essayer de les remplacer. Les extensions IODEF elle-mêmes figurent en section 4. En gros, il s'agit de permettre d'incorporer dans IODEF des descriptions issues de normes extérieures déjà existantes. Un nouveau registre IANA stocke les spécifications ainsi incorporées. Pour l'instant, le registre n'en compte qu'une seule, urn:ietf:params:xml:ns:mile:mmdef:1.2 qui est fondée sur la norme IEEE MMDEF, qui permet de décrire des logiciels malveillants.

Chacune de ces entrées dans le nouveau registre dérivera d'une classe (notre RFC utilise le vocabulaire de la programmation objet, et le langage UML pour la modélisation) parmi les huit : AttackPattern, Platform, Vulnerability, Scoring, Weakness, EventReport, Verification et Remediation. Ainsi, MMDEF, la première entrée, hérite de AttackPattern. Chacune de ces classes est décrite en détail en section 4.5

Et voici, tiré du RFC, un exemple de rapport IODEF incorporant des éléments MMDEF, décrivant un malware de nom eicar_com.zip (un fichier de test connu) :


<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document version="1.00" lang="en"
 xmlns="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Incident purpose="reporting">
    <IncidentID name="iodef-sci.example.com">189493</IncidentID>
    <ReportTime>2013-06-18T23:19:24+00:00</ReportTime>
    <Description>a candidate security incident</Description>
    <Assessment>
      <Impact completion="failed" type="admin" />
    </Assessment>
    <Method>
      <Description>A candidate attack event</Description>
      <AdditionalData dtype="xml">
        <iodef-sci:AttackPattern
         SpecID="http://xml/metadataSharing.xsd">
          <iodef-sci:RawData dtype="xml">
            <malwareMetaData xmlns="http://xml/metadataSharing.xsd"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xml/metadataSharing.xsd
             file:metadataSharing.xsd" version="1.200000" id="10000">
              <company>N/A</company>
              <author>MMDEF Generation Script</author>
              <comment>Test MMDEF v1.2 file generated using genMMDEF
              </comment>
              <timestamp>2013-03-23T15:12:50.726000</timestamp>
              <objects>
                <file id="6ce6f415d8475545be5ba114f208b0ff">
                  <md5>6ce6f415d8475545be5ba114f208b0ff</md5>
                  <sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1>
                  <sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4
                          95991b7852b855</sha256>
                  <sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83
                          f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9
                          31bd47417a81a538327af927da3e</sha512>
                  <size>184</size>
                  <filename>eicar_com.zip</filename>
                  <MIMEType>application/zip</MIMEType>
                </file>
                <file id="44d88612fea8a8f36de82e1278abb02f">
                  <md5>44d88612fea8a8f36de82e1278abb02f</md5>
                  <sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1>
                  <sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4
                          538aabf651fd0f</sha256>
                  <sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e
                          68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0
                          dc9a061d9e507d833277ada336ab</sha512>
                  <size>68</size>
                  <crc32>1750191932</crc32>
                  <filename>eicar.com</filename>
                  <filenameWithinInstaller>eicar.com
                  </filenameWithinInstaller>
                </file>
              </objects>
            <relationships>
              <relationship type="createdBy" id="1">
                <source>
                  <ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]</ref>
                </source>
                <target>
                  <ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]</ref>
                </target>
                <timestamp>2013-03-23T15:12:50.744000</timestamp>
                </relationship>
              </relationships>
            </malwareMetaData>
          </iodef-sci:RawData>
        </iodef-sci:AttackPattern>
      </AdditionalData>
    </Method>
    <Contact role="creator" type="organization">
      <ContactName>iodef-sci.example.com</ContactName>
      <RegistryHandle registry="arin">iodef-sci.example-com
      </RegistryHandle>
      <Email>contact@csirt.example.com</Email>
    </Contact>
    <EventData>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-addr">192.0.2.200</Address>
            <Counter type="event">57</Counter>
          </Node>
        </System>
        <System category="target">
          <Node>
            <Address category="ipv4-net">192.0.2.16/28</Address>
          </Node>
          <Service ip_protocol="4">
            <Port>80</Port>
          </Service>
        </System>
      </Flow>
      <Expectation action="block-host" />
      <Expectation action="other" />
    </EventData>
  </Incident>
</IODEF-Document>

On notera que bien des discussions préalables au RFC portaient sur cette plaie de l'appropriation intellectuelle, plusieurs des schémas référencés ayant des noms qui sont des marques déposées.


Téléchargez le RFC 7203


L'article seul

RFC 7157: IPv6 Multihoming without Network Address Translation

Date de publication du RFC : Mars 2014
Auteur(s) du RFC : O. Troan (Cisco), D. Miles (Alcatel-Lucent), S. Matsushima (Softbank Telecom), T. Okimoto (NTT West), D. Wing (Cisco)
Pour information
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 22 avril 2014


Pour la petite entreprise ou association, il est très intéressant d'être multi-homé, c'est-à-dire d'avoir plusieurs connexions à l'Internet, afin d'être sûr que l'accès fonctionne toujours. Financièrement, acheter deux connexions Internet grand-public, de fiabilité moyenne, est nettement moins cher qu'une seule connexion supposée de grande fiabilité. Il reste à permettre aux machines du réseau local à utiliser les deux connexions. En IPv4, cela se fait traditionnellement en utilisant le NAT, qui est de toute façon nécessaire en raison de la pénurie d'adresses. Et en IPv6 ?

On pourrait utiliser le NAT, comme le mettent en œuvre un certain nombre de boîtiers existants actuellement. Les machines du réseau local utiliseraient un seul préfixe, un ULA et le routeur traduirait vers les préfixes de l'un ou l'autre FAI (peut-être en tenant compte de la charge, du prix, etc). Mais le NAT a de nombreux inconvénients et l'un des buts d'IPv6 était justement de s'en débarasser (ceci dit, si vous voulez tenter l'aventure, il existe un RFC sur ce sujet, le RFC 6296, cf. section 7.1). Autre solution, faire du beau multi-homing propre avec des adresses PI et BGP. Mais c'est complètement hors de portée de la petite organisation, notamment par les ressources humaines que cela nécessite. (Voir le RFC 3582 pour un cahier des charges d'une solution idéale pour le multi-homing.)

Je vous le dis tout de suite, il n'existe pas encore de solution propre et déployable pour ce problème. À court terme, le RFC 6296 reste la seule solution. Notre RFC explore ce qui pourrait être utilisé pour après, en supposant un réseau multi-homé avec plusieurs préfixes IP (MHMP pour multihomed with multi-prefix). C'est donc plutôt un cahier des charges qu'un catalogue de solutions.

A priori, IPv6 permet parfaitement d'avoir deux préfixes d'adresses (un par FAI, si on est multi-homé à seulement deux FAI) sur le même réseau. Mais cela laisserait les machines face à bien des problèmes :

  • S'il y a deux routeurs (un pour chaque FAI), lequel choisir pour sortir ?
  • Quelle adresse IP source choisir pour les connexions sortantes ? Notez que c'est lié au problème précédent : si le FAI met en œuvre le filtrage du RFC 2827, il faut choisir le préfixe correspondant au FAI de sortie.
  • Et c'est encore pire si le FAI impose l'usage de ses résolveurs DNS car il y met des informations spécifiques à ses clients (comme Orangesmtp.wanadoo.fr et smtp.orange.fr donnent des résultats différents selon le réseau, interne ou externe).

Bref, simplement connecter le réseau local à deux FAI et distribuer leurs adresses sur ledit réseau ne suffit pas.

La section 3 décrit plusieurs scénarios typiques, pour rendre plus concret le problème. Le premier est celui où le réseau a deux routeurs, chacun connecté à un FAI et ignorant de l'autre routeur. C'est le cas par exemple de l'abonnement à deux FAI ADSL avec chaque FAI fournissant sa box. Le deuxième scénario imagine un seul routeur sur le réseau local, connecté à deux FAI. L'unique routeur du réseau local peut publier sur le réseau local tout ou partie des informations (préfixe IP, résolveurs DNS) reçues. Ce scénario peut se trouver, entre autres, si on a un abonnement Internet plus un tunnel vers un fournisseur de VPN. Enfin, dans le troisième scénario, c'est la machine terminale qui a deux connexions et qui doit les gérer. C'est le cas du téléphone drôlement intelligent qui est connecté en WiFi et en 3G.

Quels vont être les principaux problèmes à résoudre avec ces trois scénarios (section 3.3) ?

  • Dans le premier cas, celui à deux routeurs, la sélection, par une machine du réseau local, de son adresse IP source, en cohérence avec le routeur choisi pour la sortie (si elle se trompe, le paquet sera refusé par le FAI s'il met en œuvre le RFC 2827), et la répartition de charge (chaque machine n'enverra du trafic qu'à un seul routeur),
  • Dans le deuxième scénario, avec un seul routeur sur le réseau local, le même problème de sélection d'adresse IP source, si le routeur publie les deux préfixes sur le réseau local, et la sélection du FAI de sortie par le routeur,
  • Pour le troisième exemple, celui de la machine terminale à plusieurs connexions, le manque d'informations (sur la facturation, par exemple) pour décider quel trafic envoyer à quelle interface (curieusement, notre RFC ne cite pas l'excellent RFC 6419, entièrement consacré à cette question des machines terminales multi-homées).

Et, dans les trois scénarios, le problème du résolveur DNS, si les deux résolveurs ne donnent pas les mêmes résultats.

Maintenant, il faut résoudre ces problèmes, en respectant deux principes (section 4) : maintien du principe de bout en bout (donc pas de NAT), puisque c'est l'un des principaux buts d'IPv6, et passage à l'échelle, la solution devant fonctionner même pour des gros déploiements.

Les sections 5 et 6 explore les angles d'attaque possibles. Pour la sélection de l'adresse IP source (sections 5.1 et 6.1), la référence actuelle est le RFC 3484, qui est loin de donner un résultat optimum, puisqu'il utilise uniquement l'adresse IP de destination (dans la scénario 1 ci-dessus, il ne garantit pas qu'on sélectionne une adresse qui correspondra au routeur de sortie). Une approche actuellement étudiée à l'IETF serait de distribuer (par exemple en DHCP), depuis le routeur, des politiques de sélection d'adresse (actuellement, elles sont configurées dans chaque machine, /etc/gai.conf sur la plupart des Linux, par exemple). Pour que ces politiques soient complètes, cela nécessitera la coopération du FAI..

Pour la sélection du routeur (sections 5.2 et 6.2), c'est à peu près la même chose : les machines terminales n'ayant actuellement pas assez d'informations pour prendre une décision intelligente, il faudra leur envoyer (via DHCP), les informations permettant de choisir le routeur. Une telle information ne peut pas facilement être transmise avec les RA (Router Advertisment), qui ne permettent pas d'envoyer des informations différentes selon la machine. (On pourait envisager d'utiliser les protocoles de routage eux-même mais il y a bien longtemps qu'on a cessé de les faire tourner sur les machines terminales, et pour de bonnes raisons.)

Enfin, pour le dernier gros problème, la sélection du résolveur DNS (sections 5.3 et 6.3), notre RFC rappelle que les machines ont pu connaître le résolveur via DHCP (RFC 3646) ou RA (RFC 6106). Dans le cas du multi-homing, la machine aura typiquement plusieurs résolveurs DNS. Parfois, il faudra utiliser un résolveur spécifique pour un domaine donné (dans l'exemple d'Orange, cité plus haut, il faut utiliser les résolveurs d'Orange pour les noms en wanadoo.fr, car on obtient des résultats différents avec les serveurs publics). Cette pratique, connue sous le nom de split DNS est typiquement très mal vue (entre autres, elle rend le déboguage très compliqué) mais elle existe. Notre RFC décide donc, sans l'entériner, de « faire avec ».

Là encore, un travail est en cours à l'IETF pour normaliser une politique de sélection du résolveur, en fonction du domaine à résoudre, et distribuée par DHCP (RFC 6731).

Bien sûr, il existe des tas d'autres techniques qui peuvent aider dans ce cas du multi-homing. Le RFC cite SHIM6 (RFC 5533), SCTP (RFC 4960), HIP (RFC 5206), etc. Mais elles sont aujourd'hui trop peu déployées pour qu'on puisse compter dessus.

Enfin, la section 8 nous rappelle que tout ceci va certainement poser des problèmes de sécurité amusants. Par exemple, si on distribue une politique de sélection (d'adresse IP source, de résolveur DNS, etc) sur le réseau, il y aura toujours des machines qui n'obéiront pas. Contrôle et filtrage resteront donc nécessaires. D'autre part, il existe déjà aujourd'hui des serveurs DHCP pirates, qui répondent à la place du vrai, et le problème sera pire encore lorsque des politiques de sélection (de routeur, de réolveur DNS, etc) seront distribuées via DHCP.


Téléchargez le RFC 7157


L'article seul

RFC 7207: A Uniform Resource Name (URN) Namespace for Eurosystem Messaging

Date de publication du RFC : Avril 2014
Auteur(s) du RFC : M. Ortseifen (Deutsche Bundesbank), G. Dickfeld (Deutsche Bundesbank)
Pour information
Première rédaction de cet article le 18 avril 2014


Une famille d'URN de plus, pour les messages d'Eurosystem, famille gérée par la Bundesbank pour le compte de l'ESCB. Vous ne connaissez pas le secteur bancaire ? L'ESCB est un regroupement de banques centrales européennes (mais n'ayant pas forcément adopté l'euro) comme la Bundesbank. L'Eurosystem, comme son nom l'indique, est commun aux membres de l'ESCB qui ont adopté l'euro (voir la présentation par l'ESCB).

Et pourquoi ont-ils besoin d'URN ? Parce qu'ils échangent des messages par le système TARGET2 (un système à la norme ISO 20022) et qu'un certain nombre d'éléments dans ces messages ont besoin d'être identifiés de manière unique et stable dans le temps (les messages ont toujours besoin d'être lus et compris des années après). Les identifiants doivent être indépendants du protocole d'accès, ce qu'offrent les URN, normalisés dans le RFC 2141. Il est important que l'Eurosystem puisse être un registre d'identificateurs, avec son propre NID, son propre espace de noms pour ses URN (RFC 3406). Cet espace se nomme eurosystem et est enregistré à l'IANA.

Il n'y a pas de structure à l'intérieur de ces URN (donc, après le urn:eurosystem:), juste une suite de caractères. L'exemple donné par le RFC est urn:eurosystem:xsd:reda.012.001.02.


Téléchargez le RFC 7207


L'article seul

RFC 7165: Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)

Date de publication du RFC : Avril 2014
Auteur(s) du RFC : R. Barnes (BBN Technologies)
Pour information
Réalisé dans le cadre du groupe de travail IETF jose
Première rédaction de cet article le 15 avril 2014


Il est traditionnel de classer les mécanismes de sécurité de l'Internet en deux, ceux fondés sur la sécurité du canal et ceux fondés sur la sécurité de l'objet. Pour les premiers, on garantit certaines propriétés de l'objet pendant son transit dans un canal donné. Pour les seconds, l'objet se déplace en permanence dans une armure cryptographique qui le protège, quelle que soit la sécurité du canal où il voyage. Le groupe de travail JOSE de l'IETF cherche à procurer une sécurité de l'objet aux textes encodés en JSON. Son premier RFC est consacré à décrire les cas d'usage et le cahier des charges de cette sécurité.

JSON (RFC 7159) est un format très répandu, notamment sur le Web. Il peut être transporté dans des protocoles qui assurent la sécurité du canal comme HTTPS. Mais, comme toujours avec la sécurité du canal (IPsec, TLS, etc), elle ne garantit pas de sécurité de bout en bout. Par exemple, si le serveur d'origine est piraté, et les textes en JSON modifiés, HTTPS ne protégera plus. Même chose si on utilise certains relais, chose courante sur le Web : HTTPS ne protège pas contre les intermédiaires. Il existe à l'IETF des mécanismes assurant la sécurité du message (de l'objet) comme CMS (RFC 5652) pour l'ASN.1/DER. Mais pour le JSON ? Il y a là un manque à combler. Car la sécurité du message est nécessaire pour permettre la manipulation du messages par des intermédiaires à qui on ne fait pas forcément confiance. Pour le courrier électronique, la sécurité du canal est fournie par SMTP sur TLSRFC 3207, et la sécurité du message par PGPRFC 4880 - ou S/MIME - mais le RFC, curieusement, ne cite pas PGP. Par contre, il n'existe pas encore de solution propre pour JSON transporté sur HTTP. Les gens de XML ont choisi XML Signature et XML Encryption, les gens de JSON travaillent donc activement à leur propre solution.

Ce RFC parle de sécurité et utilise donc largement la terminologie standard du RFC 4949. Il peut être utile aussi de lire le RFC 5652 sur CMS car ce RFC le cite souvent.

Le groupe de travail JOSE (JSON Object Signing and Encryption) est chargé de développer trois formats :

Rappelez-vous que ce RFC 7165 n'est que le premier RFC du groupe, il ne donne pas encore de solutions, il explore le problème et précise les exigences du travail à effectuer (la liste officielle et numérotée de ces exigences figure en section 6).

Le cahier des charges débute en section 3 avec un résumé des exigences « de base » :

  • Le format pour l'objet chiffré doit permettre l'utilisation de la cryptographie symétrique et de la cryptographie asymétrique.
  • Le format pour l'objet signé doit permettre une vérification de l'intégrité par MAC pour le cas où les deux parties partagent une clé (cryptographie symétrique), et par signature avec de la cryptographie asymétrique.
  • Comme les textes JSON protégés ne seront pas forcément traités dans le contexte d'une communication synchrone avec possibité de négociation ou d'échange, il faut (le RFC prévoit des exceptions très encadrées) que tous les paramètres cryptographiques nécessaires (à part les clés) soient inclus dans l'objet. À noter que la liste des paramètres dépend de l'algorithme cryptographique utilisé (qui doit donc être indiqué clairement).
  • Conséquence de l'exigence précédente, les applications qui traitent les textes JSON protégés doivent avoir un moyen simple de déterminer si elles sont en possession de la clé nécessaire, et de produire un message d'erreur clair si ce n'est pas le cas.

La section 4 rappelle que l'application qui utilisera les textes JSON protégés a aussi des responsabilités, par exemple c'est elle qui décidera quels algorithmes sont acceptables, comment seront échangées les clés, etc.

La liste complète des exigences est en section 6 du RFC. Mais, avant cela, la section 5 contient les études de cas. La première est celle des jetons (security tokens), ces petits textes qu'on s'échange pour authentifier ou autoriser un tiers dans une communication (« il a le doit de lire les fichiers, laisse-le y accéder »). C'est par exemple le cas des assertions de SAML, de Persona, et d'OpenID Connect. Certains utilisent XML mais un autre groupe de travail IETF développe un format JSON, JWT (JSON Web token), déjà utilisé dans des systèmes comme Persona. Ce format a besoin des techniques JOSE pour être sécurisé. Le RFC note qu'il faudra aussi que le format final puisse être mis dans un URL, ce qui nécessite qu'il doit très compact. Le fait qu'une permission soit donnée peut être parfois confidentiel et le format de signature peut donc ne pas suffire. Même dans ce cas d'usage, il faudra donc aussi penser à la confidentialité. Autre exemple de jeton, dans OAuth (RFC 6749). Ici, la norme impose un transport par HTTPS donc la confidentialité est normalement assurée, il ne reste que l'authentification.

Ces jetons de sécurité sont également utilisés dans les cas de fédérations d'identité. Ainsi, OpenID Connect, déjà cité, repose sur OAuth et JSON et est un des gros demandeurs des fonctions JOSE.

Autre étude de cas, pour le protocole XMPP (RFC 6120), surtout connu pour la messagerie instantanée. Un instant, vous allez me dire, le X dans XMPP rappelle qu'il a XML comme format. Que vient-il faire dans un RFC parlant de JSON ? C'est parce que la sécurité de XMPP, aujourd'hui, est uniquement une sécurité du canal : les communications entre clients et serveurs, ou bien entre les serveurs, sont protégées par TLS (et de nombreux acteurs du monde XMPP se sont engagés à ce que le chiffrement soit systématisé avant mai 2014). Mais cela ne fournit pas de sécurité de bout en bout, ce qui est d'autant plus gênant que les sessions XMPP sont rarement établies directement entre deux pairs, mais passent par des serveurs qui sont la plupart du temps gérés par une organisation différente. XMPP, tel qu'utilisé aujourd'hui, est donc vulnérable à l'espionnage par le fournisseur. Le problème est identifié depuis longtemps, mais la seule solution standard, décrite dans le RFC 3923, n'a jamais été adoptée (comme la plupart des techniques S/MIME). Actuellement, la solution la plus commune pour résoudre ce problème de sécurité est OTR.

Une autre solution est donc en cours de développement dans la communauté XMPP, fondée sur JSON et JOSE. C'est certes bizarre de transporter des textes JSON dans les flux XML de XMPP et cela complique un peu les choses (il faut être sûr que le texte JSON ne contienne pas de caractères qui sont spéciaux pour XML, ou alors il faut tout mettre dans un bloc CDATA ou encore encoder tout en Base64, au prix d'un accroissement de taille).

Autre système qui aura besoin de JOSE, ALTO (RFC 6708). Ce système permet à un client de s'informer, auprès d'un serveur, sur le pair le plus « proche » pour les cas où plusieurss pairs peuvent rendre le même service. Dans son mode le plus simple, ALTO est simplement un protocole requête/réponse, où les échanges se font en JSON sur HTTP. HTTPS est suffisant pour sécuriser ce mode. Mais les futures versions d'ALTO pourrait avoir des objets d'information relayés entre plusieurs parties, et JOSE deviendrait alors utile pour les sécuriser.

Continuons la riche liste de cas d'école possibles pour JOSE, avec les systèmes d'alerte. Il y a des travaux en cours à l'IETF sur l'utilisation de l'Internet pour diffuser des alertes, par exemple concernant une catastrophe naturelle proche. Une exigence absolument critique de ces systèmes est l'impossibilité de fabriquer une fausse alerte. Si c'était possible, une grave panique pourrait être déclenchée à volonté. Et, sans même parler des effets de la panique, la confiance dans le système disparaitrait rapidement. Or, les alertes doivent être diffusées très vite, à beaucoup de gens, quel que soit le mécanisme par lequel ils sont actuellement connectés. Elles passent donc par des intermédiaires, cherchant à toucher tout le monde. Une protection du canal ne suffit donc pas, une protection du message (du texte JSON) est nécessaire.

Dernier cas que je vais citer, l'API Web Cryptography. Cette API normalisée permet notamment au code JavaScript s'exécutant dans un navigateur de demander au navigateur de réaliser des opérations cryptographiques. L'un des intérêts (par rapport à une mise en œuvre complètement en JavaScript) est la sécurité : les clés peuvent rester dans le navigateur, JavaScript n'y a pas accès. Ceci dit, dans certains cas, la capacité d'exporter une clé (par exemple pour la copier vers un autre appareil) est utile. L'API prévoit donc cette fonction (avec, on l'espère, de stricts contrôles et vérifications) et cela implique donc un format standard pour ces clés (publiques ou privées). Au moins pour les clés privées, la confidentialité de ce format est cruciale. JOSE (son format JWK) va donc être utilisé.

La section 6 du RFC liste les exigences précises du projet JOSE. Chacune, pour faciliter les références ultérieures, porte un identificateur composé d'une lettre et d'un nombre. La lettre est F pour les exigences fonctionnelles, S pour celles de sécurité et D si c'est une simple demande, pas une exigence. Par exemple, F1 est simplement l'exigence de base d'un format standard permettant authentification, intégrité et confidentialité. F2 et F3 couvrent le format des clés (dans le cas de la cryptographie symétrique comme dans celui de l'asymétrique). F4 rappelle que le format doit être du JSON, et F5 qu'il faut une forme compacte, utilisable dans les URL.

Parmi les simples désirs, D1 rappelle l'importance de se coordonner avec le groupe de travail WebCrypto du W3C, D2 souhaite qu'on n'impose pas (contrairement à beaucoup d'autres normes de cryptographie comme XML Signature) de canonicalisation du contenu, D3 voudrait qu'on se focalise sur le format, pas sur les opérations, de manière que les formats JOSE soient utilisables par des applications très différentes, utilisant des protocoles de cryptographie bien distincts.

À noter que la section 7 revient sur la canonicalisation en reconnaissant que, comme il n'existe pas de moyen automatique simple de déterminer si deux textes JSON représentent la même information, cela peut avoir des conséquences sur la sécurité de JOSE.

Merci à Virginie Galindo pour sa relecture.


Téléchargez le RFC 7165


L'article seul

Copie d'un disque dur sur Windows

Première rédaction de cet article le 14 avril 2014


Il m'est arrivé une aventure bizarre : j'ai dû intervenir sur une machine Windows. Le problème semblait simple, copier le disque d'une ancienne machine vers une nouvelle. Mais c'est plus difficile que cela n'en a l'air.

L'ancienne machine était sous Windows XP, qui, comme tout le monde le sait, n'est plus maintenu depuis quelques jours. La nouvelle était sous Windows 8 et il fallait évidemment récupérer les fichiers, les préférences, les données diverses. Comme les machines récentes ont forcément un disque plus gros que les anciennes, je me suis dit, dans mon ignorance totale, « le plus simple est de copier l'ancien disque dans un dossier du nouveau, on pourra arrêter tout de suite l'ancienne machine et ensuite déplacer à loisir les données vers le bon emplacement ». Certes, je ne connais rien à Windows. Mais ce n'est pas grave, n'importe quel commercial vous expliquera que Windows, contrairement à Unix, est convivial, est utilisable par M. Michu sans formation, et qu'il n'y aura donc pas de problème.

Je passe sur la configuration du partage de fichiers : Windows 7 avait introduit un nouveau mécanisme d'authentification, le Groupe résidentiel et configurer le serveur sur Windows 8 pour que la machine Windows XP puisse s'y connecter n'a pas été trivial, Windows XP ne pouvant pas rejoindre le groupe résidentiel. Bon, une fois que c'était fait, je me suis dit « c'est bon, je lance le cliquodrome, euh, l'Explorateur de fichiers et je copie tout le disque vers le serveur Windows 8 ». Problème (que les experts Windows ont sans doute senti venir depuis un certain temps) : il n'y a pas moyen de copier une arborescence si un seul fichier a un problème. La copie entière s'arrête. « Copying File c:\pagefile.sys The process cannot access the file because it is being used by another process. » Le problème est bien connu des utilisateurs avertis de Windows mais, curieusement, lorsque la question est posée sur un forum, tous les fanboys Microsoft se succèdent pour expliquer que c'est normal (un exemple où, comme le dit un participant frustré qui voulait juste copier ses fichiers « My GOD, you people are thick! Does MVP = something I don't know about, or could you all be that thick?! Only one poster all the way thru here so far bothered to know what the OP said. The rest of you appear to be quacks! »). Le raisonnement est que le fait qu'on ne puisse pas copier un fichier est une erreur fatale, puisque le dossier résultant ne sera pas complet. OK, que ce soit le comportement par défaut, je peux comprendre, mais qu'il n'y ait aucun moyen, avec l'Explorateur de fichiers officiel, de passer outre et de lui dire « copie moi ce que tu peux », c'est très agaçant.

Comment on fait, alors ? Eh bien, si on veut le faire uniquement avec des logiciels standard Windows XP, une seule solution, abandonner le cliquodrome et passer en ligne de commande. L'outil xcopy a une option /C (comme Continue) qui permet d'ignorer les erreurs. Une commande comme  :

xcopy /C /H /F /S /E c:\ \\nouvellemachine\data\anciennemachine

fait à peu près ce qu'il faut et copie ce qu'elle peut, ignorant les erreurs (fichiers inutiles comme l'espace de pagination ou fichiers ouverts par une application). Sauf qu'au bout d'un moment, xcopy s'arrête avec le message Insufficient memory. N'ajoutez pas de RAM, cela ne servirait à rien, le message est faux. Ce n'est pas de mémoire que manque xcopy, c'est simplement qu'il a rencontré un fichier dont le nom complet (avec le chemin dans les dossiers) est trop long. Problème bien connu des experts et largement documenté en ligne (mais comment on faisait pour régler les problèmes Windows quand on n'avait pas Google ?). Supprimer ce fichier (affiché juste avant, grâce à /F) ne suffirait pas, il peut y en avoir d'autres plus tard.

On passe donc à un outil plus perfectionné, qui figure par défaut dans les Windows récents mais qui n'était pas dans Windows XP, robocopy (il faut le chercher dans Windows Server 2003 Resource Kit Tools). L'option pour dire d'ignorer les erreurs est plus tordue qu'avec xcopy (/R:0 /W:0) mais elle marche, et la longueur des noms de fichier n'est plus un problème :

robocopy c:\ \\nouvellemachine\data\anciennemachine /MIR /R:0 /W:0

Avec robocopy et quelques heures de patience, tout a été copié.

Alors, quelles leçons à en tirer ? D'abord, je suis bien conscient de mes limites en Windows. Je n'ai aucun doute qu'un vrai expert Windows aurait fait cela en dix fois moins de temps, sans cafouiller et sans utiliser Google. Je ne prétends pas avoir choisi la meilleure méthode (au lieu de robocopy, on aurait pu installer des logiciel tiers comme Supercopier ou xxcopy ou bien utiliser la fonction de « transfert facile » de Windows). Mais pourquoi prétend t-on que Windows est utilisable par tous, sans lire la documentation et sans faire d'efforts ? Je suis au courant qu'Unix a aussi ses inconvénients mais, au moins, Unix ne prétend pas être « convivial ». La leçon à en tirer me semble être que, dès qu'on veut faire une opération peu commune, on doit faire appel à un spécialiste. (Je connais un utilisateur qui, achetant un nouvel ordinateur, a payé le vendeur pour faire cette opération de copie des anciens fichiers.)


L'article seul

RFC 7181: The Optimized Link State Routing Protocol version 2

Date de publication du RFC : Avril 2014
Auteur(s) du RFC : T. Clausen (LIX, Ecole Polytechnique), C. Dearlove (BAE Systems ATC), P. Jacquet (Alcatel-Lucent Bell Labs), U. Herberg (Fujitsu Laboratories of America)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF manet
Première rédaction de cet article le 11 avril 2014


Il existe désormais plusieurs protocoles de routage pour le problème difficile des MANETs, ces réseaux ad hoc (c'est-à-dire non organisés et non gérés) de machines diverses connectées de manière intermittente. On est loin des réseaux structurés classiques, avec leurs routeurs bien administrés qui se parlent en OSPF. Dans un MANET, le réseau doit se configurer tout seul, il n'y aura pas d'administrateur pour cela (le RFC 2501 examine les différents aspects du problème des MANETs). Notre nouveau RFC décrit la version 2 d'un de ces protocoles de routage les plus répandus, OLSR, dont la version 1 était dans le RFC 3626.

OLSR v2 est incompatible avec la v1, c'est un nouveau protocole. Il garde toutefois les mêmes principes de base (qui étaient avant ceux d'HiperLAN), notamment l'utilisation de MPR, des nœuds du réseau choisis comme routeurs (dans un MANET, il n'y a pas de routeur désigné, chaque machine peut se voir affecter cette tâche, cf. section 18). Ainsi, toutes les machines n'ont pas à émettre de l'information sur leurs interfaces, seul un sous-ensemble des nœuds, les MPR, le fait (c'est particulièrement rentable si le réseau est très dense ; s'il ne l'est pas, la plupart des nœuds seront des MPR puisqu'il n'y aura pas le choix). D'autre part, OLSR v2 est un protocole proactif, il calcule les routes en permanence et elles sont toujours prêtes (contrairement à d'autres protocoles qui calculent les routes à la demande). Principales nouveautés dans OLSR v2 : d'autres façons d'évaluer le coût d'une route que le simple nombre de sauts, et davantage de souplesse dans la signalisation. Notez enfin qu'OLSR peut fonctionner sur des liens de couche 2 variés. Ces liens ne sont pas forcément fiables (par exemple, les liens radio perdent souvent des paquets).

Pour comprendre, et surtout si vous voulez mettre en œuvre OLSR v2, il va falloir lire plusieurs RFC. En effet, la structure des normes OLSR v2 est modulaire : il y a un protocole de découverte des voisins (NHDP, dans le RFC 6130), un format de messages décrit dans le RFC 5444, des TLV normalisés dans le RFC 5497, et (mais celui-ci est optionnel) les considérations sur la gigue du RFC 5148 (variations aléatoires ajoutées pour éviter que tous les messages n'arrivent en même temps). Et, naturellement, il faut ensuite lire ce nouveau RFC 7181 (113 pages).

La section 4 résume le fonctionnement du protocole. Comme les MANETs sont loin de mes domaines de compétence, je ne vais pas la reprendre complètement. Quelques points qui me semblent importants. D'abord, le routeur OLSR a plusieurs bases de données (cf. RFC 6130) dans sa mémoire : il y a sa configuration locale (ses adresses IP), sa liste d'interfaces réseau, avec les métriques de chacune (le « coût » d'utilisation), la base des voisins (très dynamique puisque, dans un MANET, les choses changent souvent, le protocole du RFC 6130 permet de découvrir les voisins, voir aussi la section 15 de ce RFC). Cette dernière base contient les volontés d'un voisin (un nœud peut indiquer sa volonté à être routeur, elle va de WILL_NEVER à WILL_ALWAYS). Et il y a bien sûr la base de la topologie, indiquant la vision du réseau de la machine (les routes qu'elle connait).

Ensuite, OLSR v2, contrairement à son prédécesseur, dispose de plusieurs métriques pour mesurer les coûts d'utilisation d'une route. Un coût est unidirectionnel (il n'a pas forcément la même valeur dans les deux directions).

Le protocole dépend d'un certain nombre de paramètres (section 5). Certains sont spécifiés dans le RFC 5498 comme le numéro de port lorsque OLSR tourne sur UDP (269).

Comme souvent avec les réseaux ad hoc, la sécurité est souvent à peu près nulle. La section 23 de notre RFC fait le point sur les risques associés à OLSR v2 et sur l'approche utilisée si on souhaite sécuriser un MANET. Premier principe, chaque routeur doit valider les paquets (pas seulement leur syntaxe mais aussi leur contenu) puisqu'il ne peut a priori pas faire confiance aux autres. Deuxième principe, la sécurité d'OLSR v2 est réglable. On peut aller de « open bar », on fait confiance à tout le monde, à l'authentification des messages par le biais de signatures attachées aux messages (RFC 7182 et RFC 7183).

Cette sécurité, si on choisit de l'activer, nécessite que les routeurs connaissent les clés cryptographiques servant à l'authentification. OLSR v2 n'a pas de protocoles de gestion de clés. Dans le contexte d'un MANET, il n'y aura souvent pas de moyen de configurer une clé avant d'installer les machines. (Rappelez-vous qu'un MANET est censé être « zéro administration »).

Il existe bien des mises en œuvre de cette version 2 de OLSR, un protocole qui avait commencé sa carrière vers 2005. Citons entre autres (attention, elles ne sont pas forcément libres) :


Téléchargez le RFC 7181


L'article seul

Superviser ses signatures DNSSEC

Première rédaction de cet article le 7 avril 2014


Le système DNSSEC permet d'authentifier les données distribuées via le DNS et protège donc ainsi des attaques par empoisonnement. C'est un outil nécessaire dans la boîte à outils de sécurisation du DNS. Mais rien n'est gratuit en ce bas monde : la cryptographie protège mais elle complique les choses et crée des risques. Parmi ceux-ci, le risque d'expiration des signatures. Il est donc nécessaire de superviser ses signatures DNSSEC. Comment ? Et avec quoi ?

Si vous voulez une introduction à DNSSEC en français, vous pouvez lire mon exposé à JRES. Notez-y un point important : les signatures des enregistrements DNSSEC expirent au bout d'un moment et il est donc nécessaire de re-signer de temps en temps. Si ce processus de re-signature ne marche pas, les signatures vont finir par expirer, rendant le domaine inutilisable. Voici un exemple de signature DNSSEC :


% dig +dnssec A www.bortzmeyer.org
...
;; ANSWER SECTION:
www.bortzmeyer.org.	68585 IN A 204.62.14.153
www.bortzmeyer.org.	68585 IN RRSIG A 8 3 86400 20140414143956 (
				20140325120748 15774 bortzmeyer.org.
				dgJ3BOjUz3hdlRWEbcFK14Jqyl+az/tas/dKEcBs/2QK
				4vUd2VihXtEmpLQ6D+FVtMh6n7OubrEpLezEGkHtXKOe
				3FO6l+EhrjH82BwjGGnd50RMNDHGk8IR0TOsOj/cNGZM
				V4Gj24mOV5ANbYWxlqWXYPl9BVi81MVhluw9sas= )
...

On voit dans la réponse l'adresse IPv4 du serveur et la signature (enregistrement RRSIG). dig formate la signature de manière lisible par un humain, avec une date de mise en service (inception) au 25 mars et une date d'expiration au 14 avril. Ce jour-là, à 14h39 UTC, la signature expirera (le but est d'éviter les attaques par rejeu). Il faudra donc, avant, signer à nouveau. Dans le cas de bortzmeyer.org, c'est fait avec OpenDNSSEC. On pourrait aussi lancer un dnssec-signzone ou bien un ldns-signzone depuis cron. Ou laisser BIND prendre cela en charge avec son mécanisme de signature automatique. Mais toutes ces solutions ont un point commun, elles sont fragiles. Pendant des mois, elles fonctionnent puis, un jour, un léger changement fait qu'elles ne marchent plus et qu'on risque de ne pas s'en apercevoir. Un exemple qui m'était arrivé en changeant de version de Debian : la bibliothèque de SoftHSM avait changé d'emplacement, le fichier de configuration d'OpenDNSSEC pointait donc au mauvais endroit et le signeur d'OpenDNSSEC ne tournait donc plus. Quelques temps après, bortzmeyer.fr expirait...

Le problème n'est pas spécifique à DNSSEC. Dans toutes les solutions de sécurité, il y a des dates limites, conçues pour éviter qu'un méchant qui aurait mis la main sur des informations secrètes puisse les utiliser éternellement. C'est par exemple pour cela que les certificats X.509 ont une date d'expiration (attention, avec DNSSEC, les clés n'expirent pas, seules les signatures le font). Comme le savent les utilisateurs de HTTPS, il est très fréquent que le webmestre oublie de renouveler les certificats et paf. À part des bonnes procédures (rappel mis dans l'agenda...), la solution est de superviser. Tout responsable sérieux d'un site Web HTTPS supervise l'expiration. Il faut faire la même chose pour DNSSEC.

La solution que je vais montrer ici fonctionne avec ma configuration Icinga mais elle ne repose que sur des outils compatibles avec l'API Nagios donc elle devrait marcher avec beaucoup d'outils de supervision.

Après plusieurs essais (voir les notes de ces essais plus loin), j'ai choisi comme outil de base le script de test de Duane Wessels. Ses spécifications collent parfaitement à ce que je veux : il se connecte à tous les serveurs DNS d'une zone, demande les signatures, regarde les dates d'expiration et peut signaler un avertissement ou une erreur selon des seuils choisis par l'utilisateur. Un exemple à la main :

% perl check_zone_rrsig_expiration -Z nic.fr  
ZONE OK: No RRSIGs expiring in the next 3 days; (1.04s) |time=1.042905s;;;0.000000

On peut choisir les seuils, donc mettons qu'on veut un avertissement s'il reste moins d'une semaine :

% perl check_zone_rrsig_expiration -Z nic.fr -W 7
ZONE WARNING: MX RRSIG expires in 3.7 days at ns6.ext.nic.fr; (0.28s) |time=0.281515s;;;0.000000

Pour installer et exécuter ce script, il faut Perl et certains modules indiqués dans la documentation. Sur ma machine Arch Linux, ils n'étaient pas en paquetage standard, il faut donc utiliser AUR, un dépôt non officiel, accessible avec les commandes pacaur ou yaourt :

% yaourt  -S perl-net-dns perl-net-dns-sec

Attention, si vous n'installez pas tous les paquetages indiqués dans la documentation, vous aurez un message pas clair du tout :

***  WARNING!!!  The program has attempted to call the method
***  "sigexpiration" for the following RR object:

Une fois le programme correctement installé, je vous recommande l'option -d si vous voulez déboguer en détail ce qu'il fait.

On configure ensuite Icinga, par exemple :

define command {
        command_name    check-zone-rrsig
        command_line    /usr/local/sbin/check_zone_rrsig_expiration -Z $HOSTADDRESS$ -W $ARG1$ -C $ARG2$
        }

...

define service {
       use dns-rrsig-service
       hostgroup_name My-zones
       service_description SIGEXPIRATION
       # Five days left: warning. Two days left: panic.
       check_command   check-zone-rrsig!5!2
}

define host{
        name                            my-zone
        use                      generic-host
	check_command             check-always-up
        check_period                    24x7       
        check_interval                  5
        retry_interval                  1 
        max_check_attempts              3
        contact_groups                  admins 
        notification_period             24x7
        notification_options		u,d,r
        register 0
}

define hostgroup{
       hostgroup_name My-zones
       members bortzmeyer.org,bortzmeyer.fr,etc-etc
}

define host{
       use moi-zone
       host_name bortzmeyer.fr
}

Une fois que c'est fait, on redémarre Icinga. Ici, voici un test avec une zone délibérement cassée (elle a été signée manuellement en indiquant la date d'expiration ldns-signzone -e 20140322100000 -o broken.rd.nic.fr. broken.rd.nic.fr Kbroken.rd.nic.fr.+008+15802 et sans re-signer ensuite). Icinga enverra ce genre d'avertissement :

Notification Type: PROBLEM

Service: DNSRRSIG
Host: broken.rd.nic.fr
Address: broken.rd.nic.fr
State: WARNING

Date/Time: Fri Mar 28 06:50:38 CET 2014

Additional Info:

ZONE WARNING: DNSKEY RRSIG expires in 1.2 days at ns2.bortzmeyer.org: (1.12s)

Puis un CRITICAL puis, lorsque la zone aura vraiment expiré :

Notification Type: PROBLEM

Service: DNSRRSIG
Host: broken.rd.nic.fr
Address: broken.rd.nic.fr
State: CRITICAL

Date/Time: Mon Mar 31 09:10:38 CEST 2014

Additional Info:

ZONE CRITICAL: ns2.bortzmeyer.org has expired RRSIGs: (1.10s)

Si on re-signe à ce moment, le problème disparait :

Notification Type: RECOVERY

Service: DNSRRSIG
Host: broken.rd.nic.fr
Address: broken.rd.nic.fr
State: OK

Date/Time: Mon Mar 31 09:40:38 CEST 2014

Additional Info:

ZONE OK: No RRSIGs expiring in the next 3 days: (1.04s)

Et, dans le journal d'Icinga, cela apparaitra :

[Fri Mar 21 21:40:32 2014] SERVICE ALERT: broken.rd.nic.fr;DNSRRSIG;CRITICAL;SOFT;2;ZONE CRITICAL: DNSKEY RRSIG expires in 0.6 days at ns2.bortzmeyer.org: (1.09s)
...
[Fri Mar 21 21:42:32 2014] SERVICE ALERT: broken.rd.nic.fr;DNSRRSIG;OK;SOFT;3;ZONE OK: No RRSIGs expiring in the next 7 days: (0.68s)

Pour les utilisateurs d'OpenDNSSEC, le paramètre important à régler en même temps que les seuils de la supervision est le paramètre <Refresh>. Comme le dit la documentation : « The signature will be refreshed when the time until the signature expiration is closer than the refresh interval. » Donc, en pratique, c'est la durée qu'il faut indiquer avec l'option -C (seuil critique). Attention, OpenDNSSEC ajoute de légères variations (jitter).

J'ai indiqué plus haut qu'il y avait des alternatives à la solution finalement choisie. Il en existe même une liste sur le site d'Icinga. Voici quelques pistes avec mes commentaires.

J'aurais pu développer une solution complète avec Python et dnspython qui a une bonne gestion de DNSSEC. J'ai réalisé un prototype mais, dans la vie, il faut savoir reconnaître un logiciel meilleur que le sien.

Il y a un outil développé par les gens de .se, dnssec_monitor. Écrit en Perl, il a les mêmes dépendances que le script choisi. Mais je n'arrive pas réellement à comprendre comment il s'intègre avec Nagios.

Il existe un outil en Ruby dans OpenDNSSEC (il est même décrit en détail dans la documentation d'Icinga). Il a pas mal de dépendences Ruby donc j'ai renoncé.

L'outil nagval est très bien mais il n'a pas le même cahier des charges et, notamment, il ne permet pas de tester l'expiration qui va survenir.

Il existe un énorme ensemble de programmes de tests Nagios qui semble intéressant, et qui compte un check_dnssec_expiration. Il se compile bien :

% ./configure --without-man
% make

mais l'exécution est incohérente, une fois sur deux :

% ./dns/check_dnssec_expiration -v -D nic.fr -w 20 -c 3
CRITICAL - SOA is not signed.

La bogue a été signalée à l'auteur mais pas encore résolue. Il semble que l'outil soit très sensible au résolveur utilisé et qu'il faille forcer (via resolv.conf ou via l'option -H) un résolveur rapide et fiable.

Mat a également un script à lui en awk (avec une version en shell). Mais il est à mon avis très dépendant d'un environnement local, pas utilisable tel quel, sans sérieuses modifications, à mon avis. Je cite l'auteur : « c'est tout à fait adaptable, il suffit de remplacer /usr/bin/make -VSIGNED par la liste des fichiers de zones signés et /usr/bin/make -VSIGNED:R:T par l'ensemble des noms des zones. SIGNED étant défini dans le Makefile comme SIGNED!= find -s * -name '*.signed'. ». Du même auteur, un outil permet de tester des fichiers, pas facilement des zones vivantes :

% cat *.signed | awk -f check-expire.awk

Pour tester une zone vivante, il faut que le transfert de zone soit autorisé :

% dig +noall +answer axfr @$SERVERNAME $ZONE | awk -f check-expire.awk

Enfin, SURFnet a développé un outil (qui dépend de ldns) mais que je n'ai pas réussi à compiler :

...
cc -lcrypto `ldns-config --libs` -o sigvalcheck sigvalcheck.o rrsig_valcheck.o query.o
rrsig_valcheck.o: In function `ldns_rrsig_time_until_expire':
/home/stephane/tmp/sigvalcheck-0.1/rrsig_valcheck.c:42: undefined reference to `ldns_rr_rrsig_expiration'
/home/stephane/tmp/sigvalcheck-0.1/rrsig_valcheck.c:41: undefined reference to `ldns_rdf2native_time_t'

L'article seul

Détournement DNS en Turquie à la réunion FRnog

Première rédaction de cet article le 6 avril 2014


Le 4 avril, à la réunion FRnog 22, j'ai fait un très rapide exposé sur le détournement de serveurs DNS pratiqué par le gouvernement turc.

J'avais déjà analysé ce détournement dans un article en anglais. À FRnog, j'ai présenté une courte synthèse en français dont voici :


L'article seul

RFC 7143: iSCSI Protocol (Consolidated)

Date de publication du RFC : Avril 2014
Auteur(s) du RFC : Mallikarjun Chadalapaka (Microsoft), Julian Satran (Infinidat), Kalman Meth (IBM), David Black (EMC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF storm
Première rédaction de cet article le 5 avril 2014


Le protocole iSCSI permet à une machine d'accéder à des disques (ou autres dispositifs de stockage) situés en dehors, loin de l'atteinte des bus internes de la machine. iSCSI consiste à faire passer les traditionnelles requêtes SCSI sur IP, autorisant ainsi l'utilisation de tous les équipements réseaux qui font passer de l'IP, et dispensant ainsi d'acheter des équipements spécialisés dans les SAN, comme le très coûteux Fibre Channel. iSCSI était à l'origine normalisé dans plusieurs RFC, que ce nouveau document rassemble en une seule (très) grosse spécification.

Résultat, le RFC faisant autorité pour iSCSI est un document de 344 pages, un record ! Il remplace les anciennes normes, les RFC 3720, RFC 3980, RFC 4850 et RFC 5048.

Si jamais vous envisagez de lire le RFC entier, je vous souhaite bon courage. Si vous voulez juste apprendre deux ou trois choses sur iSCSI, révisez d'abord un peu SCSI (les section 2.1 et 2.2 du RFC détaillent la terminologie, la 4.1 les concepts) : c'est un protocole client/serveur où le client (typiquement un ordinateur) se nomme l'initiateur et le serveur (typiquement un disque) la cible. L'initiateur envoie des commandes à la cible, qui répond. Le transport des commandes et des réponses peut se faire sur bien des supports, entre autres SAS, Parallel SCSI et FireWire. Ces supports traditionnels de SCSI ont généralement des faibles portées. iSCSI, au contraire, met les commandes et les réponses sur TCP, donc IP, et les cibles peuvent être à n'importe quelle distance de l'initiateur (même si, en pratique, initiateurs et cibles seront souvent dans le même réseau local).

SCSI peut aussi être utilisé pour parler à des lecteurs de bande, à des DVD, mais aussi, autrefois, à des imprimantes ou des scanners. Chaque dispositif d'entrée/sortie SCSI se nomme un LU (Logical Unit). Une même cible peut comporter plusieurs LU, chacun ayant un numéro, le LUN (Logical Unit Number).

Les commandes sont regroupées en tâches. Chaque tâche est séquentielle (une commande après l'autre) mais un initiateur et une cible peuvent avoir plusieurs tâches en cours d'exécution parallèle.

Les données peuvent évidemment voyager dans les deux sens : si un ordinateur écrit sur un disque, l'initiateur (l'ordinateur) envoie des données à la cible (le disque). Si l'ordinateur lit un fichier, ce sera le contraire, les données iront de la cible vers l'initiateur. Le sens de voyage des données est toujours exprimé du point de vue de l'initiateur. Donc, du « trafic entrant » désigne des données allant de la cible vers l'initiateur (une lecture sur le disque, par exemple).

iSCSI consiste à envoyer les messages SCSI, baptisés PDU (pour Protocol data unit), sur TCP (port 3260 ou à la rigueur 860). Contrairement à ce qui se passe pour d'autres protocoles (comme SIP), données et commandes voyagent dans les mêmes connexions TCP. Pour diverses raisons, il peut y avoir plusieurs connexions TCP actives entre l'initiateur et la cible. On les appelle collectivement la session (équivalent du nexus en SCSI classique). Chaque session a son propre identificateur et chaque connexion TCP de la session a un identificateur de connexion. Des connexions TCP peuvent être ajoutées ou retirées en cours de session, augmentant ainsi la résilience.

La réponse à une commande donnée doit être envoyée sur la même connexion TCP que celle où la commande avait été reçue (« allégeance à la connexion »). Ainsi, si un initiateur demande une lecture de données, celles-ci arriveront sur la même connexion.

L'ordre des commandes est parfois essentiel en SCSI. Pour cela, elles sont numérotées (Command Sequence Number, et cette numérotation est valable globalement pour toute la session), afin que la cible les exécute dans l'ordre. Il existe aussi d'autres numéros (Status Sequence Number) qui ne servent que dans une connexion TCP donnée et sont plutôt utiliser en cas d'erreurs, pour associer un message d'erreur à une commande précise. (Le RFC 3783 décrit avec bien plus de détails le concept d'ordre dans iSCSI.)

À noter que les réponses aux commandes, en SCSI (et donc en iSCSI), ne respectent typiquement aucun ordre. Si une cible exécute la commande A puis la commande B, la réponse à B pourra arriver à l'initiateur avant la réponse à A (ce qui est logique, les opérations d'entrée/sortie pouvant avoir des durées très variables ; la commande B était peut-être très rapide à exécuter).

Les données, elles, ont un ordre. Si on lit 10 000 octets, on veut évidemment recevoir le premier octet des données en premier. D'où le Data Sequence Number qui se trouve dans les paquets de données et qui indique où se trouvent ces données dans le flux transmis.

Un autre point important : TCP fournit un service de flot d'octets continu. Il n'y a pas de séparation entre les PDU (les messages) iSCSI. Pour que le destinataire puisse donc savoir où se termine le PDU (et où commence le suivant), ceux-ci sont préfixés par leur longueur (comme dans beaucoup d'autres protocoles utilisant TCP, par exemple dans EPP et dans le DNS).

Les données peuvent être sensibles (confidentielles, par exemple) et iSCSI doit donc prévoir des mécanismes d'authentification. Ainsi, au début d'une session, l'initiateur se présente et prouve son identité. La cible doit aussi prouver qu'elle est bien la cible visée (authentification mutuelle). Il existe plusieurs mécanismes pour cela, décrits en détail en sections 6 et 12. La recommandation de ce RFC est de protéger les sessions avec IPsec (cf. section 9, ainsi que le RFC 3723).

Au fait, comme toujours en réseau, il faut des identificateurs pour désigner cibles et initiateurs. En iSCSI, il sont appelés noms. Contrairement au SCSI classique où les identificateurs n'ont besoin d'être uniques qu'à l'interieur d'un domaine très restreint (souvent un seul boîtier, parfois une salle machines), iSCSI permet de faire parler des machines situées sur l'Internet et les noms doivent donc être mondialement uniques. (Pour une vue générale du nommage en iSCSI, voir le RFC 3721.) En outre, ces noms doivent (section 4.2.7.1) être stables sur le long terme, ne pas être dépendant de la localisation physique des machines, ni même du réseau où elles sont connectées, et le système de nommage doit être un système déjà existant : pas question de réinventer la roue ! À noter que ce sont des principes analogues à ceux des URN du RFC 1737. Les noms doivent en outre pouvoir être écrits en Unicode, canonicalisés par le profil stringprep de iSCSI, spécifié dans le RFC 3722, puis encodés en UTF-8, forme normale C.

iSCSI fournit trois formats pour atteindre ces objectifs. Un nom commence par un type indiquant quel format est utilisé, puis comprend le nom proprement dit. Les trois types sont :

  • Nom de domaine, type iqn. Comme ceux-ci ne sont pas forcément stables sur le long terme (pour des raisons juridico-politiques, pas pour des raisons techniques), le format iSCSI ajoute une date indiquant un moment où le titulaire avait effectivement ce nom. C'est le même principe que les URI tag: du RFC 4151. Un nom valide comporte le nom de domaine (écrit à l'envers) et donc, on peut voir, par exemple, iqn.2001-04.com.example:storage:diskarrays-sn-a8675309, attribué par le titulaire de example.com.
  • NAA (Network Address Authority), type naa, un système spécifique au monde Fibre Channel. Un exemple de nom NAA est naa.52004567BA64678D.
  • EUI, type eui. un format de l'IEEE permettant de donner des noms uniques aux machines. Par exemple, un nom iSCSI EUI peut être eui.02004567A425678D.

Il existe également des mécanismes de découverte des noms accessibles, décrits dans les RFC 3721 et RFC 4171. Notre RFC note que, malheureusement, certains de ces mécanismes dépendent de SLP (protocole décrit dans le RFC 2608) qui n'a jamais vraiment été implémenté et déployé.

Attention, ce RFC 7143 ne décrit que le transport de SCSI sur IP (en fait, sur TCP). SCSI, lui, reste décrit par ses normes originales (qui ne semblent plus accessibles en ligne). Pour décrire le modèle, elles se servent d'UML, une technique qu'on trouve rarement dans un RFC, d'autant plus qu'elle repose sur de jolis dessins, qu'on ne peut pas facilement reproduire dans un RFC, avec leurs règles de formatage actuelles. Ce RFC comporte donc des diagrammes UML... en art ASCII (section 3).

iSCSI est décrit par une machine à nombre fini d'états et ladite machine figure en section 8.

Évidemment, les disques durs peuvent tomber en panne ou bien le réseau entre l'initiateur et la cible partir en vacances. Il faut donc prévoir des mécanismes de gestion des erreurs, et ils font l'objet de la section 7. C'est ainsi que, par exemple, une tâche qui échoue sur une connexion TCP peut être reprise sur une autre (qui peut passer par un chemin réseau différent). Notez que cette norme n'impose pas aux acteurs iSCSI de tous mettre en œuvre des techniques sophistiquées de récupération d'erreurs, juste de réagir proprement lorsque les erreurs se produisent. La section 7 est très détaillée : après tout, on ne veut pas perdre ses précieuses données juste parce que l'Internet a eu un hoquet pendant une opération d'écriture en iSCSI.

Mais comment détecte-t-on un problème sur une connexion TCP ? Cela peut être un message ICMP qui coupe la connexion mais aussi une absence prolongée de réponse à une commande, ou bien à un test iSCSI (la commande NOP, équivalente du ping IP) ou TCP (les keep-alives du RFC 1122, section 4.2.3.6).

Les pannes, c'est ennuyeux, mais les piratages, c'est pire. On ne veut pas qu'un méchant situé sur le trajet puisse lire nos données secrètes ou modifier ce qu'on écrit sur le disque. En SCSI traditionnel, une grande partie de la sécurité est physique : initiateur et cible sont dans le même boîtier (celui du serveur) ou à la rigueur dans la même armoire avec juste un SAN entre les deux. En iSCSI, on perd cette sécurité physique. Si l'initiateur et la cible sont connectés par le grand Internet, tout peut arriver sur le chemin. La section 9, « Security Considerations », fait donc le tour des menaces et des contre-mesures. (À quoi il faut ajouter le RFC 3723.)

iSCSI peut être utilisé sans sécurité, comme l'ancien SCSI, si on est parfaitement sûr de la sécurité physique. Mais notre RFC déconseille de courir ce risque. iSCSI fournit deux mécanismes de sécurité et le RFC demande qu'on les utilise. Le premier est interne à iSCSI, c'est l'authentification réciproque des deux parties lors de l'établissement de la session. Le deuxième est externe, et c'est IPsec. Ces deux mécanismes doivent être mis en œuvre (même s'ils ne seront pas forcément activés par l'administrateur système, notamment pour IPsec, complexe et pas forcément utile si tout le monde est dans la même salle machines).

À noter qu'une limite d'IPsec est que les systèmes d'exploitation typiques ne permettent pas à une application de savoir si ses connexions sont protégées ou non par IPsec. Ainsi, une application qui voudrait faire une authentification par mot de passe en clair uniquement si la connexion est chiffrée ne peut pas être sûre et doit donc supposer le pire (une connexion non chiffrée). L'authentification interne ne doit donc jamais utiliser de mot de passe en clair. La méthode recommandée est CHAP (RFC 1994, mais avec quelques ajouts). Dans le futur, un mécanisme comme celui du RFC 5433 ou comme SRPRFC 2945 - sera peut-être utilisé.

Le mécanisme interne n'assure que l'authentification réciproque. Il ne protège pas contre l'écoute, ni même contre la modification des messages en cours de route. Il ne doit donc être utilisé seul que si on est sûr que ces écoutes et ces modifications sont impossibles (par exemple si on a une bonne sécurité physique du réseau). Imaginez les conséquences d'une modification des données avant leur écriture sur le disque !

IPsec dans iSCSI doit suivre le RFC 3723 et le tout récent RFC 7146. Avec IPsec, les sessions iSCSI peuvent garantir la confidentialité et l'intégrité des données. À noter que les numéros de séquence IPsec ne sont par défaut que sur 32 bits. iSCSI verra probablement des débits élevés (par exemple plusieurs Gb/s) et ce numéro sera donc vite arrivé au bout. Le RFC demande donc les numéros de séquence étendus (64 bits) de la section 2.2.1 du RFC 4303.

Les programmeurs tireront profit de la section 10, qui rassemble des conseils utiles pour mettre en œuvre iSCSI sans se planter. Un des enjeux de iSCSI est la performance, vu les grandes quantités de données à traiter... et l'impatience des clients. Le protocole a été soigneusement conçu pour permettre d'éventuelles implémentations directement dans le matériel, et pour permettre le DDP (Direct Data Placement, RFC 5041). Ainsi, on peut mettre iSCSI dans le firmware, permettant le démarrage sur une cible iSCSI.

Parmi les points notés par cette section, la gestion des machines dotées de plusieurs cartes réseau (on peut en utiliser plusieurs pour la même session iSCSI), le délicat choix des délais d'attente maximaux (non normalisés, car dépendant de l'infrastructure, notamment matérielle), et l'ordre des commandes (une commande qui change l'état de la cible, par exemple un vidage - flush - des tampons, ne doit pas être envoyée comme commande immédiate, pour éviter qu'elle ne double d'autres commandes).

La section 11 décrit le format exact des PDU sur le câble. Si vous le désirez, on trouve des traces iSCSI sur pcapr.

Il existe de nombreuses mises en œuvre d'iSCSI et des programmeurs de nombreuses entreprises (Dell, EMC, Microsoft, NetApp, Red Hat, VMware, etc) ont participé à la création de ce RFC. Une liste partielle de mises en œuvre :

À part le gros changement éditorial (consolider plusieurs RFC en un seul), les changements de iSCSI dans ce RFC sont peu nombreux. Par exemple, une stricte prohibition des caractères de ponctuation dans les noms SCSI est devenue une forte mise en garde. La section 2.3 liste toutes les modifications.

Merci à Bertrand Petit pour sa relecture attentive.


Téléchargez le RFC 7143


L'article seul

RFC 7164: RTP and Leap Seconds

Date de publication du RFC : Mars 2014
Auteur(s) du RFC : K. Gross (AVA Networks), R. van Brandenburg (TNO)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF avtcore
Première rédaction de cet article le 1 avril 2014


Les secondes intercalaires sont une source de complication et de polémique depuis longtemps. Voilà qu'elles affectent même le protocole de distribution de multimédia RTP : si on regarde un film, ou qu'on a une communication téléphonique, au moment où une seconde intercalaire est ajoutée, RTP va mal le vivre. Ce RFC propose donc un léger changement dans la façon dont RTP tient compte du temps, afin de rester heureux même pendant les secondes intercalaires.

RTP est normalisé dans le RFC 3550. Il est conçu pour l'envoi de flux multimédias (audio ou vidéo) entre un émetteur et un récepteur. Les caractéristiques propres des flux multimédias font que TCP n'est pas très adapté, donc RTP utilise UDP. UDP, par défaut, ne prévoit pas de rétroaction (l'émetteur ne sait pas ce que le récepteur a reçu) donc RTP ajoute des fonctions permettant d'informer son pair de ce qui se passe. Certains flux étant temps réel, ces informations (sender reports et receiver reports, section 6.4 du RFC 3550) incluent des estampilles temporelles. Un des champs de ces informations, NTP timestamp, fait référence à une horloge absolue (l'horloge située sur le mur, synchronisée avec l'échelle UTC). Une horloge qui a des soubresauts, les secondes intercalaires. Or, jouer proprement un flux audio ou vidéo nécessite au contraire une horloge sans à-coups.

La section 3 de notre RFC est un rappel sur les secondes intercalaires. Il y a deux échelles de temps standard. L'une est bien adaptée à l'informatique, à l'Internet et aux activités scientifiques en général, c'est TAI, une échelle fondée sur un phénomène physique (les atomes de césium dans une horloge atomique) et où le temps est strictement croissant et prévisible. Une autre échelle est bien adaptée à l'organisation des pique-niques et autres activités au grand air, c'est UTC. La référence d'UTC est la rotation de la Terre. Comme la Terre, au contraire des atomes de césium, est imparfaite, UTC ne garantit pas que le temps progresse régulièrement, et n'est pas prévisible (je ne peux pas dire aujourd'hui quelle sera l'heure UTC dans cinq cents millions de secondes, alors que c'est trivial en TAI). Depuis 1972, UTC est définie comme étant TAI plus la correction des secondes intercalaires, qui ajoutées de temps en temps, permettent de compenser les variations de la rotation de la Terre. Ces secondes intercalaires sont forcément le dernier jour du mois et, en pratique, ont toujours été fin décembre ou fin juin (cf. texte UIT TF.460). Elles sont annoncées moins d'un an à l'avance dans le bulletin C (rappelez-vous que la rotation de la Terre n'est pas prévisible), par l'IERS.

S'il y a une seconde intercalaire, elle est forcément à la fin de la journée. Elle peut être positive (la dernière seconde de la journée est doublée, et s'affiche « 23 h 59 mn 60 s ») ou négative (la dernière seconde de la journée est omise). Jusqu'à présent, toutes les secondes intercalaires étaient positives, puisque la Terre ralentit (le jour devient plus long). À noter qu'il y a depuis des années une discussion sur la suppression des secondes intercalaires (ce qui serait une mauvaise idée), mais qu'elle n'est pas encore close. Voir mon article sur ce sujet et le document de l'UIT.

La référence de temps la plus commune sur l'Internet, NTP (RFC 5905) est en UTC (ce qui est une mauvaise idée, selon moi, les ordinateurs n'ayant pas besoin de savoir s'il fait jour ou pas). Au moment de la seconde intercalaire positive, l'horloge NTP ralentit (ce qui permet au moins de s'assurer que deux mesures successives donneront un temps strictement croissant) ou s'arrête, ce qui fait que la dernière seconde du jour dure deux secondes. Pour tout processus temps-réel, comme RTP, c'est un gros problème.

Les applications obtiennent en général l'heure via une interface normalisée POSIX. L'échelle de temps de POSIX est UTC, mais sans vraie spécification de la gestion des secondes intercalaires. En pratique, les différentes mises en œuvre de POSIX ont des comportements différents. Par exemple, certaines répètent l'heure, pendant la seconde intercalaire et deux lectures successives du temps à une seconde d'intervalle, peuvent donc donner une heure identique. Pire, l'horloge peut même aller en arrière (ce qu'UTC ne fait pas). D'autres ralentissent l'horloge, permettant une adaptation en douceur (et pas de répétition) mais cela n'est pas idéal non plus pour des applications temps-réel ! (Un bon article sur les problèmes d'utiliser une échelle de temps à secondes intercalaires est donné dans un excellent article de Google.)

Conséquences de ces comportements ? La section 4 note que l'envoyeur et le récepteur RTP peuvent donc avoir une seconde entière de décalage, ce qui est beaucoup pour la plupart des applications RTP. Cela peut mener à l'abandon de paquets RTP bien reçus mais considérés comme trop vieux, ou bien au contraire à la conservation de paquets dans les tampons d'entrée/sortie même lorsqu'ils ne sont plus utiles. Cela peut se traduire par une coupure du son ou de l'image. Certains récepteurs reconnaîtront un problème et se resynchroniseront avec l'émetteur. Les autres devront attendre.

La section 5 liste les recommandations pour éviter ce problème. D'abord, elle note que les récepteurs et émetteurs qui ne sont pas synchronisés avec l'horloge au mur, mais qui se contentent de mesurer le temps écoulé depuis leur démarrage n'auront jamais le problème. Ensuite, la section 5 note aussi que les émetteurs et récepteurs RTP qui utilisent une échelle de temps sans secondes intercalaires (évidemment TAI mais aussi IEEE 1588 ou GPS) n'ont également pas de problèmes. Mais pourquoi diable RTP n'utilise pas systématiquement TAI ? Cette échelle de temps a toutes les propriétés souhaitables pour la communication au sein d'un réseau informatique. Le RFC ne le dit pas, mais c'est probablement parce que TAI est, hélas, trop difficile d'accès sur la majorité des plate-formes. NTP et l'horloge du système fournissent un temps qui convient à beaucoup d'activités humaines, mais ne convient pas aux ordinateurs. Et il n'y a souvent pas de moyen simple d'accéder à TAI ou une autre échelle prédictible. (C'est le cas des fonctions POSIX gettimeoday() et clock_gettime().)

Pour les autres, les mises en œuvre de RTP qui doivent utiliser une échelle de temps qui a des secondes intercalaires, elles sont dans l'obligation de gérer ces secondes intercalaires. Cela implique d'abord un moyen de les connaître à l'avance (par exemple via le champ Leap Indicator de NTP). Ce n'est pas forcément réaliste (bien des machines reçoivent l'heure par des mécanismes qui n'indiquent pas l'approche d'une seconde intercalaire). Une solution un peu crade mais qui marche est alors de prendre les mesures citées plus loin tous les mois, lors de la fin du dernier jour du mois.

Les secondes intercalaires négatives ne posent aucun problème. Mais, on l'a vu, toutes les secondes intercalaires jusqu'à présent ont été positives. Dans ce cas, le RFC recommande que les logiciels RTP n'envoient pas de sender reports pendant les deux secondes où le temps est ambigu, car une seconde intercalaire a été ajoutée. Et les récepteurs doivent ignorer de tels messages. Ce changement aux règles du RFC 3550 est la principale recommandation concrète de ce RFC. Elle ne semble pas encore mise en œuvre dans un seul logiciel RTP. Est-ce que le problème, quoique joli techniquement, est assez grave en pratique pour justifier ce changement ?


Téléchargez le RFC 7164


L'article seul

Hijacking of public DNS servers in Turkey, through routing

First publication of this article on 29 March 2014
Last update on of 30 March 2014


A new step in the fight between the Turkish government and the Internet occurred recently when the access providers in Turkey started, not only to install lying DNS resolvers, but also to hijack the IP addresses of some popular open DNS resolvers, like Google Public DNS.

The first attempt of censorship by the Turkish government was to request (around 20 March) the IAP (Internet Access Providers), who typically provide a recursive DNS service to their users, to configure these recursors to lie, providing false answers when queried about censored names like twitter.com. This is a very common censorship technique, which is used sometimes for business reasons (lying about non-existing domain names, to direct the user to an advertisement page) and sometimes for plain censorship (this was done in France, Bulgaria, Ireland, etc).

An obvious workaround to this technique is to use other resolvers than the IAP's ones. Hence the calls on the walls of many Turkish cities to use a service like Google Public DNS, with the IP addresses of its resolvers

Now, the Turkish governement, replying to the reply, went apparently further. Before discussing what they have done, let's see the facts. We will use the network of RIPE Atlas probes to query Google Public DNS from various places, in the world and in Turkey, since the excellent RIPE Atlas interface allows you to select probes based on many criteria, including the country. The probe can resolve names (like twitter.com, the first censored name) with its local DNS resolver (typically configured by a DHCP reply when the probe starts) but we won't use this possibility, we already know the the IAP's DNS resolvers in Turkey lie. We will instead instruct the Atlas probes to query Google Public DNS, at its IP address 8.8.4.4 (it is less known than 8.8.8.8 but Atlas have an automatic rate-limiter and, since so many people are currently investigating Turkish censorship, Atlas does not accept queries to 8.8.8.8.)

First, to see the ground truth, let's ask a hundred probes worldwide to resolve twitter.com. The measurement ID is #1605067 for those who want to check (most Atlas measurements are public, anyone can download the results as a big JSON file and analyze them by themselves). Since Twitter is implemented by many machines, the IP addresses vary and it's normal. Here is an excerpt:

...
[199.59.148.10 199.59.149.198 199.59.150.7] : 2 occurrences
[199.16.156.38 199.16.156.6 199.16.156.70] : 8 occurrences
[199.59.149.230 199.59.150.39 199.59.150.7] : 5 occurrences
...

All IP addresses do belong to Twitter (checked with whois), which makes sense. Now, let's query only Turkish probes. There are ten available Atlas probes in Turkey. This is measurement #1605068. Here is the full result:

10 probes reported, 10 successes
[199.16.156.230 199.16.156.6 199.16.156.70] : 1 occurrences
[195.175.254.2] : 8 occurrences
[199.16.156.198 199.16.156.230 199.16.156.70] : 1 occurrences
Test done at 2014-03-29T16:57:38Z

Two probes give normal results, with three IP addresses, all in Twitter space. The majority of probes, eight, give an IP address at a Turkish provider (Turk Telekomunikasyon Anonim Sirketi alias ttnet.com.tr). So, there is clearly something fishy: even when you request specifically Google Public DNS, you get a lie.

We can measure with another censored name, youtube.com and we get similar results. In Turkey, measurement #1606453 reports:

10 probes reported, 10 successes
[173.194.34.160 173.194.34.161 173.194.34.162 173.194.34.163 173.194.34.164 173.194.34.165 173.194.34.166 173.194.34.167 173.194.34.168 173.194.34.169 173.194.34.174] : 1 occurrences
[195.175.254.2] : 8 occurrences
[195.22.207.20 195.22.207.24 195.22.207.25 195.22.207.29 195.22.207.30 195.22.207.34 195.22.207.35 195.22.207.39 195.22.207.40 195.22.207.44 195.22.207.45 195.22.207.49 195.22.207.50 195.22.207.54 195.22.207.55 195.22.207.59] : 1 occurrences
Test done at 2014-03-30T15:16:22Z

The same IP address is obtained, and of course it is not possible that the real Twitter and the real YouTube are hosted at the same place.

[All measurements show that two Atlas probes in Turkey do not see the hijacking. Why are they spared? According to the manager of one of these probes, his entire network was tunneled to a foreign server, to escape filtering, which explains why the probe on the network saw normal DNS replies.]

If you try another well-known DNS resolver, such as OpenDNS, you'll get the same problem: a liar responds instead.

So, someone replies, masquerading as the real Google Public DNS resolver. Is it done by a network equipment on the path, as it is common in China where you get DNS responses even from IP addresses where no name server runs? It seems instead it was a trick with routing: the IAP announced a route to the IP addresses of Google, redirecting the users to an IAP's own impersonation of Google Public DNS, a lying DNS resolver. Many IAP already hijack Google Public DNS in such a way, typically for business reasons (gathering data about the users, spying on them). You can see the routing hijack on erdems' Twitter feed, using Turkish Telecom looking glass: the routes are no normal BGP routes, with a list of AS numbers, they are injected locally, via the IGP (so, you won't see it in remote BGP looking glasses, unless someone in Turkey does the same mistake that Pakistan Telecom did with YouTube in 2008). Test yourself:

u*>? 8.8.4.4/32 100 None 
212.156.250.157 None - 
No As-Path 

while a normal route wil look like:

u*>i 74.82.42.0/24 100 1 
212.156.100.1 None - 
6939 
*i 74.82.42.0/24 100 1 
212.156.100.1 None - 
6939 

(6939 being the origin AS of the remote route, here a foreign one, while 8.8.4.4/3 is local)

Another indication that the hijacking is not done by a man in the middle mangling any DNS reply (as it is done in China) is that, if you try a little-known open DNS resolver, there is no problem, even from Turkey, you get correct results (measurement #1605104).

Also, a traceroute to Google Public DNS shows the user is going to Turkish servers, unrelated to the Californian corporation (see this example). RIPE Atlas probes can do traceroutes, too, but for the probes I used, the traceroute gets lost in the network of TTNET Turk Telekomunikasyon Anonim Sirketi, the lying DNS resolver, unlike the real Google Public DNS, does not reply to UDP traceroutes :

From:  212.58.13.159    8685    DORUKNET Doruk Iletisim ve Otomasyon Sanayi ve Ticaret A.S.,TR
Source address:  212.58.13.159
Probe ID:  3506
1    212.58.13.253    8685    DORUKNET Doruk Iletisim ve Otomasyon Sanayi ve Ticaret A.S.,TR    [3.98, 3.235, 3.101]
2    82.151.154.193    8685    DORUKNET Doruk Iletisim ve Otomasyon Sanayi ve Ticaret A.S.,TR    [3.15, 3.044, 3.11]
3    212.156.133.117    9121    TTNET Turk Telekomunikasyon Anonim Sirketi,TR    [4.146, 4.807, 4.157]
4    [u'*', u'*', 'late', u'*']
5    81.212.204.205    9121    TTNET Turk Telekomunikasyon Anonim Sirketi,TR    [11.185, 10.657, 10.67]
6    81.212.204.149    9121    TTNET Turk Telekomunikasyon Anonim Sirketi,TR    [10.864, 11.007, 10.685]
7    ['late', u'*', 'late', u'*', u'*']
8    [u'*', u'*', u'*']
9    [u'*', u'*', u'*']
10    [u'*', u'*', u'*']
11    [u'*', u'*', u'*']
255    [u'*', u'*', u'*']

But RIPE Atlas probes are able to do traceroute with ICMP and, this time, it works:

From:  212.58.13.159    8685    DORUKNET Doruk Iletisim ve Otomasyon Sanayi ve Ticaret A.S.,TR
Source address:  212.58.13.159
Probe ID:  3506
1    212.58.13.253    8685    DORUKNET Doruk Iletisim ve Otomasyon Sanayi ve Ticaret A.S.,TR    [3.866, 3.13, 3.132]
2    82.151.154.193    8685    DORUKNET Doruk Iletisim ve Otomasyon Sanayi ve Ticaret A.S.,TR    [3.316, 3.012, 3.176]
3    212.156.133.117    9121    TTNET Turk Telekomunikasyon Anonim Sirketi,TR    [4.362, 5.976, 4.394]
4    [u'*', u'*', 'late', u'*']
5    81.212.204.205    9121    TTNET Turk Telekomunikasyon Anonim Sirketi,TR    [13.922, 13.574, 13.753]
6    81.212.204.149    9121    TTNET Turk Telekomunikasyon Anonim Sirketi,TR    [13.933, 17.873, 13.571]
7    8.8.4.4    15169    GOOGLE - Google Inc.,US    [11.689, 11.761, 11.897]

Is the lying resolver a full standalone resolver or does it just proxy requests to the real servers, after censoring some names? To be sure, we ask the Atlas probes to query Google Public DNS with the name whoami.akamai.net, which is delegated to special Akamai servers in order to reply with the IP address of their DNS client (thanks to Alexander Neilson for the idea). Measurement #1606450 shows:

10 probes reported, 10 successes
[74.125.18.80] : 2 occurrences
[195.175.255.66] : 8 occurrences
Test done at 2014-03-30T14:49:39Z

We learn with whois that 74.125.18.80 is Google, 195.175.255.66 Turkish Telecom. So, no, Google Public DNS is not proxied but replaced by an impostor which is a full recursor.

There is no other easy way to be sure we talk to the real Google Public DNS or not: Google's servers, unfortunately, do not support the NSID identification system and, anyway, even if they did, it is easy to forge. The only real solution to be sure is the resolver you use, is cryptography. OpenDNS implements DNScrypt but Google DNS has nothing.

Of course, DNSSEC would solve the problem, if and only if validation were done on the user's local machine, something that most users don't do today.

About censoring with DNS, I recommend the comprehensive report of AFNIC Scientific Council. Thanks to Sedat Kapanoğlu for his measurements. Some other articles on this issue:

  • At BGPmon,
  • At Google,
  • At Renesys,
  • At RIPE Labs (with a new proof of the hijacking, based on the latency),
  • At the Internet Society, with an emphasis on the possible solutions (I disagree with the emphasis they put on BGP security since this hijacking was not done with BGP).

On the political side, see the good statement by Internet Society (the previous one was technical).


L'article seul

Répartition des serveurs de noms d'une zone dans plusieurs AS

Première rédaction de cet article le 27 mars 2014


L'accès aux services sur l'Internet commence presque toujours par une requête DNS. Si ce dernier est en panne, il n'y a quasiment pas d'usage de l'Internet possible (sauf si vous vous contentez de traceroute -n...) D'où l'importance de la notion de résilience du DNS. Contrairement à ce qu'on lit parfois, le DNS n'est pas juste une application parmi d'autres : c'est une infrastructure de l'Internet, presque aussi vitale que BGP. La résilience est un phénomène complexe, pas trivial à mesurer. Dans ce très court article, je me concentre sur un seul aspect, la variété des AS parmi les serveurs de noms d'une zone DNS.

Pourquoi est-ce que cette variété des AS est un critère pertinent pour l'évaluation de la résilience ? Parce que certains pannes affectent un site physique (c'est le cas des incendies, par exemple), certaines affectent telle ou telle marque de serveurs de noms ou de routeurs (pensez à cisco-sa-20140326-ipv6) mais d'autres frappent un AS entier. Ce fut le cas de la panne CloudFlare de février 2013 ou de celle d'OVH en juillet 2013, à cause d'OSPF. C'est pour cette raison que ce critère (diversité des AS) figure parmi les métriques de l'Observatoire sur la résilience de l’Internet français. Vous trouverez tous les détails dans ce rapport, mon but est différent, il s'agit d'explorer des zones individuelles.

Bon, OK, toutes choses égales par ailleurs, c'est mieux de répartir les serveurs de noms faisant autorité pour une zone vers plusieurs AS. Mais comment le vérifier ? Si vous avez un flux BGP complet et les outils pour l'analyser, vous pouvez partir de là (regarder les annonces BGP et noter l'AS d'origine). Et si ce n'est pas le cas ? Eh bien, l'excellent service RouteViews exporte, à partir de flux BGP reçus, cette information sur l'AS d'origine d'une route, et la publie notamment dans le DNS, via la zone asn.routeviews.org, qui met en correspondance une adresse IP (IPv4 seulement, hélas, je suis preneur d'informations sur une service équivalent pour IPv6) et le numéro d'AS d'origine :

% dig +short TXT 1.9.0.194.asn.routeviews.org
"2484" "194.0.9.0" "24"

La commande ci-dessus a permis de voir que l'adresse IP 194.0.9.1 était annoncée (sous forme du préfixe 194.0.9.0/24) par l'AS 2484.

On peut alors construire un petit script shell qui va prendre un nom de zone DNS et afficher les AS d'origine de tous les serveurs. Bien sûr, cela ne donnera qu'un aspect de la résilience (notion bien plus riche que juste la variété des AS) et les résultats de ce script doivent être interprétés avec raison. Mais écrire un shell script est un remède souverain lorsqu'on est déprimé ou énervé donc je l'ai fait et il est disponible, fin des avertissements.

Voici un exemple sur le domaine de ce blog. L'outil affiche, pour chaque adresse IPv4 d'un serveur de la zone, l'AS d'origine :

% asns.sh bortzmeyer.org
93.19.226.142: "15557"
79.143.243.129: "29608"
204.62.14.153: "46636"
178.20.71.2: "29608"
106.186.29.14: "2516"
217.174.201.33: "16128"
217.70.190.232: "29169"
83.169.77.115: "8784"
95.130.11.7: "196689"

On voit une grande variété d'AS (y compris un sur 32 bits, cf. RFC 6793). De ce strict point de vue, la zone a des chances d'être robuste.

Essayons avec une autre zone :

% asns.sh  icann.org
199.43.132.53: "42"
199.43.133.53: "1280"
199.43.134.53: "12041"
199.4.138.53: "26710"

Également une bonne variété, on y trouve aussi le fameux AS 42. Et sur un grand site de e-commerce ?

% asns.sh amazon.com
204.74.114.1: "12008"
208.78.70.31: "33517"
204.74.115.1: "12008"
208.78.71.31: "33517"
204.13.250.31: "33517"
204.13.251.31: "33517"
204.74.108.1: "12008"
204.74.109.1: "12008"
199.7.68.1: "12008"
199.7.69.1: "12008"

Celui-ci n'a que deux hébergeurs DNS en tout, donc deux AS seulement.

Un cas plus délicat est fourni par .com :

% asns.sh com
192.54.112.30: "36623"
192.55.83.30: "36618"
192.35.51.30: "36620"
192.33.14.30: "26415"
192.43.172.30: "36632"
192.31.80.30: "36617"
192.5.6.30: "36621"
192.48.79.30: "36626"
192.12.94.30: "36627"
192.42.93.30: "36624"
192.26.92.30: "36619"
192.52.178.30: "36622"
192.41.162.30: "36628"

Il y a beaucoup d'AS mais c'est en fait le même fournisseur, Verisign, qui met un AS par serveur, suivant le RFC 6382.

Et des gens qui ont choisi de mettre tous leurs œufs dans le même panier ? On en trouve :

% asns.sh  leboncoin.fr
213.186.33.102: "16276"
213.251.128.136: "16276"
% asns.sh  laposte.net
195.234.36.4: "35676"
178.213.67.14: "35676"
195.234.36.5: "35676"
178.213.66.14: "35676"

L'article seul

TSIG si on n'utilise pas BIND ?

Première rédaction de cet article le 26 mars 2014


Il existe des zillions (voire des zilliards) de HOWTO et d'articles de blog sur la configuration d'un serveur DNS BIND pour une authentification avec TSIG, par exemple entre serveur maître et serveurs esclaves. Et si on n'utilise pas les outils BIND ? Là, il y a nettement moins de documents. Voici donc un exemple.

Un petit rappel sur TSIG d'abord. Normalisée dans le RFC 2845, cette technique permet à deux serveurs DNS de s'authentifier mutuellement, en utilisant un secret partagé (une sorte de mot de passe, quoi). Comme les secrets partagés ne sont pas pratiques du tout à distribuer et à garder confidentiels, TSIG ne peut pas réalistement s'envisager comme solution générale de sécurisation du DNS. Mais, pour un petit groupe de serveurs qui se connaissent (typiquement les serveurs faisant autorité pour une zone donnée), c'est utile. Cela évite notamment qu'un serveur esclave, croyant parler au maître, parle en fait (par exemple par suite d'un détournement BGP) à un serveur pirate qui lui enverra des fausses données. Bien sûr, si tout le monde faisait du DNSSEC, le problème n'existerait pas, les fausses données seraient détectées par la validation DNSSEC. Mais tant que DNSSEC n'est pas largement répandu, TSIG est un moyen simple et pas cher de sécuriser les communications entre serveurs faisant autorité pour une zone (et qui transfèrent le contenu de la zone avec le mécanisme du RFC 5936).

Supposons maintenant qu'on gère une zone example.com et qu'on ait comme maître un serveur de noms n'utilisant pas du tout BIND ou les outils qui viennent avec. On va alors se servir des outils de la bibliothèque ldns pour générer les clés (les secrets partagés) et NSD comme serveur de noms.

D'abord, on va décider d'avoir une clé (un secret) différente par couple esclave/zone. Mettons que ns1.example.net soit esclave pour la zone example.com, on va nommer la clé ns1.example.net@example.com et on va générer la clé ainsi :

% ldns-keygen -a hmac-sha256  ns1.example.net@example.com
Kns1.example.net@example.com.+159+63629

(L'algorithme HMAC-SHA256 est considéré comme sûr aujourd'hui, TSIG utilisait traditionnellement MD5 qui est fortement déconseillé aujourd'hui.) On obtient alors deux fichiers mais qui ont le même contenu, seul le format est différent. Prenons Kns1.example.net@example.com.+159+63629.private :

% cat Kns1.example.net@example.com.+159+63629.private 
Private-key-format: v1.2
Algorithm: 159 (HMAC_SHA256)
Key: E8mRpGdzXXiT5UZaeUvcecKEjLOu95PJJSN6e4aFnD+cnn4BqkyYgbK2HNyA1m/aSpJIIm9jxS8QnCqvQU2685zO71ozLU02Erhoio1RsdJ0NbU6aYmPt2J+WTms0+yhctHe7XbpXVrhf/XSUAcgwiiAe5t58PDbZQR1Y+ZJbSE=

Le secret partagé est le champ Key: (évidemment, ce secret particulier ne doit plus être utilisé, depuis qu'il a été publié sur ce blog...) Mettons-le dans la configuration du maître NSD :

key:
      name: ns1.example.net@example.com
      algorithm: hmac-sha256
      secret: "E8mRpGdzXXiT5UZaeUvcecKEjLOu95PJJSN6e4aFnD+cnn4BqkyYgbK2HNyA1m/aSpJIIm9jxS8QnCqvQU2685zO71ozLU02Erhoio1RsdJ0NbU6aYmPt2J+WTms0+yhctHe7XbpXVrhf/XSUAcgwiiAe5t58PDbZQR1Y+ZJbSE="

...

zone:
        name: "example.com"
        ...
        notify: 2001:db8:1::3:83  ns1.example.net@example.com
        provide-xfr: 2001:db8:1::3:83	ns1.example.net@example.com

La ligne notify: indique que les notifications de mise à jour (RFC 1996) doivent être signées avec TSIG et notre nouvelle clé. La ligne provide-xfr: indique qu'on n'accepte de transférer la zone qu'à la machine authentifiée avec cette clé. Si vous avez dans le journal :

Mar 23 16:49:05 foobar nsd[23773]: axfr for zone example.com. \
          from client 2001:db8:2::3:83 refused, no acl matches

C'est qu'il y a une erreur (ici, adresse IP inconnue) dans la configuration.

Il ne vous reste plus qu'à envoyer le secret au gérant du serveur esclave, qu'il fasse la configuration de son côté. Naturellement, cela doit se faire de manière confidentielle, par exemple par un message chiffré avec PGP.


L'article seul

L'option GnuPG qui permet de ne pas indiquer les ID...

Première rédaction de cet article le 19 mars 2014


La sécurité, ce n'est pas gratuit. Il y a parfois des techniques qui améliorent la sécurité mais qui sont tellement embêtantes à l'usage qu'on préfère les abandonner. C'est ainsi que je viens de supprimer l'option throw-keyids de ma configuration GnuPG.

Cette option est a priori bonne pour la sécurité : pour citer la documentation elle permet de « ne pas mettre les identificateurs de clé dans le message ». Qu'est-ce que cela veut dire ? Par défaut, GnuPG, lorsqu'il chiffre un message, indique dans le message l'identificateur de la clé du (ou des destinataires). C'est décrit dans le RFC 4880, section 5.1. On peut l'afficher avec gpg :


% gpg report.txt.gpg                   
gpg: encrypted with 2048-bit RSA key, ID 336525BB, created 2009-12-15
      "ISC Security Officer <security-officer@isc.org>"
...

Ici, tout le monde peut voir que ce document a été chiffré pour la clé publique 336525BB, même si, en l'absence de la clé privée, on ne peut pas le déchiffrer. Ainsi, quelqu'un qui a accès au fichier a quand même une information utile, que j'écris des choses pour l'ISC. C'est une métadonnée qui peut être utile à un espion.

L'option throw-keyids permet de résoudre cette indiscrétion :

% gpg report.txt.gpg                                            
gpg: anonymous recipient; ...

Et voilà, l'information a disparu. En mettant throw-keyids dans son ~/.gnupg/gpg.conf, on fabriquera toujours des messages anonymes. J'avais mis cette option dans ma configuration à l'occasion d'un durcissement de sécurité qui accompagnait ma nouvelle clé PGP.

Mais, car il y a un mais, le destinataire légitime ne saura donc pas si le message est bien pour lui, il devra essayer toutes ses clés secrètes. Cela prend du temps et, surtout, cela crée des messages ennuyeux :

gpg: anonymous recipient; trying secret key 1B217B95 ...
gpg: protection algorithm 1 (IDEA) is not supported
gpg: the IDEA cipher plugin is not present
gpg: please see http://www.gnupg.org/faq/why-not-idea.html for more information
gpg: anonymous recipient; trying secret key 1CE01D31 ...
gpg: protection algorithm 1 (IDEA) is not supported
gpg: anonymous recipient; trying secret key CCC66677 ...
gpg: anonymous recipient; trying secret key 96A4A254 ...
...

Notez que GnuPG a essayé toutes les clés secrètes de mon trousseau (y compris les révoquées : le message est peut-être un très ancien, fait avec une vieille clé). Comme certaines sont vraiment anciennes, elles utilisent même IDEA d'où l'avertissement anti-IDEA. D'expérience avec cette option, la plupart de mes correspondants ne comprennent pas ces messages, les interprètent mal, s'énervent, etc. Bref, j'ai fini par supprimer cette option de mon fichier de configuration.

Notez que, pour l'utilisation de PGP pour le courrier électronique, ce n'est pas forcément très grave. Dans le cas « normal  » (pas celui du prudent qui change d'adresse de courrier tout le temps), l'espion éventuel a de toute façon tous les en-têtes RFC 5322 à sa disposition pour accéder à la même information. Pour des fichiers transmis par un autre moyen, il peut être toujours utile de se servir de throw-keyids, par exemple ponctuellement sur la ligne de commande :

% gpg --recipient 9EE8C47B --throw-keyids  --encrypt report.txt

Attention, il existe d'autres possibilités de fuite de l'information.

Merci à Ollivier Robert et Florian Maury pour des discussions intéressantes.


L'article seul

Compter sérieusement le nombre d'attaques informatiques ?

Première rédaction de cet article le 15 mars 2014


La presse à sensation et les rapports des sociétés qui vendent de la sécurité informatique sont pleins de chiffres sur les « cyber-attaques ». Des titres comme « de 10 à 100 attaques à la seconde » ou « une cyber-attaque toutes les 1,5 secondes en moyenne » sont courants. Que signifient-ils ? Quelle est la méthodologie de mesure ? Est-ce sérieux ?

On trouve sans peine des exemples de tels articles. Par exemple dans un journal peu regardant. D'autres ont un ton plus mesuré mais fournissent également leur lot de chiffres invérifiables. En l'absence de détails sur la définition des termes utilisés, aucune comparaison n'est possible. Un autre article de la presse à sensation voit moins d'une attaque par seconde (cent fois moins que l'article cité en premier, cela donne une idée du sérieux de ces chiffres)... Certains font des jolis dessins plus sérieux mais ne divulguent quasiment aucun détail sur leur méthodologie. D'autres sont tellement ignorants qu'ils se trompent aussi bien sur le vocabulaire du droit que sur celui de l'informatique (en appelant « cybercrime » des délits qui ne sont pas des crimes).

Donc, première observation, les chiffres publiés ne veulent rien dire car ils ne sont jamais accompagnés d'une méthodologie, d'une description des indicateurs utilisés. D'où les variations ridicules d'un article à l'autre, et la surenchère. Par exemple, voici un extrait du journal de ce blog, où la machine 188.143.234.90 essaie successivement plusieurs attaques PHP contre le serveur (je n'ai mis qu'une partie des requêtes HTTP) :

188.143.234.90 - - [13/Mar/2014:03:36:14 +0000] "GET /mysql-admin/index.php HTTP/1.1" 404 281 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E; Zune 4.7)" www.bortzmeyer.org
188.143.234.90 - - [13/Mar/2014:03:36:15 +0000] "GET /PMA/index.php HTTP/1.1" 404 281 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E; Zune 4.7)" www.bortzmeyer.org
188.143.234.90 - - [13/Mar/2014:03:36:15 +0000] "GET /php-my-admin/index.php HTTP/1.1" 404 281 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E; Zune 4.7)" www.bortzmeyer.org
188.143.234.90 - - [13/Mar/2014:03:36:15 +0000] "GET /webdb/index.php HTTP/1.1" 404 281 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E; Zune 4.7)" www.bortzmeyer.org
188.143.234.90 - - [13/Mar/2014:03:36:15 +0000] "GET /webadmin/index.php HTTP/1.1" 404 281 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E; Zune 4.7)" www.bortzmeyer.org
188.143.234.90 - - [13/Mar/2014:03:36:15 +0000] "POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%...

Comment dois-je compter ce qui est clairement une attaque ? Il est probable que 188.143.234.90 n'en voulait pas spécialement à mon blog et balayait tout simplement tout un tas de serveurs. Auquel cas, il serait logique de ne compter qu'une attaque pour tous ces serveurs. Mais, si chaque administrateur système compte le passage du bot 188.143.234.90 sur son site comme une attaque, le nombre total d'attaques sera bien plus élevé. Et, si je veux franchement abuser, je peux aussi compter chaque requête HTTP comme une attaque (il y en avait bien plus que ce que je montre ici). Comment font les organisations qui publient les chiffres que la presse reprend sans jamais enquêter, sans jamais chercher un point de vue critique ? Eh bien, on ne sait pas. La publication des chiffres n'est jamais accompagnée de la méthodologie et ces chiffres n'ont donc aucun intérêt.

Peut-être pensez-vous que j'ai vraiment trop abusé avec l'idée de compter chaque requête HTTP comme une attaque. Mais j'ai déjà vu cela en vrai, par exemple sur des firewalls cliquodromesques avec un bouton permettant de générer des jolis camemberts pour PHBs. Chaque paquet rejeté par le pare-feu était compté comme une attaque, ce qui permettait au PHB de se dire chaque matin qu'il avait bien dépensé son argent. (Pour les gens qui ne sont pas administrateurs système ou réseau, précisons que toute adresse IP reçoit en permanence un trafic non sollicité d'attaque ou de reconnaissance, qu'on appelle l'IBR.)

Autre cause de désaccord, comment compter les tentatives de reconnaissance, qui peuvent être malveillantes mais peuvent aussi être de la curiosité. J'ai connu un site où l'administrateur notait chaque telnet (un paquet TCP vers le port 23) comme une attaque... Et que dire alors d'un examen avec nmap qui va illuminer l'IDS comme un arbre de Noël ? Une attaque, aussi ? On voit que l'absence de définition rigoureuse permet toutes les manipulations, dans un sens ou dans l'autre. Enfin, on voit aussi des webmestres crier à l'attaque dès que leur site ralentit sous la charge. Beaucoup de site Web dynamiques sont programmés de telle façon (avec 10 000 lignes de code Java ou PHP à exécuter à chaque requête HTTP) qu'ils s'écroulent très vite dès qu'ils ont un peu de succès. Il est alors tentant d'enregistrer cela comme une attaque plutôt que de reconnaître qu'on avait mal calculé son coup...

Il faut dire que la mauvaise qualité des données n'est pas uniquement due à la paresse et à l'incompétence. Les intérêts économiques ou politiques jouent également un rôle. Il n'existe en effet pas de « chiffres officiels » sur les attaques informatiques (je ne garantis évidemment pas que des chiffres officiels seraient plus fiables...) Les données publiées dans la presse sont donc uniquement issues de dossiers de presse faits par des entreprises qui vendent de la sécurité informatique, et qui ont donc tout intérêt à produire des chiffres élevés. Comme la grande majorité des journalistes n'a ni le temps, ni les moyens, ni la volonté de creuser un peu le sujet, les grands médias ne font que reformuler légèrement ces dossiers de presse, qui leur fournissent du contenu à bas prix. Il y a donc les intérêts économiques (peindre le problème sous les couleurs les plus noires pour vendre ensuite des solutions techniques miracles) et les buts politiques (justifier des lois répressives). Les deux concourent à exagérer les chiffres, et d'autant plus facilement qu'il n'y a jamais d'enquête indépendante et de fact checking.

On a donc un problème qui n'est pas très éloigné de la classique polémique sur les chiffres de la délinquance, mais avec encore moins d'indicateurs fiables. Comme le note Nicolas Caproni « les gens veulent comparer mais comme on n'aura jamais de référentiel commun, ça semble impossible ou tout du moins très imparfait ».

Bon, assez râlé, vont se dire les plus positifs de mes lecteurs, c'est facile de critiquer mais que proposes-tu ? Je n'ai hélas pas de solution miracle. Mais il n'est pas interdit d'explorer quelques pistes :

  • Un représentant des forces de l'ordre m'avait dit une fois que le problème était simple : la définition d'un délit en informatique est claire, il suffit de compter comme attaque toute action illégale. Cette métrique a l'avantage d'être objective mais l'inconvénient de mener à des chiffres colossaux : chaque fois qu'un malware infecte une machine Windows, pouf, article 323-1 du Code Pénal et on a une attaque de plus pour les statistiques.
  • Autre métrique à base juridique, compter le nombre de plaintes déposées. Là, c'est le contraire, on va sous-estimer le nombre d'attaques puisque la plupart ne font pas l'objet d'une plainte (je n'ai pas porté plainte pour les tentatives de 188.143.234.90, trop cher et trop compliqué...)
  • Alors, prenons une métrique moins juridique et plus opérationnelle : compter le nombre de tickets ouverts par le NOC pour incident de sécurité ? Le problème est que cela mesure l'activité du NOC, pas celle des attaquants. Si on augmente les moyens du NOC, mécaniquement, cela augmentera le nombre d'attaques.
  • Bon, et le point de vue rationnel et pragmatique ? L'administrateur système, surchargé de travail, ne compte comme attaque que ce qui perturbe effectivement le service. Mais ce critère utilitariste permet quand même des faux positifs (le slashdottage, cité plus haut, compte comme une attaque puisqu'il perturbe effectivement le service) et des faux négatifs (un pirate qui ne fait que de l'espionnage passif du système se gardera bien de perturber le service et ne sera donc pas compté comme une attaque.)
  • Et compter comme attaque uniquement ce qui réussit ? Le balayage par 188.143.234.90 cité plus haut est ridicule puisque cette machine n'a aucun script PHP. De même, un balayage du port 22 sur une machine où sshd tourne sur un autre port ne serait pas compté comme une attaque. L'inconvénient de ce critère est qu'il dépend davantage de l'activité et de la compétence du défenseur que de l'activité des attaquants.
  • Bref, je ne connais pas de solution idéale. Et vous ? Je suis sûr que vous avez une idée. (Merci à Xavier Belanger pour ses suggestions.)

L'article seul

La NSA a t-elle une webcam dans votre salle de bains ?

Première rédaction de cet article le 14 mars 2014
Dernière mise à jour le 15 mars 2014


Hier, 13 mars 2014, à l'ESGI à Paris, j'ai participé au « Security Day » avec un exposé de spéculation sur les capacités effectives de la NSA. Peut-elle tout écouter et déchiffrer même ce qu'on a chiffré avec les meilleures clés RSA ? HTTPS nous protège t-il contre un tel ennemi ?

Les supports de l'exposé :

Parmi les autres exposés de la journée, je vous recommanderais bien celui de Damien Cauquil sur la sécurité des set-top boxes mais, pour des raisons de sécurité, rien n'est en ligne (résumé : il est trivial de pirater une télé, notamment parce que le chiffrement n'est pas utilisé, et cela fait des jolies copies d'écran).

Merci à Manuel Pégourié-Gonnard pour sa relecture. Et merci aux organisateurs, notamment Dylan Dubief, pour tout le travail. Et merci pour la bière « Cuvée des trolls » en cadeau :-)


L'article seul

RFC 7153: IANA Registries for BGP Extended Communities

Date de publication du RFC : Mars 2014
Auteur(s) du RFC : Eric C. Rosen (Cisco Systems), Yakov Rekhter (Juniper Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 14 mars 2014


Rien de dramatiquement nouveau dans ce RFC sur le protocole de routage BGP. Il s'agit juste d'une réorganisation des registres qui stockent les « communautés étendues », des attributs d'une annonce BGP. Les communautés étendues déjà enregistrées ne sont pas modifiées, les valeurs ne changent pas, le code continue à tourner comme avant, c'est juste la relation entre registres et les règles d'enregistrement qui sont clarifiées.

Ces communautés étendues sont normalisées dans le RFC 4360. Plus grandes que les anciennes communautés du RFC 1997, elles sont structurées en un type, parfois un sous-type et une valeur. (Rappel : il existe en ligne une liste des communautés des principaux opérateurs.) Le type indique entre autres si la communauté est transitive (si elle doit être transmise aux AS voisins) ou pas. S'il n'y a pas de sous-type, on parle de « types normaux » et, s'il y en a un, de « types étendus ». Types et sous-types sont mis dans un registre IANA. Les politiques d'allocation (cf. RFC 5226) varient, une partie de l'espace étant sous une politique restrictive (pour garantir qu'elle ne s'épuisera pas trop vite) et une autre sous une politique plus laxiste (pour faciliter la vie des utilisateurs). Par exemple, une communauté étendue qui commence par 0x0107 indique une propriété spécifique à un préfixe IPv4 (type 0x01), en l'occurence le Route ID / route type (sous-type 0x07) d'OSPF (cf. RFC 4577).

Les anciennes règles étaient spécifiées dans le RFC 4360 mais d'une manière qui s'est avérée trop confuse. D'où la réforme des registres (pas du protocole : les annonces BGP ne changent pas).

Donc, les nouveaux registres, tels que les décrit la section 2 de notre RFC :

Les registres des types doivent découper l'espace de nommage en trois, chaque partie ayant une politique d'allocation différente. De 0x00 à 0x3F, c'est du premier arrivé, premier servi. De 0x80 à 0x8F, réservé à un usage expérimental. Et de 0x90 à 0xBF, il faut une norme. Pour les registres des sous-types, ce découpage est fait une fois pour toutes : de 0x00 à 0xBF (les sous-types sont codés sur un octet, cf. RFC 4360, section 3), la politique est « premier arrivé, premier servi » (très laxiste, donc, cf. RFC 5226), de 0xC0 à 0xFF, la politique « Examen par l'IETF » (très stricte, au contraire : il faut un RFC, et pas un RFC soumis individuellement). Rappelez-vous que tous les types n'ont pas de sous-types. Le fait d'avoir des sous-types est une propriété définie à la création du type (et indiquée dans le registre).

Un cas particulier est traité dans la section 3, celui des communautés étendues spécifiques pour les adresses IPv6. Créées par le RFC 5701, sur le modèle de communautés étendues spécifiques pour les adresses IPv4, elles n'ont en fait jamais été alignées, malgré la demande du RFC 5701 : les sous-types ne correspondent pas toujours. Notre RFC 7153 en prend donc acte et supprime cette demande d'alignement entre les sous-types IPv6 et les IPv4. Les deux registres pour IPv6 sont disponibles, un pour les transitifs et un pour les non-transitifs.

OK, et si je veux déclarer un type ou un sous-type et qu'il se retrouve dans ces beaux registres qui viennent d'être réorganisés, je fais quoi ? La section 4 décrit les procédures d'enregistrement. D'abord, le demandeur doit se poser la question « faut-il un nouveau type ou bien un sous-type d'un type existant peut-il suffire ? » Ensuite, s'il faut un type, doit-il être transitif ou pas ? (Certains types ont un sens dans les deux cas et doivent donc être ajoutés dans deux registres.) Et le type aura t-il des sous-types ? (Ce n'est pas obligatoire d'en avoir mais cela doit être mentionné dès le début.) Et, si oui, ces sous-types seront-ils dans un registre à part (c'est le cas de tous les types à sous-types aujourd'hui) ou bien réutiliseront-ils un registre de sous-types existant ?

Enfin, la section 5 du RFC contient la valeur actuelle des registres, qui sont désormais en ligne à l'IANA.


Téléchargez le RFC 7153


L'article seul

RFC 7166: Supporting Authentication Trailer for OSPFv3

Date de publication du RFC : Mars 2014
Auteur(s) du RFC : M. Bhatia (Alcatel-Lucent), V. Manral (Hewlett Packard), A. Lindem (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ospf
Première rédaction de cet article le 13 mars 2014


La version 2 du protocole de routage OSPF avait un mécanisme d'authentification (annexe D du RFC 2328). Lors de la conception de la version 3 (qui permettait notamment d'ajouter IPv6), ce mécanisme avait été abandonné, l'idée étant que l'IETF avait déjà un mécanisme d'authentification plus général, IPsec, et qu'il « suffisait » de l'utiliser. Selon cette analyse, il n'y avait plus besoin de doter chaque protocole de son propre mécanisme d'authentification. C'était très bien sur le papier. Mais, en pratique, le déploiement d'IPsec est très limité, à la fois en raison de sa complexité et du caractère imparfait de ses implémentations. Résultat, les utilisateurs d'OPSFv3 n'ont, la plupart du temps, pas déployé de mécanisme de sécurité du tout. En voulant faire trop propre, on a donc diminué la sécurité du routage. Le RFC 6506 corrigeait le tir en dotant enfin OSPFv3 d'un mécanisme d'authentification léger et réaliste. Ce mécanisme a été expliqué par l'un des auteurs du RFC sur son blog. Ce nouveau RFC remplace le RFC 6506 et le met légèrement à jour.

OSPFv3 est normalisé dans le RFC 5340, dont le titre (« OSPF pour IPv6 ») est trompeur car, depuis le RFC 5838, OSPFv3 peut gérer plusieurs familles d'adresses et peut donc, en théorie, remplacer complètement OSPFv2. En pratique, toutefois, ce n'est pas encore le cas, notamment pour le problème de sécurité qui fait l'objet de ce RFC : contrairement aux autres protocoles de routage internes, OSPFv3 ne disposait d'aucun mécanisme d'authentification. N'importe quel méchant sur le réseau local pouvait se proclamer routeur et envoyer de fausses informations de routage. L'argument répété était « pas besoin de mécanisme spécifique à OSPFv3, utilisez les mécanismes IPsec, comme expliqué dans le RFC 4552 ». Mais on constate que cette possibilité a été très peu utilisée. Le RFC se contente de noter que c'est parce que IPsec est mal adapté à certains environnements comme les MANET mais il ne parle pas des autres environnements, où IPsec est simplement rejeté en raison de la difficulté à trouver une implémentation qui marche, et qu'un administrateur système normal arrive à configurer.

IPsec a également des faiblesses plus fondamentales pour des protocoles de routage comme OSPF. Ainsi, les protocoles d'échange de clés comme IKE ne sont pas utilisables tant que le routage ne fonctionne pas. Pour résoudre le problème d'œuf et de poule, et parce que les communications OSPF sont de type un-vers-plusieurs (et pas un-vers-un comme le suppose IKE), le RFC 4552 prône des clés gérées manuellement, ce qui n'est pas toujours pratique.

Enfin, l'absence de protection contre le rejeu affaiblit la sécurité d'IPsec dans ce contexte, comme le note le RFC 6039.

La solution proposée figure en section 2. L'idée est d'ajouter à la fin du packet OSPF un champ qui contienne un condensat cryptographique du paquet et d'une clé secrète, comme pour OSPFv2 (RFC 5709) (D'autres types d'authentification pourront être utilisés dans le futur, un registre IANA des types a été créé.) Les options binaires du paquet, au début de celui-ci (RFC 5340, section A.2), ont un nouveau bit, en position 13, AT (pour Authentication Trailer, désormais dans le registre IANA), qui indique la présence ou l'absence du champ final d'authentification (tous les paquets n'ont pas ce champ Options, donc le routeur devra se souvenir des valeurs de ce champ pour chaque voisin).

Pour chaque couple de routeurs ainsi protégés, il y aura un certain nombre de paramètres, qui forment ce qu'on nomme un accord de sécurité (security association, section 3) :

  • Un identifiant sur 16 bits, manuellement défini, le Security Association ID. L'émetteur le choisit et le récepteur le lit dans le paquet. Cette indirection va permettre de modifier des paramètres comme les clés cryptographiques (ou même l'algorithme cryptographique), tout en continuant le routage.
  • L'algorithme utilisé, par exemple HMAC-SHA1 ou HMAC-SHA512,
  • La clé,
  • Des paramètres temporels indiquant, par exemple, à partir de quand la clé sera valide.

Une fois qu'on a toutes ces informations, que met-on dans le paquet OSPF envoyé sur le câble ? La section 4 décrit le mécanisme. Le champ final d'authentification (Authentication Trailer) est composé notamment de l'identifiant d'un accord de sécurité (SA ID, décrit au paragraphe précédent, et qui permet au récepteur de trouver dans sa mémoire les paramètres cryptographiques liés à une conversation particulière), d'un numéro de séquence (qui sert de protection contre le rejeu ; il est augmenté à chaque paquet émis et il comprend 64 bits) et du condensat cryptographique du paquet concaténé avec la clé (la section 4.5 décrit l'algorithme en détail et notamment quels champs du paquet sont inclus dans les données condensées).

Le routeur qui reçoit un paquet utilisant l'authentification (il le sait grâce au bit AT qui était notamment présent dans les paquets OSPF Hello) va accéder au champ d'authentification (le champ Longueur du paquet OSPF lui permet de savoir où commence le champ d'authentification, éventuellement en tenant compte du bloc Link-Local Signaling du RFC 5613, un routeur doit donc gérer au moins en partie ce dernier RFC s'il veut authentifier). Le récepteur refait alors le calcul cryptographique et vérifie si le champ final d'authentification est correct. Le calcul est très proche de celui du RFC 5709 à part l'inclusion de l'adresse IPv6 source.

Supposons que nous soyons administrateur réseaux et que nos routeurs gèrent tous ce RFC. Comment déployer l'authentification sans tout casser ? La section 5 recommande de migrer tous les routeurs connectés au même lien simultanément. Autrement, les routeurs qui n'utilisent pas l'authentification ne pourront pas former d'adjacences OSPF avec ceux qui l'utilisent. Le RFC prévoit un mode de transition, où le routeur envoie le champ final d'authentification mais ne le vérifie pas en entrée mais l'implémentation de ce mode n'est pas obligatoire.

La section 6 contient l'analyse de sécurité de cette extension d'OSPF. Elle rappelle qu'elle ne fournit pas de confidentialité (les informations de routage seront donc accessibles à tout espion). Son seul but est de permettre l'authentification des routeurs, résolvant les problèmes notés par le RFC 6039. À noter que cette extension ne permet pas d'authentifier un routeur particulier mais simplement de s'assurer que l'émetteur est autorisé à participer au routage sur ce lien (tous les routeurs ont la même clé). La clé, rappelle cette section 6, devrait être choisie aléatoirement, pour ne pas être trop facile à deviner (cf. RFC 4552).

Des implémentations de cette option dans le logiciel d'un routeur ? Elle existe dans Cisco (voir leur documentation) et Quagga.

Les changements depuis le RFC 6506 ne sont pas très importants (section 1.2) et sont surtout des clarifications et des corrections de quelques erreurs dans l'ancienne spécification. Ainsi, ce nouveau RFC dit clairement que certaines calculs de somme de contrôle, redondants, doivent être omis (cela avait fait l'objet des errata 3567 et 3568). Et il supprime la possibilité d'utiliser des clés expirées lorsqu'il n'existe plus de clé valide (qui était à la fin de la section 3 de l'ancien RFC ; la nouvelle suggestion est de notifier l'opérateur et d'arrêter d'envoyer les paquets OSPF).


Téléchargez le RFC 7166


L'article seul

RFC 7151: File Transfer Protocol HOST Command for Virtual Hosts

Date de publication du RFC : Mars 2014
Auteur(s) du RFC : P. Hethmon (Hethmon Brothers), R. McMurray (Microsoft)
Chemin des normes
Première rédaction de cet article le 12 mars 2014


On ne peut pas dire que le protocole de transfert de fichiers FTP soit encore très utilisé, largement concurrencé qu'il est par HTTP ou BitTorrent. Mais il existe encore de nombreuses ressources accessibles en FTP et de nombreux serveurs FTP donc l'IETF continue à améliorer le protocole. Cette nouvelle extension résoud un problème : lorsque plusieurs noms pointent vers la même adresse IP et donc le même serveur FTP, ce serveur ne savait pas sous quel nom il avait été désigné à l'origine, et ne pouvait donc pas ajuster son comportement à ce nom. L'extension HOST résoud ce problème en permettant au client FTP d'indiquer le nom original.

Cela se fait depuis longtemps pour HTTP (RFC 2616 qui a créé HTTP 1.1, remplaçant le HTTP 1.0 du RFC 1945) avec l'en-tête Host: envoyé dans la requête, qui permet le mécanisme de virtual hosting (plusieurs serveurs, ayant des comportements différents, sur la même adresse IP). Mais FTP n'avait pas encore l'équivalent. FTP est normalisé dans le RFC 959. Si vous ne connaissez pas ce protocole ou son histoire, je recommande le texte de Jason Scott. Traditionnellement, on n'accédait à un serveur FTP que par un seul nom, et les ressources (fichiers) disponibles ensuite étaient rangés dans des répertoires différents. Si le même serveur FTP anonyme hébergeait un miroir de FreeBSD et un autre de NetBSD, on pouvait créer deux noms, mettons ftp.freebsd.example et ftp.netbsd.example pointant vers la même adresse IP mais, comme la connexion ne se fait qu'avec les adresses IP (après que le logiciel client ait résolu le nom de domaine en adresse IP, grâce au DNS), le logiciel serveur FTP ne pouvait pas savoir le nom utilisé par le client. Résultat, le serveur devait présenter le même contenu, et l'utilisateur, qu'il soit fan de FreeBSD ou de NetBSD voyait à la racine les répertoires de deux systèmes (et probablement de bien d'autres). Un exemple avec l'excellent client ncftp sur un site miroir de FreeBSD :

% ncftp ftp.fr.freebsd.org
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).
Connecting to 158.255.96.2...                                                                                        
Welcome free.org FTP service
Logging in...                                                                                                        
Login successful.
Logged in to ftp.fr.freebsd.org.                                                                                     
ncftp / > ls
debian@   mirrors/  private/  pub/      stats/    ubuntu@

ncftp / > cd mirrors/
Directory successfully changed.
ncftp /mirrors > ls
archive.ubuntu.com/          ftp.freebsd.org/             releases.ubuntu-fr.org/
cdimage.debian.org/          ftp.ubuntu.com/              releases.ubuntu.com/
ftp.debian.org/              ftp.xubuntu.com/             videolan/

Il aurait quand même été plus pratique d'arriver directement dans mirrors/ftp.freebsd.org ! Le fait que le serveur ne connaisse pas le nom original a d'autres conséquences, comme de ne pas pouvoir utiliser des systèmes d'authentification différents selon le nom (accès FTP anonyme sur certains et pas sur d'autres, par exemple).

La section 3 du RFC décrit cette extension HOST. Elle a la forme d'une commande qui doit être envoyée au serveur avant l'authentification (rappelez-vous qu'un des buts de cette commande est d'avoir la possibilité d'authentifications différentes selon le serveur virtuel). Le serveur doit répondre par un code 220 si tout s'est bien passé. Le RFC recommande que le serveur n'envoie le message de bienvenue qu'après la commande HOST puisque cela lui permettrait d'adapter le message de bienvenue au nom utilisé. Voici un exemple, où « C> » indique un message envoyé par le client FTP et « S> » un message envoyé par le serveur FTP :

C> HOST ftp.example.com
S> 220 Host accepted

Et, en cas d'authentification :

C> HOST ftp.example.com
S> 220 Host accepted
C> USER foo
S> 331 Password required
C> PASS bar
S> 230 User logged in ftp.example.com

La commande HOST prend comme paramètre le nom de domaine qui a été utilisé par le client, après d'éventuelles normalisations comme l'ajout d'un suffixe (par contre, si c'est un alias dans le DNS, on utilise l'alias, pas le nom canonique). Si le nom est un IDN, c'est la forme Punycode qui doit être utilisée dans la commande HOST :

% logiciel-client ftp.café-crème.example
C> HOST ftp.xn--caf-crme-60ag.example
S> 220 Host accepted

Si l'utilisateur humain avait utilisé directement une adresse IP, c'est elle qu'on passe à la commande HOST :

C> HOST [2001:db8::c000:201]
S> 220 Host accepted

Ou bien :

C> HOST 192.0.2.1
S> 220 Host accepted (but you should use IPv6)

Par contre, le client ne doit pas indiquer le numéro de port, même lorsque c'était un port non-standard. En effet, le serveur le connait déjà, puisqu'il a cette information dans les données de connexion.

Que doit faire le serveur en recevant un HOST ? Il doit normalement vérifier que ce nom correspond bien à un des serveurs virtuels déclarés dans sa configuration. Sinon :

C> HOST ftp.example.net
S> 504 Unknown virtual host

(Le serveur peut, à la place, décider d'envoyer le client vers le serveur virtuel par défaut.) En cas de succès, le serveur peut ensuite s'adapter à ce nom : changer de répertoire par défaut, activer un autre méthode d'authentification, etc.

Mais que se passe t-il si l'utilisateur a un vieux client FTP qui n'envoie pas de HOST ? Là aussi, c'est au serveur de décider quoi faire dans ce cas (utiliser un serveur virtuel par défaut, refuser la connexion, etc). Et si c'est le serveur qui est vieux et qui ne connait pas HOST ? C'est alors le cas normal d'une commande inconnue (RFC 959, section 4.2) :

C> HOST ftp.example.com
S> 502 Unimplemented

Un peu plus compliqué, le cas où la session est protégée par TLS. Si le client utilise l'indication TLS du nom, normalisée dans l'extension server_name (RFC 6066), le serveur doit vérifier que le nom donné en paramètre à HOST est le même que celui de la session TLS.

Des questions de sécurité ? Comme indiqué plus haut, l'utilisation de la commande HOST peut faire changer de système d'authentification. Il est donc crucial que le serveur FTP sépare bien les serveurs virtuels pour éviter, par exemple, qu'on puisse se connecter sur un serveur virtuel avec les lettres de créance d'un autre. Idem lorsque le client authentifie le serveur avec les certificats du RFC 4217. Notre RFC rappelle également l'utilité des extensions d'authentification du RFC 2228 et l'intérêt de la (re)lecture du RFC 2577 sur la sécurité des serveurs FTP.

La nouvelle commande HOST est désormais officiellement enregistrée dans le registre IANA.

L'annexe A discute des autres choix qui auraient pu être faits mais qui ont finalement été rejetés. Une solution possible était d'étendre la commande déjà existante CWD (Change Working Directory) en lui donnant comme argument le nom du serveur virtuel. Cela permettrait ainsi d'avoir des sous-répertoires différents par serveur virtuel, comme c'est déjà souvent le cas (regardez l'exemple de ftp.fr.freebsd.org et de son répertoire mirrors/). Mais cela a des limites : CWD n'est accepté qu'après l'authentification et ne permet donc pas d'avoir des mécanismes d'authentification différents selon le serveur virtuel. Et ça manque de souplesse en forçant une certaines organisation des répertoires du serveur (ou bien en modifiant le code du serveur pour traiter cette première commande CWD différemment. Et ce n'est pas terrible du côté sécurité, un visiteur pouvant facilement voir tous les serveurs virtuels.

Une autre solution qui avait été suggérée était la commande ACCT qui permet de choisir un compte particulier, mais après l'authentification. Elle a donc un défaut en commun avec CWD, elle ne permet pas une authentification différente par serveur virtuel. (Ni d'utiliser des certificats différents, lorsqu'on utilise les extensions de sécurité des RFC 2228 et RFC 4217).

Et la commande USER ? Pourquoi ne pas l'étendre en ajoutant le serveur virtuel ?

C> USER foo@example.com
S> 331 Password required
C> PASS bar
S> 230 User logged in

Le problème est que certains environnements ont déjà des comptes utilisateurs comportant un @domaine, cas qu'on ne pourrait pas distinguer de celui où on indique un serveur virtuel. Et les extensions de sécurité de FTP mentionnées plus haut font la négociation de certificats avant le USER donc, là encore, on ne pourrait pas avoir des certificats différents selon le serveur virtuel.

Cette extension à FTP est ancienne (première proposition en 2007, apparemment), même si elle n'avait pas été formellement normalisée. Elle est incluse dans IIS comme documenté par un des auteurs du RFC, dans le serveur ncftpd, dans le serveur proftpd... Mais je n'ai pas testé ce que cela donnait en vrai (il faudrait déjà trouver un client qui le gère).


Téléchargez le RFC 7151


L'article seul

RFC 7149: Software-Defined Networking: A Perspective From Within A Service Provider

Date de publication du RFC : Mars 2014
Auteur(s) du RFC : M. Boucadair (France Telecom), C. Jacquenet (France Telecom)
Pour information
Première rédaction de cet article le 6 mars 2014


Ah, le SDN (Software-Defined Networking)... Un buzz word fort du moment, il est, chez les techniciens, l'équivalent de cloud chez les commerciaux... Le terme est tellement vague et mal défini qu'il peut désigner tout et n'importe quoi. Dans ce RFC, les deux auteurs explorent le concept, tentent une définition, et nous exposent leur analyse (plutôt critique) du SDN.

SDN désigne en général un ensemble de techniques (dont la plus connue est OpenFlow) permettant de gérer centralement un réseau, lorsque ce réseau est sous une autorité unique (contrairement à ce qu'on lit parfois, le SDN n'a donc pas vocation à être déployé sur l'Internet). L'idée est de ne plus confier aux seuls protocoles de routage la capacité de configurer les éléments du réseau, mais de définir une politique, de la configurer dans une machine centrale, et de l'appliquer ensuite aux éléments du réseau. On voit que, dans la définition la plus générale du SDN, si on remplace les employés qui se loguent sur les routeurs et les commutateurs pour les configurer par un logiciel du type de Ansible ou Puppet, on fait du SDN sans le savoir.

Ah, mais justement, quelle est la bonne définition de « SDN » ? Notre RFC 7149 commence par noter qu'il n'existe pas de définition rigoureuse unique (comme avec tous les buzz words). L'approche des auteurs est de partir des services réseaux (d'où le titre du RFC) puis de tenter une introduction à SDN. La section 1 du RFC se penche sur les problèmes du fournisseur de services, à partir de l'exemple du VPN. Fournir un service de VPN à ses clients nécessite l'activation de plein de capacités différentes : adressage et routage, bien sûr, mais aussi création des tunnels, qualité de service, filtrage pour la sécurité, et bien sûr tout ce qui est nécessaire à la supervision. La méthode traditionnelle, qui consiste à configurer manuellement (via la ligne de commandes ou via une interface graphique) un grand nombre de machines différentes (car ce n'est pas une seule machine qui va avoir toutes les capacités citées plus haut) est lente, coûteuse et l'erreur arrive vite. Il est évident qu'il faut automatiser, si on ne veut pas laisser le client attendre son VPN pendant des jours... pour qu'il découvre finalement qu'une des fonctions attendues ne marche pas suite à une légère erreur humaine. Donc, si vous voulez survivre dans le business du VPN, vous allez utiliser un programme pour configurer tout cela.

Bon, mais, d'abord, c'est quoi le SDN ? La section 2 du RFC se penche sur le problème de la définition. C'est évidemment difficile car le sigle a été usé et abusé par les marketeux. Par exemple, on définit parfois le SDN comme la séparation, dans les routeurs entre le système de contrôle (en général fait en logiciel sur un processeur généraliste) et le système de transmission (souvent fait par des circuits électroniques spécialisés donc considéré à tort comme n'étant pas du logiciel). Cette séparation offre plus de souplesse d'un côté et plus de performances de l'autre. Mais notre RFC pointe tout de suite que cette séparation est faite depuis de nombreuses années : si c'est là toute la nouveauté du SDN, cela ne vaut pas la peine. En fait, quand on dit « SDN », on ajoute souvent un point important à cette séparation : que le système de contrôle, au lieu d'être dans chaque routeur, vaguement coordonnés par un protocole de routage comme OSPF, soit centralisé, et standardisé pour que le contrôleur et le contrôlé puissent être achetés à des fournisseurs différents. Dans cette définition du SDN, les routeurs et autres équipements réseaux sont « bêtes », juste capables de transmettre les paquets, et un contrôleur « intelligent » fait tous les calculs avant de transmettre des ordres simples aux routeurs. (On parle de PDP - Policy Decision Point - pour le contrôleur et de PEP - Policy Enforcement Point - pour les équipements réseau.)

L'argument en général donné par les pro-SDN est celui de la flexibilité. Lorsque de nouvelles exigences apparaissent, par exemple pour offrir un nouveau service aux clients, on change juste le logiciel du contrôleur et tout le reste du réseau suit gentiment. À noter que cela va au delà du routage : il faut aussi pouvoir transmettre aux clients des ordres portant sur la réservation de capacité réseau, par exemple. (Les solutions commerciales qui se disent « SDN » se vantent toutes de leur flexibilité, sans toujours préciser qu'est-ce qui est flexible et qu'est-ce qui est fixé.)

À noter que ces calculs dans le contrôleur supposent que celui-ci dispose d'un bon modèle du réseau. Puisque les équipements réseau vont lui obéir aveuglément, il ne faut pas qu'il transmette des ordres qui mènent à, par exemple, une congestion du réseau. Pour cela, il doit donc connaître les détails du réseau, de façon à être capable de prédire les conséquences de ces actions (ou de façon à pouvoir dire à l'administrateur réseaux « désolé, Dave, ce que tu me demandes est impossible »). Cela peut nécessiter le développement de meilleurs émulateurs de réseau, pour pouvoir tester les conséquences d'un ordre avant de l'envoyer.

Armés de ces précautions, les auteurs du RFC définissent donc le SDN comme « l'ensemble des techniques utilisées pour :

  • faciliter l’ingénierie,
  • améliorer le temps de production,
  • simplifier l’exploitation de services réseau d’une manière déterministe, dynamique et capable d’être déployée à grande échelle.

 ». On note qu'ils n'insistent pas sur le côté « logiciel » (le S de SDN), les mécanismes réseau étant par essence à base de logiciels.

Ce beau programme nécessite des techniques pour :

  • Découvrir la topologie du réseau (on ne peut pas commander un réseau qu'on ne connait pas), les capacités des équipements actifs, et comment les configurer,
  • Donner des ordres aux équipements réseau,
  • Avoir un retour sur l'exécution des ordres donnés, et sur leurs résultats.

OK, c'est très joli mais est-ce réaliste ? La section 3 se le demande. Un écosystème comme l'Internet est l'un des objets les plus complexes jamais conçus par l'humanité (et il existe des tas de réseaux qui, sans être aussi gros que l'Internet, sont d'une taille et d'une complexité redoutables). Les exigences des utilisateurs sont innombrables et souvent difficiles à concilier (résilience, y compris face aux attaques délibérées, performances, flexibilité, rapidité de déploiement des changements...) Le RFC suggère donc une certaine modestie. D'abord, se souvenir du passé. On l'a vu, les promesses du SDN étaient souvent plus ancrées dans le verbiage commercial que dans la réalité. Quand elles faisaient référence à quelque chose de concret, c'était parfois quelque chose qui existait depuis longtemps mais qui avait été rebaptisé « SDN » (qui se souvient des vieux slogans commerciaux comme « Active Networks » ou « Programmable Networks » ?) C'est ainsi que les NMS ou le PCE (RFC 4655) ont parfois été enrôlés contre leur gré sous la bannière « SDN ». Pour la séparation du système de contrôle et du système de transmission, on peut aussi citer le routage via le DNS (RFC 1383) ou évidemment ForCES (RFC 5810).

Autre suggestion de modestie, être pragmatique. Le SDN doit être utilisé s'il aide, pas juste pour le plaisir de faire des exposés à NANOG. Par exemple, la centralisation du contrôle ne doit pas conduire à diminuer la résilience du réseau en en faisant un SPOF. Si le contrôleur est en panne ou injoignable, il faut que les équipements réseau puissent au moins continuer à assurer leurs tâches de base (bien sûr, les contrôleurs sont redondés mais cela ne suffit pas dans tous les cas). Autre exemple de pragmatisme, il faut mesurer le réseau et s'assurer qu'on a réellement obtenu le résultat voulu.

D'autant plus que rien n'est gratuit dans ce monde cruel. La souplesse et la réactivité que fournissent les possibilités de configuration des équipements ont un coût, par exemple en rendant plus difficile, si on utilise des interfaces standard, d'optimiser les performances, puisqu'on ne pourra pas forcément toucher aux fonctions les plus spécifiques du matériel.

Lorsqu'on dit « SDN », on pense souvent immédiatement à OpenFlow, la plus connue des techniques vendues sous ce nom. Mais le SDN ne se réduit pas à OpenFlow et bien d'autres protocoles peuvent être utilisés pour de la configuration à distance (de PCEP - RFC 5440 - à NETCONFRFC 6241 en passant par COPS-PRRFC 3084 - ou RPSLRFC 2622). OpenFlow n'est donc qu'un composant possible d'une boîte à outils plus large.

Enfin, lorsqu'on fait une analyse technique d'un mécanisme, il est important de voir quels sont les « non-objectifs », les choses qu'on n'essaiera même pas d'atteindre (dans le discours commercial, il n'y a pas de non-objectifs, la solution proposée est miraculeuse, guérit le cancer systématiquement et fait toujours le café) :

  • La flexibilité rencontrera toujours des limites, ne serait-ce que les capacités du matériel (aucune quantité de SDN ne permettra à un routeur d'aller plus vite que ce que lui permettent ses interfaces réseaux et ses ASIC),
  • La modularité et la programmabilité se heurteront aux limites du logiciel, comme la nécessité de tests (le software est nettement moins soft que ne s'imaginent les décideurs),
  • Le contrôle absolu depuis un point central est très tentant pour certains mais il se heurte aux problèmes de passage à l'échelle et à la nécessité que les équipements aient assez d'autonomie pour gérer les déconnexions temporaires.

La section 4 du RFC discute ensuite plus en détail certains problèmes qu'on rencontre sur la route du SDN. Premier problème cité, toute automatisation d'un processus est vulnérable aux bogues dans le logiciel : c'est par exemple le syndrome du « robot fou » qui, ne se rendant pas compte que ses actions mènent à des catastrophes, les continue aveuglément (deux exemples, un avec Ansible et un avec Flowspec). Autre difficulté qui ne disparaitra pas facilement, l'amorçage du SDN : la première fois qu'on le met en place, les équipements et le contrôleur ne se connaissent pas et doivent apprendre leurs capacités. (Et utiliser le réseau pour configurer le réseau soulève plein de problèmes intéressants...)

Gérer un réseau, ce n'est pas seulement le configurer et faire en sorte qu'il démarre. Il faut aussi assurer le déboguage, la maintenance, les statistiques, la détection (et la correction) de problèmes, tout ce qui est désigné sous le sigle OAM (Operations And Management, cf. RFC 6291). Le SDN doit prendre cela en compte.

On l'a vu, un des principes du SDN est la concentration de l'« intelligence » en un point central, le PDP (Policy Decision Point, là où on configure les services attendus). Cela pose des problèmes pour la résilience du réseau ou tout simplement pour son passage à l'échelle. Un mécanisme permettant d'avoir plusieurs PDP synchronisés semble donc nécessaire. En parlant de passage à l'échelle, le RFC signale aussi que certaines promesses du SDN vont être difficiles à tenir. Par exemple, avoir des machines virtuelles ayant des politiques de QoS différentes, et migrant librement d'un data center à l'autre est faisable en laboratoire mais ne va pas passer à l'échelle facilement.

Enfin, il ne faut pas oublier les risques, souvent négligés lors de la présentation d'une belle technologie qui brille. Le contrôleur va devenir le point faible du réseau, par exemple. Et la sécurité du SDN n'a pas encore été tellement mise à l'épreuve (section 6 du RFC).

Merci à Mohamed Boucadair et Christian Jacquenet pour leur relecture.


Téléchargez le RFC 7149


L'article seul

Articles des différentes années : 2014  2013  2012  2011  2010  2009  2008  Précédentes années

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu