Geekly Articles each Day
📜 ⬆️ ⬇️

Features of the reflection of DDoS attacks and the history of attacks on one large bank



Previously, DDoS attacks could successfully fight off on the data center side of the attacked company. Fast smart admin actions and good filtering iron ensured sufficient protection against attacks. Today, botnet services are rapidly becoming cheaper, and DDoS is becoming available almost in a small business.

About half of the attacks go to the online stores or commercial sites of companies in the spirit of “overwhelm a competitor”, almost always attack the media sites, especially after the “hot” publications, much more often than they seem to hit state services. In Russia, the main objectives are banks, retail, media and tender platforms. One of the major Russian banks, for example, periodically blocks traffic from China - attacks from there come with enviable regularity, one of the latter was more than 100 Gb / s.
')
Accordingly, when the attack rolls over, say, 10 Gb / s, it becomes problematic to repel it on its side because of the banal channel clogging. At this very moment, it is necessary to make a switch to the data clearing center, so that all the “bad” traffic will be eliminated somewhere else near the main channels, and not go to you. Now I’ll tell you how it works for one of our vendors of protective equipment - Arbor, which monitors about 90 Tbit / s (45% of the global Internet traffic).

Attack scenario


First, the attacker selects targets within the infrastructure. Most of the "stupid" attacks goes to HTTP, a lot of attacks on the DNS, but the main "smart" attacks are usually directed at the previously explored nodes within the target infrastructure. Often, DDoS aims not only and not so much the failure of services, as the opportunity to carry "under the general noise" through the DMZ a more serious threat. This is often achieved through the use of “overloading” of perimeter protection systems such as firewalls, IPS / IDS, and the like, based on session tracking (stateful inspection). Therefore, colleagues believe that if the device has a state table (session table) - it should be considered as part of the infrastructure that needs protection.

The main points of attack:


The reflection attack scheme is implemented as follows:
  1. On the side of the protected company is a device that “closes” the network. As soon as the attack begins, the device must recognize it as an anomaly, using one of the mechanics, for example, built-in countermeasures, abnormal behavior of the traffic source, or matching a known attack profile (signature from the base).
  2. If the device copes with the attack, the work continues in a relatively normal mode: legitimate traffic is skipped, illegitimate traffic is cut. There are several “alarm levels” that differ in the degree of difficulty of the attack and the possible loss of legitimate traffic.
  3. If the communication channel starts to get clogged up, the traffic is automatically redirected using the standard Cloud Signaling protocol. At first, everything comes to the site of a major provider (this could be Rostelecom, Orange, Transtelecom, Akado), where the data is cleaned with Peakflow SP equipment. Already cleared traffic goes to the final client. At the same time, the client has an understanding of everything that is happening - he can promptly enter the operator’s personal account and see the current status of cleaning, what countermeasures work, what is the effectiveness of suppressing attacks, and so on. The client device also shows the effectiveness of the ongoing cleanup and the list of blocked hosts. With both devices, if desired, you can easily remove the traffic dump in pcap format for the subsequent “debriefing”.




Reality, which is not to talk


1. Loss of legitimate traffic.
The fight against DDOS attacks is the dropping of illegitimate packets and the omission of legitimate traffic, between which a very thin line sometimes passes. Many vendors in their prospectuses like to write that these losses are close to zero. In my practice, they can easily reach up to 2% - this means that theoretically the same director who went on a business trip will not be able to get into the corporate network from a hotel or from a conference. Here it is very important that the system supports the ability to resolve specific connections or protocols on the fly. A number of vendors since the start of the attack settings, in fact, almost hardkoditsya in the firmware of iron, and change them is extremely problematic. Arbor is completely different with this. First of all, there are three “alarm modes” to control the level of false-positive - from “cut everything that is definitely not ours” to “there is an opportunity to delve more detailed”. Secondly, there is a convenient search for blocked hosts and the ability to cancel the blocking of traffic for a particular host, protocol or country in one click. Note that the reality of having false positive in the fight against DDoS is recognized by all notable market players. Alexander Lyamin (Qrator) once noted: "anyone who says that he has a false positive is a charlatan."

2. The ability to use a clogged communication channel for signaling an attack.
How does the client ask the provider for an attack if the channel between them is blocked due to DDoS? Strictly speaking, even with close to 100% utilization of the communication channel in the direction from the provider to the client, there is a very big chance that the request to clear the data will reach the provider. To do this, Cloud Signaling works on top of UDP, and in addition, the protocol does not require a response from the provider. Thus, it is enough to have at least some capacity in the direction from the client to the operator. For reinsurance, it is recommended to organize a separate channel for messaging Cloud Signaling. However, a backup channel is usually created, plus an alarm goes off at a threshold of about 70-80% of the channel.

3. Time to switch to data clearing center.
A delay in redirecting traffic to the cleaning center of a DDoS protection service provider can take a few or even tens of minutes. This is mainly due to the redirection mechanism - based on DNS records or BGP announcements, as well as the fact whether the decision to redirect is made manually or automatically. In any case, if the suppression of the attack is carried out in the "cloud", then to avoid the delay will not succeed. At a minimum, it is a few minutes. Therefore, we adhere to the concept of multi-level protection, when large attacks on communication channels are suppressed by the operator, and slow, unobtrusive application-level attacks with equipment installed at the customer.

4. Use SSL certificates.
Analyzing SSL / TLS traffic for application-level attacks is problematic — you need to decrypt each packet. Here you are faced with a difficult dilemma: either sharing your certificates with your service provider, or accepting the risk that an attack at the HTTPS level could be missed. Vendors try to find solutions without opening packages (which is not always good), or use a special SSL / TLS decryption module built into the client device:



In this case, your certificates are uploaded to a device that is under your control, and the delay for additional packet processing is milliseconds.

5. Manual formation of signatures.
Most signatures are formed by manufacturers of solutions for protection against DDoS attacks. However, there are occasional situations when resources are exposed to new types of attacks.

Depending on the vendor, there are two possible scenarios for actions in such a situation: either to request a new signature from the manufacturer, or to create a signature by yourself. In the first case, you will most likely have to pay extra for the service, as well as for a considerable time to remain under attack, waiting for the problem to be solved.

In the second case, the principle of “saving the drowning is the work of the drowning themselves,” well, or their partners. Here, equipment functionality becomes critical, allowing you to quickly identify, intercept and analyze malicious traffic. And the ability to automatically generate a signature based on the information received becomes a salvation in a critical situation. For example, the ability to go into the packet capture, select the desired bit sequence (bit pattern), and in a couple of clicks make a signature blocking such a sequence.

Scale advantage


Arbor has a very interesting "trick" that allows them to use their market share very effectively. The fact is that their equipment costs all TIER-I telecom operators and providers and most TIER-II operators.


Arbor's position in the DDoS protection equipment market in the Carrier, Enterprise, Mobile segments - 65% of the total market - the first (Infonetics Research for December 2013).

Information passes through the ATLAS system at about 90 TB / s. As soon as signs of an attack appear somewhere, the devices begin to transmit information about what is happening on their own communications network, and information quickly spreads around the world. For example, if a small provider is “felled”, its iron signals according to a special protocol a level higher. If the superior operator has an agreement with the subordinate operator, then the signature is accepted and distributed to all subnets of a large provider.


Sensors (honeypots) of the ATLAS system are located on the main nodes of the global Internet to detect and classify attacks, bot network activity and various malicious software. The information is sent to the ATLAS data center, where it is combined with data obtained from the Arbor Peakflow installation and other data. The system automatically analyzes hundreds of thousands of code elements, and allows a team of engineers to quickly update signatures for company customers around the world.

Connection Features


It should say a few words about the iron, which is placed directly to you in the data center or on the site. Many realities are also associated with it, which are not always spoken about.

1. Setup and configuration.
As a rule, the device needs time to profile the traffic and evaluate the behavior of the network. But some devices are delivered in a “combat” mode to work from the first second after the connection - there are already ready-made templates, plus the device receives data from the “cloud” of its vendor. On the one hand, this is good in terms of repelling an ongoing attack, on the other - if you are used to fine-tune everything in your infrastructure, you will have to partially rely on the experience of the vendor.

2. Protective iron itself can become a point of failure.
Therefore, firstly, on serious objects it is duplicated or several devices are going to a cluster (respectively, control devices are needed). And secondly, such devices have hardware bypasses, allowing you to switch interfaces at the physical level, traffic directly in case of various emergency situations - power failure, software failure, and so on ...

3. Protective iron can also be the target of an attack.
Especially if it is a device with a state table (session table), for example, it combines the protection functionality from DDOS, IPS, firewall, etc.). Every time a new session is opened on such devices, the device allocates memory to track the session, fills the log and so on - and the smarter the device, the more work happens. Many sessions - a lot of CPU and memory utilization. Therefore, choosing a solution, it is worth paying attention to this aspect.

4. Usually there is a lot of junk traffic on the network, and in the case of large organizations, there are also regularly peaks of activity that can pass for “stupid” DDoS.
It is clear that everything is structured according to geography, time of use of services, and so on, but at the first stage it is important to get an understanding that the inclusion of the device in the network will not kill services. For this purpose, the mirror connection mode is used: the device is put into the network on the bypass and receives the mirror traffic, showing what it would reject and what it would miss. This allows you to make an assessment before problems arise. I know customers where DDoS protection is exactly in this mode for a long time. Arbor believes that building a baseline is only one of the methods of dealing with DDoS, but it is much better to use a specialized countermeasure. Colleagues say the same about signatures - how big would be the network of sensors and how much traffic would be analyzed in it, you cannot rely only on signatures. Complex threats require a combination of different protection mechanisms.

5. At the level of traffic exchange between providers, a rather unpleasant situation sometimes happens when a subnet transmits the signature of an attack, and the upstream provider says: “Yeah, interesting, but we won't clean ourselves”.
The principle is very simple - while the channel is coping, all DDoS traffic is bilingual. It is not always interesting for the upstream provider to spend money and clean it when you can just ship lower, and even for the money of the victim. Such situations are unpleasant for service providers, but they have no effect on users of DDoS protection services, since operators fulfill their obligations in full.

Reports


One of the important things is a quick understanding of what is happening. Let's look at the reports on the example of two attacks on a large Russian bank. Feel the admins add gray hair in the comic below.

Attack with a capacity of about 50 Gbit / s


This attack began with DNS amplification. Traffic recorded on the Arbor Peakflow TMS service provider: up to 7.15 Gbit / s., 1.1 Mpaket / s. Taking into account filtering most of the attack on FlowSpec, the total attack traffic is estimated at 50 Gbit / s. The attack was continued HTTP flood.



Having recorded an abnormal growth of traffic, the client device automatically requested assistance from the service provider in suppressing the attack.



The protection system installed by the operator transmitted information about the course of suppressing the attack on Pravail APS in real time.



When the DNS-amplification attack disappeared, a large amount of HTTP flood appeared.



In addition to HTTP flood, TCP SYN flood was also present.

As a result, most of the DNS-amplification of the attack was successfully suppressed using Flowspec, the rest of it was suppressed by the protection system, and the HTTP and TCP SYN flood was reset to Pravail APS.

Attack with a capacity of about 125 Gbit / s





A few minutes at the beginning - HTTP flood. There is a surge in the number of foreign hosts (red graph). About 1000 hosts on the domain of the “Large Russian Bank”. The main countries are: USA (672), Germany (141), Great Britain (82), Italy (30), Netherlands (24), France (14).



The next surprise is NTP-amplification - up to 125 Gbit / s.



After failed NTP amplification - SYN-flood with spoof IP - up to 300 Mbps

Summary


Attacks go constantly, and if you haven’t come across this yet - it’s just a matter of time. To illustrate, here are some events in the Russian Federation:

If you have questions, I’ll be happy to answer here or at avrublevsky@croc.ru. Our division can also offer various solutions if you need a different vendor.

And tomorrow, October 21, we are holding a webinar on the topic of DDoS protection . Come, tell us what is happening in Russia on this front now in Russia.

Source: https://habr.com/ru/post/240923/

More articles:


All Articles