1. 项目概述：从“攻”与“防”的双重视角审视DDoS

在网络安全领域，DDoS（分布式拒绝服务攻击）始终是一个绕不开的经典话题。它不像某些漏洞利用那样需要精巧的代码构造，其核心逻辑简单粗暴——通过海量无效或半合法的请求，耗尽目标服务器的资源，使其无法为正常用户提供服务。但正是这种“简单”，让它成为了互联网世界中最具破坏力、也最难彻底防御的攻击手段之一。上一期我们聊了DDoS的基本原理和常见类型，这一期，我们将深入“攻”与“防”的腹地，进行一次实战化的深度分析。

你可能会问，为什么还要分析“攻”？了解攻击不是为了实施攻击，恰恰相反，是为了更好地防御。这就像一名优秀的医生，必须透彻理解病毒的传播路径和致病机理，才能开出最有效的药方。在DDoS攻防中，攻击者的思路、工具、战术的演变，直接决定了防御策略的迭代方向。我们将从攻击者的工具链（包括近期在特定移动终端环境如Termux中出现的简易工具）、攻击流量的特征分析，到防御方的检测、缓解与溯源技术，进行一次全景式的拆解。无论你是运维工程师、安全研究员，还是对网络攻防感兴趣的技术爱好者，这篇文章都将为你提供一个从原理到实践、从现象到本质的清晰路线图。

2. 攻击方深度解析：工具、战术与流量特征

要构建有效的防御，首先必须像攻击者一样思考。现代DDoS攻击早已不是单兵作战，而是形成了从资源准备、攻击发动到效果评估的完整产业链。

2.1 攻击资源构建：僵尸网络与反射放大源

攻击的威力来源于“分布式”，其核心是控制大量可供调度的攻击节点。这些节点主要有两类：

  1. 僵尸网络（Botnet） ：这是最传统也最核心的资源。攻击者通过漏洞利用、恶意软件捆绑等方式，感染并控制海量的个人电脑、服务器、物联网设备（如摄像头、路由器）。这些被控制的设备被称为“肉鸡”或“僵尸”，它们会静默运行一个客户端程序，等待攻击者的指令。一个大型僵尸网络可能拥有数十万甚至数百万节点，它们发起的直接流量攻击极具冲击力。

  2. 反射放大源 ：这是一种利用互联网协议设计缺陷的“四两拨千斤”战术。攻击者并不直接让僵尸机攻击目标，而是让它们向一些具有“放大”效应的公共服务（如DNS解析服务器、NTP时间服务器、Memcached缓存服务器）发送伪造了源IP地址（即目标IP）的请求。这些服务收到一个小请求后，会向“源IP”（即受害者）回复一个体积大得多的响应数据包，从而实现流量放大。放大倍数从几倍到数万倍不等，能用极小的代价制造出惊人的流量洪峰。

注意 ：反射放大攻击的关键在于协议的无连接性和服务的开放性。防御此类攻击，一方面需要服务提供商加固自身配置（如关闭开放的递归DNS解析），另一方面也需要防御方能够识别这些特定的协议流量。

2.2 攻击工具链演变：从低阶到高阶

攻击工具是攻击者思想的具象化。它们的演变清晰地反映了攻防对抗的升级。

  • 低阶工具 ：如LOIC（低轨道离子炮）、HOIC等，界面简单，参数少，本质上是一个简单的多线程HTTP请求发送器。它们依赖使用者自己拥有大量带宽或控制大量主机，技术含量低，但容易被溯源。
  • 中阶工具 ：例如基于Python或Go编写的、可在多种平台运行的脚本工具。这类工具开始集成更多功能，如支持多种协议（TCP/UDP/ICMP Flood）、伪造IP头部、动态变换攻击模式等。近期在开发者社区和移动终端环境（如Termux）中流传的一些所谓“实用DDoS工具”，大多属于这一范畴。它们通常伪装成压力测试工具，代码开源或半开源，降低了攻击门槛。
  • 高阶工具 ：以Mirai及其无数变种为代表。这类工具专门针对物联网设备进行优化，采用模块化设计，包含扫描、爆破、感染、攻击等多个模块。它们使用硬编码的默认密码字典进行传播，能自动构建僵尸网络，并接受C&C（命令与控制）服务器的远程指令，发起复杂的混合攻击。这类工具代表了当前DDoS攻击的自动化、产业化水平。

关于Termux等环境中的工具 ：Termux是一个强大的Android终端模拟器，它提供了一个近乎完整的Linux环境。这使得一些基于Python、C或Go编写的攻击工具可以相对容易地被移植或直接运行在安卓设备上。这带来了新的风险点：移动设备也可能在不知情的情况下成为攻击节点。对于普通用户，务必从官方渠道安装应用，不要随意运行来源不明的脚本；对于安全研究人员，则需要在可控环境中进行分析。

2.3 攻击流量特征分析：识别攻击的“指纹”

不同类型的DDoS攻击，其网络流量会呈现出不同的特征，这是进行检测和过滤的基础。

  • 流量型攻击（Volumetric Attacks） ：

    • 特征 ：旨在耗尽目标网络带宽。流量速率（pps, packets per second 或 bps, bits per second）极高，通常远超过正常业务基线。
    • 示例 ：UDP Flood、ICMP Flood、反射放大攻击。流量中可能包含大量源IP随机伪造的UDP包，或来自特定端口（如DNS的53端口、NTP的123端口）的大尺寸响应包。
    • 识别关键 ：建立带宽利用率基线，监控出入流量速率突增。分析流量协议分布，异常比例的UDP或ICMP流量是重要指标。

  • 协议型攻击（Protocol Attacks） ：

    • 特征 ：旨在耗尽服务器或中间设备（如防火墙、负载均衡器）的连接状态表或处理资源。
    • 示例 ：SYN Flood、ACK Flood、Slowloris攻击。SYN Flood会发送大量TCP SYN握手包但不完成三次握手，导致服务器维护大量半开连接。Slowloris则通过极慢的速度发送HTTP请求头，长期占用服务器的连接线程。
    • 识别关键 ：监控服务器的并发连接数、半开连接数、新建连接速率。协议型攻击往往表现为连接数异常增高，但单连接流量不大。

  • 应用层攻击（Application Layer Attacks） ：

    • 特征 ：最难以检测，因为模拟的是正常用户行为。旨在耗尽Web应用、数据库等后端资源。
    • 示例 ：HTTP Flood、CC攻击。攻击者可能使用代理IP池或僵尸网络，模仿真实用户访问网站的高消耗页面（如搜索、登录、复杂查询）。
    • 识别关键 ：单纯看流量和连接数可能正常。需要分析应用层日志，关注同一IP或用户会话在短时间内的请求频率、访问的URL模式（是否集中于几个特定动态页面）、User-Agent是否异常单一或伪造。

3. 防御方体系构建：检测、缓解与溯源

面对多层次、混合式的DDoS攻击，单一的防御手段是无效的。必须构建一个纵深防御体系，涵盖从边缘到核心的多个环节。

3.1 第一道防线：流量清洗与近源压制

当攻击流量到达你的网络边界时，第一要务是将其与正常业务流量分离并过滤掉。

  1. 基于特征的过滤（Signature-based Filtering） ：

    • 原理 ：针对已知攻击模式的固定特征进行匹配和丢弃。例如，丢弃所有来自非业务端口的UDP包（针对反射放大），或丢弃带有特定畸形标志位的TCP包。
    • 实现 ：通常在路由器、防火墙或专用的清洗设备上通过ACL（访问控制列表）或深度包检测（DPI）规则实现。
    • 优缺点 ：效率高，对资源消耗小。但只能防御已知攻击，对未知变种或模拟正常的应用层攻击无效。

  2. 基于行为的异常检测（Anomaly-based Detection） ：

    • 原理 ：建立网络或应用行为的正常基线模型（如每秒请求数、源IP分布、URI访问频率等），实时监控流量并与基线对比，将显著偏离基线的流量判定为异常。
    • 实现 ：需要部署具备机器学习或统计分析能力的检测系统。例如，监控HTTP请求速率，如果某个IP在短时间内对同一个URL发起成千上万次请求，即便每次请求都合法，也可判定为攻击。
    • 优缺点 ：能发现新型或变种攻击。但存在误报可能，且系统建立和训练基线需要时间。

  3. 近源压制（Upstream Filtering / Remote Triggered Black Hole） ：

    • 场景 ：当攻击流量大到足以堵塞你的互联网接入链路时，边界设备已经无法处理。这时需要向你的上游互联网服务提供商（ISP）求助。
    • 原理 ：通过BGP协议，向ISP发布一条指向目标IP的特定路由，将去往该IP的所有流量引导到一个“黑洞”接口或清洗中心。在清洗中心完成过滤后，再将干净流量回注到你的网络。
    • 实操要点 ：与ISP建立应急响应流程至关重要。需要明确触发条件、沟通渠道和路由宣告策略。

3.2 第二道防线：架构优化与弹性伸缩

良好的系统架构能在一定程度上“吸收”或“抵御”攻击压力，为应急响应争取时间。

  1. 冗余与负载均衡 ：

    • 通过部署多台服务器、多个数据中心，并利用全局负载均衡（如DNS轮询、Anycast），将用户流量分散到不同的节点。即使某个节点被攻陷，其他节点仍可提供服务。
    • 心得 ：负载均衡器本身可能成为攻击目标（如耗尽其连接表）。因此，负载均衡器需要具备抗DDoS能力，或将其隐藏在云服务商的清洗网络之后。

  2. 扩容与弹性伸缩 ：

    • 对于云上业务，利用云平台的自动伸缩组功能。当检测到流量激增（可能是正常高峰也可能是攻击）时，自动创建更多的计算实例来分担负载。
    • 注意 ：这主要应对消耗计算资源的应用层攻击。对于旨在堵塞带宽的流量型攻击，弹性伸缩无效，因为新实例的网络出口依然共享同一带宽管道。此时需要结合云服务商提供的DDoS防护服务。

  3. 内容分发网络（CDN） ：

    • CDN将静态内容缓存到遍布全球的边缘节点，用户就近访问。这不仅能加速，也能起到很好的DDoS缓解作用：
      • 吸收静态资源请求 ：攻击者发起的对图片、JS、CSS等文件的请求，大部分被边缘节点响应，不会回源到主站。
      • 隐藏源站IP ：源站IP被CDN服务商保护起来，攻击者难以直接攻击源站。
      • CDN提供商自身的防护 ：大型CDN厂商自身就拥有巨大的带宽和清洗能力。

3.3 第三道防线：应用层加固与智能对抗

针对最难防御的应用层攻击，需要在应用代码和业务逻辑层面进行加固。

  1. 人机验证（CAPTCHA） ：

    • 当检测到某个会话或IP行为异常时（如短时间内多次提交表单、频繁搜索），弹出图形验证码或行为验证（如滑动拼图）。这能有效阻断简单的自动化脚本。
    • 技巧 ：不要对所有用户全程启用，而是在风险触发时动态启用，避免影响正常用户体验。

  2. 频率限制与速率控制 ：

    • 在应用网关或API网关上，对关键接口实施严格的频率限制。例如，同一个IP每分钟只能调用登录接口5次，同一个用户ID每小时只能发起50次搜索请求。
    • 实现 ：常用Redis等内存数据库实现分布式令牌桶或漏桶算法。

  3. 客户端指纹与行为分析 ：

    • 收集客户端的一些软硬件信息（如浏览器类型、屏幕分辨率、字体列表、Canvas指纹等），生成一个相对稳定的“指纹”。结合用户鼠标移动轨迹、点击速度等行为模式，建立模型来区分真人用户和机器人。
    • 注意事项 ：这种方法涉及用户隐私，需要谨慎处理，并遵守相关法律法规，通常仅用于高风险操作环节。

3.4 溯源与反制：从被动防御到主动响应

虽然完全追溯并定位到攻击者本人非常困难，但进行一定程度的溯源对于收集证据、了解攻击态势、甚至采取法律行动至关重要。

  1. 日志记录与分析 ：

    • 记录什么 ：必须完整记录所有网络设备、安全设备、服务器和应用的关键日志，特别是包含源IP、端口、时间戳、协议、请求URL、User-Agent等字段的日志。
    • 集中管理 ：使用SIEM（安全信息和事件管理）系统集中收集和分析日志，便于关联分析攻击事件。

  2. 流量镜像与抓包 ：

    • 在清洗设备或核心交换机上，将可疑流量镜像一份到安全分析平台。使用Wireshark、tcpdump等工具进行深度包分析，提取攻击工具的特征、C&C服务器的地址等。
    • 实操心得 ：抓包文件可能非常大，需要足够的磁盘空间。分析时，可以先用 tshark 或 capinfos 进行概要统计，再针对特定协议或特征进行过滤分析。

  3. 威胁情报共享 ：

    • 加入行业或社区的安全威胁情报共享组织。当你遭受攻击时，你发现的恶意IP、域名、攻击样本，可能对其他成员有预警价值；反之，你也可以提前获得他人共享的威胁情报，在攻击到达前就进行封堵。
    • 常见来源 ：一些开源威胁情报 feeds、云安全厂商的报告、国家级的网络安全应急响应中心（CERT）发布的信息。

4. 实战演练：构建一个简单的DDoS检测原型

理论需要实践来巩固。让我们用Python构建一个简易的应用层HTTP Flood检测原型，它运行在Web服务器前端，通过分析访问日志来发现异常。

4.1 设计思路与架构

我们将模拟一个简单的基于滑动时间窗口的速率限制检测器。其核心逻辑是：统计每个源IP在过去一分钟内的HTTP请求总数，如果超过设定的阈值，则判定该IP为可疑攻击源，并记录到告警日志中。

为什么选择滑动窗口？ 相比固定时间窗口（如整点统计），滑动窗口能更平滑地反映请求速率的变化，避免在窗口边界处出现误判或漏判。

4.2 核心代码实现与解析

我们将使用Python的 logging 模块来模拟读取Web服务器（如Nginx）的实时日志，使用字典和队列来实现滑动窗口。

#!/usr/bin/env python3
"""
简易HTTP Flood检测器
模拟从stdin读取Nginx格式日志，检测每分钟请求超阈值的IP
"""

import sys
import re
from collections import defaultdict, deque
import time
from datetime import datetime

# 配置参数
TIME_WINDOW = 60  # 滑动窗口大小，单位：秒
THRESHOLD = 120   # 时间窗口内允许的最大请求数，可根据业务调整
LOG_PATTERN = re.compile(r'(?P<ip>\d+\.\d+\.\d+\.\d+).*?"(?P<method>\w+) (?P<url>\S+)')

class SlidingWindowDetector:
    def __init__(self, window_size, threshold):
        self.window_size = window_size
        self.threshold = threshold
        # 数据结构：ip -> deque(时间戳列表)
        self.ip_request_times = defaultdict(deque)
        # 记录已告警的IP，避免短时间内重复告警
        self.alarmed_ips = set()

    def process_log_line(self, log_line, timestamp):
        """处理单条日志"""
        match = LOG_PATTERN.search(log_line)
        if not match:
            return

        ip = match.group('ip')
        # 清理该IP窗口外的时间戳
        while (self.ip_request_times[ip] and 
               timestamp - self.ip_request_times[ip][0] > self.window_size):
            self.ip_request_times[ip].popleft()

        # 添加当前请求的时间戳
        self.ip_request_times[ip].append(timestamp)

        # 检查是否超阈值
        request_count = len(self.ip_request_times[ip])
        if request_count > self.threshold and ip not in self.alarmed_ips:
            self.trigger_alert(ip, request_count, timestamp)
            self.alarmed_ips.add(ip)
            # 可选：一段时间后将该IP从告警集中移除，以便后续持续监控
            # 这里简化处理，一旦告警就不再重复告警

    def trigger_alert(self, ip, count, timestamp):
        """触发告警动作"""
        alert_time = datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %H:%M:%S')
        alert_msg = f"[ALERT] Potential HTTP Flood detected! IP: {ip}, Requests in last {self.window_size}s: {count} (Threshold: {self.threshold}), Time: {alert_time}"
        print(alert_msg)
        # 在实际环境中，这里可以发送邮件、写入数据库、调用告警接口等
        # 例如：logging.critical(alert_msg)

    def clean_stale_data(self, current_time):
        """定期清理长时间无活动的IP数据，防止内存泄漏"""
        stale_ips = []
        for ip, times in self.ip_request_times.items():
            if not times or current_time - times[-1] > self.window_size * 2:
                stale_ips.append(ip)
        for ip in stale_ips:
            del self.ip_request_times[ip]
            if ip in self.alarmed_ips:
                self.alarmed_ips.remove(ip)

def main():
    detector = SlidingWindowDetector(TIME_WINDOW, THRESHOLD)
    last_clean_time = time.time()

    print(f"简易HTTP Flood检测器已启动。窗口: {TIME_WINDOW}秒，阈值: {THRESHOLD}次请求。")
    print("正在模拟读取日志（按Ctrl+C退出）...")
    try:
        # 模拟日志输入，实际中可从文件、管道或socket读取
        # 这里我们简单模拟一些请求
        import random
        base_time = time.time()
        normal_ip = "192.168.1.100"
        attack_ip = "10.0.0.1"

        # 生成一些正常请求（每秒1-2个）
        for i in range(70):
            log_time = base_time + i * 0.8  # 正常请求间隔约0.8秒
            log_line = f'{normal_ip} - - [{datetime.fromtimestamp(log_time).strftime("%d/%b/%Y:%H:%M:%S +0000")}] "GET /index.html HTTP/1.1" 200 1234'
            detector.process_log_line(log_line, log_time)
            time.sleep(0.01)  # 模拟实时处理间隔

        # 生成攻击请求（短时间内爆发）
        print(f"\n--- 模拟攻击开始 ---")
        for i in range(150):
            log_time = base_time + 70 + i * 0.1  # 攻击请求间隔0.1秒，15秒内发150次
            log_line = f'{attack_ip} - - [{datetime.fromtimestamp(log_time).strftime("%d/%b/%Y:%H:%M:%S +0000")}] "GET /api/search?q=test HTTP/1.1" 200 5678'
            detector.process_log_line(log_line, log_time)
            time.sleep(0.005)
        print(f"--- 模拟攻击结束 ---\n")

        # 继续一些正常请求
        for i in range(30):
            log_time = base_time + 220 + i * 1.0
            log_line = f'{normal_ip} - - [{datetime.fromtimestamp(log_time).strftime("%d/%b/%Y:%H:%M:%S +0000")}] "GET /about.html HTTP/1.1" 200 1234'
            detector.process_log_line(log_line, log_time)
            time.sleep(0.02)

    except KeyboardInterrupt:
        print("\n检测器已停止。")
    except Exception as e:
        print(f"运行出错: {e}", file=sys.stderr)

if __name__ == "__main__":
    main()

4.3 代码关键点解析与优化建议

  1. 数据结构选择 ：使用 defaultdict(deque) 来存储每个IP的请求时间戳队列。 deque （双端队列）在头部弹出（popleft）和尾部追加（append）操作的时间复杂度都是O(1)，非常适合实现滑动窗口。
  2. 时间窗口清理 ：在每次处理新请求时，都会先清理该IP队列中超出窗口范围的时间戳。这保证了队列中只保留最近 TIME_WINDOW 秒内的请求记录。
  3. 内存管理 ： clean_stale_data 方法用于清理那些长时间（如两倍窗口时间）没有活动的IP数据，这是一个防止字典无限膨胀的好习惯。
  4. 告警去重 ：使用 alarmed_ips 集合来记录已告警的IP，避免在同一个攻击持续期间产生海量重复告警，淹没真正的告警信息。

这个原型的局限性及优化方向 ：

  • 单机内存限制 ：所有数据存储在内存中，IP数量巨大时会消耗大量内存。生产环境需要使用Redis等外部存储来实现分布式计数。
  • 简单阈值 ：仅基于请求频率，容易被低速率慢速攻击绕过。需要结合更多维度，如请求的URL分布（是否只攻击少数几个高消耗接口）、User-Agent是否单一等。
  • 无自动基线学习 ：阈值 THRESHOLD 是固定的。高级系统应该能自动学习不同时间（如工作日/周末、白天/黑夜）的正常流量基线，并动态调整阈值。
  • IP伪造 ：攻击者可能伪造源IP或使用代理IP池，使基于IP的统计失效。此时需要结合客户端指纹、会话行为等更复杂的标识。

5. 常见问题与排查技巧实录

在实际的DDoS攻防对抗中，会遇到各种各样的问题。下面记录了一些典型场景和排查思路。

5.1 如何判断服务器是否正在遭受DDoS攻击？

不要一感觉网站慢就认为是DDoS。系统性的排查步骤如下：

  1. 检查带宽和连接数 ：

    • 命令 ： iftop 、 nethogs 查看实时带宽占用； netstat -an | grep :80 | wc -l 查看80端口的连接数。
    • 判断 ：如果出/入带宽持续接近或达到物理上限，或TCP连接数异常高（远超平时水平），是流量型或协议型攻击的强烈信号。

  2. 检查服务器负载 ：

    • 命令 ： top 、 htop 。关注 %CPU 、 %MEM 以及 Load Average 。
    • 判断 ：如果负载极高，但通过 top 查看用户态进程的CPU占用并不高，可能是内核在处理海量网络中断，属于流量型攻击。如果负载高且是某个特定进程（如Web服务器、数据库）CPU占满，可能是应用层攻击。

  3. 分析网络连接状态 ：

    • 命令 ： ss -s 或 netstat -s 。查看TCP状态的统计信息。
    • 关键指标 ： LISTEN , ESTABLISHED , SYN-RECV 的数量。大量 SYN-RECV 状态表示可能遭受SYN Flood攻击。

  4. 查看Web服务器日志 ：

    • 位置 ：Nginx通常在 /var/log/nginx/access.log ， Apache在 /var/log/apache2/access.log 。
    • 快速分析 ： tail -f access.log | cut -d' ' -f1 | sort | uniq -c | sort -nr | head -20 这个命令管道可以实时查看最近请求最频繁的前20个IP。
    • 判断 ：如果发现少数几个IP在短时间内产生了巨量的请求记录，很可能是应用层攻击。

5.2 遭受攻击时，第一时间的应急步骤是什么？

保持冷静，按预案操作。一个简单的应急清单如下：

步骤 动作 目的与说明
1. 确认与评估 通过上述排查命令确认攻击类型和规模。 避免误操作。记录攻击开始时间、特征（源IP、协议、目标端口），用于事后分析。
2. 启动应急预案 通知安全团队、运维团队和业务负责人。 启动事先准备好的应急预案，明确沟通渠道和决策链。
3. 启用云端/ISP防护 如果使用了云DDoS防护或与ISP有清洗服务，立即在控制台开启或联系ISP启用。 这是应对大流量攻击最有效的手段，将攻击流量引流到清洗中心。
4. 调整本地防护策略 在边界防火墙或WAF上，临时封禁攻击特征明显的IP段或协议。 缓解攻击压力，为其他措施争取时间。 注意 ：对于伪造IP的攻击，此方法效果有限。
5. 应用层限流 在Web服务器或应用网关层，对关键接口实施严格的速率限制。 针对应用层攻击，保护后端应用不被打垮。
6. 扩容与切换 如果架构允许，将业务切换到备用IP或CDN，并对后端服务进行水平扩容。 保证核心业务的可用性。
7. 监控与观察 持续监控防护效果，观察业务恢复情况。 调整防护策略，直到攻击停止。
8. 事后复盘 攻击结束后，分析日志、流量包，撰写事件报告。 更新防护策略、应急预案，并考虑是否进行溯源或法律追责。

5.3 使用云防护服务后，源站服务器为什么还能看到少量攻击IP？

这是一个非常常见的情况。原因通常有以下几点：

  1. 回源流量未完全清洗 ：云清洗中心在过滤攻击流量后，会将“干净”的流量回源到你的真实服务器。清洗规则不可能100%精确，可能会有少量漏网的攻击请求（False Negative）被当作正常请求回源。
  2. 攻击者直接探测到源站IP ：如果你的源站IP曾经暴露过（例如，在DNS历史记录中、通过SSL证书信息泄露、或某些子域名直接解析到源站），攻击者可能会绕过CDN或防护服务，直接攻击源站IP。
  3. 防护策略配置问题 ：例如，在云WAF或安全组上，可能只对80/443等Web端口进行了防护，但攻击者攻击了其他管理端口（如22, 3389）。

排查与解决 ：

  • 检查回源日志 ：分析源站服务器上的访问日志，确认这些请求是否来自云清洗中心的回源IP（通常云服务商会提供回源IP段列表）。如果是，则需要联系云服务商调整清洗策略。
  • 彻底隐藏源站IP ：确保所有域名都通过CNAME解析到CDN或防护服务的地址，任何地方都不要直接记录源站IP。为源站服务器配置严格的安全组/防火墙，只允许来自云清洗中心回源IP段的流量。
  • 检查所有入口 ：确保服务器所有对外开放的端口都已纳入防护范围，或直接关闭非必要的公网访问端口。

5.4 如何区分DDoS攻击和真正的流量高峰？

业务促销、热点事件也可能带来真实的流量洪峰。误判会导致错误地拦截正常用户。可以从以下几个维度进行区分：

特征维度 DDoS攻击流量 真实业务高峰
流量来源分布 源IP可能非常分散（僵尸网络）或高度集中（反射放大），地理分布异常。 源IP分布与正常用户群体特征相符，地理分布合理。
请求规律性 请求速率异常稳定，或呈脉冲式爆发，缺乏自然波动。 请求速率有自然的起伏，符合用户行为模式（如白天多、夜晚少）。
访问内容 集中于少数几个URL（尤其是动态、高消耗接口），或大量请求不存在的资源。 访问的URL分布符合网站结构，首页、列表页、详情页等均有合理比例。
用户行为 缺乏完整的用户会话（如只请求页面，不加载CSS/JS图片；不携带Cookie或Cookie异常）。 有完整的会话链条，携带正常的Cookie，请求序列符合人类浏览逻辑。
协议与包特征 可能存在大量畸形包、小包、特定协议的泛洪流量。 协议比例正常（HTTP/HTTPS为主），数据包大小分布合理。

最可靠的方法是 建立业务流量基线 。通过长期监控，学习不同时间、不同活动下的正常流量模式，当流量偏离基线模型时，再结合上述特征进行综合判断。机器学习算法在这方面可以发挥很大作用。

# 网络安全
Logo
亚马逊云科技技术品牌专区