Powered By Blogger

Rechercher sur ce blogue

vendredi 29 octobre 2021

Un rapport révèle que Julian Assange aurait été la cible d’un inquiétant complot de la CIA

 

 

Un rapport révèle que Julian Assange aurait été la cible d’un inquiétant complot de la CIA

Un nouveau rapport d’investigation révèle les détails d’un inquiétant complot présumé de la CIA visant à assassiner le fondateur de WikiLeaks, Julian Assange. S’il est avéré, ce projet pour le moins choquant constitue une grave menace à sa sécurité et à la liberté de la presse. Reporters sans frontières (RSF) réitère son appel aux Etats-Unis à abandonner les poursuites contre Julian Assange et à le libérer avant qu’il ne soit davantage mis en danger.

Yahoo! Actualités a publié le 26 septembre un rapport citant plus de 30 anciens hauts fonctionnaires américains, qui mentionnent ce qui aurait été une vendetta menée par le directeur de la CIA de l’époque, Mike Pompeo, en réaction à la publication par WikiLeaks, en 2016, d’outils de piratage secrets de la CIA connus sous le nom de « Vault 7 » et alors décrite comme la « plus grande perte de données de l’histoire de la CIA ». Le rapport révèle l’existence présumée de plans choquants, dont le possible enlèvement ou assassinat d’Assange, ainsi qu’une vaste opération d’espionnage d’autres collaborateurs de WikiLeaks. « Il ne semble pas y avoir de limites », déclare un ancien haut responsable du contre-espionnage cité dans le rapport.

La rédactrice en chef de WikiLeaks, Kristinn Hrafnsson, a posté sur Twitter : « Une première en 30 ans de carrière comme journaliste : découvrir les plans détaillés de la CIA pour kidnapper ou assassiner Julian Assange et d’autres collaborateurs ou partenaires de WikiLeaks, et me demander si je figure sur la liste. »

 


« Si elles sont avérées, ces allégations de menaces de la CIA sur la vie de Julian Assange sont extrêmement préoccupantes et exposent le risque énorme qu’il continue de courir en détention, déclare la directrice des campagnes internationales de RSF, Rebecca Vincent. Ce risque serait démultiplié si les Etats-Unis obtenaient son extradition. Les complots présumés que révèle ce rapport et qui pourraient porter atteinte à la sécurité et à la vie de Julian Assange et de ses collaborateurs constituent également une menace pour la liberté de la presse. L’administration Biden doit immédiatement prendre des mesures pour se distancier de ces rapports choquants des actions du gouvernement Trump, clore définitivement l’affaire Assange et autoriser sa libération avant qu’il ne subisse d’autres attaques. »


Autres sources de préoccupation : des indications selon lesquelles les projets présumés de la CIA auraient influencé les poursuites judiciaires. Selon le rapport, « certains responsables du Conseil de sécurité nationale s’inquiétaient que les propositions de kidnapping d’Assange par la CIA soient non seulement illégales, mais qu’elles pourraient aussi compromettre l’action en justice contre le fondateur de WikiLeaks. Craignant que les plans de la CIA ne viennent entraver une éventuelle affaire pénale, le ministère de la Justice a accéléré la rédaction des chefs d'accusation contre Assange pour s’assurer qu'ils seraient définis s’il était amené aux États-Unis. »


La procédure d'extradition contre Assange devrait se poursuivre les 27 et 28 octobre prochains à la Haute Cour de Londres, où l’appel des États-Unis sera entendu. RSF prévoit de suivre l’audience en appel : elle a été la seule ONG autorisée à suivre l’ensemble de la procédure d’extradition à ce jour, en dépit des sévères restrictions imposées par le tribunal de première instance.


RSF est convaincue qu'Assange a été ciblé en raison de sa contribution au journalisme d'intérêt public. Elle croit également que son extradition et les poursuites engagées contre lui porteraient un coup sérieux à la liberté de la presse et à l'avenir du journalisme, et auraient un effet dissuasif durable sur le journalisme de sécurité nationale dans le monde.


 Les Etats-Unis et le Royaume Uni occupent respectivement la 44e et la 33e place sur 180 pays au Classement mondial de la liberté de la presse établi par RSF en 2021.

REF.:

Serveurs DNS des principaux FAI

 

 

Serveurs DNS des principaux FAI

La liste ci-dessous donne les adresses IP des serveurs de noms (DNS) des principaux fournisseurs d'accès à Internet (FAI) en France, en Belgique, au Canada et en Suisse :


Chargement de votre vidéo
"FAQ : serveurs dns des pricipaux fai"

DNS Belgacom

Belgacom fait désormais partie de Proximus, dont les serveurs de nom sont les suivants :

  • DNS primaire : 195.238.2.21
  • DNS secondaire : 195.238.2.22

DNS Bluewin.ch

En VDSL :

  • DNS primaire : 195.186.1.162
  • DNS secondaire : 195.186.4.162

En ADSL :

  • DNS primaire : 195.186.1.111
  • DNS secondaire : 195.186.4.111

DNS Bouygues

  • DNS primaire: 194.158.122.10
  • DNS secondaire: 194.158.122.15

DNS Cloudflare

DNS public (très rapide) de nom 1dot1dot1dot1.cloudflare-dns.com
Facile à se mémorer en plus

  • DNS 1 en IPV4 1.1.1.1 et en IPV6 2606:4700:4700::1111
  • DNS 2 en IPV4 1.0.0.1 et en IPV6 2606:4700:4700::1001

DNS Colt France

  • DNS primaire : nscache0.coltfrance.com : 195.68.0.1
  • DNS secondaire : nscache1.coltfrance.com : 195.68.0.2

DNS FDN

Résolveurs ouverts et publics disponibles aux adresses IPv4 et IPv6 suivantes :

  • DNS primaire : ns0.fdn.fr : 80.67.169.12 et en IPV6: 2001:910:800::12
  • DNS secondaire : ns1.fdn.fr : 80.67.169.40 et en IPV6: 2001:910:800::40

DNS Free

  • DNS Primaire : dns1.proxad.net 212.27.40.240
  • DNS Secondaire : dns2.proxad.net 212.27.40.241

aussi :

  • ns0.proxad.net 212.27.32.2
  • ns1.proxad.net 212.27.32.130
  • ns2.proxad.net 212.27.53.253
  • ns3.proxad.net 212.27.37.3

ipv6 :

  • 2a01:e0c:1:1599::22
  • 2a01:e0c:1:1599::23

DNS Google

  • DNS primaire : google-public-dns-a.google.com 8.8.8.8 ipv6: 2001:4860:4860::8888
  • DNS secondaire : google-public-dns-b.google.com 8.8.4.4 ipv6: 2001:4860:4860::8844

DNS Magic Online

  • DNS Primaire : 194.149.160.9
  • DNS Secondaire : 194.149.160.1

DNS Médiaserv

  • DNS Primaire : 213.188.172.70
  • DNS Secondaire : 213.16.20.51

DNS Nérim

  • DNS Primaire : 62.4.16.70
  • DNS Secondaire : 62.4.16.80

DNS Nordnet

  • DNS Primaire : 194.206.126.253
  • DNS Secondaire : 194.51.3.49

DNS Numéricable

  • DNS Primaire : 89.2.0.1
  • DNS Secondaire : 89.2.0.2

aussi, plus ancien:

  • DNS Primaire : 81.220.255.4
  • Dns Secondaire : 80.236.0.68

DNS Orange

Les DNS pour les utilisateurs de Livebox, Orange mobile ou Sosh sont les suivants :

  • DNS Primaire : 80.10.246.2
  • DNS Secondaire : 80.10.246.129

DNS OVH

  • DNS Primaire :dns1.isp.ovh.net 91.121.161.184 IPV6 2001:41d0:1:e2b8::1
  • DNS Secondaire : dns2.isp.ovh.net 91.121.164.227 IPv6 2001:41d0:1:e5e3::1
  • DNS Tertiaire : dns3.isp.ovh.net 188.165.197.144 IPv6 2001:41d0:2:8e90::1


DNS Proximus

  • DNS primaire : 195.238.2.21
  • DNS secondaire : 195.238.2.22

DNS QUAD9

Quad9 est un résolveur public :

  • dns.quad9.net opv4: 9.9.9.9
  • IPv6: 2620:fe::fe
  • IPv6: 2620:fe::9

supporte DOH (dns sécurisé sur https) à l'adresse https://dns.quad9.net/dns-query
ainsi que dnscrypt.

DNS SFR

  • DNS primaire : 109.0.66.10
  • DNS secondaire : 109.0.66.20

DNS Bell Canada

  • DNS Primaire : 198.235.216.110
  • DNS Secondaire : 209.226.175.224

DNS Videotron

  • DNS Primaire : 205.151.222.253
  • DNS Secondaire : 205.151.222.254

DNS Wanadoo

DNS Primaire : 80.10.246.2
DNS Secondaire : 80.10.246.129

DNS OpenDNS

Les DNS d'OpenDNS sont utilisables gratuitement quel que soit votre fournisseur d'accès. Cela peut être une alternative intéressantes si les DNS de votre fournisseur d'accès posent problème. En prime, ils sont très rapides et offrent une protection contre le phishing.
Mais ce sont par principe des dns menteurs.

  • DNS Primaire : 208.67.222.222
  • DNS Secondaire : 208.67.220.220

Pour plus d'informations, voir cet article sur OpenDNS.

les sites de DNS sécurisés sur HTTPS (DOH)

Depuis ses dernières versions Firefox permet d' envoyer requêtes et recevoir réponses au système DNS de manière chiffrée et sécurisée, sans les restrictions d'un état, d'un FAI ou d'une entreprise, ainsi que celles du fichier hosts.
Chrome permet ça aussi, mais dans une moindre mesure (via paramètres en ligne de commande).
Firefox propose le site du fournisseur américain cloudflare (qui produisent aussi 1.1.1.1 voir ci dessus) par défaut suite à un accord entre eux, mais d'autres serveurs https sont possibles, notamment pour ceux qui comptent dessus au niveau contrôle parental, une liste se trouve ici.
Il serait intéressant qu'à l'avenir on puisse configurer l'accès à plusieurs et non un seul serveur, mais par défaut (c'est désactivable), on revient aux DNS non sécurisés du système en cas de non réponse.

 

REF.:

13 SERVEURS RACINES POUR INTERNET, POURQUOI PAS PLUS ?

 

 

 

13 SERVEURS RACINES POUR INTERNET, POURQUOI PAS PLUS ?










La version PDF de cet article est disponible sur ce lien


Rassurez-vous ce n’est pas parce que je suis né un 13. Il y a  plusieurs raisons qui ont poussé à la standardisation du nombre de serveurs racines (13) de l’Internet.
A travers cet article je  vous donnerai un aperçu sur cette passive problématique en mettant l’accent  sur les enjeux géo-stratégiques et politiques de la localisation et de l’administration de ces serveurs racines.
Avant l’entame du vif du sujet je voudrais vous présenter un petit aperçu sur le DNS, sur ce qu'est un serveur racine DNS (en anglais root server). Il ne faut déjà pas se faire une imagination particulière sur les serveurs racines. Ce sont des serveurs DNS (Comme nous pouvons l’installer sur nos machines ou en entreprise : Bind, NSD, Knot, Ect) et dont l’infrastructure (hardware) est bien dimensionnée (puissance de processeur, mémoire disque, etc.) et capable de répondre à la charge des requêtes DNS de l’Internet mondial.
De façon spécifique un serveur racine répond  aux requêtes  relatives aux noms de domaine de premier niveau (Top Level Domain TLD). Ils assurent donc la redirection vers les serveurs DNS de premier niveau demandé. Par exemple si  la requête envoyée vers le serveur racine concerne le domaine biaou.net, le serveur racine redirigera la requête vers le serveur DNS du .NET qui est enregistré dans sa base de données.
Le rôle des serveurs racines DNS est donc ultra important dans le fonctionnement de l’Internet aujourd’hui. C’est son point d’entrée.
Le Système de nom de domaine (DNS: Domain Name System), est construit, juste parce que nous, les humains ne sommes pas assez capables de nous souvenir des numéros (Adresses IP), ou il est plus facile pour l’humain de se rappeler plus les noms plutôt que les chiffres.
Ce système appelé DNS permet donc de réaliser cette association entre les noms et les numéros IP à notre place. On parle de résolution DNS.
Je vous recommande les lectures/Vidéos suivantes pour comprendre comment fonctionne le DNS (Vidéo Ici / Lecture).
Vu la criticité que représente l’Internet, il est important d’assurer sa robustesse, sa disponibilité et surtout sa résilience. Les concepteurs ont donc adopté une architecture hiérarchique pour le DNS et dont le sommet est la racine (.).
Image 1: Architecture Hiérarchique du DNS

Même si on parle souvent de “la racine” du DNS, Il est important de préciser qu’il existe 13 serveurs racines/instances pour Internet qui sont nommées de A à M. et gérées par 12 organismes différents.

Serveur racine Nom
Géré par
a.root-servers.net
j.root-servers.net
b.root-servers.net
c.root-servers.net
d.root-servers.net
e.root-servers.net
f.root-servers.net
g.root-servers.net
h.root-servers.net
L'armée américaine
i.root-servers.net
k.root-servers.net
l.root-servers.net
m.root-servers.net
WIDE

Pourquoi se limiter à 13 serveurs/Instances vu l’importance et la criticité de l’Internet aujourd’hui ?

Ce serait une belle blague technique de dire qu’il existe seulement 13 serveurs physiques pour la racine DNS de l’Internet. Nous avons 13 instances représentées chacune par une IP de la racine. Et derrière chaque instance plusieurs serveurs racines. Imaginez un instant que nous ayons un seul serveur racine, si cette unique racine du DNS a un problème,  l'ensemble de l'Internet sera affecté. Dans la suite de ce article je vous expliquerai pourquoi nous avons seulement 13 adresses IP pour la racine du DNS et pas plus.
Comme je l’ai dit plus haut nous avons 13 adresses IP. Si vous êtes familiers avec les réseaux informatiques ou si vous êtes un administrateur système, vous auriez certainement déjà entendu parler de ces deux protocoles: UDP (User Datagramme Protocol) et TCP (Transmission Control Protocol). Pour des raisons de performances et de rapidité,  le protocole UDP est très privilégié par rapport au protocole TCP particulièrement dans le DNS.
En effet, historiquement, le protocole UDP est généralement utilisé pour le DNS lorsque la taille des paquets DNS est inférieure à 512 octets. Dès que la taille passe à plus 512 octets c’est le protocole TCP qui est engagé. Le protocole TCP convient mieux pour la fiabilité et l’UDP est adapté à la performance.
Vu l’importance du DNS dans le fonctionnement de l’Internet, cette technologie ne devrait jamais être lente. Par conséquent le protocole UDP est celui qui convient pour assurer une bonne performance du DNS.
Un paquet DNS doit contenir toutes ces 13 adresses IP de la racine  de l’Internet et d'autres informations de protocole UDP.
§  Un paquet DNS a  une taille 512 octets (Historiquement)
§  Et 32 octets pour l’IP
Si les 13 adresses IP de la racine doivent être encapsulées dans un paquet DNS ils occuperont 416 (13 x 32) octets. Il restera donc 96 (512 - 416) octets pour les informations de l’en-tête du paquet UDP et éventuellement pour ajouter une autre adresse IP à la racine au besoin.
Il n’est pas compliqué que IANA (Internet Assigned Numbers Authority) définisse plusieurs adresses IP : 50 ou 100 pour la racine du DNS. Le problème c’est qu’on ne serait plus en mesure de les encapsuler tous dans un paquet DNS et par conséquent impossible de les envoyer dans un seul paquet DNS en UDP.
Dans un tel contexte on serait obligé de les envoyer en plusieurs paquets; ce qui réduira les performances, une exigence capitale pour le DNS car c’est le protocole TCP qui sera utilisé.
Cette contrainte a donc conduit à garder à 13 le nombre d’adresse IP pour la racine. Ce choix technologique est ainsi basé sur une contrainte de protocole Internet (IP) version 4 (IPv4) et celui de l’UDP.
J’imagine que vous avez maintenant une grande visibilité sur le choix du nombre 13 qui n’est pas aléatoire.
Maintenant avec l'apparition de l’IPv6 qui est codé sur 128 bits que va-t-il se passer?

Maintenant avec IPv6, aurions-nous moins de 13 adresses IP pour la racine DNS ?

Une adresse IPv6 est codée sur 128 bits. Alors il serait impossible d’ajouter les adresses IPv6 de la racine dans un paquet UDP. Déjà si on conserve les 13 adresses IPv4 il ne reste plus 96 octets sur 512 octets.
Mais ne vous inquiétez pas, l'arrivée de l’IPv6 qui est codée sur un nombre important de bit  a été anticipée au niveau du DNS. En 1999 une RFC: RFC 2671 (Mis à jour dans le RFC 6891) a supprimé la contrainte liée à la limitation de la taille des paquets DNS 512 octets. Désormais les paquets DNS peuvent atteindre 4096 octets et même plus. On parle donc depuis ce temps de l’introduction de l’EDNS0 extension du protocole Domain Name System (En anglais Extension mechanisms for DNS).
La standardisation de L’EDNS0 n’est pas seulement liée à l’IPv6. Elle est importante pour la mise en œuvre du DNSSEC dont je vous parlerai très bientôt dans une autre publication. Malheureusement plus de dix ans après la publication de cette RFC certains pare-feu sont toujours mal configurés et filtrent encore les paquets DNS de plus de 512 octets. Cela est un véritable danger pour la résolution des noms.
Pire, certains fournisseurs d’accès à Internet en France filtrent toujours et n’appliquent pas l’EDNS0 dans leur infrastructure. Je me suis amusé à vérifier cela via la boxe Internet de quelques opérateurs en France. Le constat est ultra amer et très décevant. Certains opérateurs filtrent toujours des paquets de plus 512 octets sur certains de leur firewall. Seul un opérateur a un pare-feu qui limite la taille du paquet à 1433 octets (Lors de mes tests).
Vous pouvez vérifier cela par vous-même et savoir si le pare-feu de votre fournisseur d’accès à internet filtre ou non les paquets DNS supérieur à 512 octets.
Si vous êtes sur une machine Linux/Mac OS
# dig +short rs.dns-oarc.net txt
Si la taille est inférieure à 2048 octets, danger : Les réponses aux requêtes DNS signées en DNSSEC c’est-à-dire sécurisées, auront du mal à traverser ces pare-feu; ce qui pourrait engendrer des problèmes au site web sécurisé en DNSSEC.
Il est important de retenir que cette limite est une très vielle pratique qui ne devrait plus être d’actualité surtout qu’aujourd’hui  six (06) des treize (13) serveurs racines sont en IPv6 et la racine signée en DNSSEC.

Combien de serveurs racines physiques avons-nous précisément?

J’espère que vous n’imaginez pas que nous ayons seulement 13 serveurs racines physiques.
Nous avons environ 370 serveurs racines physiques qui sont géographiquement distribués sur l’ensemble de la planète. Juste que l’ensemble de ces serveurs est accessible via les 13 adresses IP des différentes instances.
La répartition géographique des serveurs DNS est très importante. Elle permettra à un utilisateur localisé en France par exemple d’atteindre plus rapidement le serveur DNS racine près de chez lui que d'atteindre un serveur racine situé aux États-Unis.
C’est vrai qu’au début ils étaient tous situés aux États-Unis. Mais des améliorations récentes ont rendu disponibles dans différents pays et continents, des images de serveurs racines, démocratisant ainsi un tout petit peu l’impérialisme étasunien sur les serveurs DNS racines.

Comment ça marchent 13 IP racines pour plus de
370 serveurs racines physiques?

Il y a plusieurs serveurs pour une instance de serveur racine. Par exemple a.root-servers.net est une instance constituée de nombreux serveurs à différents endroits de la planète.
Il y une technique en réseau appelée Anycast. En effet, l’Anycast joue un rôle majeur dans la réalisation de cette architecture pour distribuer des serveurs racines DNS.
En termes simples l’Anycast est une technologie qui permet à plusieurs serveurs situés à des endroits différents de partager une seule adresse IP.  Avec l’Anycast, lorsqu'une requête est envoyée à une adresse IP racine, celle-ci sera redirigée vers  le serveur racine le plus proche ou le "plus efficace" en tenant compte de la métrique de routage.
Cela signifie que si je veux atteindre f.root-servers.net de Nancy, les emplacements les plus proches possibles sont Paris, Francfort en Allemagne et Genève en Suisse. Ça ne sera donc pas les Etats-Unis. C’est la raison pour laquelle les IP des serveurs racines sont des IP de type Anycast.
La racine DNS s’appuie  fortement sur cette technologie qui offre de nombreux avantages notamment une haute vitesse, une faible latence, une forte résilience aux pannes et une protection contre les attaques de types DDOS.

D’accord, mais comment sont-ils distribués
géographiquement sur la terre?

Selon Wikipedia, il y a plus de 370 serveurs racines réparties dans différents continents. La carte ci-dessous montre l’emplacement des serveurs racines DNS sur la planète.
On se rend compte qu’il existe plusieurs serveurs racines sur chaque continent.
Source : Root-Servers 
Image 2: Répartition Géographique des serveurs racines

Quel est le rôle des États-Unis aujourd’hui qui disposent un nombre important de serveurs racines sur leur territoire?

Les États-Unis dominent-ils Internet aujourd’hui?
Comme vous pouvez le déduire, la racine du DNS est à la fois le cœur et le maillon le plus important de l’Internet. Sur les 13 Instances de serveurs racines du DNS, 10 sont gérées par des organismes étasuniens  sous contrat avec leur Etat. Un serveur est géré par un organisme suédois, un autre par un organisme japonnais et puis le dernier par le registre européen basé aux Pays-bas (RIPE NCC).
Même si les États-Unis n’ont pas un contrôle absolu sur la racine du DNS il faut dire qu’ils ont aujourd’hui une position extrêmement dominante qui pourrait influencer l’Internet mondial.
D’ailleurs cette position étasunienne ne va pas durée.  L’Agence nationale des télécommunications et de l’information des États-Unis (National Telecommunications and Information Administration (NTIA) a annoncé le 14 Mars 2014 une ouverture importante qui pourrait changer  la donne par rapport à l’impérialisme étasunien sur la racine du DNS et sur l’attribution et la gestion des ressources critiques de l’Internet. Son intention est  le retrait et le transfert du rôle de la supervision de la fonction IANA (Internet Assigned Numbers Authority) à la communauté multi-partite mondiale de l’Internet
En effet, l’IANA qui depuis 1998 est une composante de l’ICANN a pour rôle la gestion de la racine du DNS, de l’attribution des adresses IP, et de la maintenance des protocoles du système Internet avec I'IETF.
Par ailleurs il est important de préciser en lisant dans les lignes de cette déclaration que le gouvernement  étasunien ne ferait pas cette concession sans aucune garantie de la continuité de la supervision de l’Internet. Aujourd’hui c‘est l’ICANN,  soumis au droit Californien, qui conduit ce processus de transition.  Vous pouvez suivre l’évolution des discussions publiques et de cette transition en consultant ce lien.

La version PDF de cet article est disponible sur ce lien
Références de rédaction

§  Ressource Wikipédia sur les serveurs Racines
 
http://fr.wikipedia.org/wiki/Serveur_racine_du_DNS


§  Serveurs Racines, Infrastructure critique de l’Internet par Sarath Pillai
http://www.slashroot.in/dns-root-servers-most-critical-infrastructure-internet

§  Explication du nombre de serveur par Miek GIEBEN
http://miek.nl/posts/2013/Nov/10/13%20DNS%20root%20servers/



§  Votre serveur DNS peut-il faire passer des paquets de toutes les tailles ? par Stéphane Bortzmeyer
http://www.bortzmeyer.org/dns-size.html
    §  Article de l’Afnic sur le rôle des Etats-Unis dans ICANN, par Pierre Bonis

     §  Wikipédia sur EDNS, IPv4, IPv6
         §  Processus de Transition de la fonction IANA par ICANN

https://www.icann.org/fr/system/files/files/process-next-steps-18jun14-fr.pdf

 

REF.: