基于ASP.NET Core+Azure：检测DDoS恶意请求后如何提升攻击成本？

针对你提到的已在请求管线早期检测到恶意请求（无有效CAPTCHA Cookie）的场景，下面直接拆解两种处理思路的可行性、实现方式及优劣：

一、快速返回响应：简单高效的基础方案 #

• 核心优势：实现成本极低，完全不占用额外服务器资源，能快速过滤恶意请求，避免其消耗后续管线资源。
• 劣势：攻击者能快速收到响应并发起下一轮请求，无法增加其攻击成本。
• 代码实现（中间件形式）：

public class MaliciousRequestMiddleware
{
    private readonly RequestDelegate _next;

    public MaliciousRequestMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (!IsValidRequest(context))
        {
            // 返回403或直接跳转至CAPTCHA验证页面
            context.Response.StatusCode = StatusCodes.Status403Forbidden;
            await context.Response.WriteAsync("请完成人机验证后访问");
            return;
        }

        await _next(context);
    }

    // 你的恶意请求检测逻辑：检查有效CAPTCHA Cookie
    private bool IsValidRequest(HttpContext context)
    {
        return context.Request.Cookies.TryGetValue("ValidCaptcha", out var _);
    }
}

// 在Program.cs的请求管线最早期注册该中间件
app.UseMiddleware<MaliciousRequestMiddleware>();

二、“消耗攻击者资源”方案：云环境下的限制与替代方案 #

你提到的“伪装连接打开实际关闭”思路，本质是反向利用半开连接消耗攻击者资源，但在Azure+ASP.NET Core环境下有诸多限制：

1. Azure网络层限制：Azure App Service/VM的负载均衡器、网关有默认连接超时（约4分钟），即使你不主动关闭，Azure也会强制断开连接，无法让攻击者无限挂着。
2. ASP.NET Core连接占用：保持连接但不响应会占用Kestrel连接池资源，攻击者发起大量请求时，反而会耗尽自身可用连接，影响正常用户访问。
3. TCP协议特性：直接发RST包关闭连接会被攻击者立刻感知；若只关输出流不发终止信号，攻击者客户端会等待至自身超时，但服务器仍会占用该连接资源。

低消耗的替代耗敌方案 #

如果想增加攻击者的时间/带宽成本，同时避免反噬自身，可以尝试：

• 缓慢分段返回响应：分多次小批量返回无意义内容，拉长攻击者的请求等待时间：

public async Task InvokeAsync(HttpContext context)
{
    if (!IsValidRequest(context))
    {
        context.Response.StatusCode = StatusCodes.Status200OK;
        context.Response.ContentType = "text/plain";
        // 分10次，每次间隔1秒返回内容，总耗时10秒
        for (int i = 0; i < 10; i++)
        {
            await context.Response.WriteAsync(" ");
            await context.Response.Body.FlushAsync();
            await Task.Delay(1000);
        }
        return;
    }

    await _next(context);
}

注意：Azure App Service默认请求超时为230秒，不要超过这个阈值；同时可通过Kestrel配置限制这类请求的并发数，避免线程池被占满。

• 流式返回大体积无效内容：通过流式输出生成大量随机无意义数据，消耗攻击者的带宽和内存，但要避免一次性生成大内存块，用逐段输出的方式控制自身内存占用。

三、最终推荐方案 #

结合Azure和ASP.NET Core的环境特性，优先选择「快速返回403+CAPTCHA引导」的方案：

1. 对恶意请求直接返回403并引导至验证页面，正常用户完成验证后获得有效Cookie即可访问，兼顾安全性和用户体验。
2. 若想小幅增加攻击者成本，可在返回前加入500ms以内的短暂延迟，不要过长，避免影响自身服务可用性。
3. 不要尝试半开连接这类方案，云环境下效果有限且极易反噬自身。

内容的提问来源于stack exchange，提问作者Dirk Boer