Georgy is a graduate of the Moscow State University, has been working in the Qrator team since 2012. He was involved in development, project management, and assembled a team of pre-sales engineers in the company. Now he is developing a new product in Qrator, namely protection against online bots.
We share with you the transcript of the broadcast and the recording.
❒ Hello everyone, my name is Georgy Tarasov. I work for Qrator Labs and know a thing or two about DDoS attacks and how to counter these threats. Basically - from my own experience, from the experience of working with clients who suffer from DDoS attacks or know about the threats emanating from them, and decide in advance to build a defense for themselves, apply countermeasures, and be prepared for such activity.
Communicating with dozens, then hundreds (by now, probably, it has already exceeded a thousand) of different organizations, a rather interesting picture is formed of where attacks come from, why they happen, what business actions can lead to this. And, of course, the technical side of the matter: what happens on the victim's side, what happens in transit on the network to the victim, who else can be affected by the attack, and many other things.
Today we, I think, will talk informally enough: we will not touch on common truths, but rather look at the effects of DDoS attacks, try to understand why they occur, and how to behave when we find ourselves face to face with the DDoS attacker who came to your resource, to a promo site or to the site of the business you are doing.
❒ First, I’ll probably put in a few words about myself.My name is Georgy Tarasov, I studied at Moscow State University at the Faculty of CMC, dreamed of doing distributed computing, supercomputers, but life turned a little differently. After graduation, I joined the company of wonderful people, who were few then - a little more than a dozen. And they told me: have you heard something about DDoS attacks? At first I rolled my eyes: what kind of DDoS attacks? Hacking, cybercrime, what is it? They immediately explained to me, I studied the initial amount of materials, read the articles; at that time - it was 2012 - in terms of DDoS and protection against them, the complete "Wild West" reigned. That is, services have not yet taken the dominant position of defenders for small, medium and large businesses, everyone defended themselves with improvised means, who in what way, hired specialists to set up firewalls. And in the midst of it all was that companywhich I came to - and she strove to establish a more or less equally high quality service both for small sites, which are applied with something so applied-economic, and for large business, which faced much greater threats.
❒ Year after year, my work path pushed me closer and closer to the clients themselves, to their cases, to the stories with their connection. As a result, over time, I came to do the pre-sale work. That is, a customer comes - he is either already under attack, or awaiting it, or simply wants to build a secure infrastructure for his business. He wants to connect to the service, protect himself from attacks, buy additional services. He needs to be consulted, to find out what is most suitable for him, to listen to what risks he has now and what are expected, and to combine the mountain with the mountain: to understand what range of services, what setup, in technical and organizational terms, is more suitable than others in order to him to relieve the pain, tension and troubles with which he came.
❒ ours was not always simple and fast; sometimes clients had to connect for months, communicate with them. Whiteboarding, charting, iterative approach ("it didn't work, try different") all turned out to be very fun activities. Well, plus - a huge database of contacts of organizations from all areas of Internet activity, all market segments, organizations from business and not from business, training, for example. Each has its own unique infrastructure, goals, objectives, and pains in relation to DDoS attacks. An interesting puzzle has emerged from this, and now it allows me, looking back on this experience, to move on and help our company diversify in products, launch new things. Now, for example, the most important topic for me is the fight against scrapers, namely, with bots from among those that openly harm,because scraping is different. We specifically fight those who, with their scraping, brute force, parsing, hurt the clients who come to us. This is a similar, related, albeit not entirely directly related, DDoS protection activity. The main thing is that platforms and tech stacks are similar.
❒ Let's get back to DDoS attacks: we talk about them today, and we also talked about them six months ago, and we talk about them many times every year, but, nevertheless, they do not disappear anywhere. They are still with us.
I must say that, despite their evolution in technical terms, the emergence of new vectors, the growth of the bandwidth and the increase in the intensity of attacks, the tools and approaches that DDoS attacks use have not changed much over the past 30 years. Let's compare this with hacker activity, with hacking, with the search for holes, vulnerabilities, various methods of penetrating through the protection of someone else's application and extracting data from it. We have a vulnerability - in the framework, component, in-house application; a hole is found in it. There is an attack vector that exploits it. A researcher comes, a whitehat comes - or a real attack happens; developers, security specialists are closing the hole. It may later appear in a modified form again, somewhere in a new version of the framework or in similar solutions, but a specific episode remains in history.We are unlikely to see a literal repetition.
❒ DDoS attacks are different.Exactly the same attack vectors, using the same protocols, the same method up to the signature of the traffic, continue to hammer sites and networks for decades. They rarely leave the scene: only vectors that use completely outdated protocols that are closed on any device leave. Although there are sometimes jokes. If we look at the list of application protocols on top of the UDP transport protocol used in large-scale volumetric attacks using amplification, we will see interesting exhibits that, along with TNS, ATP, SSDB, are used all the time. There are, for example, MotD, RIPv1 protocols. Go to any company, ask devops or admins - is there at least one component or endpoint listening or writing that uses this? Most likely,they will look at you like Rip van Winkle from Washington Irving who slept for 100 years and asks for some irrelevant museum bullshit. Nevertheless, if there is a hole, then water will certainly go into it. If somewhere there is an open port for this protocol and, God forbid, there is some standard system component that can listen on this port, then the attack can go there. Therefore, the zoo of solutions for organizing DDoS does not move on a historical scale from point A to point B. It continues to grow in breadth and depth from point A with all sorts of new methods as new protocols appear, develop, they are implemented by large companies, and they contain their tricks and schemes in order to hurt the receiving party reading the protocol.who slept for 100 years and asks for some irrelevant museum bullshit. Nevertheless, if there is a hole, then water will certainly go into it. If somewhere there is an open port for this protocol and, God forbid, there is some standard system component that can listen on this port, then the attack can go there. Therefore, the zoo of solutions for organizing DDoS does not move on a historical scale from point A to point B. It continues to grow in breadth and depth from point A with all sorts of new methods as new protocols appear, develop, they are implemented by large companies, and they contain their tricks and schemes in order to hurt the receiving party reading the protocol.who slept for 100 years and asks for some irrelevant museum bullshit. Nevertheless, if there is a hole, then water will certainly go into it. If somewhere there is an open port for this protocol and, God forbid, there is some standard system component that can listen on this port, then the attack can go there. Therefore, the zoo of solutions for organizing DDoS does not move on a historical scale from point A to point B. It continues to grow in breadth and depth from point A with all sorts of new methods as new protocols appear, develop, they are implemented by large companies, and they contain their tricks and schemes in order to hurt the receiving party reading the protocol.If somewhere there is an open port for this protocol and, God forbid, there is some standard system component that can listen on this port, then the attack can go there. Therefore, the zoo of solutions for organizing DDoS does not move on a historical scale from point A to point B. From point A it continues to grow in breadth and depth with all sorts of new methods as new protocols appear, develop, they are implemented by large companies, and they contain their tricks and schemes in order to hurt the receiving party reading the protocol.If somewhere there is an open port for this protocol and, God forbid, there is some standard system component that can listen on this port, then the attack can go there. Therefore, the zoo of solutions for organizing DDoS does not move on a historical scale from point A to point B. From point A it continues to grow in breadth and depth with all sorts of new methods as new protocols appear, develop, they are implemented by large companies, and they contain their tricks and schemes in order to hurt the receiving party reading the protocol.From point A, it continues to grow in breadth and depth with all sorts of new methods as new protocols appear, develop, they are implemented by large companies, and they contain their own gags and schemes in order to hurt the receiving party reading the protocol.From point A, it continues to grow in breadth and depth with all sorts of new methods as new protocols appear, develop, they are introduced by large companies, and they contain their own gags and schemes in order to hurt the receiving party reading the protocol.
❒ Old methods are not leaving the arena.A simple example: if you look a little into history, in the first recorded cases of large DDoS attacks in the mid-late 90s, which even then made the news - that is, they were not noticed by historians and researchers years later, but made headlines right away - TCP SYN Flood vector was used. That is, these were attacks using TCP SYN packets. Anyone who is in the slightest degree familiar with the topic of DDoS attacks, who has read books or watched presentations and articles on this topic, most likely saw a description of such an attack on the first pages. This, one might say, is a textbook case of generating a fairly large amount of cheap traffic, the costs of processing which on the server side will turn out to be much higher than the costs of creating it on the part of the attacker - a botnet, some devices that it uses.If we look at the statistics of attacks for 2020-21, for example, we will see that TCP SYN Flood has not gone anywhere, such attacks still occur in the wild, and they are used by large and small business players. The tools and botnets that generate TCP traffic are still there, because this attack - even after adjusting for how the performance of computers and the bandwidth of Internet channels and corporate networks has changed over the past 30 years - leads to equally effective results ... There is simply no point in giving it up. Another thing is that the world has already learned to defend itself a little better from them, but there are some reservations here too.that generate TCP traffic are still there, because this attack - even after adjusting for how the performance of computers and the bandwidth of Internet channels and corporate networks has changed over the past 30 years - is producing equally effective results. There is simply no point in giving it up. Another thing is that the world has already learned to defend itself a little better from them, but there are some reservations here too.that generate TCP traffic are still there, because this attack - even after adjusting for how the performance of computers and the throughput of Internet channels and corporate networks has changed over the past 30 years - is producing equally effective results. There is simply no point in giving it up. Another thing is that the world has already learned to defend itself a little better from them, but there are some reservations here too.
We'll talk about defense a little later, but for now let's try to look at the numbers and answer the question: why do attacks happen? Here's some of the historical data we've pulled from our clients, organizations and businesses we work with over the past couple of years.
It is clear that an attack is not a scheduled action, it is more like a natural disaster. You don't know when it will happen, but you should always be ready to meet it. It usually does not last long - with the exception of certain cases, which we will consider later; flew in, broke everything, piled garbage everywhere and disappeared, as if she had never existed. All that remains for the victim is to reboot the servers, restart the databases and return their resource online.
▍DDoS attacks
❒ The motivation for DDoS attacks , which we managed to find out about, is, to some extent, based on the opportunity to get rich on this topic. We have such data about this story.
That is, all these points, according to which someone can organize a DDoS attack on another, are quite understandable. Personal dislike, political issues and beliefs; unfair competition - this will be a separate story, which we have probably already told many times, but maybe not all of those present on our air have heard it. Now you are unlikely to see a situation when one bank orders a DDoS attack on another, it is more profitable for them to coexist in the information field than to try to put each other; it is a double-edged weapon. It is unlikely that you will see an online store that has a different DDoS-it traffic, even if we are talking about a large retail.
Nevertheless, at the dawn of our youth there was an interesting episode:there was one online store of cedar barrels. He did not sell pine nut oil or pine nuts - he specifically sold barrels for industrial use by food workers. This was their main business, selling barrels through the site; we can say that they were among the first to do this. And when we talked with the client about the attacks on him, it turned out that there are other online stores of cedar barrels, and there is a real blood feud between them: competitors constantly DDoS each other's sites, in non-stop mode, trying to turn off the flow of customers. Well, are there many customers for cedar barrels - we can say that these are the same people who come either to one place or to another, and are unlikely to order in both places at once. Therefore, this trickle of clients was a life-and-death struggle.
❒ Another funny case from the history of competition and DDoS attacks, which also happened in our country, is the sites of magicians, wizards, esotericists, fortunetellers, shamans, spellcasters and others ... businessmen from this sphere, so to speak. It turned out that instead of damage, evil eye and all sorts of curses at each other for diverting clients and violating public reputation, they use more modern and technical methods, ordering attacks on each other's sites from DDoSers.
❒ These two casesI remember it very well, because in no other legal market segment we have seen such a war of businesses at the same level - when specific businesses are fighting each other using such unscrupulous methods. Of course, there is also a gray area that we, as a company, do not work with; There are also frankly illegal activities where DDoS attacks occur hourly, but this is not about them.
❒ What do we know about the face of a DDoS attack today?Is it a parasitic load clock, or a 5 second burst of traffic that knocks down the router? In fact, if you take the average for the hospital, taking into account the morgue and crematorium, you get neither one nor the other. Something mediated. Last year, the median duration, according to our annual report, was about 5 minutes;
▍ With regards to botnets and their involvement in the modern DDoS landscape.
The largest botnet that we observed, and from which we protected our clients from an attack, is about 200 thousand sources. These are unique IP-addresses - we are not talking about traffic sources, which we can assume from the capacity of the attack, but about attacks where valid sessions are used, in which the source must confirm itself via TCP-handshake or higher-level protocols and sessions. That is, these are valid devices of Internet users from which DDoS traffic came to the victim.
This is not to say that all DDoS in the world comes from such classic botnets. I will now briefly describe, in the order of common truths, how they appear at all, so as not to dwell on this later. A botnet is a network of devices controlled by an attacker who has the ability to perform certain actions on each of the devices on this network - for example, generate traffic. Due to this, a distributed denial of service attack occurs: an attacker gives a command, devices send traffic in various forms and at different levels - packets, requests, bits - to the target that he wants to disable. This is how we are used to seeing DDoS attacks: there are thousands of infected machines, and a hacker from his C&C center - the machine from which he controls - centrally sends a broadcast command. For example, "send UDP traffic to address X",which is what happens. But now this process may look a little different, because a significant layer of attacks uses a traffic amplification (amplification) approach. Its idea is that the botnet does not send traffic directly to the victim's resource. The botnet's task is to generate some initial traffic flow, which can be small (of the order of hundreds of megabits), and by exploiting the features of UDP-based application protocols - for example, DNS - force a large number of DNS servers in networks (many networks have a large number of DNS -servers that are not protected from using them in such attacks) accept the request without really checking who it is from and execute it. For example, they ship a domain zone of tens of kilobytes to some address, which it is not clear who belongs to, and it is not clear whether this address sent this request.Thus, the initial traffic flow passes through thousands of DNS servers that the hacker does not directly control - these servers are simply on the Internet and are ready to process the query without checking who it comes from. Due to this scheme, a hundred megabits of traffic generated by an attacker using a relatively small botnet (it can be only a few dozen machines) turns into tens of gigabits per second of bandwidth that flies from these name servers towards the victim.which the attacker generated with the help of a relatively small botnet (it can be only a few dozen machines) turns into tens of gigabits per second of the bandwidth that flies from these name servers towards the victim.which the attacker generated with the help of a relatively small botnet (it can be only a few dozen machines) turns into tens of gigabits per second of the bandwidth that flies from these name servers towards the victim.
❒ What to do with this case? Banning the sources from which the traffic came - this way you can ban half of the Internet, because they do not even have a direct relationship to the hacker and botnet. Here we need other mechanisms to combat this traffic - at least, it needs to be drained somewhere so that it does not get on the machine that is under attack, and at the same time not remember the addresses of the sources and not try to apply any sanctions to them.
It turns out that some of the attacks still come directly from botnets using valid sessions and valid IP addresses, and some - mainly those that use the amplification method - do not come from the botnets themselves at all. Botnets are used there only as a spark plug in the engine. This has not always been the case; amplification is a relatively new story. If you look at large cases, then we have been living with attacks of this type only for the last 10 years, perhaps less. Another thing is what exactly made them so popular, what made them as dangerous as that of traditional methods - it will be interesting to consider here, perhaps, the most famous case, which happened in 2016. Then the world learned that botnets are not only computers infected with viruses, but also IPTV cameras, coffee makers, microwave ovens, “smart homes”,gate with Wi-fi and stuff. At some point, the development, popularity and prevalence of the "Internet of Things" - a variety of devices with Internet access - reached a critical point at which cybercriminals became interested in using them instead of more difficult-to-use PCs, corporate servers, public servers, and so on. to generate traffic.
❒ The famous Mirai botnetwas based on tens of thousands of IPTV cameras from specific manufacturers, on which the same firmware was installed, no protection from external control was provided, and Internet access was not always tied to a local network. At least the admin panel can be accessed via the Internet, and this is already enough to use a small piece of hardware to generate traffic. And, although one camera will not be able to generate a lot - it has a small channel - there are tens and hundreds of thousands of such devices, and they are maximally spread all over the world. The danger of such an attack, from the point of view of traditional defense methods, is very high. This was taken advantage of by the authors of Mirai and those who followed them, copying and pasting this approach and deploying their botnets. 2016-17 was a real surge in terms of amplification attacks,which used botnets of this kind as a root source of traffic. This story continues now: new boxes continue to come out, and their security against hacking and exploitation has remained at the same level, because cheapness and mass production are in the first place. Another thing is that the world has already learned to defend itself a little better against them, as in the case of SYN Flood attacks. It is rather difficult to drive such traffic streams from IPTV, security people are already too accustomed to such a story.as with SYN Flood attacks. It is rather difficult to drive such traffic streams from IPTV, security people are already too accustomed to such a story.as with SYN Flood attacks. It is rather difficult to drive such traffic streams from IPTV, security people are already too accustomed to such a story.
Regarding "calling the heroes by name" - I, unfortunately, cannot / will not do this. But this information is, in principle, public, you can read the investigations about Mirai. If someone is interested, the organizers will have my contacts - I can share links to interesting material, including the one that I myself study, and that our company writes on this topic. But the story with Mirai, the cameras and how this activity was discovered is already a legacy of history, and you can find it in many places.
❒ One way or another, this story has not ended in any way.Another thing is that other methods of attacks have pulled up in their danger and intensity to what Mirai demonstrated in 2016. The attacks at that time were about 600-700 gigabits per second of bandwidth, at that time - unprecedented numbers. This was almost 10 times the attacks seen in the wild. Now you won't surprise anyone with such numbers: since the inception of Mirai, the growth of the attack rate has long exceeded terabits per second and continues to grow. Broadband connections and reliable provider backbones contribute to this.
❒ As for what we saw from this activity.Despite the fact that Mirai was mainly a Western story, a piece reached our clients in Russia. This happened the next year after its occurrence: the largest attack for the Russian Federation at that time, which was about 500 gigabits per second, flew to us. Of course, half-terabit was already a fairly popular figure in the global DDoS-ology, but for Runet sites, whose infrastructures were located in Russia and connected to our providers, it was something with something. Fortunately, we quickly and effectively knocked down the attack, and subsequent encounters with such botnets were no longer surprises either for us or for our customers.
▍ DDoS attacks on the darknet
❒ I have an interesting question on my agenda:talk about what happens in DDoS attacks on the darknet. That is, the organization, conduct, methods, methods of protection. The topic of DDoS attacks on the darknet has never been of much interest to us as a company: for obvious reasons, darknet clients do not come to us to defend themselves. The specifics of the occupations in which they earn money, and their own base of users who come to their resources, do not dispose to enter into this kind of relationship with security services. Of course, there are exceptions in the world. It is clear that where there is demand, there is supply, and competition in the darknet has approximately the same types and guises as in the public network. Therefore, a DDoS attack as a way to turn off a competitor or make someone pay a ransom to stop DDoS attacks, gradually leaving the headlines of news articles on the public Internet,continues to bloom lush on the Tor networks and on the darknet in general.
It is clear that the structure of Tor is somewhat different from what we have in the public network. The connection of the darknet with the public Internet, which is carried out through exit nodes (guard nodes), is itself a bottleneck and does not have a large amount of traffic flowing from the darknet to the public (and vice versa). Nevertheless, in ancient times (2012-14), such a thing as hiding the C&C center of a botnet that exists on a public network inside Tor networks took place. That is, a hacker keeps his C&C computer on the darknet, sends control traffic through Tor to a botnet located in a public network, and an attack on the site takes place in the public network. For an attacker, the profit is that if C&C in a public network can be caught - there are specific methods that are used by information security specialists and forensics to find control centers,intercepting them and finding their owners is much more difficult to do on the darknet. But this shop did not last long, for a number of reasons. Firstly, the work of C&C itself, sending control traffic to tens, hundreds or hundreds of thousands of machines to start an attack - even such a load, which is small from the point of view of the public network (control point traffic), is very noticeable and significant for Tor. In 2013, when one of the major botnets settled its C&C center on an onion resource, the traffic that it generated was noticeable enough to slow down an entire segment of the Tor network. Not everyone liked it, of course. And most importantly, if an attack has already happened or was prevented, and law enforcement agencies, information security companies, forensic experts are involved in the investigation of the attack, then if the botnet has been compromised,the threads lead to the exit nodes of the torus. And, as always in this case, the owner of the exit node gets the cap. The hacker himself is not directly threatened, but closing the exit node and holding the owner accountable (although the owner is not specifically related to these attacks) makes it impossible to use the Tor infrastructure in the future, including for other similar actions. Therefore, in order not to cut the branch on which the organizers of the attacks themselves sit, they downplayed this activity, and now it is no longer so noticeable.but closing the exit node and holding the owner accountable (although the owner is not specifically related to these attacks) makes it impossible to use the Tor infrastructure in the future, including for other similar actions. Therefore, in order not to cut the branch on which the organizers of the attacks themselves sit, they downplayed this activity, and now it is no longer so noticeable.but closing the exit node and holding the owner accountable (although the owner is not specifically related to these attacks) makes it impossible to use the Tor infrastructure in the future, including for other similar actions. Therefore, in order not to cut the branch on which the organizers of the attacks themselves sit, they downplayed this activity, and now it is no longer so noticeable.
When it comes to finding botnet control centers and their owners, that's not really our story. We deal specifically with protection against attacks, not investigations and search for organizers, although the information we have helps infosec companies do their job - specifically, search. One such case was passed to a large extent in front of my eyes, so I will share it with pleasure. In 2014, one of our clients - a large bank with a large online presence - was hit by a series of DDoS attacks, which were quite intense. We managed to filter them out and protect the client. The client did not stop there and turned to information specialists to find the sources of the attack and its organizers. They had considerations that a number of attacks that took place on their resource, using approximately the same technical stack,could well have come from the same place and be of the same nature - that is, most likely, the customer and the organizer were the same. What people did from infobesity: they quickly found the botnet itself, from which the traffic was generated - this was the simplest thing. And then they hooked their own honeypot - the same machine - into this botnet in order to catch the moment when the control team came to attack some resource. During the next attack case, they not only found the machine that controlled the start and process of the attack, but also found out that there were calls from the same machine to the attacked resource. That is, the attacker-organizer of the attack, in parallel with the twisting of the knobs to send the garbage traffic, himself came to the resource - to check how he was there, still alive or fell. On these two signs he was found, compared,found the owner of the car. Then the story turned into a criminal case; the end was rather prosaic, and has nothing to do with the technical sphere. However, it is understandable that a similar story is more difficult with the darknet. The exit will, of course, be the owner of the exit node, and what happens to them in Russia - I have already said.
This is about the attacks from the Tor networks outside, now - about what is happening inside the darknet itself. There DDoS blooms in lush color, of all varieties and stripes. What's interesting - for example, in our statistics for the last couple of years, you can see that attacks at the 7th level - that is, at the application level, those that use HTTP, HTTPS requests, select specific URLs ...
Q: Did you manage to plant? If not, they will still attack with impunityYes, it was possible to prove and prosecute the attacker. True, this did not happen in the Russian Federation, but in a neighboring country.
... well, application-level attacks now account for only a small part of the statistics. Most of the attacks that we see regularly are TCP, UDP, packet floods, amplifications. That is, more primitive methods that are cheaper in an organization, for which there are many more tools to quickly deploy and get started. They do not need much preparation before attacking any site - it is enough to deploy this "gun" in the general direction of the victim and kick it out of it. Application attacks are always some preliminary research, finding out how the application that will be attacked works, how the infrastructure works, where it is most efficient to hammer - into which URIs, into which application components. This work costs money for the organizer, and in terms of costs, such attack methods are much higher than generic drugs.And generic drugs are popular and cheap, also because since the time of Mirai, from 15-16, the industry of organizing DDoS attacks and, in general, activity on this basis has become a service industry.
That is, such a thing as "arrange DDoS to order" - write to some hacker, tell him to put down a certain site at a certain time - this is practically gone. Because botnet owners and botnet owners have found a more profitable way to make money from their craft. DDoS as a service works in much the same way as any legal subscription service - protection, CDN, site acceleration. The botnet is provided to the client in a shared form: that is, some of the capacities are provided to the customer for use for a certain time at a certain price. Let's say a 5 minute attack with a significant streak will cost $ 10. It is clear that the marginality for the owners is still high: it is much more profitable than one-time orders from dubious persons, who may be handed over to the authorities.Service work is much more mediated and does not contact the customer directly, while the involvement of such a botnet in attacks is much higher. That is, infected devices are used to generate junk traffic much more efficiently. Such services - they are also called "buters" - grow like mushrooms; they are eradicated, they are demolished, organizers are found, but they immediately grow back. The most famous example of "buters" is a service called vDOS, which controlled part of the Mirai botnet, providing it in a shared format to everyone. They even had a website on the public network, quite visited, and they generally accepted payment through PayPal. Actually, it was through PayPal that forensics experts found the organizers; they turned out to be two Israeli students,who preferred this way of making money to study and career prospects. They were brought to justice, but, according to the latest news, everything was limited to community service; Perhaps we will still see them either in a new incarnation of business, or already in the service of some state secret service.
Anyway, such a model- that is, instead of developing a DDoS attack method for a specific victim, making a service that you can come to, pay with cryptocurrency and rent a botnet for attacks for 5 minutes (or 10, or an hour) - and this leads to that most of the attacks turn out to be very "generic". They are not specific either for a specific purpose, or for a protocol, or for the specifics of traffic generation. They do not last long, since the task of a DDoS attack primarily includes intimidating the victim. If this is not some kind of political story, then it does not matter whether the victim's site will be down for 5 minutes or an hour. If the victim agrees to pay the ransom or otherwise go to meet the attackers, then one minute is enough, and if so, then why overpay. The attacks that stand out from this landscape are much more interesting,and they just need to learn - and we are doing this.
❒ That is: the landscape of DDoS attacks has changed in this direction, and those things that stand out from it - quantitatively or qualitatively - are of the greatest interest.
There is another interesting story about the darknet. ... The tech stack that is used there goes through the same evolutionary stages that the public Internet went through decades ago. The vulnerability of specific web servers, the vulnerability of devices that are used to host a resource on the dark web to the most primitive methods of DDoS attacks, have not gone away. It is gradually being eliminated, but since this is not done by specialized companies, it happens spontaneously and slowly. There are a lot of methods to overwhelm a resource hosted on the darknet - there were a million of them, and now there are decent ones. If you go to GitHub and look for tools with which you can disable a resource hosted on the darknet, you can find completely curious ways. Such primitive things as a slow GET request attack that anyone, even a free one, could handle.the service to protect against DDoS and bots (and if the free one does not cope, then you can pay $ 20 to CloudFlare and solve this issue, or configure the balancer yourself) were still effective against onion sites a couple of years ago. Such methods are publicly available and do not require large resources, that is, a large botnet, to organize an attack. Quite a common story - not DDoS attacks come to Tor resources, but unallocated DoS attacks. A certain sequence of requests from one specific machine is enough to extinguish the Tor server.Quite a common story - not DDoS attacks come to Tor resources, but unallocated DoS attacks. A certain sequence of requests from one specific machine is enough to extinguish the Tor server.Quite a common story - not DDoS attacks come to Tor resources, but unallocated DoS attacks. A certain sequence of requests from one specific machine is enough to extinguish the Tor server.
This situation persisted; For example, the Tor browser fix 0.4.2 closed the hole that allowed requests from this browser to flood any resource on the darknet, spending 0 rubles on the attack.
▍Defense on the darknet
As far as protection on the darknet is concerned, this is also a funny story. In the end, the adhoc-security community that exists there came to the conclusion that it is still necessary to defend itself. There is such a thing as EndGame: it is a DDoS protection toolkit on its specific machine that publishes a resource in Tor.
There is one more aspect, not quite technical, which may be important here. DDoS protection for businesses can be implemented in different ways. It could be a box that filters traffic. It can be a huge network of boxes filtering outside the infrastructure. It could be an Internet service provider's battery of boxes doing the same thing - looking for traffic anomalies and blocking bad sources. All these things are not needed on a situational basis: you need to grab them not when the attack is already underway. Then it's too late. These things should always be at the ready; in fact, you are being sold a guarantee that if an attack happens, these things will cope with it, and this will not negatively affect you, your users, the availability of your resource. These guarantees are not very applicable on the dark web, where there is no specific identity of that,who provides this resource and who purchases and uses it. Therefore, adhoc protection on its own machine, which will help from the most primitive methods, but with a distributed attack that generates a large bandwidth, will not be able to do anything, it is used there and has the right to exist there. Such a story.
▍
If we talk about funny cases from the experience of working with clients, from the experience of connecting - we are talking about a public network, of course. I have already talked about competition, this is our staple case, as they say when we talk about different business segments. Technically, the things that happen to our clients at the onboarding stage and at the stage of pilot work, the first weeks and months of connecting to protection, are also funny. As a rule, they are associated with the fact that some users - maybe even quite legitimate ones - behave in a very interesting way, completely different from everyone else. The same can be said for the resources we protect. Some resources in a very interesting way approach the issues of communication with users, having their own interpretation of the HTTP protocol. Sometimes this led to misunderstandings and specific incidents,which were resolved even without mutual negativity, but with a smile and a laugh.
When we talk about the application layer and attacks at this layer, often the traffic of these attacks differs little from the requests that normal users make. This is the interest and complexity of such attacks. Apart from the effect of their work and the sources from which these requests come, they can be indistinguishable from the pattern of normal users. Here you have to use a deeper behavioral analysis, look at the session of each user from handshake to leaving the resource, in order to understand what he was doing on the resource in general - good or bad, whether he did any harm, whether the rest of the users became bad for requests from this particular source? Our automation has to answer such questions every second for hundreds of different clients and for thousands of sites.Sometimes edge cases of user behavior come to the attention of the system and drive it crazy.
A simple example is when a user with an absolutely, in general, legal line of behavior works as a task scheduler, visiting news pages on a resource at a strictly defined time. Starts at .00 in the morning, ends at .00 in the evening. At the same time, the actions that the user performs do not cause any harm: this is not parsing or scraping, he just walks through the articles, writes comments and responds to them.
There is nothing to find fault with - except that it starts and ends at the same time every day, and the amount of work that it does on the resource is incomparably greater than that of all users who were not identified as bots. We had different hypotheses on this score; a couple of times we accidentally banned him, after which he wrote to the resource abuse about what was actually happening. In the end, we gave up - you never know, maybe this is a content writer who clearly works in two shifts without days off and breaks. In any case, as long as such users do not bring harm, we do not consider it necessary to take any sanctions against them.
❒ Another case- on the other hand, this is when the resource behaves strangely towards all users. We had a customer, one of the functionality of the resource which was to provide users with generated reports in the form of DOC files. Each such report weighed about 200 MB, with pictures and tables. The funny thing was that the generation of the report on the server started at the click of a button on the web page. After that, the server went into thinking, generated a report and, when ready, sent it in one piece, without cutting into chunks, via HTTP file transfer, as part of the response to the request. The joke was that this file was generated on the server for tens of minutes. At some point, our support service received a request from a client with a request to increase the timeout time for processing a request to our reverse proxy to 20 minutes.At first, people did not believe their eyes and went to figure it out: how so, 20 minutes for a timeout for a request? We went to the site, checked, it turned out exactly like this: from the moment the button is pressed, the connection lasts 20 minutes, after which the server finally uploads the file, and you can get it. Experimentally - rather, even with a sober evaluative look - it became clear that a dozen users who simultaneously got to the site could accidentally arrange DDoS and completely take the server out of circulation without any malicious intent, labor or expense. And this is not a "habraeffect", when tens of thousands of people break into the information resource at the same time, and the server cannot process them all due to lack of performance; here is just an interesting story with the responses to requests leads to the fact that the server can not work like that. For our part, of course, we recommended dividing the file into chunks,send it in pieces, generate reports in the background, and more.
There are resources on the Internet that work on a similar principle - that is, by design, they are vulnerable to attacks of any intensity and complexity of the organization. In general, nothing is needed to disable such a site. There are APIs that work in the same way (heavy responses, expensive API requests to process, synchronous API work). The very fact of this leads to the fact that DDoS attacks happen in different places even without the participation of attackers, hackers, without any ulterior motive. When we are faced with such situations, we try to advise the customer about where the weirdness in the application is and how it can be corrected. And, of course, we replenish our freak show of funny architectural solutions, which we would not recommend anyone to implement.
– .
▍ :
- vDOS:
- DoS Tor
- Endgame — Tor-:
- DDoS-
, #ruvds_
