RFC 7720 : DNS Root Name Service Protocol and Deployment Requirements
L’Internet repose en grande partie sur le #DNS (si ce dernier est en panne, presque plus rien ne fonctionne) et le DNS doit à sa nature arborescente de dépendre de sa racine ou plus exactement de ses serveurs racine. La gestion de ces derniers est donc une question cruciale. Ce très court RFC précise les obligations des serveurs racine en terme de protocoles réseau à suivre. D’autres documents décrivent les exigences opérationnelles.
Maintenant faut juste encore trouver un moyen de se défendre contre une attack DDoS vers les DNS root servers comme celle de fin novembre - début décembre :)
Enfin bon, je pense que l’attaque a montré que le système est tout de même assez robuste.
5 milion de requêtes par seconde c’est quand même pas mal.
@erratic Et si on veut rigoler avec ces attaques, le texte délirant du délirant McAffee vaut la peine (résumé : ces attaques sont faites par Daesh avec des téléphones) ▻http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-ap
OK pour ISIS oui, proofless speculation.
mais pour les smartphones, why not ?
McAfee and other cybersecurity experts believe that smartphones are the most likely culprit for such a botnet, as one can be easily installed to a device through an app, such as a flashlight app. There are other possibilities for the botnets, such as Spam emails, but due to the sheer volume displayed in the attack that answer is unlikely. With more than 7 billion smartphones in the world, McAfee sees this route for an attack on the internet as the logical answer.
“The problem with the recent attack is that the originating IP addresses were evenly distributed within the IPV4 universe,” McAfee says. "This is virtually impossible using spoofing. The second oddity is that every single request asked to resolve the exact same address. There is only one circumstance that can explain the above: the mythical “Zombie Army” of botnets has been built and has been partially activated."
Verisign’s Perspective on Recent Root Server Attacks
Sometimes, the DNS root name servers receive attack traffic where the intent seems to be clear. By examining the traffic, and perhaps with other supporting information, it may be easy to discern whether the intended victim is a third party, or perhaps the root server system itself. At other times, however, the intent is less obvious.
The events of Nov. 30 and Dec. 1, 2015, are one of those cases where the intent as observable on the root server operations side of the system is unclear. While a number of DNS root name servers did receive high levels of traffic, it is unclear whether the intent was to harm the root server system itself.
In addition to anycasting and an array of DNS transaction processing capabilities, Verisign and the other DNS root server operators have a number of techniques for identifying anomalous system loads and then classifying and mitigating malicious activity, as appropriate.
• blocking bogons
• source address filtering, (#BCP38)
although not usable at the root server system itself in this case due to the obvious presence of source address spoofing employed by the attacker source networks
• response rate limiting (RRL)
In this very interesting video is shown graphically, using Hilbert space-filling curve representations that the spoofed source addresses are being generated more or less sequentially, and you can obtain an idea of how the attack operated in two fronts, as monitored on Verisign’s A-Root.
 a space-filling curve, mapping 1D into 2D while preserving locality, ie. points near each other in terms of distance along the curve will also be near each other on the 2D plane ▻http://datagenetics.com/blog/march22013/index.html
@erratic Il n’existe aucune indication qu’il s’agisse de smartphone. Pure spéculation sensationnaliste. Le raisonnement de McAfee est ridicule : c’est justement si les adresses sont usurpées qu’elles peuvent être réparties équitablement ! En outre, c’est un cinglé connu ▻https://en.wikipedia.org/wiki/John_McAfee#Legal_issues
@stephane En effet, curieux personnage !
Ce qui est intéressant c’est de voir de plus en plus de sites/blogs reprendre ses spéculations sur les smartphones espions.
Je suis curieux de voir ce que le #téléphone_arabe en aura fait dans 1 mois, et s’il y aura encore des traces de l’origine du message.
Sinon, je viens de tomber sur cet article assez, on va dire polarisé. Mais bon, si en effet la Maison Blanche l’intéresse, je peux comprendre son discours sur les smartphones.
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.
War machines arise from Kyiv’s ’tank cemetery’
“Ukraine had approximately 5,000 to 7,000 tanks left after the breakup of Soviet Union,” military expert and director of consulting firm Defense Express Serhiy Zhurets told the Kyiv Post. “But I doubt that the government has allocated any funds for tank maintenance at all for the last 25 years. About 10 tanks could have been kept in good condition, but no more.”
What is known is that hundreds, perhaps thousands, have ended up in outdoor storage sites dotted around the country, like the Kyiv Armored Vehicles Plant. The plant, which was designed to produce new tanks and armored personnel carriers, as well as repair them, has mostly been used as a storage site for Defense Ministry’s property since Ukraine became independent.
There are at least 350 tank hulks in the plant’s outdoor storage area – equal to perhaps a third of Ukraine’s present tank force.
Avec une galerie de 17 photos prises sur le site
On a beaucoup parlé des attaques #DoS par réflexion + amplification en les présentant souvent comme spécifiques à #UDP. Mais un article récent (mais passé curieusement inaperçu) montre qu’on peut en faire également avec #TCP.
TCP Handshake Amplification
DDoS amplification attacks currently typically use UDP-based protocols with spoofed source IPs. The reason being that there is no 3-way handshake in UDP.
However, it turns out there are TCP-based protocols are also vulnerable to amplification attacks. Better even, the handshake itself can be abused for amplification.
Authors of the 2014 research mentioned in Stéphane’s article (and below) have identified 4.8 million devices vulnerable to an average TCP-based amplification factor of 112x. Of those, they identified thousands of hosts that can be abused for an amplification of almost 80.000x.
They identified that there are hosts responding to a SYN with an excessive amount of RST packets, and others that transmit actual payload data via PSH packets – even before the three-way handshake has been completed.
From the point of view of an attacker, the number of amplifiers is important to scale up the overall attack bandwidth.
Compared to UDP-based amplification attacks, the fact that there are much more amplifiers makes this form still the most attractive.
An attacker has to scan many more IPv4 hosts in order to find a large enough number of TCP-based amplifiers.
Why would TCP-based amplifiers be interesting?
• They could be interesting to attackers who have little bandwidth available and who want to amplify as much as possible.
• Also, TCP traffic is considerably harder to filter at the network edges than UDP-based protocols. It is not easy to make a difference between legitimate and malicious TCP traffic without appliances that keep trace of and inspect the states of TCP connections.
• Another reason why TCP-based is more complicated is that TCP-based amplification traffic does not carry payload that can be inspected for validity.
Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks
(Marc Kuhrer, Thomas Hupperich, Christian Rossow, Thorsten Holz)
SYN/ACK: The majority of amplifiers cause amplification by repeatedly retransmitting SYN/ACK packets upon our SYN segments. This attack type amplifies traffic up to 80x on average, and for SIP even up to 1,596x.
PSH: The number of amplifiers that transmit payload data via PSH (without a completed handshake) is low for most protocols. Nevertheless, the amplification factor is higher compared to the SYN/ACK amplifiers.
RST: The by far highest amplification is observed for hosts that transmit a tremendous number of RST segments. As such, an attacker could abuse the 4,242 vulnerable Telnet hosts to achieve an average amplification rate of 79,625x. Compared to SYN/ACK, the RST amplifiers of most protocols also have a much higher traf- fic volume—even though the number of hosts is significantly lower. That is, the 8,863 SYN/ACK amplifiers of NetBIOS transmitted about 25 MB of traffic, while the RST amplifiers caused traffic of more than 12 GB. Similarly, even though we observed most of the FTP ampli- fiers sending SYN/ACK packets (causing a total of 3.2 GB of traffic), the RST amplifiers transferred 15.1 GB of traf- fic in the same amount of time, a multitude of factor 5x.
Apple OS X 10.11 and iOS 9 now prefer IPv6 for connections
Thanks to an improved Happy Eyeballs implementation (Erick Vyncke says 25 ms instead of the 300 ms specified in RFC 6555) that went from roughly 50/50 IPv4/IPv6 in iOS 8 and OS X 10.10 to about 99% IPv6 in iOS 9 and OS X 10.11.
This is good news, when you think that now ARIN also “ran out of IPv4 addresses”; i.e. was unable to meet a legitimate demand for IPv4 address space as from 1 July 2015. (This does not mean there are no more IPv4 addresses, it just means that for the first time ARIN could not satisfy a valid demand for address space).
Apple Will Require IPv6 Support For All iOS 9 Apps
“Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement, starting with iOS 9.
Well, it’s one more step in the right direction towards the tipping point
Most significantly, though, this step by Apple means that all the iOS apps that run on iOS 9 will work well over the IPv6-only networks that are starting to be deployed. Even in dual-stack (IPv6/IPv4) networks, this should mean that iOS 9 apps will work better in those environments when, for instance, IPv6 may be faster. (More needs to be understood here about the specifics of the IPv6 support.)
“#Telstra has revealed it has run out of #IPv4 internet addresses, prompting warnings that its use of network addressing translation could impact the carrier’s ability to accurately collect customer metadata for the Government”
Yes, of course, undermining the police state is the most important impact from running out of IPv4 addresses.
Oh well, let’s use the next batch of stupid pseudoantiterrorist legislation to mandate migration to #IPv6 - the moral dilemma will tear Internet geeks apart !
% zonemaster-cli seenthis.net
Seconds Level Message
======= ========= =======
17.65 WARNING All nameservers IPv4 addresses are in the same AS (29169).
17.65 WARNING All nameservers IPv6 addresses are in the same AS (29169).
17.65 WARNING All nameservers are in the same AS (29169).
17.80 NOTICE 18.104.22.168 returned no DS records for seenthis.net.
18.09 NOTICE SOA 'refresh' value (10800) is less than the recommended one (14400).
Pas mal pour SeenThis
This animation is a visualisation which I originally produced for my PhD research and which was published in my book Rediscovering the World. While the printed book showed these maps in static form, the above animation gives a much more vivid impression of the current climate observations on the global #precipitation distribution over a period of approximately 50 years (~1950-2000, obtained from the WorldClim database).
“After some heated discussions about packet sizes on the mailinglist of the IETF v6ops working group, I decided to do some measurements to find out what maximum packet sizes are supported on today’s internet.”
“The data showed no fewer than 72 different MTU sizes for IPv4, ranging from 576 to 9198 bytes. However, both of these extremes only showed up once, and other values below 1280 and above 1500 are also quite rare”
Kolomoisky suggests #Ukraine build 2,000-kilometers wall against Russia
#Dnipropetrovsk regional state administration deputy head #Hennadiy_Korban has presented to the Ukrainian presidential administration an engineering project and a feasibility study of a 1,920-kilometers-long wall along the Russian border with an approximate value of euro 100 million.
This week, the routing table of the Internet reached 512 000 routes... “It’s not just you. Many Internet providers have been having trouble as they run into long expected (but not adequately prepared for) routing table problems.”
Un témoignage en français d’un opérateur, avec les jolis messages d’erreur du Cisco : « FIB TCAM exception for IPv4
unicast. Packets through some routes will be dropped. » ▻http://email@example.com/msg29487.html
Et un autre très bon article technique, expliquant notamment pourquoi il ne s’est en fait pas passé grand’chose (les vieux routeurs sont sur le bord, pas au cœur) ▻http://www.renesys.com/2014/08/internet-512k-global-routes
Self-Hosting, IPv6 and carrier-grade NAT
Since IPv4 addresses have become sparse internet access providers tend to keep users inside a carrier-grade NAT prison . Here are some informations on how to re-establish connections to your home-server.
How to use IPv6 on an Android phone anywhere
How to contact your home-server in spite of carrier-grade NAT (#auf_deutsch)
How to create a restricted SSH user for port forwarding?
Citrix-Blog about DS-Lite and other technologies
“Each #RIPE_Atlas probe has at least one #DNS resolver, indicated by a DHCP reply on the local network of the probe. Irrespective of the IP address of the resolver, this server may have IPv4 and #IPv6 connectivity or only IPv4 connectivity. What is the percentage of IPv6-enabled resolvers among RIPE Atlas probes?”
Why does #iperf's reported MTU differ from the correct one, reported by other tools using Path MTU Discovery ? “Mysterious Transfer Unit”...