DDoS attacks are becoming more common as the Internet of Things grows. More or less every webmaster has heard of or actually been attacked by a DDoS. This article, based on my experience in dealing with DDoS in recent years, describes a relatively inexpensive DDoS defense idea for everyone, hoping to shed some light.

classification

In terms of traffic authenticity, there are only two types of DDoS attacks:

– Actual traffic DDoS

– Fake traffic DDoS

Let’s first look at real traffic DDoS. Real traffic DDoS is very difficult to defend against, especially attacks on real requests for site resources, which will bring great pressure to the operation and maintenance.

For example, an attack using a web reverse proxy site that is open on the network is highly similar to a normal user access and difficult to resolve.

Or it can inject a high-traffic site, sending requests from the high-traffic site across domains to the victim’s site.

But this kind of attack cost is high, and the income is not high, so it is very rare for small and medium-sized sites.

Next up is fake traffic DDoS.

In terms of attack cost, traffic magnification and other factors, reflective DDoS attacks based on non-TCP protocol are still the best choice for small-scale DDoS attacks against small and medium sites.

Therefore, the site is most likely to be attacked by a fake DDoS attack of reflex traffic.

To complete such an attack, the following conditions are required:

– You can modify the Packet Header to direct traffic to the victim.

– Available reflection nodes have reflection.

Let’s go through them one by one:

Modifiable Packet Header indicates that because protocols such as UDP are non-connection-oriented, it is easy to forge the Source IPv4 Address so that it is set to the victim’s IPv4 Address.

Reflection nodes refer to specific exposed network services that return data that is many times larger than the requested data when accessed using the tamper-able protocol above. Bigger attacks work better.

Take the Memcached protocol vulnerability as an example. If some Memcached servers are placed on the public network without any protection measures, we can operate them freely. All you need to do is SET a huge amount of data into Memcached and send a request to Memcache with the Source IPv4 Address of the target IPv4 Address. This completes the attack.

Such an attack can amplify traffic by 10,000 to 51,200 times. After all, the requested Payload is a GET {key} binary data. But what we get back is a whole bunch of data that we SET into it. Assuming that the botnet we control can make 50Mbps requests, the Memcached protocol vulnerability amplifes the attack bandwidth to 50Mb * 51,200 = 2.44TB. What a terrible result. The largest DDoS bandwidth in history was only 1.35Tb.

The cost of such an attack is relatively low. Home broadband now has a lot of uplink bandwidth up to 30Mb, and home iot devices are increasing. We can imagine that once you have a device in your home that has vulnerabilities, those vulnerabilities are likely to be exploited. The most typical is the SSDP vulnerability of some home routers, which happen to be plugged into the broadband entrance. If it can be accessed, it’s a terrible consequence.

Protection services for cloud service providers

The best defense against reflex DDoS attacks is, of course, left to cloud service providers. However, the high IP or DDoS protection services provided by cloud service providers also have the following disadvantages:

– price high

The following is the lowest price of high IP protection service of a domestic cloud service provider:

Line resources: 8-line BGP, region: mainland China, guaranteed protection bandwidth: 30Gb, elastic protection bandwidth: 30Gb, service bandwidth: 100 M, function package: standard function, number of protected domain names: 50, service QPS: 3000, number of ports: 50, purchased quantity: 1. Purchase duration: 1 month; configuration cost: 20,800.00 CNY

30Gb, $20,000 per month. It’s safe to say that this protective bandwidth is bullying a kindergartner to try to bring you down. But this price is not generally small and medium-sized sites can accept.

– Latency is not ideal

After being connected to high defense, user traffic will be sent to high defense first and then back to your service.

However, IDC high-defense devices require huge bandwidth access. Therefore, to save bandwidth costs, the IDC where the high-defense devices reside may not be in first-tier cities. This brings us to the second problem, which is that latency increases a lot. This is detrimental to the user experience.

– The source IP address is leaked

Strictly speaking, this is not the problem of high defense service providers, but their own problems. The source IP address of the DDoS device is leaked accidentally. As a result, the DDoS device directly hits the IP address corresponding to the service.

A new way of thinking

So, let’s discuss some other ways to defend against such attacks.

Let’s start by analyzing the attacker’s entire operational flow.

First, the attacker needs to determine the target of the attack, because the protocol used to attack packets is layer 4 protocol, so the attacker only needs one piece of information, the IP address.

Maybe it’s an IP address, maybe it’s a domain name, maybe it’s a URL. At this point, he needs to use DNS to translate the domain name to an IP address.

It then balances IP addresses, or a bunch of IP addresses (such as your domain name load across multiple IP addresses). Fill it in to his attack program. Then all that’s left is to run the program and attack.

As we can imagine, the attack bandwidth controlled by the attacker is certainly not unlimited, nor are the available reflection resources. Therefore, if more targets are attacked at the same time, the attack bandwidth allocated by each target will be smaller.

Ok, so that’s the first core idea of our defense: multiple IP addresses to reduce attack bandwidth per IP address.

In addition, in my observation of the attack process, I found that some attacks are insensitive to IP changes.

For example, if the IP you were attacked is taken offline by IDC and you change to a new IP address, the attack may not immediately attack your new IP address.

Either you are innocent, the attack is on an IP range, and you just happen to be affected. This is often the case when you’re reusing your server with someone else.

Another possibility is that the attacker did not follow up on the change or gave up the attack.

So, we can go through the above ideas, to build our defense system.

First we need to buy a service called CNAME load balancing.

After CNAME load balancing is applied, a user accesses your domain name, first requests DNS, and obtains the CNAME corresponding to the target domain name. Then, the user obtains the real target IP address through the CNAME domain name.

The advantage of CNAME load balancing is that DNS switching CNAME records takes effect faster than switching A records, and the client cache can be updated easily (of course, this depends on the specific Settings and implementation of the DNS service provider and client).

The fact that the cache is fast and easy to update means that it is cheaper to switch IP addresses in the event of an attack to allow normal users to continue accessing it.

So let’s do the math. Suppose there are 50 IP addresses corresponding to my CNAME load balancing. Then, if a wave of 300Gb attacks are evenly distributed, the average bandwidth of each IP address attacked is 300Gb / 50 = 6Gb. This attack bandwidth is likely to be included in the defense bandwidth that is given away with the IP purchase.

So what is the cost of 50 ips? The average rental price per IP (paid according to the flow rate, the flow rate is calculated separately) is about 0.020 CNY/h, 50 IP a month is 0.02 x 24 x 30 x 50 = 720CNY. Is it cheap?

We can even save 50 more ips, and when we get hit, we can change them one by one and see who loses patience first.

Advanced defense

With multiple IPS, we can even develop more sophisticated defense strategies.

We just assumed that the traffic per IP is evenly distributed. But actually the site’s users are not evenly distributed geographically. Therefore, some IP addresses are bound to have larger normal traffic. So for these IPS, we can buy some cheap protection services. By means of disguised degradation, so that most users are attacked, still can continue to access. Because the attacker and our information is not equal, so if he wants to know which IP is the heavy traffic IP and turn to attack, or difficult. It also saves money on defense.

If we can access OpenAPI of cloud service providers, we can even change IP dynamically through programs to further reduce the operation and maintenance pressure.

conclusion

The defenses described above are most effective for stateless businesses, such as websites.

But for stateful businesses, such as game servers, it’s hard. No matter what protocol the game server is, it is difficult to switch IP. Because once it is switched, all the clients corresponding to IP have to reconnect to the server, which is unbearable for some games with high real-time performance. However, for the use of HTTP itself in some of the lower real-time games, such as board games, can be considered.

It doesn’t hurt to have a lot of IP, after all, one IP is only 14 yuan a month.

During my nearly 3 years of practical application, the above scheme has played a significant role. For attacks under 100Gb, most users can continue normal access within 15 minutes after the attack is discovered. But for attacks above 500Gb, more than patience, especially in the case of high defense can not afford, can only be artificial defense, minimize the loss.

This article is only a personal experience, welcome every big guy not misgive correct.

Reference

  • www.cloudflare.com/learning/dd…