如何对服务器进行DoS攻击

Source: Dev.to

免责声明

本实验在我拥有的受控家庭实验室系统上进行。未对真实世界的系统造成任何伤害。仅用于教育目的。

它是如何开始的

和许多学习网络安全的人一样，我曾经认为拒绝服务（DoS）攻击需要庞大的僵尸网络、惊人的带宽以及好莱坞级别的黑客技术。事实并非如此。你只需要一台存在漏洞的服务器和一种利用该漏洞的方法——不需要恶意软件，不需要奇特的漏洞利用，只要糟糕的应用程序设计和一种敢于尝试的态度。

DoS 与 DDoS

在本实验中，我使用 一台机器 对目标进行攻击，因此这是一次 DoS 场景。

我搭建的实验室

我使用 Oracle VirtualBox 搭建了一个小型、隔离的实验室：

• Kali Linux → 攻击者机器
• Ubuntu Linux → 目标机器

两台虚拟机通过 Host‑only network（仅主机网络）连接，这样它们可以相互通信，同时完全与互联网隔离。这使得实验合法、安全且受控。

易受攻击的服务器

你能找出下面 Python 代码有什么问题吗？

from http.server import BaseHTTPRequestHandler, HTTPServer
import time

a = 0

class VulnerableHTTPRequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        global a
        time.sleep(3)                     # <-- intentional delay
        self.send_response(200)
        self.send_header('Content-type', 'text/html')
        self.end_headers()
        self.wfile.write(bytes(f"Request processed. Count: {a}", "utf-8"))
        a += 1

def run(server_class=HTTPServer, handler_class=VulnerableHTTPRequestHandler, port=8080):
    server_address = ('', port)
    httpd = server_class(server_address, handler_class)
    print(f"Starting vulnerable server on port {port}...")
    httpd.serve_forever()

if __name__ == "__main__":
    run()

你看到了吗？ time.sleep(3)

这行代码是为了模拟“繁重的处理”，但它正是整个漏洞所在，因为：

• 服务器是 单线程 的。
• 每个请求都会阻塞 3 秒。
• 没有速率限制或并发处理机制。

这使得它成为应用层拒绝服务（DoS）攻击的理想目标。

启动服务器

在 Ubuntu 虚拟机上运行：

python3 vulnerable_server1.py

服务器将在 8080 端口启动。可以在 Kali 虚拟机上验证其是否工作：

curl http://192.168.56.103:8080

每个请求应返回响应并递增计数器。

攻击

在 Kali 上，我运行了 ApacheBench：

ab -n 50 -c 10 http://192.168.56.103:8080/

• 总计 50 个请求
• 并发 10 个请求

虽然这些数字看起来很温和，服务器却很快“卡住”了。响应变慢，请求开始排队。我并没有淹没网络或让操作系统崩溃——我只是让服务器承担了超出其设计承受能力的负载。

实际发生的情况

因为服务器是 single‑threaded，每个请求会阻塞 3 秒。一次只能处理一个请求，所以当 10 个请求同时到达时：

1. 处理一个请求。
2. 其余九个在队列中等待。
3. 新的请求不断堆积。

这是一种 application‑layer DoS，而不是带宽攻击。

在 Wireshark 中观察攻击

作为额外补充，我在 Kali 上使用 Wireshark 并使用以下过滤器捕获了流量：

ip.addr == 192.168.56.103 && tcp.port == 8080

捕获显示：

• 重复的 HTTP GET 请求
• 响应延迟
• TCP 重传
• 拥塞逐渐加剧

现实世界的相关性

类似的漏洞可能出现在：

• 内部工具
• API
• 微服务
• 定制仪表盘

攻击者并不总是需要“破坏”某些东西；他们可以简单地等待写得不好的代码自行崩溃。在生产环境中，这类缺陷（希望）会被迅速修补，但它是一个极好的学习练习。

缓解措施

• 使用异步或多线程服务器（例如 aiohttp、gunicorn、uvicorn）。
• 添加速率限制。
• 在应用前放置反向代理（例如 Nginx）。

结论

破坏我自己的服务器是迄今为止我学到的最有价值的教训之一。它展示了应用层 DoS 的工作原理、为何设计选择很重要，以及攻击流量到底是什么样子。

如果你正在学习网络安全，我强烈推荐构建类似的实验室：它们安全、合法且极具启发性。

附加: 我在实验上述设置时写了这篇博客文章。欢迎复现实验并进一步探索！

虽然没有计划如何完成它，我也测试了一个 HTTP 喷射 DoS 攻击，但博客篇幅已经太长。如果想查看该工具，它在我的 GitHub 上。若有时间，我计划在接下来几天改进它。