GuiGui's Show

Sur une machine GNU/Linux, on observe plein de fichiers /dev/ttySx même sur les machines qui ne sont pas équipées d'un port série (RS232).

Comment savoir sur quel device (/dev/ttyS?) a été mappé le port série de votre ordinateur ?

find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
  - Pourquoi j'exclu les fichiers dans /sys/class/tty/ ? Pour ne pas avoir les devices eux-mêmes
  - Pourquoi j'exclu les fichiers qui se trouvent dans un chemin contenant "serial8250" ? La ressource pointée par ce shaarli l'explique très bien : « ttyS* under "serial8250" probably doesn't exist (they are present by default because it's hard to detect if they are present or not)  »

Exemples :
  - Sur une machine sans port série :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    $ [ Aucun résultat ]

  - Sur une machine avec un port série soudé sur la carte mère :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    /sys/devices/pnp0/00:08/tty/ttyS0 [ notre port série est donc mappé sur /dev/ttyS0 ]

  - Sur une autre machine avec un port série soudé sur la carte mère :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    /sys/devices/pnp0/00:0b/tty/ttyS0  [ notre port série est donc mappé sur /dev/ttyS0 ]

:D

« We're looking for someone with the wisdom of a 50-year-old, the experience of a 40-year-old, the drive of a 30-year-old and the pay scale of a 20-year-old. »

C'pas un scoop mais c'est toujours aussi vrai.

Via http://sebsauvage.net/links/?a04rcA

Ok donc mailman (gestionnaire de ML) propose un système anti-spam basé sur les headers « To » et « Cc » : si l'adresse de la ML n'est pas dans ces champs, le mail est placé en attente de modération. Ça évite les bots qui mettent plein de ML en « Bcc ». C'est activé par défaut mais débrayable.

Une telle option n'est pas activée de base dans Sympa. Je suis sceptique sur l'efficacité d'une telle méthode : je gère des ML avec Sympa et les spams que j'ai reçu contenaient bien XXXX adresses de ML en Cc ... Les spammeurs vont à la simplicité car c'est un gage d'efficacité et donc de rentabilité.

Du coup, quand une ML doit envoyer un mail à une autre ML (mailman), ça ne marche pas puisque l'émetteur original a mis l'adresse de la première ML en « To » ou « Cc » (il ne sait pas que ça va être cascadé dans une autre ML). Heureusement, mailman propose un système de liste blanche en fonction du header « To » : « acceptable_aliases ».

« Installer Windows 10 Technical Preview sur son ordinateur donne à Microsoft à peu près tous les droits, y compris celui de collecter des informations sur votre historique de navigation ou ce que vous saisissez sur votre clavier.

[...]

Le but est d'alimenter un véritable centre de télémétrie qui serait appelé en interne "Asimov", pour permettre aux équipes de développement de Windows 10 de voir en temps réel comment s'adaptent les utilisateurs, et quels sont les éventuels problèmes à régler.

[...]

Mais pour y parvenir, selon la politique de vie privée spécifique à la Technical Preview, Microsoft s'autorise à collecter énormément de données (il faudrait chercher ce qu'il ne collecte pas)

[...]

En réponse aux réactions, Microsoft a tenu à rappeler qu'il s'agit d'une preview destinée aux tests technologiques (d'où le nom : "Technical Preview"), et qu'au moins une partie  [NDLR : MDR] de ces informations ne seront plus collectées lors de la version finale ou des prochaines versions bêta.

Par ailleurs, "toutes les données envoyées de Windows 10 Technical Preview vers Microsoft sont chiffrées en transit et nous stockons les informations que vous fournissez sur des systèmes informatiques qui sont en accès limité et dans des centres contrôlés" [NDLR : des centres contrôlés par la NSA ? :D ], veut rassurer la firme de Redmond. »

C'est mignon tout plein. :')

Vous avez une image disque (obtenue avec dd, par exemple) qui contient plusieurs partitions dont une luks + lvm et vous voulez accéder au contenu d'un LV dans cette partition ? Aucun problème avec kpartx, l'outil qui « Create device maps from partition tables. ».

Ça marche aussi pour accéder au contenu d'un LV contenu dans un VG contenu dans un PV qui serait lui-même dans un LV (cas d'une virtualisation, par exemple : chaque VM à un LV dans le VG hôte et est libre de faire du LVM dedans).

« Ma doc sur ganeti au taff… déjà beaucoup d'info, j'en rajouterai par la suite. En tous cas il y a moyen de faire un setup sympa : cluster de VM (donc on peut les bouger même si l'host tombe), avec disques directement (sans montage) dans un stockage partagé via la libgfapi de GlusterFS.
Là où je me suis bien amusé c'est avec le script pour installer GRUB dans un chroot… »

Très intéressant les hooks GRUB + set de l'IPv4 (bouh, y'a pas IPv6). Installer GRUB directement dans la VM permet de pas utiliser le même noyau que l'hôte ni de dupliquer une VM "modèle" mais bel et bien d'avoir une nouvelle VM (issue d'un debootstrap) totalement indépendante.

Via https://twitter.com/bortzmeyer/status/517687819557691393

« Lors des débats à l'Assemblée sur le projet de loi Cazeneuve dit "terrorisme", le ministre de l'Intérieur a indiqué qu'il travaillera avec tous les fournisseurs d'accès. Puisque la Fédération, ce sont 26 fournisseurs d'accès, elle s'est sentie invitée à participer. Par la présente lettre ouverte, la Fédération FDN accepte donc l'invitation faite par le ministre de l'Intérieur à venir prendre part aux discussions sur les décrets qui mettront en oeuvre la censure par les FAIs sur décision secrète de la police.

[...]

Oh, il n'y a pas d'illusion à se faire. Il est peu probable que la lettre ouverte de la Fédération soit suivie d'effets. Mais voilà, nos gouvernants ne parlent qu'aux gens du même monde qu'eux, soit-disant capitaines d'industrie.

Il faut être juste, on constate une vraie ouverture de la part de certains services, en particulier de ceux qui sont spécialisés dans le numérique: l'ARCEP nous connaît, et nous écoute parfois; le Conseil national du numérique tient compte de nos positions sur certains dossiers clefs où nous sommes considérés comme spécialistes; la CNIL sait que nous existons; en son temps, le ministère de l'Économie numérique nous invitait à parler sur le neutralité du net, etc.

Mais ces cas sont encore trop rares. L'aménagement numérique du territoire ? Ce sont des échanges de milliards entre copains, jamais la plèbe des FAIs de moins d'un milliard n'est consultée sur rien. Les études d'impact au ministère de l'Intérieur ? On en a parlé à Orange, ça doit bien suffir. Les travaux de ministère de la Culture ? Même chose. Les accords Olivennes pour faire HADOPI ? C'est signé par 4 FAIs, c'est bien que tous les représentants d'Internet sont d'accord. Le statut des hébergeurs ? Les hébergeurs, c'est Twitter, Facebook et Youtube, ils sont américains, donc on s'en fout.

Nous faisons l'effort, autant que nous le pouvons, de respecter les obligations idiotes des fournisseurs d'accès. Nous essayons, autant que le peut un groupe de bénévoles, de défendre certaines valeurs, de faire du réseau humain, et pas du business. Il nous semble que les personnes chargées de l'administration de la chose publique pourraient être tenues à une certaine impartialité, à traiter tous les acteurs sur un pied d'égalité, à prendre en compte la diversité existante.

Encore une fois, il est peu probable qu'on modifie en profondeur ces habitudes pénibles. Mais on va quand même essayer. On ne sait jamais, ça pourrait bouger, un tout petit peu. »

Très bon rapport, comme chaque année. Les explications sur les technos (DNSSEC, RPKI+ROA par exemple) sont synthètiques et très bien foutues. Plein de chiffres à apprendre et à resortir pour argumenter dans des soirées mondaines. Vraiment très intéressant.

Ci-dessous : ma synthèse. Les phrases entre crochets sont des ajouts/notes personnels.

[ Rappel - Périmètre de l'obvervatoire ]
Mis en place sous l’égide de l’ANSSI 1 en 2011, l’observatoire de la résilience de l’Internet français vise à améliorer la connaissance de celui-ci en étudiant les technologies critiques à son bon fonctionnement. Un de ses objectifs est donc d’augmenter la compréhension collective de l’Internet afin d’en avoir une vision la plus complète possible.

De par sa nature, l’Internet ne possède pas de frontière. L’Internet en France peut toutefois se définir comme l’ensemble des acteurs exerçant une activité sur le territoire national. L’observatoire se focalise sur l’Internet français, un sous-ensemble de l’Internet en France ne prenant pas en compte les acteurs étrangers, afin d’appréhender les dépendances des activités économiques et sociales françaises vis-à-vis de l’étranger.


[ Bilan ]
Au regard de ses analyses, l’observatoire considère que la situation de l’Internet français est satisfaisante. Cependant, les bonnes pratiques d’ingénierie admises ne sont pas pleinement suivies par les acteurs de l’Internet français. Par conséquent, l’observatoire les encourage à se les approprier et émet les recommandations suivantes :
• déployer IPv6 afin de développer rapidement les compétences, et d’anticiper les problèmes opérationnels futurs ;
• bien répartir les serveurs DNS faisant autorité afin d’améliorer la robustesse de l’infrastructure ;
• tester DNSSEC et le déployer pour lutter contre les attaques par pollution de cache ;
• déclarer systématiquement les objets route, et les maintenir à jour, afin de faciliter la détection et le filtrage d’annonces BGP illégitimes ;
• utiliser la RPKI et déclarer des ROA ;
• appliquer les bonnes pratiques BGP au niveau des interconnexions entre opérateurs.


[ Quels progrès depuis 2012 ?
Les recommandations sur IPv6 + disperser les serveurs DNS qui font autorité + une déclaration systèmatique dans les IRR + appliquer les BCP BGP sont encore d'actualité cette année, sans surprise (on ne change pas les choses en un claquement de doigts). Utiliser RPKI+ROA est un nouvel indicateur. Tester DNSSEC : pas nouveau mais ça commence à pouvoir s'envisager sérieusement, dont l'apparition de cette recommandation cette année. ]


[ RPKI+ROA - Hosted model versus delegated model]
•  en autorisant le RIR à gérer l’autorité de certification et le point de publication. Ce modèle de gestion est couramment désigné par l’expression hosted model. Cela permet au détenteur des ressources IP de s’affranchir de la gestion de l’infrastructure associée à l’autorité de certification et au point de publication. En adoptant ce modèle de gestion, l’organisation accepte que le RIR conserve sa clé privée. Le RIPE-NCC décrit la gestion de l’autorité de certification dans leur Certification Practice Statement [17]. Le RIR a notamment recours à un HSM pour protéger les éléments secrets en confidentialité et en intégrité, en particulier les clés privées des membres ;

• en gérant sa propre autorité de certification et son propre point de publication. Cela permet notamment au détenteur des ressources de gérer lui-même sa clé privée et sa politique de signature. Il s’agit du delegated model.

À l’heure de l’écriture de ce document, le RIPE-NCC indique que le delegated model n’est pas en production [18]. Il met à disposition de ses membres une interface web[19] simplifiant la création et la gestion des ROA. L’administrateur décrit les annonces qu’il souhaite autoriser en indiquant l’AS origine, le préfixe devant être annoncé, ainsi que la longueur maximale des annonces. Une fois cette étape effectuée, il peut utiliser cette même interface pour publier les modifications dans la RPKI.


[ BGP - Consolidation des données ]
Dans les rapports précédents, seules les données du collecteur situé à Londres (au LINX, London Internet Exchange) étaient utilisées. Afin d’obtenir une vision exhaustive de l’Internet français, il est nécessaire d’utiliser l’ensemble des collecteurs car certains AS français ne sont pas visibles depuis tous les collecteurs. Dans cette nouvelle édition, afin d’améliorer la qualité des analyses tout en limitant la quantité de données générée, deux collecteurs supplémentaires sont utilisés : celui d’Amsterdam (à l’AMS-IX, Amsterdam Internet Exchange) et celui de Genève (au CIXP, CERN Internet eXchange Point). Ils ont été sélectionnés car ils permettent de voir tous les pairs français du projet RIS, et offrent une vision presque exhaustive des AS français et des préfixes qu’ils annoncent.


[ BGP - Qu'est ce qu'un AS français ? ]
Nous avons conservé les huit critères indépendants choisis en 2012, et permettant de donner une indication sur le fait que l’AS puisse être français ou non :
1. la description dans la base whois du RIPE-NCC [22] contient des mots-clés français ;
2. plus de 75 % des adresses IP sont localisées en France par la bibliothèque GeoIP [23] ;
3. la description dans la base du RIPE-NCC contient des mots-clés issus de la liste des opérateurs déclarés auprès de l’ARCEP [24] ;
4. l’organisation gérant l’AS a une adresse postale en France dans la base du RIPE-NCC ;
5. les administrateurs de l’AS ont une adresse postale en France dans la base du RIPE-NCC ;
6. il s’agit de l’un des trente-quatre AS français identifiés manuellement par les membres de l’observatoire ;
7. c’est un AS directement connecté à l’un de ces trente-quatre AS ;
8. son numéro d’AS a été attribué par le RIPE-NCC.


[ BGP - Nombre d'AS français identifiés ]
En 2013, l’observatoire a identifié 1412 AS français. Parmi ceux-ci, le nombre d’AS actifs est de l’ordre de 850, et peut varier en fonction de l’indicateur concerné.


[ BGP - Dépendance entre AS ]
Les AS pivots qui sont des AS dont la panne entraînerait la perte de connectivité à l’Internet d’un ou plusieurs AS français. On considère qu’un AS français perd la connectivité à l’Internet s’il ne peut plus contacter un AS Tier ;

[ Comment on détermine un vrai Tiers 1 ? Non parce que tout opérateur se dit Tiers 1 et crache sur son voisin « c'pas vraiment un Tiers 1 lui !

Pour ceux qui s'interrogent à la page 20 sur comment sont identifiées les relations entre AS (peering/transit), voir la référence 28, c'est-à-dire le papier de recherche « AS Relationships, Customer Cones, and Validation » qui présente un nouvel algorithme pour qualifier ces relations en utilisant les données BGP. ]


L’Internet français ne se suffit pas et des AS étrangers peuvent être nécessaires pour faire transiter le trafic entre deux AS français. C’est pour cette raison qu’il est nécessaire de calculer l’enveloppe convexe de l’Internet français. Le nombre d’AS étrangers contenus dans celle-ci est représenté sur la figure 1.7. On peut voir qu’en IPv4, le nombre d’AS étrangers dans l’enveloppe a décru de manière régulière tout au long de l’année 2013, passant de 356 en janvier à 270 en décembre, soit une diminution de 24 %. En IPv6, le nombre d’AS étrangers dans l’enveloppe est resté relativement stable, d’un maximum à 67 en février, il est passé à un minimum de 50 en août et ce malgré la forte augmentation du nombre d’AS présents sur les chemins d’AS en IPv6. Enfin, on peut remarquer que la proportion d’AS étrangers dans l’enveloppe convexe de l’Internet français en décembre 2013 est de 24 % en IPv4 contre 17 % en IPv6.

Au cours de l’année 2013, les AS pivots en IPv4 ont peu évolué comme on peut le voir sur la figure 1.8. Le nombre d’AS pivots français a légèrement augmenté sur l’année, évoluant entre 59 en janvier et 63 en décembre. En revanche, le nombre d’AS pivots étrangers a diminué en passant de 28 en janvier à 21 en décembre. Ces deux tendances se compensent et le nombre d’AS pivots est resté stable sur l’année 2013. En revanche, la situation est différente pour IPv6 où le nombre d’AS pivots a sensiblement augmenté au cours de l’année. Ainsi, il y avait 13 AS pivots français en janvier contre 21 en décembre et 5 AS pivots étrangers contre 12 en décembre avec un maximum de 15 en septembre. Au total, le nombre d’AS pivots a crû de 83 % sur l’année. Cette augmentation s’explique certainement par la croissance forte des AS actifs en IPv6. En effet, les nouveaux entrants n’ont pas forcément tous encore consolidé leur connecti- vité en prenant plusieurs fournisseurs pour IPv6. La connectivité IPv4 paraît d’ailleurs légèrement plus robuste que celle en IPv6 avec environ un AS pivot pour dix AS français en IPv4 contre un pour huit en IPv6.

[ => Peut sacrement mieux faire pour IPv6. Aucun changement pour IPv4, les SPOF sont devenus des opérateurs FR au lieu d'opérateurs étrangers. ]


Le nombre d’AS pivots ne suffit pas pour évaluer la robustesse de la connectivité, il faut également évaluer l’impact de la disparition d’un AS pivot. Il existe relativement peu d’AS dont la disparition aurait un impact significatif. Ainsi, comme on peut le voir sur la figure 1.9, pour le cas d’IPv4, seuls 8 AS pivots affecteraient au moins dix AS en cas de défaillance et seuls 22 auraient un impact sur au moins trois AS. En revanche, les 8 AS les plus critiques peuvent avoir un impact significatif. Ainsi, l’AS pivot le plus critique aura un impact sur 34 AS, soit 4 % des AS français actifs au même moment.

Pour IPv6, la figure 1.10 montre qu’il existe seulement 2 AS pivots pouvant déconnecter au moins dix AS mais chacun d’entre eux peut affecter 15 ou 16 AS soit plus de 5 % des AS français actifs en IPv6. De même, 12 AS pivots peuvent avoir un impact sur plus de trois AS français. En proportion, c’est 33 % des AS pivots contre 26 % pour IPv4.

[ => La connectivité est fortement contrentrée tout de même. :/ ]


Enfin, il est bon de noter que l’utilisation de deux transitaires est suffisante pour avoir un bon niveau de protection contre la défaillance d’un AS dans l’Internet. Aucun des AS français qui ont plus d’un fournisseur de transit ne serait déconnecté de l’Internet par la défaillance de l’un des AS pivots. Ceci n’est pas vrai dans l’Internet globalement et on pourra se reporter à un rapport technique [26] pour plus de détails à ce sujet.

[ => Un seul AS pivot ne peut rien faire tomber tout seul. ]


[ BGP - Qualité / mise à jour des IRR ]
Afin d’évaluer la qualité des informations import/export saisies par les acteurs de l’Internet français dans les bases whois, une analyse automatique a été effectuée sur celle-ci et les résultats principaux sont donnés dans le tableau 1.1. Ces résultats sont ceux du de décembre 2013 mais les variations au cours de l’année sont faibles. Dans la colonne de gauche, se trouve le pourcentage des relations annoncées par BGP présentes dans les bases whois et, dans la colonne de droite, est donné le pourcentage de relations présentes dans les bases whois et visibles dans des annonces BGP. Comme on peut le voir, les informations sur les relations de transit sont relativement correctes. Ainsi 76 % des relations de transit observées dans les archives BGP sont  déclarées dans les bases whois. Ce résultat peut sans doute s’expliquer par le fait que denombreux fournisseurs de transit demandent à leurs clients de renseigner les informations dans les bases de données avant d’autoriser leur trafic. Par ailleurs, les fournisseurs changent relativement peu. Inversement, 65 % des relations de transit déclarées sont vues dans les archives BGP. Les 35 % qui ne sont pas vues peuvent s’expliquer en partie par les liens de secours qui ne sont annoncés que lorsque c’est nécessaire.

Les résultats sur les relations de clients sont plus mitigées. Ainsi, seules 52 % des relations annoncées dans les bases whois sont visibles dans les archives BGP. Inversement, 41 % des relations visibles dans les archives BGP sont déclarées dans les bases whois. Deux phénomènes principaux sont sans doute à l’origine de ce constat. Premièrement, les changements parmi les clients d’un AS sont beaucoup plus fréquents que ceux parmi les fournisseurs. En second lieu, nous avons pu observer que beaucoup de mises-à-jour sont incomplètes. Pour certaines connexions, des AS ont les attributs import sans avoir les attributs export associés ou réciproquement. Ceci est en particulier dû à la mauvaise maintenance des objets as-set associés.

Enfin, seulement 10 % des relations de peering vues dans les archives BGP sont déclarées dans les bases whois, et seulement 6 % des relations déclarées sont visibles. Les remarques précédentes sur le maintien des objets s’appliquent également pour les relations de peering. Par ailleurs, certains AS ne sont pas en capacité de lister l’ensemble de leurs relations de peering, notamment lorsqu’ils utilisent les peerings publics dans les points d’échange. Enfin, il n’est pas surprenant qu’une faible proportion des relations déclarées soient visibles car, comme expliqué plus haut, pour qu’une relation soit visible dans les archives BGP, il faut qu’un des collecteurs utilisés soit connecté à l’un des AS dans la relation de peering ou l’un de ses clients.


Nous pouvons constater que deux tendances se dégagent à l’analyse des graphiques représentés. La première tendance, encourageante, montre que le nombre d’AS n’ayant aucun objet route déclaré diminue de 2 points pour l’ensemble des AS français. De plus, même si le nombre d’AS n’utilisant aucun objet route augmente d’un point pour l’ensemble des AS français, ce chiffre diminue pour les AS français actifs et ramène le pourcentage d’AS sans objet route à 5,4 %. Enfin, le pourcentage d’AS français actifs utilisant au moins un objet route croît de 2,9 points. La seconde tendance, en revanche, montre que le nombre d’objets route inutilisés dans la base de données du RIPE augmente, pouvant expliquer la diminution de 2,1 points des AS français actifs utilisant tous leurs objets route.

Pour IPv6, la figure 1.17 pourrait laisser penser que les AS français respectent mieux les bonnes pratiques de déclaration d’objet route6. En effet, une baisse de 3,8 points des AS français n’ayant aucun objet route6 déclaré, ainsi qu’une augmentation de 2,1 points du nombre d’AS français utilisant l’ensemble des objets route6 déclarés tendent à conforter cette intuition.

L’analyse des AS français actifs en IPv6 présentés dans la figure 1.18, montre cependant que la réalité est toute autre. Entre 2012 et 2013, le nombre d’AS français actifs en IPv6 est passé de 178 à 240. Cette croissance d’AS français utilisant le protocole IPv6 n’a pas été accompagnée d’une déclaration systématique d’objets route6. La quantité d’AS français actifs n’ayant aucun objet route6 a augmenté de 3,2 points.

[ => Sur-déclaration d'objets route/route6 sous la pression de la communauté "pour avoir la paix" ? Le temps de déployer (route6) ? ]


Nous avons constaté des tendances intéressantes lors de l’étude des objets route. Le nombre d’AS sans objets route déclarés a baissé en 2013. Cependant, les objets route inutilisés ont augmenté s’ajoutant aux objets route obsolètes. Il convient donc de rappeler qu’il faut vérifier régulièrement que les informations déclarées auprès du RIPE sont encore valables. En ce qui concerne IPv6, les objets route sont moins bien déclarés qu’en IPv4. Cela semble donc indiquer qu’un moindre soin est apporté à la gestion des ressources IPv6. Finalement, les AS créés au cours de l’année 2013 ont tendance à bien appliquer les bonnes pratiques de déclaration. Il s’agit d’un résultat très encourageant pour les travaux de l’observatoire.


[ BGP - usurpation ]
On parle d’usurpation de préfixes lorsqu’un AS, appelé « AS usurpateur », annonce de façon illégitime un préfixe égal ou plus spécifique à un préfixe  délégué à un autre AS, appelé « AS usurpé ».

[ => Donc le rapport ne traite pas du cas des annonces larges. Pour quelles raisons ? Compliqué à qualifier (fuite partielle, souvent volontaire) ? ]


L’AS_PATH est par ailleurs utilisé afin de déterminer la distance, en nombre d’AS, entre l’AS usurpé et l’AS usurpateur. La distance est un facteur pertinent pour l’analyse des usurpations. En effet, lorsque l’AS usurpateur est directement connecté à l’AS usurpé, l’expérience et le rapport 2012 montrent que les annonces associées sont pour la majorité des défauts de déclaration d’objets route ou de ROA.


[ BGP - Fuite/réannonce de la full view ]
En marge des usurpations de préfixes, les analyses menées dans le cadre de cet indicateur permettent également de mettre en évidence des réannonces de table de routage. Suite à des erreurs de configuration, il arrive parfois qu’un AS réannonce l’intégralité des routes de l’Internet à ses fournisseurs en prétendant être à l’origine de ces préfixes. Par conséquent, il semble usurper un nombre important de préfixes au même instant. Les analyses concernant les réannonces récentes [8, 29, 30] mettent en évidence que les fournisseurs des AS, à l’origine de ces réannonces, n’appliquent pas de filtre sur le nombre maximal de préfixes annoncés par leurs clients [1].


[ BGP - Fuite/anonce de services de peering ]
Par ailleurs, dans le cadre d’accords entre deux opérateurs, il est fréquent que des services de peering [Il s’agit de préfixes /25, /32, ou /128 qui correspondent, par exemple, à des adresses de serveurs d’authentification.] soient annoncés localement au sein de leurs réseaux, afin de faire transiter les paquets via des liens de peering plutôt que sur Internet. Il arrive parfois que des annonces de services réannoncées par erreur soient visibles sur Internet.

La figure 1.13 présente la répartition des 181 957 événements 18 identifiés suivant les quatre types définis. On peut constater que près de la moitié des événements détectés sont validés par des objets route ou des ROA.

Par ailleurs, la catégorie relation représente 35 % des événements. Il s’agit d’un résultat très important qui confirme les intuitions formulées dans le rapport 2012 : un grand nombre d’événements non valides correspond à des défauts de déclarations d’objets. Il est intéressant de signaler que l’utilisation des ROA, quoique anecdotique, permet de valider quelques événements pour lesquels aucun objet route n’est déclaré. L’étude de la catégorie relation montre que 84 couples d’AS sont à l’origine de ces événements. La plupart de ces couples correspondent à des réseaux universitaires, des délégations de services à des clients d’opérateurs, des filiales ou des AS avec numéros sur 16 et 32 bits. Les événements de la catégorie relation proviennent, pour la plupart, d’annonces anormales ou directes.

[ => 5% de direct (AS collés dans AS_PATH donc probablement problème de déclaration ), 12% anormal. ]


[ BGP - Incidents rigolos ]
Par ailleurs, un AS jordanien est à l’origine de cinq d’entre elles, entre mi-avril et mi-mai 2013. Après analyse, il s’avère que cet AS a annoncé ponctuellement plus de 700 préfixes. En temps normal, il en annonce une vingtaine. Il s’agit d’un résultat particulièrement intéressant car ces réannonces n’avaient pas été discutées publiquement. Ces réannonces sont probablement dues à des erreurs de configuration de routeurs chez cet AS jordanien.

Environ 250 réannonces de service de peering ont pu être identifiées. Elles concernent principalement des préfixes IPv4 /32 inclus dans des préfixes annoncés par des AS français. Un transitaire international est à l’origine de la plupart de ces réannonces.

La seconde a été effectuée par un AS français pendant 10 minutes environ. Trois autres AS français ont été touchés. Les préfixes en cause étaient annoncés de façon légitime par cet AS avant 2013. Il pourrait s’agir de la mise en route d’un vieil équipement, ou de l’utilisation d’une ancienne configuration.


[ BGP - Vraies usurpations ]
À ce stade, il reste une centaine de conflits qui pourraient être des usurpations. Afin de simplifier les dernières analyses, nous ne conservons que les 34 derniers conflits effectués par des AS étrangers et dont la durée réelle est comprise entre 1 jour et 6 mois. Cela permet de mettre en évidence les conflits qui auraient pu provoquer des détournements de trafic sans que les AS français ciblés ne puissent réagir rapidement. Une dernière analyse manuelle a permis d’identifier que 10 de ces conflits semblent être des usurpations contre 7 AS français. Elles ont des durées variables, de 15 à 166 jours, et ont été vues par les trois collecteurs. Cela laisse à supposer qu’elles ont pu être suivies par des détournements de trafic. L’une des ces usurpations correspond d’ailleurs aux usurpations rapportées par la société Renesys [33] et pour lesquelles du trafic a été détourné.


[ BGP - RPKI+ROA ]
Le nombre d’AS français participant à la RPKI a quasiment triplé au cours de l’année 2013 : au 31 décembre 2013, 110 AS avaient publié un ROA dans la RPKI, tandis qu’ils n’étaient que 41 au 1er janvier 2013. La figure 1.19 montre l’évolution du nombre de préfixes IPv4 et IPv6 déclarés par les AS français dans la RPKI. On peut constater que le nombre de préfixes IPv4 a augmenté significativement au cours de l’année, tandis que l’augmentation du nombre de préfixes IPv6 a été plus faible. L’augmentation observée en IPv4 et en IPv6 n’est pas uniquement due à l’arrivée progressive de nouveaux AS : la mise à jour de ROA par les AS déjà présents dans la RPKI participe à cette augmentation.

[ => 110 AS sur 1412 ... Autant dire marginal. ]


[ BGP - Cohérence ROA/annnonces BGP ]
La figure 1.20 illustre l’évolution de la validité des annonces des AS français par rapport à la RPKI. On peut constater que le pourcentage d’annonces non couvertes a diminué sensiblement : d’environ 90 % au début de l’année 2013, il est passé à moins de 80 % à la fin de l’année. Cette baisse ne s’est pas directement traduite par une augmentation du même ordre de grandeur du pourcentage d’annonces valides : celui-ci est passé de 8 % au début de l’année à 12 % au 31 décembre 2013. Le pourcentage d’annonces invalides a, quant à lui, augmenté significativement au cours de l’année : de 2 % au 1er janvier 2013, il est passé à presque 9 % à la fin de l’année.

Notre analyse nous a permis de constater que les données publiées dans la RPKI ne correspondent pas toujours aux annonces effectuées. Pour commencer, près de la moitié des AS participant à la RPKI ne déclarent pas la totalité de leurs préfixes IP dans la RPKI. Au 31 décembre 2013, le pourcentage d’AS participant à la RPKI pour lesquels chaque annonce était couverte par un ROA était de 55 %. Par ailleurs, à la même date, 6 AS français participant à la RPKI effectuaient au moins une annonce invalide, car trop spécifique.

Nos observations montrent qu’un filtrage strict, c’est-à-dire n’acceptant que les annonces considérées comme valides, entraînerait le rejet de près de 90 % des annonces. En revanche, on peut remarquer qu’un filtrage consistant à rejeter uniquement les annonces invalides aurait un impact bien moindre, et entraînerait le rejet de 9 % des annonces à la fin de l’année.

[ => Ça correspond bien à mes observations, cf http://www.guiguishow.info/2013/10/07/rpkiroa-et-bird-pour-samuser/ ]


Ce rapport a vu disparaitre l’indicateur cherchant à mesurer l’adoption d’IPv6 et des bonnes pratiques d’utilisation de BGP. En effet, les résultats étaient peu pertinents.

[ => :D ]




[ DNS ]
[ DNSSEC - taille des clés ]
Une grande partie des déploiements actuels utilise des clés RSA de 1024 bits pour les ZSK, et 2048 bits pour les KSK. Étant donné les attaques connues et les risques associés, le RGS 10 [47] préconise une taille de 2048 bits au minimum.

[ DNS - combien de sous-domaines dans .fr ? ]
Toutes les mesures actives ont été faites en utilisant la zone .fr qui varie au gré des créations, suppressions et modifications de zones déléguées. De 2012 à 2013, le nombre de ces zones déléguées a augmenté de 7,6 % (contre 14 % entre 2011 à 2012) pour atteindre le nombre de 2 716 055 au 31 décembre 2013. Ce nombre était de 2 509 913 au 31 décembre 2012.

[ DNS - Charge sur une partie des serveurs qui font autorité sur .fr. ]
Cela représente un volume important car les huit instances de serveurs DNS administrés par l’Afnic reçoivent environ 3400 requêtes par seconde (moyenne en journée et en pleine semaine). Le nombre de requêtes DNS, toutes sondes confondues, analysées par semaine par DNSmezzo est de l’ordre de 45 millions de requêtes pour octobre 2013. Ce taux d’échantillonnage a été choisi en fonction des ressources matérielles disponibles en termes de stockage et de calcul.


[ DNS - Nombre de serveurs qui font autorité par zone ]
L’année 2012 avait été marquée par un accroissement sensible du nombre de serveurs par zone. En effet, en 2011, pratiquement la moitié des zones déléguées sous le .fr ne possédaient que 2 serveurs ; alors qu’en 2012 plus de la moitié des zones possédaient 4 serveurs et plus.

En 2013, nous observons toujours la même tendance : le nombre de serveurs par zone est très souvent un nombre pair. La répartition du nombre de serveurs reste sensiblement la même que l’année précédente, avec un léger infléchissement pour les zones ayant respectivement 2 et 4 serveurs. Mais cette baisse est compensée par la hausse des zones ayant plus de 6 serveurs (gain de près de 3 points). On retrouve notamment 500 zones ayant 12 serveurs DNS, et et 200 zones ayant 20 serveurs.

[ => WTF O_O échantillonnage vaseux qui reprend toujours des zones atypiques ? O_O ]


[ DNS - Nombre d'AS par zone ]
Le nombre moyen d’AS par zone a très légèrement augmenté en 2013. Il était de 1,26 en 2011 et 2012 et atteint 1,30 en 2013.

La dispersion des serveurs DNS par AS reste donc toujours faible avec la majeure partie des zones ayant tous leurs serveurs au sein d’un unique AS. Facteur aggravant, 70 % de ces serveurs sont tributaires des AS de quatre hébergeurs DNS.

[ => Donc le message sur le nombre de serveurs par zone a bien été reçu, il faut désormais acccentuer les efforts sur la dispersion de ces serveurs dans plusieurs réseaux. ]


[ DNS - Nombre d'AS par zone -> concentration chez les hébergeurs DNS ]
La figure 2.9 montre la dispersion des serveurs de noms par AS afin d’observer la concentration des serveurs chez les hébergeurs DNS. Nous nous focalisons ici sur  les quatre AS les plus importants en termes de nombre de serveurs DNS hébergés. Il s’agit des mêmes AS d’année en année.

On constate que ces quatre acteurs concentrent près de 70 % des serveurs DNS faisant autorité pour les zones déléguées sous .fr depuis 2012. Le premier acteur reste relativement stable sur les trois années d’études avec plus de 34 % des serveurs DNS hébergés. L’AS2 passé de la troisième à la seconde place en 2012, conserve sa position en 2013 avec une part importante des serveurs hébergés : plus de 20 %. Il est donc probable qu’une panne de routage chez l’un ou l’autre des deux premiers AS affecte un nombre important de zones sous le .fr.

[ => Il faut relativiser àmha : ce nombre ne prend pas en compte des situations comme l'auto-hébergement où seul un slave est chez l'hébergeur DNS, donnant un faux sentiment de concentration alors que bien au contraire, on a au moins 2 serveurs qui font autorité sur la zone + une dispersion par AS. La perte temporaire d'un slave n'est pas dramatique. ]


[ DNSSEC ]
DNSSEC n’est pas un facteur de résilience en soi. Aujourd’hui, il n’y a guère plus de débat sur son intérêt mais plutôt sur le moment de le déployer pour chaque acteur concerné.


[ DNSSEC - Signature des zones ]
La différence entre le pourcentage de zones signées et le pourcentage de zones possédant un enregistrement DS dans .fr vient des zones signées à titre expérimental, pas encore stabilisées, et surtout des zones dont le bureau d’enregistrement n’offre pas la possibilité de soumettre un DS au niveau de .fr. C’est le cas aujourd’hui pour la majorité des bureaux d’enregistrement en France.

Même si d’année en année, l’augmentation du nombre de zones signées est substantielle, proportionnellement à la taille de la zone .fr, ce chiffre reste faible : en 2013 cela ne représente que 3,4 % des zones déléguées.

La figure 2.11 indique le taux de zones signées à la fin de chaque trimestre pour les années 2012 et 2013. Pour l’échantillon de fin décembre 2013, on observe que les 92 500 zones signées se répartissent entre 39 bureaux d’enregistrement. Cependant, un bureau d’enregistrement détient à lui seul plus de 97 % de ces zones, le bureau d’enregistrement qui suit, en nombre de zones signées, n’en détient que 0,7 %.

[ => Donc ce boom est dû à un bureau d'enregistrement (procédure de soumission d'un DS disponible + effet attirant puisque DNSSEC disponible dans la page d'administration du nom acheté) donc cette tendance ne va pas durer. ]


Là encore, proportionnellement à la taille de la zone .fr, le taux de zones possédant un DS dans la zone parente reste faible : il représentait 1,4 % des zones en 2012 et 3,3 % en 2013.

[ => Très faible différence entre signature pour tester DNSSEC et signature de production. ]


[ DNS - Déployement IPv6 vu par le DNS - Côté zones ]
Le taux de serveurs web ayant activé IPv6 a progressé de manière significative en 2013 (progression supérieure à 80 %) pour atteindre 7,7 %. Cependant c’est toujours au niveau des serveurs web que le protocole IPv6 est le moins déployé des trois services étudiés.


En revanche, pour les zones dites « IPv6 complet », celles ayant tous leurs serveurs (DNS, mail et web) compatibles IPv6, leur taux reste faible comme les années précédentes : il était de 0,2 % en 2011, 0,5 % en 2012 et il est de 0,7 % en 2013.

[ => Y'en a encore qui pensent vraiment qu'IPv6 c'est demain ? :D ]


[ DNS - Déployement IPv6 vu par le DNS - Côté récursifs-caches ]
Pour les serveurs faisant autorité pour .fr et étant directement administrés par l’Afnic, environ 16 % des requêtes sont transportées en IPv6 (voir figure 2.14) en décembre 2013. On remarque donc une progression constante, bien que limitée, du transport IPv6 au cours des deux dernières années.


[ DNS - Déployement IPv6 vu par le DNS - Côté stub-resolvers donc clients finaux ]
Quant aux types de données demandées, on remarquera la faible progression des adresses IPv6 au niveau des requêtes (voir figure 2.14) [14 % en 2013]. Il faut se rappeler que les clients des serveurs faisant autorité pour le .fr ne sont généralement pas des machines d’utilisateurs finaux mais plutôt des résolveurs DNS, souvent gérés par des FAI et hébergeurs. Le type de transport observé par les serveurs de l’Afnic dépend de ses clients directs, soient les gros résolveurs, alors que le type de données demandées reflète le choix des machines des utilisateurs finaux.

[ => Effet Windows XP / parc vieillissant combiné au jemenfoutisme des FAI français (récursifs-cache + IPv6 @home). ]


Cette année, nous avons supprimé l’indicateur qui concernait les serveurs DNS vulnérables à la faille Kaminsky [60]. Du fait des mises à jour appliquées aux serveurs
concernés, cet indicateur devenait de moins en moins significatif. En effet, les résolveurs DNS qui n’avaient toujours pas corrigé ce problème ne représentaient plus que 6 % du trafic observé par les serveurs de l’Afnic.

[ => 2008 - 2014 ... 6 % du trafic observé ... tout de même quoi. ]


L’Internet français, du point de vue du DNS, se caractérise par de fortes concentrations au niveau des hébergeurs DNS mais également au niveau des opérateurs et autres FAI auxquels les utilisateurs finaux s’adressent pour la résolution DNS. Ce dernier point s’explique dans une certaine mesure par la concentration du marché de l’accès à l’Internet en France.


En effet, si l’on regarde la dispersion topologique des serveurs DNS faisant autorité, on remarque que depuis la mise en place de cet indicateur, quatre acteurs, les mêmes d’année en année, se partagent près de 70 % du marché de l’hébergement DNS. En ce qui concerne la dispersion du trafic IPv4 par AS, un seul opérateur français est à l’origine de plus de 22 % du trafic total. Cette forte concentration du marché soulève la question des impacts d’une panne majeure chez un opérateur de taille importante.