TL;DR: Client-server architecture of our internal configuration management tool, QControl.
At its basement, there’s a two-layered transport protocol working with gzip-compressed messages without decompression between endpoints. Distributed routers and endpoints receive the configuration updates, and the protocol itself makes it possible to install intermediary localized relays. It is based on a differential backup (“recent-stable,” explained further) design and employs JMESpath query language and Jinja templating for configuration rendering.

Qrator Labs operates on and maintains a globally distributed mitigation network. Our network is anycast, based on announcing our subnets via BGP. Being a BGP anycast network physically located in several regions across the Earth makes it possible for us to process and filter illegitimate traffic closer to the Internet backbone — Tier-1 operators.

On the other hand, being a geographically distributed network bears its difficulties. Communication between the network points-of-presence (PoP) is essential for a security provider to have a coherent configuration for all network nodes and update it in a timely and cohesive manner. So to provide the best possible service for customers, we had to find a way to synchronize the configuration data between different continents reliably.

In the beginning, there was the Word… which quickly became communication protocol in need of an upgrade.

Two days ago, May 5 of the year 2019 we saw a peculiar BGP outage, affecting autonomous systems in the customer cone of one very specific AS with the number 721.

Right at the beginning, we need to outline a couple of details for our readers:

1. All Autonomous System Numbers under 1000 are called “lower ASNs,” as they are the first autonomous systems on the Internet, registered by IANA in the early days (the late 80’s) of the global network. Today they mostly represent government departments and organizations, that were somehow involved in Internet research and creation in 70-90s.
2. Our readers should remember, that the Internet became public only after the United States’ Department of Defense, which funded the initial ARPANET, handed it over to the Defense Communication Agency and, later in 1981, connected it to the CSNET with the TCP (RFC675)/IP (RFC791) over X.25. A couple of years later, in 1986, NSF swapped the CSNET in favor of NSFNET, which grew so fast it made possible ARPANET decommission by 1990.
3. IANA was established in 1988, and supposedly at that time, existing ASNs were registered by the RIRs. It is no surprise that the organization that funded the initial research and creation of the ARPANET, further transferring it to another department because of its operational size and growth, only after diversifying it into 4 different networks (Wiki mentions MILNET, NIPRNET, SIPRNET and JWICS, above which the military-only NIPRNET did not have controlled security gateways to the public Internet).

As we wrote in the 2018-2019 Interconnected Networks Issues and Availability Report at the beginning of this year, TLS 1.3 arrival is inevitable. Some time ago we successfully deployed the 1.3 version of the Transport Layer Security protocol. After gathering and analyzing the data, we are now ready to highlight the most exciting parts of this transition.

As IETF TLS Working Group Chairs wrote in the article:
“In short, TLS 1.3 is poised to provide a foundation for a more secure and efficient Internet over the next 20 years and beyond.”

TLS 1.3 has arrived after 10 years of development. Qrator Labs, as well as the IT industry overall, watched the development process closely from the initial draft through each of the 28 versions while a balanced and manageable protocol was maturing that we are ready to support in 2019. The support is already evident among the market, and we want to keep pace in implementing this robust, proven security protocol.

Eric Rescorla, the lone author of TLS 1.3 and the Firefox CTO, told The Register that:
“It's a drop-in replacement for TLS 1.2, uses the same keys and certificates, and clients and servers can automatically negotiate TLS 1.3 when they both support it,” he said. “There's pretty good library support already, and Chrome and Firefox both have TLS 1.3 on by default.”

Free Wireguard VPN service on AWS

The reasoning

The increase of Internet censorship by authoritarian regimes expands the blockage of useful internet resources making impossible the use of the WEB and in essence violates the fundamental right to freedom of opinion and expression enshrined in the Universal Declaration of Human Rights.

Article 19
Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.

The following is the detailed 6 steps instruction for non-IT people to deploy free* VPN service upon Wireguard technology in Amazon Web Services (AWS) cloud infrastructure, using a 12 months free account, on an Instance (virtual machine) run by Ubuntu Server 18.04 LTS.

I tried to make this walkthrough as friendly as possible to people far from IT. The only thing required is assiduity in repeating the steps described below.

On March 13, a proposal for the RIPE anti-abuse working group was submitted, stating that a BGP hijacking event should be treated as a policy violation. In case of acceptance, if you are an ISP attacked with the hijack, you could submit a special request where you might expose such an autonomous system. If there is enough confirming evidence for an expert group, then such a LIR would be considered an adverse party and further punished. There were some arguments against this proposal.

With this article, we want to show an example of the attack where not only the true attacker was under the question, but the whole list of affected prefixes. Moreover, it again raises concerns about the possible motives for the future attack of this type.

It was an ordinary Thursday on 4.04.2019. Except that at some point of the midday timeline an AS60280 belonging to Belarus’ NTEC leaked 18600 prefixes originating from approximately 1400 ASes.

Those routes were taken from the transit provider RETN (AS9002) and further announced to NTEC’s provider — RU-telecom’s AS205540, which, in its turn, accepted all of them, spreading the leak.

As many of our readers know, Qrator.Radar is constantly researching global BGP connectivity, as well as regional. Since the Internet stands for “Interconnected Networks,” to ensure the best possible quality and speed the interconnectivity of individual networks should be rich and diverse, with their growth motivated on a sound competitive basis.

The fault-resistance of an internet connection in any given region or country is tied to the number of alternate routes between ASes. Though, as we stated before in our Internet Segments Reliability reports, some paths are obviously more critical compared to the others (for example, the paths to the Tier-1 transit ISPs or autonomous systems hosting authoritative DNS servers), which means that having as many reachable routes as possible is the only viable way to ensure adequate system scalability, stability and robustness.

This time, we are going to have a closer look at the Russian Federation internet segment. There are reasons to keep an eye on that segment: according to the numbers provided by the RIPE database, there are 6183 autonomous systems in Russia, out of 88664 registered worldwide, which stands for 6.87% of total.

This percentage puts Russia on a second place in the world, right after the USA (30.08% of registered ASes) and before Brazil, owning 6.34% of all autonomous systems. Effects of changes in the Russian connectivity could be observed across many other countries dependant on or adjacent to that connectivity, and ultimately by almost any ISP in the world.

Just a few months ago there were a lot of buzz because IETF in expedited time frame (about one year) accepted DNS over HTTPS (DoH) as a standard (RFC-8484). The discussions about that are still going on because of its controversy. My personal opinion is that DoH is good for personal privacy (if you know how to use it and trust your DNS provider) but it is a security risk for enterprises. DNS over TLS (DoT) is a better alternative for enterprise customers only because it uses a well-defined TCP port but for personal privacy it is not good because of the same reason (easy to block).

^{Beautiful scheme for BGP connection to Qrator filtering network}

A little historical overview

• BGP hijacks — when an ISP originates an advertisement of address space that does not belong to it;
• BGP route leaks — when an ISP advertises prefixes received from one provider or peer to another provider or peer.

This week it has been 11 years since the memorable YouTube BGP incident, provoked by the global propagation of a more specific prefix announce, originated by the Pakistan Telecom, leading to an almost 2 hour in duration traffic disruption in the form of redirecting traffic from legitimate path to the bogus one. We could guess if that event was intentional, and even a correct answer wouldn’t help us completely prevent such incidents from happening today. While you read this, a route leak or a hijack is spreading over the networks. Why? Because BGP is not easy, and configuring a correct and secure setup is even harder (yet).

In these eleven years, BGP hijacking became quite damaging attack vector due to the BGP emplacement in the architecture of modern internet. Thanks to BGP, routers not only acquire peer information, and therefore all the Internet routes — they are able of calculating the best path for traffic to its destination through many intermediate (transit) networks, each representing an individual AS. A single AS is just a group of IPv4 and/or IPv6 networks operating under a single external routing policy.

I’m going to hazard a guess and say that everyone whose friends or family have ever flown on a plane, have used Flightradar24 — a free and convenient service for tracking flights in real time.



But, if my friends are any indication, very few people know that the service is community-driven and is supported by a group of enthusiasts gathering and sending data. Even fewer people know that anyone can join the project — including you.

Let’s see how Flightradar and similar other services works.

While working on the annual report this year we have decided to avoid retelling the news headlines of the previous year and, though it is almost impossible to ignore memories absolutely, we want to share with you the result of a clear thought and a strategic view to the point where we all are going to arrive in the nearest time — the present.

Leaving introduction words behind, here are our key findings:

• Average DDoS attack duration dropped to 2.5 hours;
• During 2018, the capability appeared for attacks at hundreds of gigabits-per-second within a country or region, bringing us to the verge of “quantum theory of bandwidth relativity”;
• The frequency of DDoS attacks continues to grow;
• The continuing growth of HTTPS-enabled (SSL) attacks;
• PC is dead: most of the legitimate traffic today comes from smartphones, which is a challenge for DDoS actors today and would be the next challenge for DDoS mitigation companies;
• BGP finally became an attack vector, 2 years later than we expected;
• DNS manipulation has become the most damaging attack vector;
• Other new amplification vectors are possible, like memcached & CoAP;
• There are no more “safe industries” that are invulnerable to cyberattacks of any kind.

In this article we have tried to cherry-pick all the most interesting parts of our report, though if you would like read the full version in English, the PDF is available.