cc-attack-on-index-php
This commit is contained in:
JamesFlare1212
204
content/en/posts/wordpress/cc-attack-on-index-php/index.md
Normal file
204
content/en/posts/wordpress/cc-attack-on-index-php/index.md
Normal file
@@ -0,0 +1,204 @@
|
||||
---
|
||||
title: Principles and Discussion of DDoS Attacks Targeting WordPress Features
|
||||
subtitle:
|
||||
date: 2024-04-13T13:12:44-04:00
|
||||
slug: cc-attack-on-index-php
|
||||
draft: false
|
||||
author:
|
||||
name: James
|
||||
link: https://www.jamesflare.com
|
||||
email:
|
||||
avatar: /site-logo.avif
|
||||
description: This blog post explores the principles and challenges of a specific DDoS attack targeting WordPress instances by requesting non-existent paths to bypass caching mechanisms, and discusses possible defense and offense strategies from the perspectives of both blue and red teams.
|
||||
keywords: ["DDoS", "WordPress", "Nginx", "CloudFlare", "IPv6"]
|
||||
license:
|
||||
comment: true
|
||||
weight: 0
|
||||
tags:
|
||||
- WordPress
|
||||
- Nginx
|
||||
- WAF
|
||||
categories:
|
||||
- Security
|
||||
- Discussion
|
||||
hiddenFromHomePage: false
|
||||
hiddenFromSearch: false
|
||||
hiddenFromRss: false
|
||||
hiddenFromRelated: false
|
||||
summary: This blog post explores the principles and challenges of a specific DDoS attack targeting WordPress instances by requesting non-existent paths to bypass caching mechanisms, and discusses possible defense and offense strategies from the perspectives of both blue and red teams.
|
||||
resources:
|
||||
- name: featured-image
|
||||
src: featured-image.jpg
|
||||
- name: featured-image-preview
|
||||
src: featured-image-preview.jpg
|
||||
toc: true
|
||||
math: true
|
||||
lightgallery: false
|
||||
password:
|
||||
message:
|
||||
repost:
|
||||
enable: true
|
||||
url:
|
||||
|
||||
# See details front matter: https://fixit.lruihao.cn/documentation/content-management/introduction/#front-matter
|
||||
---
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Background
|
||||
|
||||
KEIJILION mentioned in [Website Defense Upgrade: fail2ban Integrates with CloudFlare to Intelligently Block Malicious Attacks](https://blog.kejilion.pro/fail2ban-cloudflare/) that there is a DDoS attack method targeting WordPress instances, which bypasses the caching mechanism by requesting a non-existent path to attack the server. However, he did not clearly explain the principle of this attack method, so I will attempt to explain it here.
|
||||
|
||||
First, Layer 7 DDoS attacks require the target server to run a program or code in order to consume its resources. In other words, our requests cannot be intercepted before reaching WordPress, because the overhead of WAFs like Nginx intercepting requests is very small, and it would be very costly to exhaust them with a massive number of requests, which is beyond the capability of most people.
|
||||
|
||||
Secondly, the requests cannot hit the cache, because if they are cached by CDN or other means, the WordPress program is not involved in serving them, and our goal of exhausting the target server's resources cannot be achieved. Finally, avoid being banned based on IP, UA, or other content, for the same reason as why requests cannot be intercepted before reaching WordPress.
|
||||
|
||||
## Challenge
|
||||
|
||||
So why does the "404" attack mentioned by KEIJILION result in cache penetration and resource exhaustion?
|
||||
|
||||
### Behavior
|
||||
|
||||
First, let's talk about what the "404" attack he refers to is. It's actually generating random URL paths. For example:
|
||||
|
||||
```text
|
||||
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7
|
||||
https://www.jamesflare.com/en/mvQ3oX3NJRCfy8LBdWdL
|
||||
https://www.jamesflare.com/en/AK3VdReDX4AKmAYanV9j
|
||||
https://www.jamesflare.com/en/2Msmu2zDGwA4Fd4hDroF
|
||||
https://www.jamesflare.com/en/crq8KXvMaFphdYhGNaFA
|
||||
```
|
||||
|
||||
This is done to penetrate the cache and let the requests reach the WordPress instance.
|
||||
|
||||
### Nginx Rewrite Rule
|
||||
|
||||
You may ask, doesn't that just return a 404? What's the problem with that? First, we need to understand that returning a 404 also has an overhead, and this overhead varies across different applications. If it's a static website served by Nginx, then when Nginx can't find the requested file locally, it will return a 404, and the overhead is very low.
|
||||
|
||||
But in WordPress, this overhead is not very low, which has to do with its logic. WordPress pages need to be handled by `index.php`, and we've probably written similar Rewrite Rules when configuring it, right?
|
||||
|
||||
```nginx
|
||||
# enforce NO www
|
||||
if ($host ~* ^www\.(.*))
|
||||
{
|
||||
set $host_without_www $1;
|
||||
rewrite ^/(.*)$ $scheme://$host_without_www/$1 permanent;
|
||||
}
|
||||
|
||||
# unless the request is for a valid file, send to bootstrap
|
||||
if (!-e $request_filename)
|
||||
{
|
||||
rewrite ^(.+)$ /index.php?q=$1 last;
|
||||
}
|
||||
```
|
||||
|
||||
The idea is to let `index.php` handle the request,
|
||||
|
||||
```text
|
||||
# Requested by the browser
|
||||
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7
|
||||
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7.jpg
|
||||
# What WordPress sees
|
||||
https://www.jamesflare.com/index.php/en/XXbwQMzBFL27zizGAeh7
|
||||
https://www.jamesflare.com/index.php?q=XXbwQMzBFL27zizGAeh7.jpg
|
||||
```
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Browser --https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7--> Nginx --https://www.jamesflare.com/index.php/en/XXbwQMzBFL27zizGAeh7--> WordPress
|
||||
```
|
||||
|
||||
### Performance
|
||||
|
||||
Now the pressure is on WordPress. It first matches the database to see if there is such an article, and after not finding it, returns a 404, then starts weaving the HTML content of the 404 page like knitting a sweater. If your 404 page is more stylish and uses more resources, the overhead is even greater. It's almost equivalent to directly accessing a dynamic article (but the overhead should still be less than a real article).
|
||||
|
||||
Also, people may overestimate the performance of their VPS. The vast majority of VPS have poor performance, and 3-4 junk cores may not even match half a core of your laptop. Without caching, a few dozen RPS may be enough to crash the webpage.
|
||||
|
||||
{{< link href="../netcup-arm-review" content="netcup vServer (ARM64) Benchmark and Review" title="netcup vServer (ARM64) Benchmark and Review" card=true >}}
|
||||
|
||||
This 18-core VPS only reaches the level of an AMD Ryzen 7 7840U, and that's conservative, because my laptop also has an AMD Ryzen 7 7840U, and its performance is about 40% higher than the data in Geekbench 6. The multi-core score in the database is 8718, while my actual test is 12127, so the 18-core VPS is roughly 8650.
|
||||
|
||||
## Blue Team
|
||||
|
||||
I speculate that KEIJILION's solution to this `index.php` feature is to scan the Nginx logs for IPs that generate abnormal codes like 404, and add them to the CloudFlare blacklist via API, releasing them after an hour. The logs look something like this:
|
||||
|
||||
```text
|
||||
47.29.201.179 - - [28/Feb/2019:13:17:10 +0000] "GET /?p=1 HTTP/2.0" 200 5316 "https://domain1.com/?p=1" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36" "2.75"
|
||||
```
|
||||
|
||||
This greatly alleviates this vulnerability (actually I think it's more appropriate to call it a feature).
|
||||
|
||||
## Red Team
|
||||
|
||||
So, what are the loopholes in this model? First, let's sort out the ideas. This specialized approach is based on:
|
||||
|
||||
1. Detect abnormal HTTP codes
|
||||
2. Block IP
|
||||
|
||||
In addition to this extra patch, general security measures include:
|
||||
|
||||
1. Rate limiting
|
||||
2. CloudFlare security rules
|
||||
1. IP address risk
|
||||
2. Browser fingerprint
|
||||
3. UA
|
||||
4. Human verification
|
||||
3. Origin blocks non-CloudFlare IPs
|
||||
|
||||
### Objective
|
||||
|
||||
So, our approach is also clear, which is to find a way to hit the site's dynamic resources with our requests. Let's break down the tasks:
|
||||
|
||||
1. Find dynamic resources
|
||||
2. Bypass CloudFlare's security measures
|
||||
3. Send requests at a not-so-aggressive rate
|
||||
|
||||
First, we need to understand that the performance of most people's VPS is not good, and WordPress is not as efficient as imagined. I think handling a few dozen to a hundred RPS without caching is already very high, and it's not impossible to crash with just a dozen RPS. Those who aggressively send packets, easily reaching thousands or tens of thousands of RPS, and don't spread the traffic across many IPs, who else would they ban if not you?
|
||||
|
||||
### IP Wave Tactics
|
||||
|
||||
Here I'll just throw out some ideas, as the Red Team I'll give a few bad ideas. The most brutal one is to use a bunch of IP addresses, still using the previous "404" attack, at most I'll use one IP per request. You might say, how is this possible, wouldn't it require tens of thousands or hundreds of thousands of IP addresses in an hour? Even those DDoS attacks recorded in history only had tens of thousands of addresses. Even renting IPs, one IP must cost at least $1, right?
|
||||
|
||||
You're right, but also not quite right. This is the case for IPv4 addresses, but what about IPv6? Many VPS come with a /48 subnet when you buy them, and even if they're stingy, it's a /64 subnet, which is still incomparably huge.
|
||||
|
||||
|Prefix Length|Example Address|Address Range|
|
||||
|-|-|-|
|
||||
|32|2001:db8::/32|2001:0db8:0000:0000:0000:0000:0000:0000 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff|
|
||||
|40|2001:db8:ab00::/40|2001:0db8:ab00:0000:0000:0000:0000:0000 2001:0db8:abff:ffff:ffff:ffff:ffff:ffff|
|
||||
|48|2001:db8\:abcd::/48|2001:0db8\:abcd:0000:0000:0000:0000:0000 2001:0db8\:abcd:ffff:ffff:ffff:ffff:ffff|
|
||||
|56|2001:db8\:abcd:1200::/56|2001:0db8\:abcd:1200:0000:0000:0000:0000 2001:0db8\:abcd:12ff:ffff:ffff:ffff:ffff|
|
||||
|64|2001:db8\:abcd\:1234::/64|2001:0db8\:abcd\:1234:0000:0000:0000:0000 2001:0db8\:abcd\:1234:ffff:ffff:ffff:ffff|
|
||||
|
||||
To make it easy, let's not count reserved addresses. A /64 prefix means there are still 64 bits of address space behind it, which is 2^64 IP addresses. This number is astronomical, and I don't know if there are that many grains of sand on Earth. If the blocking strategy is not changed, it is absolutely impossible to block them one address at a time.
|
||||
|
||||
You might say, isn't this tactic too outrageous, relying on the other party not reacting in time? Wouldn't it be unfortunate to make them block subnet by subnet? You're right, but you can mix subnets of different sizes, and blocking subnets will result in a huge number of IP addresses being blocked, which is a very bad choice. Besides, it's not impossible to rent a portion of a /32 subnet, right? If you have a good relationship with a vendor and they give you a subnet slightly smaller than a /32, wouldn't that be hard for you to deal with?
|
||||
|
||||
### Chromedriver
|
||||
|
||||
Okay, let me give you another bad idea. Since we don't need a very large request volume to crash WordPress, and the performance gap is very large, we can use some advanced tools to directly simulate browsers to bypass CloudFlare's verification code, which is not impossible.
|
||||
|
||||
[](https://github.com/ultrafunkamsterdam/undetected-chromedriver)
|
||||
|
||||
We can use this modified Selenium Chromedriver to bypass CloudFlare's verification code, UA, browser fingerprint, and other detection methods.
|
||||
|
||||
Then find a more dynamic point, such as entering random content in the search box to search. Coupled with our IPv6 human wave tactics, just a few dozen RPS can lead to a performance crisis for them. So many Selenium Chromedrivers may indeed consume some performance, but it's not very difficult to run on your own laptop. But from the Blue Team's perspective, it's a headache. They will see an extremely normal scene, with different IP addresses having a user accessing only once every half hour, an hour, or even a few hours. Or some IP addresses may not even access a second time. Will you wonder if your website has gone viral somewhere, rather than being attacked?
|
||||
|
||||
## Summary
|
||||
|
||||
KEIJILION mentioned a DDoS attack method targeting WordPress instances, which bypasses the caching mechanism by requesting a non-existent path to consume server resources. This attack is effective because:
|
||||
|
||||
1. WordPress page requests all need to be handled by index.php, and even 404 pages consume some resources. Many VPS have limited performance, and WordPress without caching may only be able to handle a few dozen RPS.
|
||||
|
||||
2. Attackers bypass CDN, WAF, and other defenses by requesting random URL paths, allowing requests to penetrate the cache and directly reach the WordPress backend.
|
||||
|
||||
3. Attackers will avoid being banned based on IP, UA, etc. to evade detection.
|
||||
|
||||
KEIJILION may alleviate this problem by scanning Nginx logs for abnormal status codes and blocking the corresponding IPs. But this solution still has some loopholes:
|
||||
|
||||
1. Attackers can leverage the huge address space of IPv6, making it nearly impossible to block one by one.
|
||||
|
||||
2. By simulating real browser requests, CloudFlare's verification code, fingerprint, and other detections can be bypassed, making the attack look like normal access.
|
||||
|
||||
3. Due to WordPress's performance bottleneck, attackers only need low-rate attacks of a few dozen RPS to cause harm, which is difficult to notice.
|
||||
|
||||
In summary, this type of DDoS attack exploits the characteristics of the WordPress architecture and is difficult to completely prevent. In addition to improving WordPress performance, website administrators also need more comprehensive monitoring and defense measures.
|
||||
204
content/zh-cn/posts/wordpress/cc-attack-on-index-php/index.md
Normal file
204
content/zh-cn/posts/wordpress/cc-attack-on-index-php/index.md
Normal file
@@ -0,0 +1,204 @@
|
||||
---
|
||||
title: 针对WordPress特性的DDoS攻击原理与探讨
|
||||
subtitle:
|
||||
date: 2024-04-13T13:12:44-04:00
|
||||
slug: cc-attack-on-index-php
|
||||
draft: false
|
||||
author:
|
||||
name: James
|
||||
link: https://www.jamesflare.com
|
||||
email:
|
||||
avatar: /site-logo.avif
|
||||
description: 这篇博客文章探讨了一种针对WordPress实例的特定DDoS攻击的原理和挑战，该攻击通过请求不存在的路径来绕过缓存机制，并从蓝队和红队的角度讨论了可能的防御和进攻策略。
|
||||
keywords: ["DDoS", "WordPress", "Nginx", "CloudFlare", "IPv6"]
|
||||
license:
|
||||
comment: true
|
||||
weight: 0
|
||||
tags:
|
||||
- WordPress
|
||||
- Nginx
|
||||
- WAF
|
||||
categories:
|
||||
- 安全
|
||||
- 讨论
|
||||
hiddenFromHomePage: false
|
||||
hiddenFromSearch: false
|
||||
hiddenFromRss: false
|
||||
hiddenFromRelated: false
|
||||
summary: 这篇博客文章探讨了一种针对WordPress实例的特定DDoS攻击的原理和挑战，该攻击通过请求不存在的路径来绕过缓存机制，并从蓝队和红队的角度讨论了可能的防御和进攻策略。
|
||||
resources:
|
||||
- name: featured-image
|
||||
src: featured-image.jpg
|
||||
- name: featured-image-preview
|
||||
src: featured-image-preview.jpg
|
||||
toc: true
|
||||
math: true
|
||||
lightgallery: false
|
||||
password:
|
||||
message:
|
||||
repost:
|
||||
enable: true
|
||||
url:
|
||||
|
||||
# See details front matter: https://fixit.lruihao.cn/documentation/content-management/introduction/#front-matter
|
||||
---
|
||||
|
||||
<!--more-->
|
||||
|
||||
## 前情提要
|
||||
|
||||
KEIJILION在 [网站防御再升级 fail2ban 对接 cloudflare 智能拦截恶意攻击](https://blog.kejilion.pro/fail2ban-cloudflare/) 中提到有一种针对WordPress实例的DDoS攻击方式，即通过请求请求一个不存在的路径绕过缓存机制来对服务器进行攻击。但是他没说清楚这种攻击方式的原理，我在这里尝试解释一下这种攻击方式的原理。
|
||||
|
||||
首先，Layer 7的DDoS攻击需要让目标服务器运行某个程序或者代码，这样才能消耗它的资源。换句话说，我们的请求不能在到达WordPress之前被拦截，因为Nginx等WAF拦截请求的开销非常小，如果我们要通过海量请求把它们耗死，代价会非常大，一般人根本做不到。
|
||||
|
||||
其次不能命中缓存，因为如果命中被CDN等缓存，那么WordPress程序没有参与服务，我们想耗尽目标服务器资源的目的就无法达成。最后，避免被封禁IP，UA等内容，原因和为什么请求不能在到达WordPress之前被拦截一样。
|
||||
|
||||
## 挑战
|
||||
|
||||
那么为什么KEIJILION提到的“404”攻击会造成缓存击穿，资源耗尽的结局呢？
|
||||
|
||||
### 行为
|
||||
|
||||
首先我们讲，它指的“404”攻击是什么？其实就是生成随机的URL Path。比如
|
||||
|
||||
```text
|
||||
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7
|
||||
https://www.jamesflare.com/en/mvQ3oX3NJRCfy8LBdWdL
|
||||
https://www.jamesflare.com/en/AK3VdReDX4AKmAYanV9j
|
||||
https://www.jamesflare.com/en/2Msmu2zDGwA4Fd4hDroF
|
||||
https://www.jamesflare.com/en/crq8KXvMaFphdYhGNaFA
|
||||
```
|
||||
|
||||
这么做是为了击穿缓存，让请求到达WordPres实例。
|
||||
|
||||
### Nginx Rewrite Rule
|
||||
|
||||
那么，你可能要问了，那不就返回404了吗，有什么问题呢？首先我们要明白返回一个404也是需要开销的，这个开销在不同应用下不一样。如果是一个Ngnix服务的静态网站，那么当Nginx在本地找不到请求的文件时就会返回404，这个开销很低。
|
||||
|
||||
但在WordPress里，这个开销不是很低，这要从它的逻辑说起。WordPress的页面需要让`index.php`来处理，我们在配置的时候想必写过类似的Rewrite Rule吧
|
||||
|
||||
```nginx
|
||||
# enforce NO www
|
||||
if ($host ~* ^www\.(.*))
|
||||
{
|
||||
set $host_without_www $1;
|
||||
rewrite ^/(.*)$ $scheme://$host_without_www/$1 permanent;
|
||||
}
|
||||
|
||||
# unless the request is for a valid file, send to bootstrap
|
||||
if (!-e $request_filename)
|
||||
{
|
||||
rewrite ^(.+)$ /index.php?q=$1 last;
|
||||
}
|
||||
```
|
||||
|
||||
道理就是把请求交给`index.php`处理，
|
||||
|
||||
```text
|
||||
# 浏览器请求的
|
||||
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7
|
||||
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7.jpg
|
||||
# WordPress看到的
|
||||
https://www.jamesflare.com/index.php/en/XXbwQMzBFL27zizGAeh7
|
||||
https://www.jamesflare.com/index.php?q=XXbwQMzBFL27zizGAeh7.jpg
|
||||
```
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Browser --https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7--> Nginx --https://www.jamesflare.com/index.php/en/XXbwQMzBFL27zizGAeh7--> WordPress
|
||||
```
|
||||
|
||||
### 性能
|
||||
|
||||
这下压力来到WordPress这一边，它首先匹配一遍数据库里有没有这篇文章，没有之后返回404，然后开始像织毛衣一样编织404页面的HTML内容，要是你的404页面还比较时髦，用到的资源比较多，那开销更大了。约等于直接访问了一次动态的文章（但开销应该还是比真文章小）。
|
||||
|
||||
还有就是一般人可能会高估他们VPS的性能，绝大多数的VPS性能很差，可能3-4个洋垃圾核心不如你笔记本的半个核心，没缓存的话可能几十rqs网页就爆了。
|
||||
|
||||
{{< link href="../netcup-arm-review" content="netcup vServer (ARM64) 基准测试和评测" title="netcup vServer (ARM64) 基准测试和评测" card=true >}}
|
||||
|
||||
这一台18核心的VPS性能也才达到AMD Ryzen 7 7840U的水平，而且是保守的，因为我的笔记本同样搭载AMD Ryzen 7 7840U，性能比Geekbench 6里的数据高了40%左右。数据库里多核是8718，我实测有12127，那18核VPS差不多8650。
|
||||
|
||||
## Blue Team
|
||||
|
||||
我猜测KEIJILION针对这个`index.php`特性的解决方法是通过扫描Nginx日志中产生404等异常码的IP，并且通过API加入CloudFlare中的黑名单，一小时后释放。日志差不多长这个样子
|
||||
|
||||
```text
|
||||
47.29.201.179 - - [28/Feb/2019:13:17:10 +0000] "GET /?p=1 HTTP/2.0" 200 5316 "https://domain1.com/?p=1" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36" "2.75"
|
||||
```
|
||||
|
||||
这样就极大程度缓解了这个漏洞（其实我觉得叫特性更合适）。
|
||||
|
||||
## Red Team
|
||||
|
||||
那么，它这个模式有什么漏洞呢？首先我们理一下思路，这个特化思路在于
|
||||
|
||||
1. 发现异常http code
|
||||
2. 封禁IP
|
||||
|
||||
除了这个额外的补丁，一般的安全措施有
|
||||
|
||||
1. 速率限制
|
||||
2. CloudFlare的安全规则
|
||||
1. IP地址风险
|
||||
2. 浏览器指纹
|
||||
3. UA
|
||||
4. 人机验证
|
||||
3. 站源阻止非CloudFlare IP
|
||||
|
||||
### 目的
|
||||
|
||||
那么，我们的思路也就明确了，也就是通过一种办法把我们的请求命中站点的动态资源。分解一下任务
|
||||
|
||||
1. 找到动态资源
|
||||
2. 绕过CloudFlare的安全措施
|
||||
3. 以一个不是那么激进的速率发出请求
|
||||
|
||||
首先我们要明白，一般人的VPS性能并不好，WordPress也没想象中那么高效，我觉得没缓存处理几十上百rqs已经很高了，十几rqs就爆了也不是不可能。那些猛猛发包，动不动就几千上万rqs的人，而且没几个IP分摊流量，人家不封你封谁。
|
||||
|
||||
### 人海战术
|
||||
|
||||
这里我就抛砖引玉，作为Red Team那我就来几杯坏水。最粗暴的那就是来一堆IP地址，还是用之前的“404”攻击，大不了我一个请求换一个IP。你可能说，这怎么可能，1个小时下来岂不是要几万，十几万个IP地址，那些载入史册的DDoS攻击不过上万个地址。就算租IP，1个IP怎么也得1美元吧。
|
||||
|
||||
你说的对，也不对。IPv4地址是这样的，但是IPv6呢？很多VPS买就送你一个/48子网，就算抠门一点是/64子网，那也是无比巨大的。
|
||||
|
||||
|前缀长度|示例地址|地址范围|
|
||||
|-|-|-|
|
||||
|32|2001:db8::/32|2001:0db8:0000:0000:0000:0000:0000:0000 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff|
|
||||
|40|2001:db8:ab00::/40|2001:0db8:ab00:0000:0000:0000:0000:0000 2001:0db8:abff:ffff:ffff:ffff:ffff:ffff|
|
||||
|48|2001:db8\:abcd::/48|2001:0db8\:abcd:0000:0000:0000:0000:0000 2001:0db8\:abcd:ffff:ffff:ffff:ffff:ffff|
|
||||
|56|2001:db8\:abcd:1200::/56|2001:0db8\:abcd:1200:0000:0000:0000:0000 2001:0db8\:abcd:12ff:ffff:ffff:ffff:ffff|
|
||||
|64|2001:db8\:abcd\:1234::/64|2001:0db8\:abcd\:1234:0000:0000:0000:0000 2001:0db8\:abcd\:1234:ffff:ffff:ffff:ffff|
|
||||
|
||||
我们方便一点不算保留地址，/64前缀意味着后面还有64位的地址空间，也就是2的64次方个IP地址，这个数量是天文数值，我不知道地球上的沙子有没有这么多。如果不改变封禁策略，一个一个地址封那是根本不可能封禁的。
|
||||
|
||||
你可能说，这招也太逆天了吧，不就仗着人家没反应过来，要让人家一个子网一个子网封禁岂不是倒霉了。你说的对，但是你可以混合不同大小的子网，而且封禁子网会导致巨量的IP地址被封禁，这是一个很糟糕的选择。况且租一个/32子网中的一部分也不是不可能对吧，和哪个商家关系好，给你个/32子网下面一点的子网，你不就不好处理了。
|
||||
|
||||
### 微操大师
|
||||
|
||||
好吧，那我换一个坏水，介于我们打爆WordPress的请求量不需要很大，而且性能差距很大，我们用一些高级工具，直接模拟浏览器绕过CloudFlare的验证码也不是不可能。
|
||||
|
||||
[](https://github.com/ultrafunkamsterdam/undetected-chromedriver)
|
||||
|
||||
我们可以用这个改进的Selenium Chromedriver绕过CloudFlare的验证码，UA，浏览器指纹等检测方式。
|
||||
|
||||
然后找一个动态点，比如去搜索框输入随机内容搜索。再配合我们的IPv6人海战术，只需要几十rqs就可以导致它的性能危机。这么多Selenium Chromedriver可能确实会有些消耗性能，但是在自己笔记本上运行也不是很有难度。但是在Blue Team看来就头大了。他们会看见无比正常的一幕，不同的IP地址有一个用户每半个小时，一个小时甚至几个小时才访问一次。或者有一些IP地址的用户甚至不会访问第二次，你会不会疑惑自己的网站是不是发到哪里火了，而不是被攻击了。
|
||||
|
||||
## 总结
|
||||
|
||||
KEIJILION提到了一种针对WordPress实例的DDoS攻击方式，即通过请求一个不存在的路径来绕过缓存机制，消耗服务器资源。这种攻击之所以有效，是因为
|
||||
|
||||
1. WordPress的页面请求都需要交给index.php处理，即使是404页面也需要消耗一定的资源。很多VPS性能有限，没有缓存的WordPress可能只能承受几十rqs。
|
||||
|
||||
2. 攻击者通过请求随机URL路径，使请求击穿缓存直达WordPress后端，绕过了CDN和WAF等防御。
|
||||
|
||||
3. 攻击者会避免被封禁IP、UA等，以逃避检测。
|
||||
|
||||
KEIJILION可能通过扫描Nginx日志中的异常状态码并封禁相应IP来缓解这个问题。但这个方案仍有一些漏洞
|
||||
|
||||
1. 攻击者可以利用IPv6的巨大地址空间，几乎不可能一个个封禁。
|
||||
|
||||
2. 通过模拟真实浏览器发起请求，可以绕过CloudFlare的验证码、指纹等检测，使攻击看起来像正常访问。
|
||||
|
||||
3. 由于WordPress的性能瓶颈，攻击者只需要几十rqs的低速率攻击就能造成危害，很难引起注意。
|
||||
|
||||
总之，这种DDoS攻击利用了WordPress架构的特点，难以彻底防范。网站管理员除了提高WordPress性能外，还需要更全面的监控和防御措施。
|
||||
Reference in New Issue
Block a user