MISC N°
Numéro
83

IPv6 : 10 ans après !

Temporalité
Janvier/Février 2016
Image v3
IPv6 : 10 ans après !
Article mis en avant

Résumé

Au début des années 2000, un professeur enseignant la théorie des systèmes d’exploitation m’a affirmé ceci : « Unix a toujours été le système de demain, un jour ce sera le système d’hier sans jamais avoir été celui d’aujourd’hui ». La suite lui a plutôt donné tort, mais s’il est vrai que l’avenir d’Unix en 2000 n’appelait pas forcément à l’optimisme, celui d’IPv6 semblait assuré. L’épuisement des adresses IPv4 induirait mécaniquement l’obligation à plus ou moins courte échéance de passer sur IPv6. Et en attendant d’y être obligé, disposer d’une adresse IPv6 permettait de voir bouger la vache [1].

Dans ce numéro...


Suite au massacre de Virginia Tech en 2007, Bruce Schneier publia un billet dans Wired intitulé « Virginia Tech Lesson : Rare Risks Breed Irrational Responses » [1]. Il y expliquait combien il était difficile d’évaluer les risques et à quel point notre perception était biaisée. Aussi dangereuses et meurtrières que puissent être certaines menaces, leur rareté induit un risque relativement faible comparé à d’autres menaces que nous sous-évaluons. Schneier explique que paradoxalement nous avons tendance à surévaluer le risque des événements rares et à adopter des mesures de sécurité irrationnelles lorsqu’ils se produisent.
Le 7 octobre 2015, un mail [1] a été envoyé à l'équipe sécurité d'Ubuntu pour rapporter une vulnérabilité dans le logiciel Apport [2] permettant à un attaquant d'élever ses privilèges. Apport est un logiciel en Python développé par Canonical pour afficher des informations à l'utilisateur lors du crash d'un programme, et avec son accord remonter ces informations aux développeurs d'Ubuntu.
Les termes « exécution arbitraire de code » font généralement rêver tout chercheur en sécurité. Parvenir à détourner le flot d'exécution d'un programme pour en démarrer un autre est rarement une tâche aisée. Toutefois, il arrive que des programmeurs implémentent des options tout à fait légitimes dans leurs programmes qui peuvent être détournées et abusées. Qui soupçonnerait tar, zip ou tcpdump de pouvoir démarrer un programme externe? C'est ce que cet article va présenter.
Lorsqu’on évoque les malwares, on parle souvent de la manière de les supprimer, de celle de s'en prémunir, des techniques pour assurer la désinfection des systèmes. Mais si on veut en analyser, la question fondamentale est de savoir comment en trouver, surtout lorsqu'on travaille sous GNU/Linux.
La première série d'articles dédiée au protocole IPv6 a été publiée dans MISC n°27 à la rentrée 2006. Depuis, IPv6 n'est toujours pas omniprésent, comme certains l'avaient prédit, mais beaucoup de choses ont changé. Ainsi, la plupart des OS modernes prennent en charge IPv6, et l'activent par défaut, et de nombreux fournisseurs d'accès le propose à leurs clients [ORANGE-IPV6-NOVEMBRE-2015]. Côté serveurs, IPv6 a été largement adopté pour le DNS [IPV6-PROGRESS-REPORT]. Concernant le Web, la situation est plus mitigée, et seuls 10 % des sites les plus fréquentés, d'après la société américaine Alexa, l'ont configuré. À titre indicatif, environ 10 % des utilisateurs de Google utilisent IPv6 [GOOGLE-IPV6-STATISTICS]. Cet article présente tout d'abord les changements structurels et fonctionnels du protocole IPv6. Fort de ces descriptions théoriques nécessaires, l'objectif de cet article est de s'attarder sur cinq éléments distincts, qui 10 ans plus tard, semblent les plus pertinents pour appréhender le protocole IPv6 sous l'angle de la sécurité. Il s'agit de l'espace d'adressage, du mécanisme de découverte de voisins, de la question du respect de la vie privée, des entêtes d'extension, et de l'énumération de réseaux. Afin d'illustrer le contenu, les fonctions et messages de Scapy relatifs à IPv6 sont également discutés.
Nous présentons dans cet article les éléments de sécurité IPv6 à prendre en compte au sein d’un réseau multi-services d’un opérateur. Cet article abordera à la fois la partie routage d’accès et de routage interne, mais aussi le filtrage du trafic en transit sur le réseau de l’opérateur.
Depuis 2003, nous tentons de traiter IPv6 à parité avec IPv4 sur notre réseau de campus, aussi bien pour la connectivité que pour les services. Établir ce principe ne s'est pas fait sans difficulté et le maintenir est un véritable défi au quotidien.
On parle depuis plus de 20 ans d'IPv6 et de l'urgence de migrer nos infrastructures vers ce nouveau protocole. Pour autant il est parfois difficile de prendre la mesure des impacts de cette migration. Cet article se propose de faire un retour d'expérience sur le déploiement d'IPv6 sur un réseau de collecte régional pour la communauté enseignement recherche. Nous nous intéresserons aux choix techniques réalisés pour cette migration ainsi qu'aux difficultés rencontrées durant plus de 10 ans d'exploitation d'IPv6. Nous aborderons également un aspect plus prospectif sur IPv6 et ce qui nous attend au-delà de la problématique de migration en elle-même.
Ces dernières années, différentes failles majeures dans des librairies cryptographiques connues ont montré qu'au-delà du bon choix des primitives cryptographiques, leur bonne implémentation est essentielle. Nous présentons ici quelques conseils pour correctement implémenter (ou attaquer...) des fonctions cryptographiques.
De récentes nouvelles sur des sites d'informations et blogs spécialisés remettent en question le fait que la plateforme d'Apple soit exempte de code malveillant. Pire encore : même les terminaux non jailbreakés seraient en danger !
Cet article présente un POC d'outils d'analyse exhaustif basé sur la pile ELK.
Dans le domaine de la sécurité des systèmes d'information, la visualisation est couramment utilisée pour différentes tâches comme l'analyse de logs [14], la détection d'attaques [11], l'analyse de binaires [3] et l'ingénierie inverse [2,1], mais aujourd'hui, il n'existe pas de façon simple d'analyser et de différencier des données aléatoires. Cependant, les systèmes d'exploitation ou les protocoles cryptographiques utilisent constamment la génération d'aléa, par exemple, pour générer un numéro de séquence TCP ou pour générer une clef de chiffrement aléatoire pour le Wi-Fi ou le Web.

Magazines précédents

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Body