La newsletter Afnic de février est en ligne ▻http://afnic-media.fr/newsletter/20200227.html Abonnez-vous ici ►https://www.afnic.fr/fr/ressources/newsletter-afnic-36.html
The Afnic newsletter for February is out ▻http://afnic-media.fr/newsletter/20200227-english.html You can subscribe today on ▻https://www.afnic.fr/en/resources/afnic-newsletter-90.html
99 % des articles sur cette affaire sont ridicules. (À commencer par la dépêche AFP.)
Ici, le mieux est « Sur Reddit, certains désignent les Russes, les Coréens ou en encore les Chinois comme responsables » Reddit !!!! ??? Ça, c’est de l’investigation. Prochaine étape : « au Café du Commerce, certains désignent les immigrés comme responsables »
Si encore il y avait le début d’une information concrète, ça serait chouette. Mais pour l’instant, rien vu dans ce que j’ai lu.
Des articles sérieux (je ne dis pas « plus sérieux », je dis « sérieux ») : ▻https://www.nextinpact.com/brief/non--internet-n-est-pas-mort-ce-week-end--mais-deployez-dnnsec--7869.htm ►https://www.lemonde.fr/pixels/article/2019/02/25/non-une-attaque-massive-et-inedite-n-est-pas-en-cours-sur-l-internet-mondial
Selon les experts, les pirates appartiennent le plus souvent à deux catégories principales : des individus ou des groupes de « hackers » qui veulent gagner de l’argent (rançongiciels, revente de données personnelles sur la partie cachée d’internet surnommée darknet...) ou bien des Etats, qui souhaitent espionner d’autres pays et/ou y semer des dissensions politiques. La Chine, la Russie, l’Iran ou la Corée du Nord seraient particulièrement actifs en matière de piratage, ce que démentent les intéressés.
►https://seenthis.net/messages/762877
Selon les experts ce serait une attaque de l’axe du mal dont le grand satan iranien. houla houla houlala, j’ai peur !
Les opportunistes sont déjà sur le coup...
Bonjour,
Vu l’ampleur de l’attaque en cours, nous pensons qu’il est très impotrtant de vous en informer.
Une vague d’attaques informatiques sans précédent ciblant l’organisme international ICANN,est en cours.
L’ICANN est l’organisme qui gère tous les noms de domaines dans le monde, donc TOUS les sites internet sont potentiellement la cible des hackeurs.
Le mode opérétoire permet à un attaquant de se substituer à un site légitime et voler ainsi les identifiants, mots de passe, adresse mail et autres informations personnelles de personnes s’y connectant.
Voici un rappel des préconisations élémentaires à respecter lorsque vous accédez à tout site Internet :
• Vérifiez la présence d’un cadenas dans la barre en haut à gauche de la page du navigateur
• Ne poursuivez pas la navigation si un message vous indique que le certificat du site visité n’est pas valide. Cette information peut vous être affichée de différentes manières, comme par exemple :
o « Non sécurisé » dans la barre en haut à gauche du navigateur ;
o « Votre connexion n’est pas privée » ;
o « Echec de la connexion sécurisée ».
Nous restons à votre disposition du lundi au vendredi de 9h00 à 17h00 au 09 54 43 67 20.
Nous vous remercions de votre confiance et à très bientôt sur www.prout.com
Cordialement,
Les équipes du groupe PROUT SERVICES
A propos de PROUT Services
Au travers de ses deux centres de compétences dédiées aux CMS JOOMLA et au CMS WORDPRESS, nos équipes vous proposent l’ensemble des services vous permettant une communication numérique efficiente.
Ce message étant envoyé par un automate, merci de ne pas y répondre directement puisque votre message ne pourrait être pris en compte.
Remplacement de la clé KSK de la zone racine : Êtes-vous prêts ? Voici quelques tips pour bien vérifier que votre résolveur connait KSK-2017 ▻https://www.afnic.fr/fr/ressources/blog/remplacement-de-la-cle-ksk-de-la-zone-racine-etes-vous-prets.html
Replacement of the KSK of the root zone : Are you ready ? Here are a few tips to help you check your resolver is familiar with KSK-2017 ▻https://www.afnic.fr/en/resources/blog/replacement-of-the-ksk-of-the-root-zone-are-you-ready.html
« Selon la légende, 14 personnes contrôlent Internet, à l’aide de 7 clés secrètes. Dans ce second épisode Goat In The Shell, nous nous pencherons sur ces fameux maîtres d’Internet… »
▻https://www.youtube.com/watch?v=uxCeG-XpLdU
[Bonnes explications dans la seconde partie.]
#humour #darknet #hackers #DNSSEC #DNS #pipeautage_médiatique
Le renseignement militaire et les « petits pédés » de 4chan
►http://www.slate.fr/story/140342/le-renseignement-militaire-4chan
Qualifié de « poubelle du web », le forum 4chan est également connu pour être le plus prolixe générateur de mèmes mais aussi pour ses « fake news ». L’une d’entre elles, délirante et conspirationniste, a pourtant été reprise, au premier degré, par le service de renseignement militaire français en charge du contre-espionnage et l’un des experts « cyber » de la gendarmerie nationale.
La revue de la gendarmerie nationale omettait de même de préciser que ledit blogueur définissait aussi l’informatique quantique comme « quelque chose dont le nom est « falcighol dérivation polymère » (resic), ou encore qu’il existe, et au-delà dudit « Marianas Web », trois autres « couches (6, 7, 8) : les niveaux 6 et 7 ne sont que des conneries. Le huitième, et le dernier niveau, est celui qui intéresse la plupart des gens », et pour cause :
« Le niveau 8 du web est censé contrôler l’ensemble d’Internet. C’est apparemment une anomalie découverte dans les années 2000. Il est complètement insensible, mais envoi des signaux directement dans les ordinateurs du monde entier, ce qui lui permet de contrôler Internet, mais cela dépend du hasard. Personne ne semble avoir le contrôle. D’après ce qu’on dit, une organisation / gouvernement secret détient le contrôle sur ce niveau, mais on ne sait pas. Apparemment, vous devez résoudre un simple puzzle… verrouillage des fonctions de niveau 17 niveau quantique TR001. Il s’agit essentiellement de l’informatique quantique le plus avancé, totalement impossible à résoudre avec nos ordinateurs. Vous avez besoin d’une technologie profonde que personne ne possède. »
RFC 8198 : Aggressive Use of DNSSEC-Validated Cache
Lorqu’un client #DNS interroge un résolveur, celui-ci peut répondre très vite si l’information demandée est dans sa mémoire (son « cache ») mais cela peut être beaucoup plus lent s’il faut aller demander aux serveurs faisant autorité. Il est donc essentiel, pour les performances du DNS, d’utiliser le cache le plus possible. Traditionnellement, le résolveur n’utilisait le cache que si la question posée par le client avait une réponse exacte dans le cache. Mais l’arrivée de #DNSSEC autorise un usage plus énergique et plus efficace du cache : ce nouveau #RFC permet aux résolveurs de synthétiser des réponses à partir des informations DNSSEC.
RFC 8063 : Key Relay Mapping for the Extensible Provisioning Protocol
Un des problèmes pratiques que pose #DNSSEC est le changement d’hébergeur #DNS. Si on sous-traite sa gestion des clés cryptographiques, et ses signatures à un tiers, que faire lors du changement de prestataire, pour ne pas casser la chaîne de confiance DNSSEC ? On ne peut évidemment pas demander à l’ancien hébergeur de transmettre la clé privée au nouveau ! Même pour les données non confidentielles, comme la clé publique, la transmission est difficile car les deux hébergeurs n’ont pas de canal de transmission sécurisé commun. Ce nouveau RFC propose d’utiliser comme canal sécurisé le registre de la zone parente et, plus concrètement, de définir une extension au protocole #EPP, qui permet un mécanisme de « messagerie » électronique sécurisée, afin de l’utiliser entre deux clients du même registre.
DNS issues? Who Ya Gonna Call? ZoneMaster! A blog article by Sandoche Balakrichenan from Afnic for CENTR
Read now and share ! ▻https://www.centr.org/news/news/who-ya-gonna-call-for-dns-issues.html
#DNS #ZoneMaster #Afnic #DNSSEC
RFC 7958 : DNSSEC Trust Anchor Publication for the Root Zone
Le mécanisme d’authentification des informations DNS nommé #DNSSEC repose sur la même structure arborescente que le #DNS : une zone publie un lien sécurisé vers les clés de ses sous-zones. Un résolveur DNS validant n’a donc besoin, dans la plupart des cas, que d’une seule clé publique, celle de la racine. Elle lui servira à vérifier les clés des TLD, qui serviront à valider les clés des domaines de deuxième niveau et ainsi de suite. Reste donc à configurer la clé de la racine dans le résolveur : c’est évidemment crucial, puisque toute la sécurité du système en dépend. Si un résolveur est configuré avec une clé fausse pour la racine, toute la validation DNSSEC est menacée. Comment est-ce que l’#ICANN, qui gère la clé principale de la racine, publie cette clé cruciale ? Six ans après la signature de la racine du DNS, c’est enfin documenté, dans ce #RFC.
RFC 7929 : DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
Un problème classique du système de cryptographie #OpenPGP est de vérifier les clés publiques des correspondants. Les trouver, c’est relativement facile : le correspondant pense à vous les envoyer ou bien on se sert tout simplement d’un serveur de clés. Mais ceux-ci ne garantissent rien sur la clé. N’importe qui peut créer une clé marquée flotus@whitehouse.gov et la mettre sur les serveurs de clé, même si cette clé n’a rien à voir avec la Maison-Blanche. Avant la solution de ce nouveau #RFC, il n’existait pas de mécanisme sécurisé pour récupérer une clé publique PGP. Que propose ce RFC ? De mettre les clés dans le #DNS (nouveau type d’enregistrement OPENPGPKEY), dans le domaine de la partie droite de l’adresse de courrier, sécurisée par #DNSSEC. En gros, il s’agit de faire pour le courrier et PGP ce que fait déjà #DANE pour le Web/TLS.
Avant la solution de ce nouveau #RFC, il n’existait pas de mécanisme sécurisé pour récupérer une clé publique PGP.
/me s’étouffe dans son verre d’eau
PKA ?
DNSSEC as DDoS amplification attack vector
Here is a report that explains how DNSSEC can be subverted as an amplifier in DDoS attacks.
• Average DNSSEC amplification factor : 28.9 x
• Average response to a 80 byte “ANY” query : 2313 bytes
• Largest amplification response : 17377 bytes
▻https://ns-cdn.neustar.biz/creative_services/biz/neustar/www/resources/whitepapers/it-security/dns/neustar-dnssec-report.pdf
We ran DNS queries from four separate and independent open recursive servers to look for DNSSEC name servers that responded to queries using the DNS command “ANY,” which is a favorite malicious query used by hackers.
[...]
Of the 1,349 domains that we examined, 1,084 were signed with DNSSEC and responded to the “ANY” query.
Which means: 80% of the domains in this one community could be repurposed as a DDoS amplifier and
used maliciously.
[...]
For organizations that use and rely on DNSSEC, Neustar
recommends ensuring that your DNS provider does not
respond to the “ANY” queries or has some mechanism in
place to identify and stop misuse.
L’observatoire de la résilience de l’Internet français publie son rapport 2015 ▻https://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/9991/show/l-observatoire-de-la-resilience-de-l-internet-francais-publie-son-rapport-2015
#ANSSI #AFNIC #INTERNET #RESILIENCE #WEB #TLS #BGP #SMTP #DNSSEC #IPv6 #HTTPS #RPKI #DDoS
La newsletter Afnic de janvier est en ligne ! Consultez la ici ▻http://afnic-media.fr/newsletter/20160119.html
Pour vous inscrire ►https://www.afnic.fr/fr/ressources/newsletter-afnic-36.html
Afnic newsletter for January is out! Read it here ▻http://www.afnic-media.fr/newsletter/20160119-english.html
Subscribe directly here ▻https://www.afnic.fr/en/resources/afnic-newsletter-43.html
[Blog Afnic] IPv6 et DNSSEC ont 20 et 19 ans. Même combat et mêmes défis !? par Mohsen Souissi ▻https://www.afnic.fr/fr/ressources/blog/ipv6-et-dnssec-ont-20-et-19-ans-meme-combat-et-memes-defis.html
[Afnic blog] IPv6 and DNSSEC are respectively 20 and 19 years old. Same fight and challenges? by Mohsen Souissi ▻https://www.afnic.fr/en/resources/blog/ipv6-and-dnssec-are-respectively-20-and-19-years-old-same-fight-and-challenges
NTP - Network Time Protocol - can be abused for attacks on HTTPS, DNSSEC, and Bitcoin.
Researchers at University of Boston describe how unencrypted NTP traffic can be intercepted and then used to change the time of clients. For example, the clock can be turned back to a point where the host would accept a fraudulent digital certificate that has been revoked.
Or by advancing the time on a DNS resolver the DNSSEC validation can be made to fail.
The researches also give advice on how to protect yourself against these various attacks.
Attacking the Network Time Protocol
Abstract—We explore the risk that network attackers can
exploit unauthenticated Network Time Protocol (NTP) traffic to
alter the time on client systems. We first discuss how an onpath
attacker, that hijacks traffic to an NTP server, can quickly
shift time on the server’s clients. Then, we present a extremely
low-rate (single packet) denial-of-service attack that an off-path
attacker, located anywhere on the network, can use to disable NTP
clock synchronization on a client. Next, we show how an off-path
attacker can exploit IPv4 packet fragmentation to dramatically
shift time on a client. We discuss the implications on these
attacks on other core Internet protocols, quantify their attack
surface using Internet measurements, and suggest a few simple
countermeasures that can improve the security of NTP.
▻http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf
backup: ▻http://docdro.id/Cf0QqBD
RFC 7583 : DNSSEC Key Rollover Timing Considerations
Contrairement au #DNS classique, le système de sécurité #DNSSEC est très dynamique : il faut changer les signatures régulièrement et il est souvent recommandé de remplacer (changer) les clés. Compte-tenu du fait que le DNS n’est pas synchrone (les changements n’apparaissent pas instantanément partout dans l’Internet), ce changement, ce remplacement (rollover, dans la langue d’Alan Turing) est une opération délicate et qui nécessite le strict respect d’un certain nombre de durées. Ce #RFC donne des conseils sur la temporalité des opérations DNSSEC.
La vaste blague Images d’art — Medium
▻https://medium.com/@symac/la-vaste-blague-images-d-art-644e83124136
Et commençons par l’élément le plus critique, comment peut-on, en 2015, espérer faire rayonner la France en proposant des images de 768 pixels par 650 ? Pour donner un ordre d’idée et sans entrer dans des considérations techniques sur ce qu’est une résolution d’image, cela correspond à un demi écran du dernier iPhone ! Et très concrètement, cela s’illustre par la comparaison suivante pour La liberté guidant le peuple d’Eugène Delacroix proposée par Gallorum sur twitter. Ce rayonnement international est un peu flou…
On peut aussi noter que le domaine est mal signé avec #DNSSEC et donc inaccessible depuis les gens qui utiisent un résolveur DNS validant (Free, Google). ▻https://zonemaster.net/test/40381 ▻http://dnsviz.net/d/images-art.fr/ViTnig/dnssec
Ce problème est désormais réparé. Leçons en ▻http://www.bortzmeyer.org/dnssec-qui-est-coupable.html
à comparer aux musées nationaux norvégiens ▻http://seenthis.net/messages/421876
RFC 7646 : Definition and Use of DNSSEC Negative Trust Anchors
Comme toutes les techniques de sécurité, #DNSSEC, qui vise à assurer l’autenticité des réponses #DNS, a ses inconvénients. De même qu’une serrure fermée à clé peut avoir pour conséquence de vous empêcher de rentrer chez vous, si vous avez oublié la clé, de même DNSSEC peut empêcher d’accéder à un domaine si le gérant de la zone a commis une erreur technique. Autant le DNS d’avant était très tolérant (il fallait vraiment insister pour « planter » une zone), autant DNSSEC est délicat : les erreurs ne pardonnent pas, puisque le but de DNSSEC est justement d’empêcher l’accès aux données si elles sont suspectes. Mais les outils et les compétences pour gérer DNSSEC ne sont pas encore parfaitement au point et ne sont pas utilisés partout. Il y a donc de temps en temps des plantages, qui ont pour conséquence la panne d’une zone DNS entière. Face à ce problème, les gérants des résolveurs DNS validants aimeraient bien temporairent suspendre les vérifications, après avoir vérifié qu’il s’agissait bien d’un problème et pas d’une attaque. Cette suspension temporaire et limitée se nomme #NTA pour Negative Trust Anchor et est décrite dans ce #RFC.
Après un lecture rapide, je comprends que les arguments principaux sont :
– la technologie est vieille
– la sécurité n’augmente avec DNSSEC que dans peu de cas
– personne n’utilise DNSSEC alors que ça fait des années que c’est disponible
– c’est trop compliqué à implémenter et utiliser
– ça revient à transférer la confiance des autorités de certification PKI (privées pour la plupart) aux gouvernements qui gèrent les noms de domaine de primer niveau (et ça serait mal selon l’auteur).
J’ai bien lu ? Et qu’en penses-tu, ce sont des arguments valables pour conseiller de ne pas implémenter ni utiliser DNSSEC ?
Qu’en pense @stephane ?
Stéphane il en pense que « réfuter les conneries prend bien plus de temps que de les produire » et qu’il n’a pas de temps à perdre avec un travail trollesque d’aussi mauvaise foi.
Discussion sur #HN :
▻https://news.ycombinator.com/item?id=8894902
J’avoue que je pensais très fort à @stephane en postant ça...
ISOC has some ideas to keep the beginning hackers active on weekends: “Do you have some vacation time during Christmas and New Year’s Day? Are you looking for a weekend project to try out something new? Maybe improve your home network? Or learn a new skill for 2015? If so, why not check out our list of weekend projects [...]”
▻http://www.internetsociety.org/deploy360/blog/category/weekend-projects
Faut-il changer la clé #DNSSEC de la racine ?
Voici le genre de question qui ne va pas angoisser le célèbre M. Michu, mais que se posent sérieusement des tas de techniciens de l’Internet. Cette question a suscité la création récente d’une liste de diffusion très animée, et fera l’objet d’une réunion à la rencontre ICANN de Los Angeles en octobre prochain.
RFC 7344 : Automating DNSSEC Delegation Trust Maintenance
Un des obstacles à un plus large déploiement de #DNSSEC est la nécessité de faire mettre, par le gestionnaire de la zone parente, un enregistrement faisant le lien avec la clé de signature de la zone fille. Cet enregistrement, nommé DS (pour Delegation Signer) est indispensable pour établir la chaîne de confiance qui va de la racine du DNS à la zone qu’on veut sécuriser. Mais, autant signer sa zone ne nécessite que des actions locales, qu’on peut faire tout seul, mettre cet enregistrement DS dans la zone parente nécessite une interaction avec une autre organisation et d’autres personnes, ce qui est souvent compliqué et réalisé d’une manière non standardisée. Ce nouveau #RFC propose une méthode complètement automatique, où la zone fille publie les enregistrements de clé localement, et où la zone parente va les chercher (via le DNS) et les recopier.
Document simple et concret, en français, pour les administrateurs système qui veulent utiliser #DNSSEC (validation et signature) mais sont un peu perdus.
