我用 Zip 炸弹保护我的服务器

447 条评论 | |

网络上的大部分流量都来自机器人。在大多数情况下，这些机器人是用来发现新内容的。它们是 RSS Feed 阅读器、抓取您内容的搜索引擎，或者是如今抓取内容以支持 LLM 的人工智能机器人。但也有恶意机器人。这些机器人来自垃圾邮件发送者、内容刮擦者或黑客。在我以前的雇主那里，一个机器人发现了一个 wordpress 漏洞，并在我们的服务器中插入了一个恶意脚本。然后，它把机器变成了一个用于 DDOS 的僵尸网络。我的第一个网站就是因为机器人生成垃圾邮件而被完全从谷歌搜索中删除的。在某些时候，我必须找到一种方法来保护自己免受这些机器人的攻击。于是，我开始使用压缩炸弹。

zip 炸弹是一个相对较小的压缩文件，它可以扩展成一个非常大的文件，让机器不堪重负。

元素周期表

网络早期开发的一项功能就是使用 gzip 压缩。由于互联网速度慢，信息量大，因此我们的想法是在通过网络传输数据之前，将数据压缩得尽可能小。因此，一个由文本组成的 50 KB HTML 文件可以压缩到 10K，从而在传输过程中节省 40KB。在拨号上网的情况下，这意味着下载页面的时间从 12 秒缩短到 3 秒。

同样的压缩也可用于提供 CSS、Javascript 甚至图像。Gzip 不仅快速、简单，还能大大改善浏览体验。当浏览器发出网络请求时，它会包含向目标服务器发出支持压缩信号的头信息。如果服务器也支持压缩，就会返回预期数据的压缩版本。

Accept-Encoding: gzip, deflate

抓取网络的机器人也支持这一功能。特别是由于它们的工作是从网络各处摄取数据，因此它们会通过使用压缩来最大化带宽。而我们可以充分利用这一功能。

在这个博客上，我经常会收到一些扫描安全漏洞的机器人，但我大部分情况下都会忽略它们。但当我检测到它们试图注入恶意攻击或正在探测响应时，我会返回 200 OK 响应，并向它们提供 gzip 响应。我提供的文件从 1MB 到 10MB 不等，他们也乐于接受。在大多数情况下，当他们这样做时，我就再也听不到他们的声音了。为什么？因为他们在摄取文件后会立即崩溃。

Content-Encoding: deflate, gzip

发生的情况是，它们接收到文件后，读取了指示它们这是压缩文件的头信息。于是，他们尝试解压这个 1MB 的文件，以找到他们要找的内容。但文件会不断扩大，直到内存耗尽，服务器崩溃。1MB 的文件解压成了 1GB。这足以让大多数机器人崩溃。不过，对于那些喋喋不休的讨厌脚本，我会向它们提供 10MB 的文件。这个文件会解压成 10GB，并立即杀死脚本。

在告诉你如何创建 zip 炸弹之前，我必须警告你，你可能会崩溃并毁坏自己的设备。请自行承担风险。下面是我们创建压缩炸弹的方法：

dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz

下面是该命令的操作

  1. dd： dd 命令用于复制或转换数据。
  2. if： 输入文件，指定 /dev/zero 一个特殊文件，它能产生无限的零字节流。
  3. bs：数据块大小，将数据块大小设置为 1 千兆字节（1G），这意味着 dd 将以每次 1 GB 的数据块读写数据。
  4. count=10：表示 dd 处理 10 个块，每个块大小为 1 GB。因此，这将产生 10 GB 的归零数据。

然后，我们将命令输出传递给 gzip，它将把输出压缩成 10GB.gz 文件。在这种情况下，生成的文件为 10MB。

我在服务器上添加了一个中间件，用于检查当前请求是否为恶意请求。我有一个黑名单 IP 列表，它会反复扫描整个网站。我还有其他启发式方法来检测垃圾邮件发送者。很多垃圾邮件发送者会尝试向一个页面发送垃圾邮件，然后再回来查看垃圾邮件是否已经到达该页面。我使用这种模式来检测他们。它看起来像这样

if (ipIsBlackListed() || isMalicious()) {
    header("Content-Encoding: deflate, gzip");
    header("Content-Length: "+ filesize(ZIP_BOMB_FILE_10G)); // 10 MB
    readfile(ZIP_BOMB_FILE_10G);
    exit;
}

这就够了。唯一的代价是，我现在有时要提供 10MB 的文件。如果有一篇文章要进行病毒式传播，我会将其减小到 1MB 文件，这样同样有效。

还有一点，压缩炸弹并非万无一失。它很容易被发现和规避。毕竟你可以阅读部分内容。但对于那些盲目爬网、扰乱服务器的不成熟机器人来说，这已经是保护服务器的好工具了。

你也许感兴趣的：

共有 447 条讨论

  1. 曾几何时，大约在 2001 年左右，我在家里架设了一条静态线路，并在家里的 Linux 主机上托管了一些东西。Windows NT 的一次更新意味着很多系统都启用了优化加密功能，Windows 系统会尝试连接到某个端口，并在进行 TCP 通信前协商一个 s/wan 协议。我已经习惯了在防火墙上经常看到这种流量，所以没什么大不了的。不过，有一台机器特别令人讨厌。它每隔几秒钟就会尝试连接一次，而且就是不退出。

    我试着联系盒子的管理员（是的，人们习惯这么做），但一无所获。最后，我发了一条信息说：”嘿，我看到你的机器每隔几秒钟就尝试连接端口<什么的>。我只是给你提个醒，我们正在该端口上启动一项新服务，我想确保它不会给你带来任何问题。

    当然，我没有收到回复。然后，我在那个端口上设置了一个服务器，基本上就是从 /dev/urandom 读取数据，设置 TCP_NODELAY 和其他一些标志，然后尽可能快地推送随机的胡言乱语。我想，这项服务的客户可能不希望他们的随机字符串以空格结束，所以我很周到地删除了任何可能自然出现的空格。配置错误的 NT 盒子连接后，喝了 5 秒左右的随机数，然后就消失了。5 分钟后，它再次出现、连接、服用缓冲区溢出药剂并再次消失。这样的模式持续了几个星期，直到这个盒子完全从互联网上消失。

    我猜想，当时某个管理员正坐在那里挠头，不明白为什么他的 NT 盒子会不停地重启。

    回复

    1. 对于任何程序员来说，读到这篇文章的教训就是，一定要为从别人那里接受的数据量设置上限。每个请求都应该有超时和消耗数据量的限制。

      回复

      1. 正如一位前任老板常说的 “无限是个坏主意”。

        回复

      2. 这并不一定需要在请求本身中规定。

        你也可以限制你的请求所涉及的更广泛的流程或系统。

        回复

        1. 虽然这是事实，但我还是建议在请求中写明，因为这可以让程序员非常清楚地知道，请求可能会失败，而失败需要以某种方式来处理–即使是杀死并重启进程。

          回复

          1. 我赞成这个观点：根据具体情况，可能会有一种更优雅的方法来处理过长的响应，而不是让进程崩溃。

            回复

            1. 不过 “过多字节 ”限制的问题在于，这往往会在时间流逝后导致中断，而此时无论原来的大小是多少，现在都变得 “很小 ”了，比如在处理图片等时。

              如果带宽受到一定限制，时间限制往往也会事实上限制大小。

              回复

              1. 因为技术发展而故意拒绝为一个用户流提供服务，要比因为系统的某些部分出现问题而意外拒绝为所有人提供服务要好得多。

                超时和大小限制在发现合理需求时进行更新是微不足道的。

                回复

                1. 天哪，我真希望能和你们分享一些故障后的经验。

                  实际上，在某个地方设置任意的大小限制就像在某个关键系统中设置另一个需要更新的 SSLert。它最终会导致你意想不到的故障。

                  会有一个似是而非的人对此负责吗？当然会。现实中，也难免有人会忘记，然后直接撞上。

                  出于各种原因，时间限制往往不存在这个问题。

                  回复

                  1. 但是，如果不设置限制，就会造成缓冲区溢出，从而引发另一种形式的故障，这也会带来安全风险，因为攻击者可以利用这种风险。

                    回复

                    1. 不，只是 OOM。是的，确实需要在某个地方设置一个限制–只是这个限制不能是任意的，而要基于某种处理限制，而且最好能随着内存占用空间的增大而调整。

                  2. > 将另一个需要更新的 SSLert 放在某些关键系统中

                    几年前我找到了一个解决方法：

                     openssl req -x509 -days 36500

                    888/4/Gibbon1

                    回复

          2. 这就是我的一个测试策略。随意将超时设置得太短、缓冲区设置得太小都很容易。用它来制造错误，看看系统会怎么做。它是会打嗝并继续运行，还是会倒下？

            回复

        2. 那么你就会杀死你的服务，而你的服务可能也在为合法用户提供服务。

          回复

          1. 这取决于你如何设置。
            例如，如果你对每个请求都进行分叉，那么该进程就只能为这一个用户提供服务。或者，你是否能以足够快的速度重启。
            我的灵感主要来自 Erlang。

            回复

            1. 每次请求都分叉并不能让服务器变得更快。

              回复

    2. 大约在同一时间，或者更早一些时候，一些公司每周五给我发垃圾传真。我多次礼貌地给他们的办公电话发语音邮件，他们都置之不理，于是我做了一份 100 页的 PDF 文件，每一页都是一个黑色的大矩形，然后用一种新式的电子邮件传真网关发送给他们。不到一个小时，我就接到了一个愤怒的电话。传真停止了。

      回复

      1. 大约在 1997 年，一位同事抱怨说，他注册了某个电子邮件列表，但试图取消订阅却不起作用（我记得更多的是手动操作）。我建议他设置一个 cronjob，每小时运行一次，发送退订请求邮件。它将从一个文本文件中获取退订请求。每次迭代，它都会复制文件中的文本，这实际上是一个几何级数。大约一周后，列表所有者回复了我，非常迫切地要求我的同事把它删除，说要把他从列表中除名。显然，名单所有者一直在度假。

        回复

    3. 我很喜欢读这篇文章，谢谢你的分享。你说你试图联系盒子的管理员，这在当时很常见，那么你一般会如何找到任意客户管理员的联系信息呢？

      回复

      1. 在当时，postmaster@theirdomain 和 webmaster@theirdomain 等信息都是由实际人员读取的。此外，whois 命令也经常起作用。

        回复

        1. 我在瑞士最大的互联网服务提供商之一工作，这些邮箱至今仍被实际存在的人（包括我）读取，因此即使在今天，有时也是值得的。

          回复

          1. 我用 Stalwart 安装了一个新的邮件服务器，并一直收到自动发送到我的邮件管理员地址的邮件（主要是安全处理结果）。
            很不错。

            回复

          2. 我试图联系 Hetzner 和其他人，了解客户扫描我端口的情况。没人关心这个问题。当我不断收到防火墙对开放的 Plex 端口进行端口扫描的警报时，我就有意见了。
            我进入了一个疯狂的兔子洞，发现了一堆域名，它们是街道地址的随机部分。很明显，这些域名是自动创建的，他们故意增加查找相关域名的难度。

            回复

        2. 负责任的域名所有者仍然会阅读它们。我自己的邮件管理员就是我所有域名的总管，这样用户名中的错别字仍然会被发现。事实证明，这对我的家庭域名非常有用，因为忙碌的医务人员会在为我父母设置账户时出错。

          回复

      2. 你还可以找出谁拥有一组普通的 IP 地址，当时他们往往会帮助你进一步确定谁是某个地址的负责人。

        回复

      4. tech-c/滥用地址在 whois 上很常见。

        回复

    4. 切题
      我曾偷懒解决了家里 RPi 服务器上的故障检测问题，它正在 ping 我拥有的一个域，如果它无法 ping 到那个域，就认为它没有连接到网络/重启了自己。我让域名失效了，结果 RPi 在 5 分钟左右一直宕机……我以为是电源故障，后来才想起 CRON 作业。

      回复

      1. 这就是为什么其他人都很懒，直接 ping google.com

        回复

    5. 你一定会惊讶地发现，在那个时代，大多数提供服务的 NT 安装都很少有管理员注意到发生了什么。在 NT 盒子上运行这样的服务是 “为了不需要管理员”，这种情况数以千计，不可低估。
      免责声明：在上世纪 90 年代/2000 年代初，我在互联网上架设了很多服务器。当时整个行业的标准做法是：’使用 NT，所以不需要管理员’。

      回复

      1. 是什么原因导致 NT 不需要管理员？仅仅是市场营销吗？

        回复

    6. 我不明白为什么 WinNT 系统会连接到你的系统。是因为配置错误的 Windows 更新程序吗？

      回复

      1. 我从未发现过这个问题，但有一些功能，NT 会尝试协商加密连接来进行通信，这就是它连接的端口。这是很久以前的事了。有可能盒子已经被破解了，那是僵尸网络的命令/控制之类的。当时很多面向互联网的 Windows 操作系统都是这样，因为当时的 MS 安全性绝对糟糕透顶。

        回复

  2. 当我还是个傻孩子的时候，我曾经做过

     ln -s /dev/zero index.html

    作为一个玩笑。当时的浏览器并不喜欢这样，它们基本上都会死机，有时还会连累客户端系统。

    后来，浏览器开始检查实际内容，我想，它们会放弃这种请求。

    回复

    1. 我曾经制作过一个 64kx64k 的 JPEG 文件，方法是向编码器输入同一行宏块，直到它生成整个图像。

      多年后，我终于可以打开它了。

      回复

      1. 几周前，我在打开一个 10MB 左右的 png 文件时遇到了很多麻烦。它是由一张游戏中某些区域的截图拼接而成的，因此相当大。有的文件根本打不开，好像文件无效一样，有的文件会卡住几分钟，有的文件打开后很模糊。我的第一个半成功案例是手机上的 F-Droid Fossify Gallery。如果我让它运行一会儿，它就会显示模糊的图像，再运行一会儿就会对焦。然后我尝试缩放或平移，它又会模糊很久。我猜它是在偷懒。最后还是 GIMP 起了作用。我想，图像可能是用编辑器制作的，所以编辑器肯定能打开它。问题是，它需要 8GB 的内存，但我可以清楚地看到、缩放和平移我想要的一切。这让我不禁要问，为什么没有一个图像查看器，而只是 GIMP 的查看器部分或其他东西呢？

        无法使用的软件包括 qutebrowser、icecat、nsxiv、feh、imv 和 mpv。一开始我确实担心文件损坏了，因为我重新下载了文件，还和朋友比较了哈希值等等。我想这是一个有趣的基准。

        对于其他好奇的人，文件如下：https://0x0.st/82Ap.png

        我认为只需用 curl/wget 就可以了，不要指望它能在浏览器中加载。

        回复

        1. 这是一个 36,000×20,000 PNG 文件，720 万像素。许多解码器都明确限制了它们能处理的最大图像面积，其合理假设是，这将超出可用 RAM 并耗时过长，并假定该文件是恶意或错误制作的。

          回复

        2. 在安卓系统的火狐浏览器上，在我的老手机上，一个模糊的预览在 10 秒左右就能呈现，20 多秒后就能完全呈现。整个过程中平移和缩放都很流畅

          回复

          1. 三星 S23 Ultra 上的火狐浏览器快了几秒，但其他体验相同

            回复

            1. 在 S24 Ultra 上使用火狐浏览器，从空白加载到图像只需一秒钟，然后可以直接放大，完全没有模糊或卡顿现象！

              回复

        3. 我使用蜜糖视图阅读漫画等。它可以处理这个问题。

          老式的 acdsee 也可以。

          我认为这都是现代图像浏览器的像素处理造成的（或者他们只是在使用并非 100% 直接渲染的系统网页视图）。

          我怀疑原生渲染器在这里做了一些额外的处理。或者只是在耗尽所有内存方面做得更好。

          回复

        4. 在使用 Safari 的 iPhone 12 上，加载时间约为 5 秒。

          平移和缩放也很迅速

          回复

          1. 一样，直到我放大并等待 Safari 生成更高分辨率的渲染。

            部分放大没有问题，但放大到最大保真度时，标签页就会崩溃（崩溃前反应完全正常）。看起来 Safari 进行了一些非常智能的渐进式渲染，但强迫它以全分辨率渲染图像（通过放大）会导致渲染出现 OOMed 或类似情况。

            回复

            1. 我记得几年前（手机）Safari 会积极使用 GPU 图层，如果 GPU 内存不足就会崩溃。也许现在还存在这种情况？

              Mac 上的预览可以很好地处理文件。

              回复

          2. 真奇怪，在我使用 Safari 的 iPhone 12 Pro Max 上加载文件至少需要 30 分钟，但之后平移和缩放都很流畅。这比我那台 16 核 64GB 内存的 Windows 电脑要好得多，在 Windows 电脑上，Chrome 浏览器和 Edge 浏览器都很快就出现了 “损坏的缩略图 ”图标。

            回复

              1. 奇怪的是，同一代的两部 iPhone 会表现出如此不同的性能，同时具有尖端性能的设备上的桌面浏览器（与引擎无关）却不能像手机那样运行，这真是一种讽刺。

                回复

        5. IrfanView 使用 2.8GB 内存在 8 秒左右（Ryzen 7 5800x）内加载，但缩放/平移速度相当慢（每次操作约 500ms）

          回复

          1. 我电脑上的 IrfanView 非常快。放大到 100%，我可以毫无问题地平移。是使用 CPU 还是 GPU？我的 CPU 是 11900K，GPU 是 RTX 3090。

            回复

            1. Irfanview 中有快速和慢速重采样查看选项，他可能打开了慢速选项以获得更高的质量。

              回复

        6. 火狐浏览器在中档三星手机和廉价数据连接（4G）上加载需要大约 30 分钟。我可以平移，但它限制了我的放大，而我能放大的一小部分看起来非常模糊。

          回复

        7. 值得一说的是，我在 Windows 上的 Firefox 中加载（很慢）了这张照片（但缩放很模糊），默认的照片查看器打开它也没有问题，缩放和平移都很流畅。

          回复

        8. 在我的 Waterfox 6.5.6 上，它可以打开，但放大后仍然模糊不清。MS Paint 拒绝打开它。GIMP v2.99.18 崩溃了，还带走了我的显示驱动程序。Windows 10 照片查看器竟然能打开它，并在放大时保持清晰。GIMP v3.0.2（本文撰写时的最新版本）崩溃了。

          回复

        9. 我 MacBook Air 上的 Safari 可以正常打开它，不过花了大约 4 秒钟。缩放工作也很正常。根据 “活动监视器 ”显示，它占用了约 3GB 内存。

          回复

        10. 在 FP5 上使用 fdroid 的 ImgurViewer 打开图片后，大约 5 秒钟后图片就变得模糊不清，5 秒钟后就完全呈现出来了。

          而 Pan&zoom 则是在预览模糊的情况下立即运行，然后再花 5-10 秒钟才能完全渲染。

          回复

        11. > 不要指望它能在浏览器中加载

          需要几秒钟，但在桌面 Safari 中似乎还不错。Preview.app也能很好地处理它（尽管需要分配额外的 ~1-2GB 内存）

          回复

        12. 有趣的是，在我的 Pixel 6a 上加载只需 5 秒左右。

          回复

        13. 在装有 Firefox 137 的 Macbook Pro M3 Pro 上加载正常，速度相当快。刚开始放大时有一点延迟，但之后的平移和缩放都很正常。

          回复

        14. 在我使用了 5 年、配备 A12 处理器的 iPad Pro 上运行正常。

          回复

        15. 包含矢量图层的 PDF 文件（如大面积的平面图或地图）也很难渲染/打开。

          回复

          1. 就在今天，我的同事在看 PDF 格式的空中交通许可证地图，大概有 12MB 左右。他抱怨 Adobe Reader 更改了一些东西，使他无法再平移/缩放。

            我建议他试试 HN 心爱的苏门答腊 PDF。唉，它无法正常处理。Chrome 浏览器处理得更好。

            回复

        16. 在我 1GB 的 iPhone 上加载这个文件大约需要 5 秒钟，而且我可以轻松地平移和缩放。台式机应该能很好地处理它。

          回复

        17. 在 myiPad Pro M1 上加载需要 10-15 秒，不过在我四处查看后，它确实开始重新加载了。

          回复

        18. 在 M1 Air 上的 Safari 中，加载时间约为 10 秒。我想我是被宠坏了。

          回复

        19. Oh hey it’s the thing that ruins an otherwise okay rhythm game.

          回复

        20. I get a Your connection was interrupted on Chrome.

          回复

        21. on mobile Brave just displayed it as the placeholder broken link image but in Firefox it loaded in about 10s

          回复

        24. Safari on iPhone did a good job with it actually lol

          回复

      2. I once encoded an entire TV OP into a multi-megabyte animated cursor (.ani) file.

        Surprisingly, Windows 95 didn’t die trying to load it, but quite a lot of operations in the system took noticeably longer than they normally did.

        回复

    2. I wonder if I could create a 500TB html file with proper headers on a squashfs, an endless <div><div><div>… with no closing tags, and if I could instruct the server to not report file size before download.

      Any ideeas?

      回复

      1. Why use squashfs when you can do the same OP did and serve a compressed version, so that the client is overwhelmed by both the uncompression and the DOM depth:

        yes “<div>”|dd bs=1M count=10240 iflag=fullblock|gzip | pv > zipdiv.gz

        Resulting file is about 15 mib long and uncompresses into a 10 gib monstrosity containing 1789569706 unclosed nested divs

        回复

        1. You can also just use code to endlessly serve up something.

          Also you can reverse many DoD vectors depending on how you are setup and costs. For example reverse Slowloris attack and use up their connections.

          回复

      2. Yes, servers can respond without specifying the size by using chunked encoding. And you can do the rest with a custom web server that just handles request by returning “<div>” in a loop. I have no idea if browsers are vulnerable to such a thing.

        回复

        1. I just tested it via a small python script sending divs at a rate of ~900mb (as measured by curl) and firefox just kills the request after 1-2 gb received (~2 seconds) with an “out of memory” error, while chrome seems to only receive around 1mb/s, uses 1 cpu core 100%, and grows infinitely in memory use. I killed it after 3 mins and consuming ca. 6GB (additionally, on top of the memory it used at startup)

          回复

        2. 我会让它成为主页上的一个隐形链接（隐藏在徽标或其他东西后面）。用户不会点击它，但机器人会。

          回复

          1. 这样做的问题是，对于 tarpit 而言，你不仅要让机器人觉得贵，还要让自己觉得便宜。

            回复

            1. 对，所以隐形链接+拉链炸弹才是大炸弹。

              回复

              1. 也许是，也许不是。这是您可以使用的一种工具。如果您了解压缩炸弹，就很容易防范–问题是，您的目标僵尸开发者有多彻底？

                例如：保持连接打开，每隔几秒才推送几个字节–这对你来说是否便宜取决于你的服务器并发模型（如果每个连接只有一个操作系统线程，那么你就会用这个方法 DOS 自己–但如果是事件模型，你就应该没问题）。如果机器人分析图片或 pdf，你可以尝试利用已知弱点的有毒文件，这些弱点会导致内存损坏，从而使它们崩溃；当然，这取决于机器人的能力和使用的库。

                回复

      1. 看来我应该为我的网络应用程序接口添加一些东西，因为只有了解应用程序接口规范的客户端才能查询这些应用程序接口。

        回复

    4. 我希望你没有按 KiB 支付带宽费用。

      回复

      1. 不，那时我们是按千字节支付带宽费用的。

        回复

    5. 也许是时候安装一个 /dev/zipbomb 设备了。

      回复

      1. ln -s /dev/urandom /dev/zipbomb && echo ‘Boom!

        好吧，不是真正的压缩炸弹，我们需要一个内核模块来实现。

        回复

        1. > 好吧，不是真正的压缩炸弹，为此我们需要一个内核模块。

          或者是一个用户态的 fusefs 程序，实际上是个不错的想法（可配置动态文件名，例如 `mnt/10GiB_zeropattern.zip`…

          回复

        2. 这样会耗费大量带宽，有违压缩炸弹的初衷。

          回复

    6. 等等，你设置了一个符号链接？

      我不知道这怎么可能行得通。除非真正的/dev 树暴露在网络服务器的 chroot 环境中，否则除了 “找不到文件 ”之外，不会有任何特别的提示。

      网络服务器 chroot 的全部意义就在于防止客户端访问类似的特殊文件！

      回复

      1. 你自己也解释了它是如何工作的： 很多网络服务器都是或不是 chroot 的。

        回复

        1. 这就意味着，如果你的机器人因此而受到攻击，你就可以认为它没有被chroot，因此更有可能成为攻击目标。

          回复

          1. 这在逻辑上是不成立的。如果你的机器人被一个返回全为 0 的页面攻击（我回复的那个人就是这种情况），那么你只需要知道服务器上有什么东西正在返回无穷无尽的 0。与 /dev/zero 的符号链接是一种简单的方法，但知道服务器正在提供无休止的零数据流并不能说明服务器是否运行在良好的隔离环境中。

            即使你知道它是通过符号链接完成的，你也不知道–如今它很可能运行在容器或虚拟机中，因此访问/dev/zero的意义不大。

            回复

    7. 服务器端包含的内容能否用于 html 炸弹？

      编写一个普通的静态 html 页面，然后使用 <!–#include file=“/dev/random”–>，用无限的随机数据填充 <p>。

      否则服务器会崩溃吗？

      回复

      1. 我想这取决于服务器的实现。不过，既然你需要一些逻辑来决定何时提供 HTML 炸弹，我不明白为什么你会喜欢这种解决方案。您只需使用您用来检测机器人的脚本来提供炸弹即可。

        回复

        1. 没有其他脚本。将炸弹链接隐藏在图片后面，这样人类就无法点击它了。

          回复

          1. 我首先想到的是这将如何与读屏器和其他无障碍设备进行交互

            回复

            1. 难道屏幕阅读器不会忽略隐形文本/链接吗？

              回复

    8. 每个人最终都会遇到 “化整为零 ”的情况。

      https://medium.com/@bishr_tabbaa/when-smart-ships-divide-by-…

      1997年9月21日，美国海军 “约克城 ”号在弗吉尼亚州查尔斯角海岸进行训练演习时，由于数据库应用程序中的除以零错误，导致整个舰艇控制系统停顿了近3个小时。

      “技术人员试图通过在 SMCS 远程数据库管理器（RDM）中输入燃油阀一个组件属性的 0 值，对燃油阀进行数字校准和重置”。

      回复

    9. 早在 IE3 出台时，我们就发现，如果不使用表格关闭标签，就会导致 Windows 崩溃。

      回复

  3. 如今，几乎所有浏览器都接受 zstd 和 brotli，因此这些炸弹如今可以更加有效！[这个](https://news.ycombinator.com/item?id=23496794) 旧评论显示了令人印象深刻的 1.2M:1 压缩比，[zstd 似乎做得更好](https://github.com/netty/netty/issues/14004)。

    不过，机器人可能不支持现代压缩标准。不过，这也可能是阻止机器人的一个好办法：每个现代浏览器都支持 zstd，因此只需在非白名单浏览器代理上强制使用，就能自动混淆爬虫程序。

    回复

    1. 实际上，我在我的百万复选框 Datastar 演示[1]中就是这么做的（使用压缩来过滤僵尸）。它在很大程度上依赖于在每次交互时对整个用户视图进行流式处理。在 SSE 上使用 brotli，可以轻松达到 200:1 的压缩率[2]。问题是，恶意行为者可能会请求未压缩的流。由于 98% 的浏览器都支持 brotli，因此我不会向不支持 brotli 压缩的客户端推送数据。我还发现很多爬虫程序和机器人都不支持它，所以它的效果还不错。

      [1] 复选框演示 https://checkboxes.andersmurphy.com

      [2] 关于 brotli SSE 的文章 https://andersmurphy.com/2025/04/15/why-you-should-use-brotl…

      回复

    2. 如果将 gzip 嵌套在另一个 gzip 中，压缩后的数据块 “0 ”在第一代 gzip 中本身就是低熵的，因此压缩后的数据块会变得更小。嵌套的 zst 可将 10G 文件压缩到 99 字节。

      回复

      1. 你能手工编辑创建递归文件结构，使其无限大吗？我曾在 dos 中使用 debug，通过编辑胖文件来制作看似巨大的软盘。

        回复

      2. 但机器人很可能只会自动解开外层。所以嵌套对阻止机器人没有帮助。

        回复

      3. 这样一来，攻击不就失败了吗，因为你不再提供大型内容了？

        回复

        1. 这需要一个通过超链接访问文件的僵尸，目的是解压缩文件并浏览其中的内容。压缩文件可以通过压缩响应来传输，以实现双层传输，从而大大减少出站流量。passwd.zst、secrets.docx 等文件看起来会非常多汁。在 robots.txt 中列出的蜜罐目录（暴露于文件访问）中投放一些诱饵，看看谁会上钩。

          回复

    3. 我的浏览器收到这种炸弹后会有什么反应？我不想亲自测试…

      回复

      1. 上次我检查的时候，标签页一直在加载、冻结，分配给渲染标签页的进程会在内存消耗过多时被杀死。这可能会导致弹出 “此标签拖慢了您的浏览器速度 ”的提示，或者导致一般的浏览器运行缓慢，但不会造成灾难性后果。

        标签页进程死亡的严重程度取决于每个浏览器。如果你的浏览器网站隔离做得很好，它只会让一个网站崩溃，你几乎不会注意到。如果该进程是由其他标签页共享的，则可能会丢失状态。Chrome 浏览器应该没问题，Firefox 浏览器可能不行，这取决于你的设置和你打开了多少个标签页，而 Safari 浏览器则取决于标签页是如何打开的以及浏览器是如何配置的。不过 Safari 不支持 zstd，所以你只能用 brotli 炸弹。

        回复

    4. 到处都是 gzip，它会让所有爬虫都乱了阵脚。

      回复

  4. > 在我的老东家，一个机器人发现了一个 wordpress 漏洞，并在我们的服务器中植入了一个恶意脚本。

    我知道这有点跑题，但知道我不是唯一一个在设置了 WordPress 1 小时后，服务器上就神奇地部署了一个 PHP 外壳的人，这实在是太有趣了（编辑：令人欣慰）。

    回复

    1. >为客户接手一个 WordPress 网站

      >看啊，有 3 个独立的 php shell，名字都是随机字符串。

      永远不会少于 3 个，但总是有保证的。

      回复

    2. 是的，如果你珍视自己的理智，就永远不要自己托管 WordPress。即使不是第一个小时，当你忘记打补丁时，它最终还是会发生的。

      回复

      1. 我自己托管 WordPress 已经 13 年了，没有任何问题:) 只需遵循标准的安全惯例，不要安装数以百万计的插件。

        回复

        1. WordPress 缺少很多基本功能，这意味着您必须安装插件。这取决于你需要做什么。

          但是，WordPress 是一个如此糟糕的平台，任何人都没有理由使用 WordPress 来做任何事情。无论你的用途是什么，都会有比 WordPress 更好的替代品。

          回复

          1. 对于非技术性组织，有人需要定期编辑页面和上传文档，因此他们需要一个尽可能友好的用户界面，您能推荐一个替代方案吗？尤其是当他们没有这方面的预算，而你只是帮他们一个忙的时候？为他们安装 WordPress 非常简单，但我也不喜欢。

            在这种情况下，我以前也试过 Drupal，但对他们来说太复杂了。那是几年前的事了，也许现在好多了。

            回复

            1. 我发现这个帖子里没有两个回复是推荐同样的东西，这很能说明问题。这证实了我的观点，即除了 WordPress 之外，没有其他真正的免费开源 CMS 可供非技术专家直接安装和使用来创建和编辑页面。

              回复

              1. 也许那些想推荐与已写评论相同内容的人只是向上投票，而不是写自己的评论？

                回复

              1. > Drupal

                > 新项目

                我敢肯定 Drupal 已经有 20 年左右的历史了。还是说这是另一个 Drupal？

                回复

                1. Drupal 已经存在了一段时间，但直到现在我才听说 “Drupal CMS ”是一个独立的产品。

                  Drupal CMS 似乎是 Drupal 的一个定制版本，对于不太精通技术的人来说更容易上手和运行。至少，这是我在阅读营销炒作时得到的印象，这些营销炒作只用了一些拗口的词语来 “解释 ”它。

                  回复

            3. 我可以。有一个优秀而稳定的解决方案叫 SurrealCMS，是由一个独立开发者制作的。你可以通过 FTP 将其连接到任何传统网页设计（HTML+CSS+JS）上，用户就能获得一个所见即所得的编辑器，发布的输出结果与编辑时一模一样。它的价格非常便宜，每月 9 美元。

              编辑：实际上，我有点同情 SurrealCMS 开发者。他的产品非常出色，本应成为行业标准，但却默默无闻。

              回复

            4. > 你能为非技术性组织推荐一个替代方案吗？如果有人需要定期编辑页面和上传文档，那么他们需要一个尽可能友好的用户界面。

              25 年前，我们使用 Microsoft Frontpage 来做这件事，网络根目录映射到文件共享，非技术秘书可以写入并编辑它，就像文字处理器一样。

              不知怎的，我觉得我们已经从这种简单的方式退步了，除了挥挥手之外，我们什么也做不了。这种方法被宣布为 “过时”，… WordPress的笨办法取而代之，被认为 “更好”。谁能证明我错了。

              回复

              1. 部分原因是 Frontpage 需要 Windows 服务器，而这一切都需要 Windows 服务器。

                另一部分原因是 Frontpage 连续出现一系列危险的 CVE 后，客户们都吓坏了。

                最后，每当 Frontpage 的某个部分流行起来，MS 就会淘汰该 API 并用新的 API 取而代之。

                WordPress 在正确的时间出现在了正确的地点。

                回复

                1. 是啊，让 Frontpage 在 Linux/Apache 系统上运行并为其提供支持在当时并不是一件容易的事。也许想法不错，但实施起来很糟糕。

                  回复

                  1. 我想你搞错了。使用 WebDAV 并不是必要条件。Frontpage 可以在 “HTML 编辑器 ”模式下运行，并直接写入文件系统。在这种情况下，任何 WYSIWYG 编辑器都可以使用，但 FP 是可用的。

                    回复

              2. 我以前的一个工作场所也用 Netscape（后来是 Mozilla）Composer 做了同样的事情。用户可以通过 WebDAV 修改内容。

                回复

              3. 对于使用 macOS 的用户，RapidWeaver 仍然存在：https://www.realmacsoftware.com/rapidweaver/。(可惜现在是订阅软件了–我发誓以前每个主要版本都要直接购买）。

                回复

              4. “使用 Internet Explorer 浏览器在 1024×768 下观看效果最佳

                回复

              1. 是！我已经改用它来进行专业和个人 CMS 工作，它非常棒。在我看来，它非常灵活和简洁。我同时使用有头和无头系统。

                回复

              2. 这个项目的 “许可证 ”很奇怪。除了个人博客外，几乎不允许任何自托管使用。

                而受版权保护的代码的唯一托管选项起价为 300/y。

                这些并不包括人们使用 WordPress 的任何情况。

                回复

                1. 不知道为什么兄弟姐妹被降权到遗忘，许可证可能更容易找到。在这里：https://statamic.com/license

                  回复

              3. 附议。作为一个有头或无头的 CMS，它绝对是个了不起的东西。

                回复

            6. 我们有一个（仅限内部访问）WP 实例，使用插件将内容导出为 ZIP 文件，然后使用脚本/Ansible 将其部署到 NGINX 服务器上。

              可以更好地实现自动化（将 ZIP 文件放到某个共享位置，然后在那里进行处理和部署），但两全其美。

              回复

                1. 问得好–我自己没有设置，但我认为没有什么太隐晦的东西

                  回复

            7. 在这方面，我使用 Decap 遇到了一些麻烦。在最初的开发设置中，几乎不需要公关团队的支持。

              [0] https://decapcms.org/

              回复

            8. 我们正在开发 https://bluocms.com/

              – 很难入侵，因为我们预先将所有资产渲染到 Cloudflare kv 存储器中

              – 公共网站和 CMS 编辑器位于不同的域上

              基本上很难被黑。此外，由于只有 Cloudflare 出现故障时，网站才会宕机，因此更加可靠。

              回复

            9. 你需要建立自己的前端，但 PayloadCMS 是我的首选。

              回复

              1. Jekyll 和其他静态网站生成器不会像记事本一样将 WordPress 复制到 MSWord 中。

                在一个用户界面中，多个用户可以登录、编辑所见即所得、预览、添加图片等。您可以从任何浏览器（包括智能手机和平板电脑）访问它。

                而在另一个系统中，你需要指导用户如何使用 git、如何处理合并冲突、如何审查代码（两个人不能像在 wordpress 中那样轻松地处理一个帖子），预览需要手动构建，你需要本地签出和本地构建安装来完成构建。没有所见即所得（WYSIWYG），添加图片需要手动复制文件、确定 URL 等。不支持智能手机/平板电脑等….。

                我把我的博客从 wordpress 安装换成了静态网站基因器，因为我厌倦了不断更新博客，但我的发帖量却减少了，因为发帖的摩擦大大增加了。我再也不能用手机发布信息了。我无法轻松添加图片。我不得不构建预览。还得通过 git 提交和推送来提交。所有这些都意味着原本简单的工作变得繁琐。

                回复

                1. 你检查过静态网站 CMS 吗？

                  例如（与他们无关）https://www.siteleaf.com/

                  回复

                2. 您最喜欢的静态网站生成器是什么？我用谷歌搜索了一下，cloudflare 的文章中出现了 Jekyll、Gatsby、Hugo、Next.js 和 Eleventy。但如果能帮助我了解每种生成器的优缺点，我就不用再做研究了。

                  回复

                  1. 我最近在考虑创建一些新的共享博客时看了看。我的标准是 “基于我所了解的技术”。我不懂 Ruby，所以 Jekyll 被排除在外。我尝试了 Eleventy 和 Hexo。我选择了 Hexo，但最终决定不做这个新博客。

                    我记得，Eleventy 在我安装时打印了很多过期警告，而且/或者默认样式有各种问题，这让我很没信心。

                    我妹妹让我帮她建一个博客。我只是指给她看了一下 substack。不费吹灰之力，对她来说轻而易举。

                    回复

                    1. 我用 Ruby 工作，但我从来没有用 Ruby 来使用 Jekyll。我下载了 docker 镜像并运行它。它会检查主机目录是否有更新，并生成 HTML 文件。它可以用我不知道的任何其他语言编写。

                  2. 我对其他 SSG 没有太多经验，但我的个人网站使用 Eleventy 已经有好几年了，我是它的忠实粉丝。它上手非常简单，构建速度快，功能强大且灵活。

                    我使用 GitHub Actions 构建我的网站，并将其免费托管在 Pages 上。

                    回复

                  3. Jekyll 和 GitHub 页面配合得很好。

                    回复

                  4. 我非常欣赏 Astro.js，它上手非常简单，对我来说相当直观，而且功能非常强大。

                    回复

              2. 像 citydesk 这样的软件没能发展成为多用户应用软件而夭折，实在令人惋惜。

                回复

          2. 尽管 HN 用户经常认为 HN 上的书呆子水平在现实世界中也很常见，但他们的看法却完全一致。WP 并不坏，只是你做错了，而且在成百上千的使用案例中，确实没有更好的替代方案。

            回复

            1. 我的观点是，WordPress 对大多数现实世界的用户来说太复杂、太书呆子气了。他们通常更倾向于使用为其使用案例量身定制的解决方案。这样的解决方案有很多。即使是博客，对于非技术用户来说，也有比 WordPress 更好的解决方案。

              回复

              1. 完全不同意！如果你不是技术人员：wordpress.com – 选择网站名称、创建账户、制作网站。然后，如果你想发展，可以付费购买域名、自定义插件、主题和商店。如果你真的想发展，那么你可以把你的数据拿出来，建立自己的（或花钱请人建立）wordpress.org 实例。在托管、主题等方面有成千上万种选择。

                而且：与 Wix、Squarespace 等其他构建工具相比，你不会被锁定。如果你在 wordpress.com 或 wordpress.org 上制作了一个东西，但又想退出，你只需以通用的 XML 格式导出你的东西。而商业软件则没有这些功能。

                因此，无论 HN 如何憎恨它，它仍然是非技术人员在网络上发布内容的最佳平台。

                回复

          3. 我是做定制网站开发的，所以不懂网站托管。如果我想帮助一个稍微懂点技术的人建立一个网站，现在有什么好的框架？不是带有 API 的全反应 SPA。

            回复

            1. 听你的问题，我猜你是想为中小型机构制作网站？

              如果他们要在自己的网站上销售任何东西，很可能是通过云托管的第三方服务，然后只是在他们的网站上嵌入一个 iframe。

              如果你要为一家大型企业或类似规模的企业制作整个网络商店，那你就得问别人而不是我了。

              回复

              1. 现在还有人在使用jQuery吗？

                在过去的五年里，我所做的一切几乎都是纯 ES6，再加上一些辅助工具，比如 jsviews。

                回复

                2. 当然，为什么不呢？它既轻便又好用，而且你可以在网上找到很多已经为你做好的解决方案。

                  回复

                1. jQuery代码更加简洁易懂，而且网上有大量针对jQuery编写的解决方案，几乎可以满足你的任何需求。

                  回复

          4. 您可以将 WordPress 用作静态网站生成器：https://simplystatic.com/。

            然后，WordPress 就是你的私人 CMS/UI，用于进行修改，它生成的静态文件会上载到 CloudFlare Pages、GitHub Pages 等 webhost。

            回复

            1. 我已经很久没有试过了，但它从未像他们宣称的那样简单。

              现在该插件变成了一种服务，这时你可能只需使用 WP 主机，让他们做他们的事情。

              回复

              1. 是的，没错。还有其他更好的选择，比如 https://wordpress.org/plugins/staatic/。

                我认为从你的网站生成静态目录的爬虫可能是最好的方法，因为它可以覆盖任何网站。如果能提前声明所有路径，效果会更好。

                回复

        2. 我有更重要的事情要做，所以我很乐意花钱让别人帮我托管。

          回复

      2. 我想你的意思是，如果你珍惜你的理智，就永远不要使用那些垃圾。

        回复

      3. 我曾经在美国一个州政府机构工作过，我的同事是我们基于 WordPress 的门户网站的主要管理员，要保持正常工作，工作量实在太大了。

        回复

      4. 同理，自助托管 WordPress 在标准托管方式下也能正常运行，而且不会安装大量的随机插件。

        回复

    3. 我从未托管过 WP，但只要你的 HTTP 服务器接入互联网，就会收到 /wp-login 等请求。这也是发现机器人的好方法。如果我看到一个 IP 请求来自流行的 CMS，就会跳转到 iptables 孔中

      回复

      1. 嘿，我有时会检查 /wp-admin，当我看到一个网站时，它有一种特定的感觉

        回复

      2. 我也是这么做的。这是过滤安全扫描仪的好方法。

        回复

    4. WordPress 确实是一个不错的后门，它甚至内置了内容管理系统功能。

      回复

    5. >1小时后

      我曾用它教过开发人员，这里部署了你的第一个 hello world nginx 服务器……日志中那些奇怪的请求是什么？

      回复

    6. 有一些方法可以防止这种情况–通过权限冻结更新后的所有代码–不允许大部分目录可写–不允许上传文件，或将上传文件限制为媒体文件。

      有一些插件可以做到这一点，但普通的 WP 是很危险的。

      回复

  5. 我在使用 ssh 时也曾这样做过，我想出了如何让试图猜测 root 密码的 ssh 客户端崩溃。我的麻烦是被许多脚本小鬼给我可怜的小服务器灌了药。我转而只识别那些明显想干坏事的 “坏人”，并用防火墙规则禁止他们的 IP。不过，随着 IPV6 的出现，这变得更具挑战性。

    编辑：对于自己编写网页的人来说，你可以在网页上创建一些不为人类显示的链接（白底白字，悬停/点击锚点时没有高亮显示）。机器人会下载这些东西看一看（爬虫和人工智能搜刮器也会下载）。

    回复

    1. > 你总是可以在网页上创建一些不为人类显示的 zip 炸弹链接。

      我在我的 fediverse 服务器上申请账户的表单中就使用了这种方法。我遇到的问题是，有一些非常不成熟的机器人会抓取网页，并将它们非常不成熟的垃圾邮件提交到它们看到的每一个表单中，而这些表单看起来可能会在某个地方发布。

      首先，我添加了一个带有扭曲字符的简单验证码。这确实阻止了许多机器人，但不是全部。然后，在阅读了服务器日志后，我注意到它们只连续快速发出三个请求：包含表单的页面、验证码图片，然后是包含表单数据的 POST 请求。它们既不加载 CSS，也不加载 JS。

      因此，我又在表单中添加了几个字段，并用 CSS 隐藏了它们。在这些字段中提交任何内容都会导致请求失败，并禁止你的会话。我还修改了验证码，让图片本身成为 CSS 背景，并让 src 指向透明图片。

      就这样，垃圾邮件完全停止了，而真正的用户却什么也没发现。

      回复

      1. 我也做了同样的事情。我在一个表单中输入了这样的内容：

            <label for="gb-email" class="nah" aria-hidden="true">Email:</label>
    <input id="gb-email"
           name="email"
           size="40"
           class="nah"
           tabindex="-1"
           aria-hidden="true"
           autocomplete="off"
    >

        With this CSS:

            .nah {
      opacity: 0;
      position: absolute;
      top: 0;
      left: 0;
      height: 0;
      width: 0;
      z-index: -1;
    }

        任何设置了电子邮件值的表单提交都会被阻止。它能 100% 阻止我收到的垃圾邮件。

        回复

        1. 如果禁用了 CSS 或使用未实现 CSS 的浏览器，这可能也是一个问题。(禁用 CSS 的模式最好也能处理 ARIA 属性（除非用户也禁用了这些属性），但并不是所有的实现都能做到这一点（实际上，我不知道是否有实现能做到这一点；我的浏览器似乎做不到），尤其是在 ARIA 属性发明之前编写的浏览器。）

          回复

        2. 这是否也会阻止启用了自动填写表格功能的用户？

          回复

          1. 不会，“autocomplete=”off“”可以解决这个问题

            回复

      2. 我们习惯直接调用这些蜜罐字段。效果非常好。

        回复

      4. 除了盲人用户，他们现在也完全无法在你们的网站上使用屏幕阅读器了

        回复

        1. aria-hidden=“true” 应该可以解决这个问题。

          回复

    3. > 您总是可以在网页上创建不为人类显示的 zip 炸弹链接（白底白字，悬停/点击锚点时没有高亮）。

      RIP 屏幕阅读器用户？

      回复

      1. “ria-hidden “可以让这些用户幸免于难，而且可能会被机器人忽略，除非它们很复杂。

        回复

    4. 为什么使用 IPv6 设置防火墙更难？我觉得这似乎是两种防火墙中最容易的一种。

      回复

      1. 手动封禁的难度差不多，因为你只需预订 /56 或更大的服务器、整个提供商或国家。

        自动封禁比较困难，你可能需要一个启发式系统和查找 IP 信息。

        带有 NAT 的 IPv4 也意味着可以 “过度封禁”。

        回复

        1. 为什么像 fail2ban 这样的系统不能在这里工作？它就是为此而生的，而且已经存在了很长时间。

          回复

          1. 有趣的是，fail2ban 存在 RCE 漏洞。所以你不运行它更安全，现在它应该被修复了，但你能确定吗？

            回复

          2. 在 Linux 中，80/443 并不总是防火墙 🙁

            回复

      2. 我认为他们是在暗示要阻止的 IP 范围太大？

        回复

          1. 在全面封堵之前，您可能需要检查提供商公布了多少个 IP/封堵。

            在开放式防火墙中，这也不是一个可以过滤的常用指标，因为您必须查找并维护 IP 到 ASN 的缓存，而缓存必须随着块的移动而被删除和更新。

            回复

      3. 也许因为获取新的 IPv6 地址比 IPv4 更容易，所以更容易规避？

        回复

    5. 对于使用文本浏览器、（也许）屏幕阅读器、列出页面链接的书签等的人来说，这些链接确实会显示出来。

      回复

      1. 奇怪的是，文本浏览器会忽略隐藏元素的所有属性。我知道它们不关心样式，但即使是普通的 hidden 属性或 aria-hidden 也会被忽略。

        回复

      2. 没错，但你可以将链接文本设置为 “请勿点击 ”或 “不是真正的链接”，让它们知道。我不确定爬虫是否已经开始使用 LLM 来检查页面，这将是一个问题。

        回复

    6. > 我在使用 ssh 时也遇到过这种情况，我想出了如何让试图猜测 root 密码的 ssh 客户端崩溃的方法。结果，我的服务器被许多脚本小鬼 “嗑药 ”了。

      这也是我还没有在网站上安装压缩炸弹的主要原因 — 万一我惹怒了别人，最终不得不抵御 DDoS 的攻击。

      目前，我有一些 URL 模式，会返回没有内容的 418，以节省网络/处理时间（因为如果真正的用户合法地遇到 404，我希望有一个漂亮的网页给他们看）。

      也许应该想办法把它接入 fail2ban 或其他系统，但目前还不是当务之急。

      回复

    7. Cloudflare 等自动化系统也有僵尸 IP 列表。我最近在建立一个自托管的 VPN，我不得不把服务器的 IPv4 改了 20 多次，才得到一个没有被半数网站禁用的 IP。

      回复

    8. 我只是禁止了大片的 IP。禁用亚洲和中东的大部分地区后，不良流量减少了大约 98%。

      回复

      1. 一样，使用 ipsets 和 systemd {service,timer} 更新列表。

        回复

    9. fail2ban 可自动完成更新，而且在软件包管理器中也有提供

      回复

  6. Zip 炸弹很有趣。有一次，我在一款安全产品中发现了一个漏洞，如果文件是或包含的压缩包超过一定大小，该产品就无法正确扫描文件是否含有恶意软件。

    这样做的实际效果是，你可以在 office xml 文档中放置一个 zip 炸弹，而这个产品会通过 ooxml 文件，即使它包含了很容易识别的恶意软件。

    回复

    1. 我有个消息要告诉你。

      文件大小问题仍然是许多大牌 EDR 的问题。

      回复

      1. 毫无疑问。如果你去打探大多数安全产品（我指的产品不属于 EDR 领域），你会发现到处都存在这类问题。

        回复

        1. 必须这样。

          扫描它们需要耗费大量资源。选择有：（1）跳过扫描；（2）将其视为恶意软件；（3）扫描后被 DoS。

          (把决定权交给人类，实际上就是对 IT 支持团队的 DoS’ed）。

          回复

          1. 方案 4：检测压缩形式的 zip 炸弹，跳过文件的这一部分。就像恶意软件忽略压缩炸弹一样。

            回复

            1. 只要包含压缩炸弹这一事实本身就会使其成为恶意软件。

              回复

          2. 不一定非要这样。安全厂商可以在产品测试和红队方面做得更好，以避免绕过，并提供更合理的默认设置。

            回复

  7. 我部署了这个，而不是我常用的蜜罐脚本。

    效果不是很好。

    在网络服务器日志中，我可以看到机器人并没有下载整整 10 兆字节的毒药。

    它们在不同的长度上截断了下载。到目前为止，我还没有看到任何机器人下载超过 1.5 Mb 的内容。

    还是它们在工作？它们是在以流的形式进行解码，然后崩溃吗？例如，如果有记录显示读取了 1.5 Mb 的内容，那么它是否在 RAM 中将其解码为 1.5 Gb，然后就崩溃了？

    我们无从得知。

    回复

    1. 试试内容迷宫。也就是说，无限生成的内容中包含大量对其他生成页面的引用。这可能有助于对付简单的 wget，直到机器人适应。

      附注：我是站在机器人一边的，但不介意帮忙。

      回复

      1. 不过，如果你为服务器支付带宽和 CPU 使用费，这个方法就不起作用了。

        回复

        1. 迷宫不一定要快，像 iocaine（https://iocaine.madhouse-project.org/）这样的东西，如果你不给它们输入像《阿克斯皮亚全集》这样的东西（我的用的是《白鲸》），就不会占用很多 CPU，如果你担心资源占用，可以很容易地用 cgroups 进行限制。

          我注意到，大语言模型(LLM) 抓取程序往往非常耐心。即使是少量的文本，它们也会等上几分钟。

          回复

        2. 这将是你的贡献。如果其他人也加入进来，搜索将变得非常昂贵。直到机器人变得更聪明。但到那时，它们就不会下载太多生成的垃圾了。这样对你来说就更便宜了。

          总之，从机器人的角度来看，迷宫并不是主要问题。互联网上充斥着大语言模型(LLM)生成的高质量内容。

          回复

      2. 这不会浪费你自己的带宽/资源吗？

        回复

      3. 我有点怀疑是否可以用 “内容迷宫 ”来影响机器人的想法/态度–用支持/反对共产主义、资本主义或任何你想做的事情的内容来填充迷宫，希望它能让生成的大语言模型(LLM)倾向于你的想法。

        回复

    2. 也许需要半随机化文件大小？我猜有些机器人对下载资源的大小有硬性限制。

      其中很多都是恼人的大语言模型(LLM)训练/抓取机器人（反正就我而言）。因此，虽然你吐出一个 800KB 的压缩炸弹可能不会让它们崩溃，但至少会浪费它们端的计算资源。

      回复

    3. 它们会反击吗？如果是，那么它们会检测到并避开。如果没有，那么它们就崩溃了，任务完成。

      回复

      1. 目前，如果不修改一下配置，我是无法判断的，因为一旦某个 IP 地址被记录为访问过陷阱 URL（蜜罐或 zipbomb 或其他），日志监控脚本就会禁止该客户端。

        其次，我知道这些机器人大多不会再回来。这些攻击不会重复使用针对同一服务器的地址，以规避几乎所有基于先前访问的过滤规则。

        回复

        1. 我可能问了一个非常愚蠢的问题，但是

          > 一旦某个 IP 地址被记录为访问过陷阱 URL（蜜罐、zipbomb 或其他），日志监控脚本就会禁止该客户端。

          这是不是他们得不到完整文件的原因？

          回复

          1. 我相信 Apache 会记录完整的请求。例如，在客户端被发送到蜜罐的情况下，当我从进程列表中选择蜜罐脚本并将其杀死时，就会看到日志条目出现。这可能是客户端连接数小时后的事情。记录的时间戳是连接时间，而不是完成时间。例如，这里有一对连续的日志：

            [124.243.178.242 – – [29/Apr/2025:00:16:52 -0700] “GET /cgit/[…]

            94.74.94.113 – – [29/Apr/2025:00:07:01 -0700] “GET /honeypot/[…］

            请注意第二个时间戳几乎提前了十分钟。

            回复

  8. 值得注意的是，这是一个 gzip 炸弹（就像一个普通的压缩网页），而不是一个使用嵌套压缩来击溃反病毒软件的经典压缩文件。

    回复

  10. 我通过创建固定大小的临时磁盘分区（每个分区约 10MB）来保护我的一个应用程序的上传，如果有人上传了过大的内容，解压到这些分区就会产生后果。

    回复

      1. 无法处理多文件 ZIP 压缩包。在你认为可以拒绝用户上传多文件 ZIP 压缩包之前，请记住 macOS ZIP 文件包含带有 ._ 文件的 __MACOSX 文件夹。

        回复

    2. 你把磁盘分区了，而不是不解压某个大得离谱的文件？

      回复

      1. https://github.com/uint128-t/ZIPBOMB

         2048 yottabyte 压缩炸弹
  这个压缩炸弹利用文件重叠和递归实现了 7 层，每层 256 个文件，最后一层是一个 32GB 的文件。
  它在磁盘上只有 266 KB。

        当你意识到这是一个压缩炸弹时，为时已晚。只看文件大小并不会泄露文件内容。也许可以用 ClamAV 应用一些启发式方法？但即使这样也不能保证。我认为用一个小分区来隔离解压缩实际上是非常明智的。不知道我们是否能用覆盖层实现同样的效果。

        回复

        1. 你在说什么？你得到一个压缩文件。你开始解压缩。当你写入的字节数超过某个阈值（比如 5 兆）时，就停止解压，丢弃目前的输出并删除原始文件。就是这样。

          回复

          1. 我曾在一家商业 HTTP 代理公司工作，该公司负责扫描压缩文件。那时，我们会开始解压文件，但会跟踪压缩率。我忘了截止值是多少，但只要我们看到压缩率超过某个阈值，我们就会将该文件标记为恶意文件并阻止它。

            回复

          2. 假设他们使用的是流解压库，并手动输入流。将接收到的文件写入 $TMP 并运行外部工具（或使用 sendfile()）的解决方案没有在 N 个解压缩字节后终止的选项。

            回复

            1. > 将接收的文件写入 $TMP 并直接运行外部工具（或使用 sendfile()）的解决方案没有在 N 个解压缩字节后终止的选项。

              带有硬限制的 cgroups 会让外部工具的进程崩溃，而不会导致脚本或系统崩溃。

              回复

              1. > 带硬限制的 cgroups

                这与分区的概念完全相同。

                回复

            2. > 假设他们使用流解压库，并手动输入流。将接收到的文件写入 $TMP 并运行外部工具（或使用 sendfile()）的解决方案无法选择在 N 个解压缩字节后终止。

              从实际意义上讲，这与创建 N 字节分区并让操作系统返回 ENOSPC 有什么区别？

              回复

          3. 根据语言/库的不同，这可能并不总是可行的。例如，python 的 zip 库只提供了一个提取函数，却没有办法连接到解压缩过程，也没有限制可以写出多少。当然，你也可以 fork 这个库，自己添加检查功能，但从可维护性的角度来看，使用分区解决方案可能更省事。

            回复

            1. 它还为 zip 文件中的文件提供了一个打开函数。我看不出这样的东西有什么理由不会在一个小的限制后跳出：

                  import zipfile
    with zipfile.ZipFile("zipbomb.zip") as zip:
        for name in zip.namelist():
            print("working on " + name)
            left = 1000000
            with open("dest_" + name, "wb") as fdest, zip.open(name) as fsrc:
                while True:
                    block = fsrc.read(1000)
                    if len(block) == 0:
                        break
                    fdest.write(block)
                    left -= len(block)
                    if left <= 0:
                        print("too much data!")
                        break
              回复

          4. 这正是 OP 正在做的事情，他们只是在操作系统/文件系统层面实现了这一点。

            回复

          5. 这些文件的设计目的是在进行此类检查之前就耗尽系统资源。我对压缩算法的来龙去脉并不特别熟悉，但我直觉上并不奇怪一个经过精心设计的压缩文件会在进行任何检查之前就耗尽内存和 CPU。也许有更多经验的人可以提供模式细节。

            不过我相信，如果真的这么简单，我们甚至都不会给它起个名字。

            回复

            1. 不是这样的。真的很简单。它只是字典解压缩，只是在某个极限时停止解压缩。

              只是通常没人会在解压缩过程中实施限制，因为人们通常不会给你压缩炸弹。而且有时你确实想解压巨大的文件，所以默认情况下并没有内置限制。

              你所使用的语言可能不容易做到这一点，但你应该总能用文件流来做一些事情。这只是一个额外的步骤而已。

              回复

              1. 老实说，我还以为更难呢。开发人员仍然有责任以预期的方式使用工具，这样应用程序就不会受到攻击，所以在实现需要解压用户提供的压缩包的功能时，需要牢记这一点。

                回复

            2. > 对我来说，有一个经过精心制作的压缩包，在进行任何检查之前，内存和 CPU 就会被耗尽，这在直觉上并不奇怪。

              我直觉上觉得非常奇怪！

              甚至忽略了压缩包的工作原理： 内存需要分块分配。因此，在分配内存块之前，你可以检查新内存的使用是否会超过阈值。CPU 是由你控制的程序指令使用的，所以你可以在程序中的重要节点进行检查，看看是否达到阈值。或者，你也可以在一定时间后杀死一个线程。

              不过，ZIP 的工作方式要简单得多： 从根本上说，它就是 “输出 X 个原始字节，然后从 Z 位置重复输出 Y 个字节”。如果这些数字太大，就中止。

              回复

          6. 这基本上不就是一个关于停止问题的问题吗？你选择的任意截止值可能并不适用于所有人。

            回复

            1. 不，压缩格式不是图灵完备的。你可以控制解释压缩流、分配内存、写入输出等的代码，这些都是基于它在压缩流中看到的内容，你只需选择在写入 N 字节后返回错误即可。

              回复

              1. 是的，即使它们是图灵完备的，你也可以在退出之前只运行你的图灵机等价物 N 步。

                回复

            2. 其实不然。写入的未压缩字节或文件超过一定数量后很容易中止。问题是处理这些文件的典型软件并没有实施限制来防止这种情况。

              回复

      2. 在我看来，这是一个简单的好策略。不需要真正的分区；Linux 上的 tmpfs 很便宜。也许 OP 使用的工具不便于跟踪未压缩字节的数量。

        回复

      3. 是的，我宁愿处理一个简单的磁盘空间不足错误，也不愿意 “安全地 ”解压缩一个潜在的压缩炸弹。

        另外，在解压缩之前，压缩炸弹的体积并不会大得离谱。

        你也可以直接解压任何压缩文件格式，而不用考虑是否安全。

        回复

        1. 我会在/papers子目录下添加一个robots.txt文件来 “禁止 ”它。添加一些带有假 “论文 ”链接的 index.html，一周后，这些爬虫就会疯狂地将你列入黑名单。

          回复

  11. 我使用多年来拼凑的脚本做了类似的事情。我每年都会检查一次 404 日志，然后将试图利用某些东西（如古老的 phpmyadmin 漏洞）的最常用路径添加到黑名单中。请求其中 3 个 URL 会将该主机添加到一个灰名单中，该名单只接受对非常有限的合法路径的请求。

    回复

  12. ssh 服务器也有类似的功能，称为 endlessh (https://github.com/skeeto/endlessh)。在 ssh 协议中，客户端首次连接时必须等待服务器发送一个横幅，但横幅的大小没有限制！因此，这个程序会非常……非常慢地发送一个无限大的横幅，并使爬虫/脚本小程序无限期地挂起、或直接崩溃。

    回复

  14. 同样，对于凯迪拉克：https://www.dustri.org/b/serving-a-gzip-bomb-with-caddy.html

    不过 10T 可能有点过了。

    回复

    1. 搞笑的是，作者和 OP 的作者都在压缩 `/dev/null`。虽然他们意识到这 “既不占用磁盘空间，也不占用内存”，但我觉得他们并没有意识到这一点。

      想想吧：

        $ dd if=/dev/zero bs=1 count=10M | gzip -9 > 10M.gzip
  $ ls -sh 10M.gzip 
  12K 10M.gzip

      除此之外，为什么要使用 gzip 呢？我不会设置 Content-Length 标头，而是扼杀连接，并将 MIME 类型设置为随机类型，比如八进制流，然后重定向到”/dev/random”。

      我不明白 “压缩炸弹 “的概念，你所做的只是压缩 0。为什么不压缩”/dev/random”？你会得到一个大得多的文件，如果机器人接收到它，它就会有更多的 CPU 周期来处理它。

      就连 OP 文章也说，创建 “10GB.gzip “后，”本例中生成的文件为 10MB”。

      是因为听起来很大吗？

      下面是如何避免在 “压缩炸弹 “上浪费时间的方法：

        $ time dd if=/dev/zero bs=1 count=10M | gzip -9 > 10M.gzip
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 9.46271 s, 1.1 MB/s
  real    0m9.467s
  user    0m2.417s
  sys     0m14.887s
  $ ls -sh 10M.gzip 
  12K 10M.gzip
  $ time dd if=/dev/random bs=1 count=10M | gzip -9 > 10M.gzip
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 12.5784 s, 834 kB/s
  real    0m12.584s
  user    0m3.190s
  sys     0m18.021s
  $ ls -sh 10M.gzip 
  11M 10M.gzip
      回复

      1. 问题的关键在于发送方的成本要低（即体积小），而接收方的成本要高（即体积大）。

        压缩率是关键所在……如果你能以几乎不花钱的方式发送小文件，导致接收方因内存、存储、计算等限制而崩溃，那你就赢了。

        回复

      2. 不，这不是通过网络发送大文件的问题，而是读取内容的脚本的 RAM 饱和的问题。如果脚本足够天真，一个压缩炸弹就够了。以我的电脑为例，这样的代码段会导致操作系统关闭 python 进程：

            >>> from requests import get
    >>> r = get("https://acme.tld/trap/")
    >>> r.text

        服务器不会做什么（提供的字节数相对较少），而客户端基本上会崩溃。

        回复

  15. 顺便提一句，有很多人在为相对较小的网站/应用程序建立大规模的微服务实现¹，他们需要把这部分打印出来，包在砖头上，然后扔到他们的头上：

    > 优化良好的轻量级设置胜过昂贵的基础设施。只要有适当的缓存，月租 6 美元的服务器就能承受数以万计的点击量，根本不需要 Kubernetes。

    —-

    [1] 当然，为了玩/学习/练习而这样做也是可以理解的。

    回复

  16. 在伪代码中，IsMalicious() 做了一些真正繁重的工作。希望能看到更多的代码。

    回复

    1. 它可能在监视与 robots.txt 中列出的不应该被抓取的文件的连接等。一旦客户端试图做这件事（它被告知不能这样做），就会被标记为恶意，并被发送压缩文件。

      回复

    2. 长话短说，我使用 memcached 跟踪 ips、用户代理和 POST 方法的使用情况。每分钟的请求次数、请求有效载荷和过去的行为都会让 isMalicious() 返回 true。

      回复

    3. 我知道我以前上过这个名单。上天保佑，我没有安装 Chrome 浏览器，也没有及时更新，真为我感到羞愧！

      回复

  17. 我很好奇，为什么一个 10GB 的全零文件只能压缩到 10MB。我是说理论上你可以把它压缩到一个字节。我想压缩是在数据流上进行的，而不是对整体进行分析，但我想它还是会比 10MB 好。

    回复

    1. 一个只有一个字节长的压缩文件最多只能代表 256 个不同的未压缩文件。

      有一个 90 年代的孩子从 BBS 上下载了一个 “小波压缩 ”程序，因为这个程序承诺可以把他所有的 WaReZ 压缩得更大，这样他就可以在磁盘上装更多的文件了。他运行了压缩器，天哪，500MB 的 ISO 现在只能装进 10MB 的磁盘了！后来他发现（经过一次磁盘碎片整理），“压缩器 ”只是将数据隐藏在未使用的磁盘扇区中，并存储对这些扇区的引用。后来，他从 comp.compression.research 了解到香农熵，才恍然大悟。

      回复

      1. > 他后来发现（经过一次磁盘碎片整理），“压缩器 ”只是将数据隐藏在未使用的磁盘扇区中，并存储对它们的引用。

        所以，在向磁盘写入更多数据之前，你可以访问这些文件？

        回复

        1. 奇怪的是，这种方法实际上对大多数人都非常有效，因为大多数人并没有因此而占用硬盘空间。

          回复

      3. 老兄，你的评论勾起了我的回忆。

        回复

    2. 它必须满足任何可能的输入。即使是对大量运行相同值的这种特殊情况（一般不常见）进行特殊处理：压缩数据可能会以某种方式打包，而每个数据包只能重复这么多次，所以你需要重复每个数据包足够多的次数来重现输出。10 GB 的数据量会非常大。

      我在自己的电脑上用其他几个工具试了一下，按照文章中的方法创建了一个满是 0 的文件。

      gzip -9 在大约 1 分钟内将文件压缩为 10,436,266 字节。

      xz -9 在大约 4 分钟内将文件压缩为 1,568,052 字节。

      bzip2 -9 能在大约 5 分钟内将文件压缩成 7,506 （！）字节。

      我认为 OP 应该考虑使用 bzip2。2 TB 字节的 0 应该可以很好地压缩。而且我的笔记本电脑早就该升级了……你可能不用等很久就能在现代电脑上看到结果。

      回复

      1. 本主题之所以围绕 gzip（和 brotli / zstd）展开讨论，是因为这些都是 HTTP 客户端通常支持的标准压缩方案（RFC 1952、7932 和 8478）。

        据我所知，zstd 的最大放大倍数是 32768 倍：根据标准，最大解压缩块大小是 128KiB，最小压缩块是一个 3 字节的头和一个 1 字节的块（如运行长度编码）。事实上，压缩一个 1GB 的零文件可以得到 32.9KB 的输出，这与理论上的最大值非常接近。

        Brotli 承诺允许解压高达 16 MiB 的数据块，因此实际上可以超过 bzip2 在特定输入上提供的压缩率。用 `brotli -9` 压缩同样的 1 GiB 文件，输出结果是 809 字节。如果我选择 16GB 的文件（dd if=/dev/zero of=/dev/stdout bs=4M count=4096 | brotli -9 -o zeroes.br），相应的输出为 12929 字节，压缩率约为 130 万；理论上这应该可以再扩展 2 倍，但实际情况是否如此就另当别论了。

        (brotli 的最佳压缩率应该是 -q 11，这是默认设置，但与 `brotli -9` 相比，压缩速度要慢得多。我还没有精确计算出 brotli 的理论压缩率上限是多少，但大概在 130 万到 280 万之间）。

        另外要注意的是，zstd 的速度可以提供非常好的压缩比，因此在实际应用中，大多数情况下都可以从使用 zstd 中获益。

        回复

        1. 这一点很好，谢谢–我是从客户端下载文件然后试图检查它的角度来考虑这个问题的，当然，你最好在管道的早期阶段就把它们搞得一团糟。

          回复

    3. 我明白你的意思（也不知道为什么没有压缩得更多），但 1 字节的理论值正确吗？只有一个字节，它怎么知道解压缩后的文件应该有多大？

      回复

      1. 一般来说，这个理论问题被称为字符串的柯尔莫哥洛夫复杂度：对于某种定义的 “程序”，例如给定通用图灵机的初始输入磁带，输出输入字符串的最小程序的大小。遗憾的是，由于存在停止问题，一般来说，科尔莫哥洛夫复杂度是无法计算的。

        但 gzip 解压缩机并不是图灵完备的，而且也不存在会扩展到无限大输出的 gzip 流，因此理论上可以通过以下算法找到给定解压缩程序的字符串的伪柯尔莫哥洛夫复杂度：

        设 file.bin 是一个包含输入字节序列的文件。

        1. BOUNDS=$(gzip –best -c file.bin | wc -c)

        2. 长度=1

        3. 如果 LENGTH==BOUNDS，运行 `gzip –best -o test.bin.gz file.bin` 并停止。

        4. 生成一个长度为 LENGTH 字节、包含所有零位的文件 `test.bin.gz`。

        5. 运行 `gunzip -k test.bin.gz`。

        6. 如果 `test.bin` 等于 `file.bin`，停止运行。

        7. 如果 `test.bin.gz` 只包含 1 位，则递增 LENGTH 并 GOTO 3。

        8. 将 test.bin.gz 解释为 LENGTH 字节的无符号整数并递增 1，从而用其后继词法替换 test.bin.gz。

        9. GOTO 5.

        test.bin.gz 包含你的最小 gzip 编码。

        对于流行的压缩库（如 zlib）来说，有一些 “更强 ”的压缩器比现有的 “最佳 ”压缩器更胜一筹，但没有一个压缩器是如此详尽的，因为你肯定能看到问题是如何迅速变得难以解决的。

        不过，就生成高效压缩文件而言，输出文件的确切内容并不重要。如果你的目标仅仅是获得最佳压缩比，你可以用这种算法枚举所有可能的文件（压缩所有 0 以达到目标解压缩大小，这是一个很好的起点），然后检查解压缩长度是否达到或超过目标大小。

        我想我会这么做的。我会让它运行几天，看看能否生成一个比压缩零数据流更有效的压缩炸弹。我希望答案是 “不行，搜索空间太大了”。

        回复

        1. 我是个白痴，搜索空间当然太大了。即使 “测试 ”没有结果，当搜索空间达到 16 字节时，它也已经超出了我能用宇宙的热死强行搜索的范围。

          我需要有选择性地生成语法有效的 zstd 流，这样才有意义。

          回复

      2. 这是个压缩炸弹，创建者会在乎吗？我的意思是从实用的角度来看–溢出和崩溃将是一个很好的结果。

        回复

    4. 问得好。终极压缩炸弹 “看起来就像 https://github.com/iamtraction/ZOD – 这将产生臭名昭著的 ”42.zip “文件，该文件约为 42KiB，但会扩展到 3.99 PiB（！）。

      现在地球上根本没有机器能处理这个文件（我是指单个文件）。

      回复

      1. > 现在地球上还没有哪台机器能处理这样的文件（我是指单个文件）。

        内存当然不行，但 4 PiB 相当于 125x 36TiB 硬盘（或 188x 24TiB 硬盘）。(如果你想为每块 100TB 的固态硬盘支付数万元的费用，你可以把硬盘容量做得更大（此时你 “只 ”需要 45 块这样的硬盘）。

        这些数字表明，一台配有足够 SAS 扩展器的专用服务器可以轻松地将这些驱动器安装在一个机架内，价格不到 10 万美元（根据 Exos X24 的上市价格计算，甚至还未考虑任何批量折扣）。

        回复

        1. 我想你可以从 OVH 租用一台 4.5 PiB 的服务器–作为标准产品提供，甚至不需要特殊要求。显然，这需要很多钱。

          回复

          1. 我希望如果你申请 4.5 PiB 的分配，会有人打电话问你是不是不小心多放了几个零。

            回复

      3. 默认情况下，解压程序必须递归工作吗？

        回复

        1. 据我所知，这类攻击通常以内容扫描程序（主要是杀毒软件）为目标。而防病毒程序当然必须对所有内容进行递归解压缩。

          回复

    5. 必须不止一个字节。有中央目录、压缩头、本地头，然后是文件本身，你还需要告诉它在解压实际文件时要做多少个零，但大多数压缩算法都不是这样工作的，因为它们是为实际文件而设计的，而不是本质上的空白文件，所以你会得到比绝对最小压缩量更大的文件。

      回复

      1. 我的意思是，如果我做了一个新的压缩算法，将一个 10GB 的零文件用一个特定的字节表示，这在技术上就是压缩。

        这完全取决于你想在 “算法 ”中注入多少魔力

        回复

        1. 如果不是标准的，我就把解压所需的额外程序算作压缩包的一部分。

          回复

          1. 是的，不过在这种情况下，这并不会增加什么。

            回复

    6. 我想可能没有完美的无损压缩算法吧？没有什么东西会是全部为零的，所以可能没有考虑到边缘情况什么的？我也不知道，只是随便问问。也许有更聪明的人能插上一脚。

      回复

      1. 没有一种无损算法可以压缩所有字符串；有些字符串最终会变大。这是鸽子洞原理的结果。

        回复

    7. 它至少需要几个字节，没有办法用 8 位来表示 10GB 的数据。

      回复

      1. 当然可以。想象一下下面的压缩方案：

         0-253：输出输入字节
    254 后接 0：输出 254
    254 后接 1：输出 255
    255：输出 10GB 的零

        当然，这只是一个人为的例子，但理论上是完全正确的。事实上，我认为使用某些格式（包括 gzip）支持的静态 huffman 树就可以达到这个目的。

        回复

        1. 你所建议的是将信息保存到其他地方，并用数字来表示。这不是压缩，而是映射。按照这种逻辑，我们也可以认为一个比特就足够了。

          回复

        2. > 254 后接 0：输出 254

          126，确定吗？

          回复

    8. 一个压缩数据块的大小限制约为 64KB。这设定了最大压缩率。

      回复

    9. 在这种情况下，gzip 并不是最佳选择。它将文件分为多个块，每个块都有一个头文件。显然，每 1000 个字节中只有 1 个字节。

      回复

  18. 有没有流行的攻击向量网址列表？我想自动禁止嗅探 .env 或 ./../../../…/等的人。

    我不想自己写

    回复

    2. 这是一个相当简短的 Perl 脚本，可以读取访问日志，并向所有访问过的 URL 发出 HEAD 请求，只打印那些有 200 OK 响应的 URL。

      下面是在我手机上测试的黑客脚本：

       perl -lnE 'if (/GET ([^ ]+)/ and $p=$1) {
        $s=qx(curl -sI https://BASE_URL/$p | head -n 1)；
        unless ($s =~ /200|302/) {
            说 $p
        }
    }'
      回复

    3. 我也对此感兴趣。目前，我让一台服务器运行了几个星期，查看了日志，并为最常见的违规者设置了 fail2ban。我每个月左右检查一次违规者，但第一次迭代已经封禁了很多人。

      回复

    4. 查看 Modsecurity WAF 和 CoreRuleSet。

      回复

  19. 由于我的服务器不使用 PHP，但却收到了大量与 PHP 有关的请求，因此我添加了一条规则，用从 /dev/urandom 导出的 “口令 ”加密 Linux 内核，作为对这些请求的回复。压缩炸弹可能是更糟糕的回复……

    对于那些 “急于 ”获取内容的人工智能机器人，我在思考是否应该建立马尔科夫链，以经典的 https://en.wikipedia.org/wiki/Mark_V._Shaney 风格生成半可读性文本……

    回复

  20. 15 多年前，我曾在一家公司打击盗版，该公司拥有非常知名的认证培训材料。我分发了标有培训材料文件名的压缩炸弹。那很有趣。

    回复

  21. 有可能面临任何法律风险吗？

    比如，合法的爬虫起诉你，声称你破坏了他们的东西？

    回复

    1. 披露：我不懂法律

      CFAA[1] 禁止

      > 在知情的情况下导致程序、信息、代码或命令的传输，并因此在未经授权的情况下故意对受保护的计算机造成损害；

      据我所知（还是我的个人意见），如果你认为所述计算机正积极试图滥用你的系统[2]，则没有例外。我不确定压缩炸弹是否构成蓄意破坏，但它至少离这条线很近，我不会冒这个险。

      [1]: https://www.law.cornell.edu/uscode/text/18/1030

      [2]: 当然，你也可能会犯错，错误地将其提供给合法流量。

      回复

      1. 我认为客户端不能算作受保护的计算机，因为是他们发起了连接。另外，受保护计算机是一个非常具体的定义，涉及银行和/或商业和/或政府。

        回复

        1. 受保护计算机 “定义的 B 部分写道：

          > 用于或影响州际或国外商业或通信的计算机，包括位于美国境外、以影响美国州际或国外商业或通信的方式使用的计算机。

          假设服务器在美国各州运行，我认为这将适用，除非客户端与服务器在同一州，在这种情况下，可能会有类似的州法律产生影响。我没有看到任何将客户端排除在外的规定，这是有道理的，否则就不会禁止建立一个欺骗人们下载恶意软件的网站。

          回复

          1. 法律中多次使用 “访问 ”一词。客户端访问服务器。服务器不访问客户端。服务器响应客户端。

            此外，受保护的计算机必须参与商业活动。除非他们使用一台也用于州际或国外商业的计算机访问带有压缩炸弹的网站，否则就不符合条件。

            回复

            1. > 此外，受保护的计算机必须涉及商业活动。

              在美国，几乎所有事情都涉及 “州际贸易”。参见 https://en.wikipedia.org/wiki/Commerce_Clause

              > 商业条款是《受控物质法》中联邦禁药法律的渊源。在 2005 年的 “冈萨雷斯诉雷奇”（Gonzales v. Raich）医用大麻案中，美国最高法院驳回了关于禁止种植供个人使用的医用大麻的禁令超出了国会在商业条款下的权力的论点。法院认为，即使没有货物跨州销售或运输，也可能会对州际贸易产生间接影响，并在很大程度上依赖于新政案例 Wickard v. Filburn，该案认为政府可以对个人种植和消费农作物进行监管，因为个人消费的总体影响可能会对州际贸易产生间接影响。

              回复

            2. > 整部法律多次使用 “获取 ”一词。

              那又怎样？我上面引用的部分中没有这个词。我的理解可能有误，但我的理解是，不管你是否 “访问 ”了另一个系统，以造成损害为目的传输可能造成损害的信息都是违法行为。

              > 此外，受保护的计算机必须参与商业活动

              或通信。

              现在，从道德的角度来看，我不认为向恶意机器人发送 zipbomb 有什么不妥。但我对这样做是否合法没有足够的信心，所以我不会冒险这么做。

              回复

              1. > 那又怎样？我上面引用的章节里没有。

                你不能在这样的章节中解读法律。这两节是连在一起的。整部法律都是关于通过恶意访问造成损害的。但服务器不会访问客户端。

                你所引用的章节与此无关，因为整部法律是关于客户访问服务器，而不是服务器响应客户。

                回复

                1. 我在该法律中看到的所有关于访问的内容都是在第 1 条的违规行为列表中的一个单独项目中。你在哪里看到暗示第 5a 条仅适用于客户访问服务器的内容？

                  回复

        2. 受保护的计算机是指 “受本法保护的计算机”，也就是大多数美国计算机，而不是一类特殊的美国计算机。不是所有美国计算机的唯一原因是，美国联邦政府对美国没有完全的管辖权。他们在撰写 “受保护计算机 ”的定义时，将他们拥有管辖权的所有计算机都包括在内。

          尤其是州际商业条款的规定过于宽泛。有人裁定，自己种植农作物喂养自己的农场动物并在当地销售的人就是在进行州际贸易，因为他们不必从另一个州购买农作物。

          回复

      2. 只要在 zipbomb 的前面加上 “连接本服务，即表示您同意并授权…… ”就行了。

        (我半开玩笑半哭丧着脸。基本上，其他任何东西都是这样工作的。为什么在这里行不通呢？你甚至可以明确地称之为 “拉链炸弹测试递送服务”。那些机器人不知道他们在连接什么，这又不是你的错……）。

        回复

      3. 所以诀窍就是把它伪装成意外。让压缩炸弹在开头看起来像一个真正的 HTML 文件，然后在后面加上零，就像它被破坏了一样。

        回复

        1. 填满磁盘不是破坏性的，填满 RAM 也不是破坏性的，zip 炸弹中没有任何破坏性的东西；重启或 “rm”（最多）就能消除一切。我认为这绝不是破坏性操作。

          非专业意见

          回复

      4. 在没有事先法律协议的情况下，外部计算机系统与我的系统建立连接是不合法的。这一切都是出于善意，因此可以随时终止。

        回复

        1. 所以你可以黑掉任何连接到你网站的浏览器，因为他们没有与你签订法律协议？我不认为这可以作为辩护理由

          回复

      5. 在没有事先法律协议的情况下，外部计算机系统与我的系统建立连接在法律上是不成立的。这一切都是出于善意。

        回复

    2. 我刚刚想到，也许大量僵尸流量来自不知情的受害者僵尸网络，他们下载了一个低劣的游戏或类似游戏，由其他地方的恶意 C&C 服务器精心策划。(最近有一篇关于这类恶意软件的帖子）。现在，如果你让受害者的机器崩溃，即使不合法，至少在道德上也很复杂。

      回复

      1. 虽然从道德角度讲，关闭受感染的电脑而不是让它继续运行可能是件好事。

        回复

    3. 作为一个对话，请告诉我你认为有哪些可能性？

      我来扮演防御者，你可以扮演 “机器人”/机器人部署者。

      回复

      1. 创建机器人本身并不违法，所以假设服务器上的恶意检测器并不完美，那么它可以将压缩炸弹发送给合法的机器人。而且我认为，如果提供拉链炸弹的目的是为了破坏客户端，那也不算违法。当然，我不是律师。

        回复

        1. 透露一下，我也不是律师。这里只是假设性的高层讨论。

          > 它可以向合法的机器人发送拉链炸弹。

          你能为我定义一下合法机器人和非合法机器人的区别吗？

          OP 没有提到这一点，但如果我们可以假设他们有某种形式的 robots.txt（鉴于他们的历史，这种假设是安全的），那么那些无视机器人的机器人会被视为合法/非合法机器人吗？

          几乎是最后一个问题，我知道我们不是律师，但在判例法或任何地方，是否有任何先例可以界定法律眼中的 “坏机器人”？

          最后一个问题，作为一个机器人，你认为自己有权利或特权对网站进行搜索吗？

          回复

          1. > 你能为我定义一下合法机器人和非法机器人的区别吗？

            默认情况下，每个机器人都是合法的，不合法的机器人可能是探测安全漏洞的机器人（但我甚至不确定，如果你不破坏服务器作为副作用，即如果你只是试图确定服务器上运行的 WordPress 或 SSHD 版本，这是否违法）。

            > OP 没有提到这一点，但如果我们可以假设他们有某种形式的 robots.txt（鉴于他们的历史，这种假设是安全的），那么那些无视 robots 的机器人会被认为是合法/非法的吗？

            robots.txt不具有法律约束力，所以我不认为无视它的机器人就不合法。

            > 最后一个问题，我知道我们不是律师，但在判例法或其他任何地方，是否有任何先例来定义法律眼中的 “坏机器人”？

            可能有，但我不知道。

            > 最后一个问题，作为一个机器人，你认为自己有权利或特权对网站进行搜刮吗？

            我不是机器人，但我认为我有权建立机器人来抓取网站（而不会被提供恶意内容来破坏我的电脑）。当然，如果你不喜欢我的机器人，也可以拒绝提供服务，只提供错误页面。

            回复

      2. 螳螂捕蝉黄雀在后是一个相当好的比喻，而且这是非常违法的。如果读煤气表的人被你的捕捉器抓住，你就会坐牢。如果有人入室盗窃时被你的捕鼠器夹住，你也可能会坐牢。

        https://en.wikipedia.org/wiki/Mantrap_（陷阱）

        当然，他们的电脑还能用，但如果你不小心弄垮了自己的互联网服务提供商，或者你使用的第三方服务，我想他们会起诉你的。

        回复

      3. 任何人都可以因任何事情起诉任何人，而拥有最多资金的一方最有可能胜诉。

        回复

    4. 虽然任何人都可以起诉任何人，但不做 X 是最简单的事情，可能会避免因做 X 而被起诉。

      但如果这很重要，那就付钱给你的律师，如果这不重要，那就无所谓。

      回复

    5. >用户代理： *

      >禁止访问： /zipbomb.html

      合法的爬虫会跳过这种方式，只有人渣才会忽略 robots.txt

      回复

      1. 我不确定这样做是否足够，robots.txt 并不真正具有法律约束力，所以如果压缩炸弹是非法的，那么用 robots.txt 规则来保护它可能并不会让它变好。

        回复

        1. > robots.txt 并不具有法律约束力

          HTTP 规范也没有。没有什么能阻止你在 TCP 80 端口上运行 Gopher 服务器，如果它碰巧导致某个爬虫崩溃，你会有麻烦吗？

          在一个随机的服务器上发出 HTTP 请求，就像在一个城市里对一个随机的人说一句话：有些人可能会帮你，有些人可能会让你滚蛋，有些人可能会打你的屁股。如果你不喜欢后者，那就不要在没有标记的地方对陌生人大声说废话。

          回复

          1. 如果唯一的目的是破坏提出请求的计算机，法律可能会阻止你发送特定的回复。我不是 100% 熟悉美国法律，但我认为故意破坏计算机系统是违法的。

            回复

            1. 我也不是律师，但如果请求者不是在法律上被迫提出请求，他们难道不会将此视为破坏吗？

              回复

              1. 不会，他们为什么要这么做？如果我自愿要求访问你的网站，你也不能回复我说要清除我的硬盘。尽管我可以选择不发送请求。在我提出申请之前，我并不知道你们会对我进行破坏。

                回复

                1. 因为是你要求的？除了标准（您的浏览器希望对方提供有效文件等）之外，并没有关于送达内容或方式的协议。

                  我只是假设法庭可能会说，你请求了所有可猜测的端点，却发现有一个端点会对你的电脑造成伤害（而你访问该页面的理由是零），而有人在 index.html 中放入 zipbomb，故意伤害所有人，这两者之间是有区别的。

                  回复

                  1. 所以，在一个可以通过抓取发现的 URL 下提供一个利用浏览器零日进行 RCE 的文档（因为另一个页面链接到了它），意图伤害客户端（例如通过删除本地文件）是合法的，因为客户端提出了请求？这太荒谬了。

                    回复

                    1. > 因为另一个页面链接到了它

                      robots.txt是唯一指定文档URL的文件，而且是在 “禁止 ”规则中指定的。在这种情况下，“他们不知道该请求会受到敌意回应 ”的论点可能没有实际意义（可能是因为 “合理的人 ”会选择不请求被禁止的文档，但我并不太了解这种说法何时适用）。

                      > 例如删除本地文件

                      这个例子与压缩炸弹有本质区别，因为它明显具有破坏性，而压缩炸弹却没有。诚然，压缩炸弹可能会对系统造成破坏，但这并不能保证，而删除文件则必然会造成破坏。zip 炸弹的更坏结果可能会导致值得提起诉讼的损害，但 zip 炸弹的假定意图（和表面结果）是有效地导致接收者的机器非自愿关闭，鉴于周围的环境，法院可能会也可能不会认为这是合法的。

        2. 有类似的案件审理过吗？我认为，了解 robots.txt 和禁止规则意图的法官很有可能会持同情态度。我的意思是，似乎两种结果都有可能。(陪审员可能更多的是废话）。

          回复

        3. 运行违反 robots.txt 的爬虫时，谁会起诉/控告服务器所有者？

          服务器所有者可以很容易地向陪审团证明，这是一个防范非法入侵者的陷阱。

          回复

          1. > 服务器所有者可以很容易地向陪审团证明，这是一个防止非法入侵者的诱杀装置。

            我不知道有任何网上案例，但许多（大多数？）地方的法律肯定倾向于对实体诱杀装置持否定态度。即使是在美国全面实行 “站在你的立场上 ”立法的州，以及普通法允许在自卫中使用所有 “合理武力 ”的英国，诱杀装置通常也不被视为自卫或站在立场上。从根本上说，如果诱杀装置可以自动引爆，而不是由人在自卫时引爆，那么它就不是自卫。

            > 谁[……]会起诉/追究服务器所有者？

            可能没有。不过，他们可能会采取针锋相对的行动，反复使用拉链炸弹来消耗你的带宽，而他们的带宽可能比你的小网站更多也更便宜。最好为此准备好一些技术防御措施，因为你也不可能起诉他们：他们可能是在完全不同的法律管辖区运行，和/或攻击来自僵尸网络，几乎没有证据跟踪是谁发起的攻击。

            回复

            1. 在家中安装诱杀装置似乎是非法的，因为这可能会威胁到生命/健康。拉链炸弹不会威胁到任何人。最坏的情况是，它会占用设备的内存和存储空间。我很确定它不会违反任何相同的法规，而且很可能也不会很好地适用你提到的任何普通法判例。

              > 你的小网站可能比他们有更多更便宜的带宽。

              去读读什么是压缩炸弹。有一种只有几 KB 的压缩炸弹，在服务器负载和带宽方面与 robots.txt 不相上下。

              回复

              1. > 去看看什么是压缩炸弹。

                没必要这么混蛋。尤其是当你自己都不明白别人在说什么的时候。

                我很清楚什么是压缩炸弹。一个大的压缩文件即使以压缩的形式存在，仍然有一定的大小（在不嵌套的情况下，1G 的最小熵数据压缩后约为 1M）。如果有人注意到了你的炸弹，并通过实施相关检查绕过了它（或者因为已经实施了这些检查而没有受到它的影响），他们就可以通过多次下载占用你的带宽来报复一下。好吧，如果嵌套后只剩下几 Kb，他们仍然可以向这些内容或网站上的其他内容投掷僵尸网络，给你造成一些损失，如果他们想采取针锋相对的行动的话。另外：当你使用 HTTP 传输压缩作为传输机制时，嵌套就不起作用了，而这正是这里要讨论的： 支持 HTTP 压缩编码的 “标准 ”库一般不会解压缩嵌套内容。没有 “Accept-Encoding: gzip+gzip ”或类似功能。

                大多数人，也许是绝大多数人，都不屑于做这种努力，所以这可以被视为一种假设，但有些人可能会这么做。在我早期上网的时候，肯定发生过垃圾邮件发送者和地址清除者故意浪费网站带宽的情况，这些网站鼓励使用 FormFucker 等工具或实施清除者漏洞。

                回复

        4. 法律通常会奖励善意的尝试，robots.txt 是一个既定的商业标准。

          回复

  22. > 在告诉你如何创建一个 zip 炸弹之前，我必须警告你，你可能会让自己的设备崩溃并毁于一旦。

    当然，设备确实会崩溃，但不会被摧毁？

    回复

  23. 这个话题时不时就会出现，我很惊讶至今还没有人提到拉链炸弹可能违法的惯用恐吓言论。

    我不是律师，但在现实生活中，我还没有看到过机器人所有者起诉公司或个人用拉链炸弹回应其恶意请求的案例。通常的说辞是这样的：用恶意回复回应他的恶意请求，你就成了网络罪犯，他（真正的网络罪犯）就可以起诉你。同样，除了低俗的言论，我从未听说过这样的法庭案例。但我很容易想象他们试图用这种低级威胁来勒索别人。

    我无法想象像微软或苹果这样的大公司会使用压缩炸弹，但我不明白为什么压缩炸弹会被认为是坏的。任何有过与恶意机器人打交道经历的人都知道，它们从企业或个人那里窃取的时间和金钱是多么令人沮丧。

    回复

    1. 任何人都可以以任何理由起诉他人。

      这就是让我头疼的地方：

      >在我的服务器上，我添加了一个中间件，用来检查当前请求是否是恶意的。

      其中包含了很多信任：

      >if (ipIsBlackListed() || isMalicious()) {

      被分配到先前列入黑名单的 IP 的人，或者使用工具将网站存档以模仿僵尸的人，会被提供恶意软件吗？中间件是否足够好或 “目前足够好”？

      我几乎 100% 的互联网流量都是通过 VPN 传输的。我曾多次在连接 VPN 或切换服务器时被各种服务列入黑名单。

      回复

      1. 是的。

        不过，用户必须手动解压缩炸弹。他们必须打开文件，然后看到 “解压缩大小：999999999999999999999999999999999999999999999999999999999999”，然后仍然尝试解压缩。因此，我不认为这存在任何道德困境。

        回复

        1. 出于某种原因，我的印象中浏览器有能力透明地解压某些压缩格式文件？不过我想的可能是 less 和 gzip。

          回复

  24. > 大多数情况下，当他们这样做的时候，我就再也没有听到他们的消息了。为什么？因为它们在摄取文件后会立即崩溃。

    我本以为进程/服务器会重新启动，而且会用你的特定 URL 重新启动，因为那是最后一个未完成的。

    是什么原因让机器人今后不再访问这个网站？它们真的聪明到可以硬编码一条规则来检查崩溃情况，并在未来避免访问这些网站吗？

    回复

    1. 看来一个指数级的回退规则就能解决这个问题： 我相信崩溃发生的原因是多方面的，其中有些是机器人的错误，即使是在非对抗性输入的情况下也是如此。

      回复

    1. 概念相同，但我觉得你的信息量更大。总体上有很大不同。

      回复

  26. 我也曾想过用 zip 炸弹来迷惑行为恶劣的刮刮卡（我以前也向其他人提过这个想法，尽管我没有付诸实施）。不过，也许你可以使用不同的字节值来代替 0x00。

    我还有其他想法，但我不知道其中一些想法的效果如何（可能取决于它们是什么机器人）。

    回复

    1. 不同字节值的压缩效果可能不如全部为 0 的压缩效果好，除非它们是重复模式的数据块。

      另一种方法是使用 Brotli，它有一个静态字典。也许可以用它来实现较高的压缩率。

      回复

      1. 我的意思是，所有的字节值都是相同的（所以它们仍然是重复的），但数值与零不同。不过，如果客户端支持的话，Brotli 可能是另一个想法。

        回复

      2. 压缩任何单一字符的序列在长度上都会得到几乎相同的结果（也许不完全相同，但差别会非常小）。

        例如，使用默认选项的 gzip：

            me@here:~$ pv /dev/zero -s 10M -S | gzip -c | wc -c                    
    10.0MiB 0:00:00 [ 122MiB/s] [=============================>] 100%      
    10208                                                                  
    me@here:~$ pv /dev/zero -s 100M -S | gzip -c | wc -c                   
     100MiB 0:00:00 [ 134MiB/s] [=============================>] 100%      
    101791                                                                 
    me@here:~$ pv /dev/zero -s 1G -S | gzip -c | wc -c                     
    1.00GiB 0:00:07 [ 135MiB/s] [=============================>] 100%      
    1042069                                                                
    me@here:~$ pv /dev/zero -s 10M -S | tr "00" "141" | gzip -c | wc -c 
    10.0MiB 0:00:00 [ 109MiB/s] [=============================>] 100%      
    10209                                                                  
    me@here:~$ pv /dev/zero -s 100M -S | tr "00" "141" | gzip -c | wc -c
     100MiB 0:00:00 [ 118MiB/s] [=============================>] 100%      
    101792                                                                 
    me@here:~$ pv /dev/zero -s 1G -S | tr "00" "141" | gzip -c | wc -c  
    1.00GiB 0:00:07 [ 129MiB/s] [=============================>] 100%      
    1042071
        回复

  29. 我认为这是个好主意，但必须与 robots.txt 结合使用。

    回复

    1. 我昨天查看了我的日志。

      坏机器人根本不看 robots.txt。

      回复

      1. 最糟糕的机器人会把它当作目标。

        回复

    2. 人工智能搜刮机器人不尊重 robots.txt

      回复

      1. 我想这就是问题的关键所在，你应该使用 robots.txt 来引导 Googlebot/Bingbot/etc 远离可能会扰乱你的搜索引擎优化的反制措施。如果其他机器人忽略了路标，而路标上明确写着不要进入 “tarpit”，那就是它们自己愚蠢的过错了。

        回复

      2. 幸存下来的机器人会这样做

        回复

  30. 我对大多数机器人的工作原理一无所知。能不能为躲避炸弹的机器人设置第二道防线？从 /dev/random 中动态生成一个文件，然后涓滴流式传输给它们，还是说它们只会不断产生并行请求？它们将永远无法完成流式传输，并可能在某些时候放弃。这样做的目的是让它们更难检测到这是无效内容。

    回复

    1. 你需要考虑你的资源消耗与他们的资源消耗之比。如果你从 /dev/random 传输字节，那么你就在以最小的开销维持着一个 TCP 连接，而这也是他们正在做的事情。我们假设他们足够聪明，使用了许多现代语言或框架，可以在现代系统上轻松处理 10K/100K 或更多连接。他们并不都那么聪明，但肯定有一些是聪明的。你和他们的资源消耗基本上是 1:1。这对你来说可不是什么好结果。

      gzip 炸弹意味着你提供 10MB 的服务，但他们却要消耗大量的 RAM，很可能会崩溃。这个比例要好得多。

      回复

      1. 还可能在 /dev/random 消耗的熵上开辟新的 DoS 向量，因此可能比 1:1 更糟糕。

        回复

        1. 在现代系统中，熵并不会真正被 “消耗”。你可以从 /dev/random 中读取数 TB 的数据，而不会耗尽任何东西。

          回复

        2. 如前所述，在现代系统中这并不是个问题。但无论如何，你是否可以从 /dev/urandom 中读取 1K 到缓冲区，然后不断重复发送该缓冲区？

          回复

      2. 很明显。关键在于他们的行为。他们会坐在那里等待完成下载，还是开始并行发送其他请求，直到你自己完成下载？我希望他们会把这个网站标记为低价值网站，然后去其他网站寻找。

        回复

    2. Endlessh 上的这篇文章还展示了如何实现轻资源的 http tarpit：https://nullprogram.com/blog/2019/03/22/。

      回复

      1. 这样做的好处是可以非常缓慢地传输数据，就像猫在角落里盯着一团绒毛一样。

        回复

        1. 猫也会为绒毛球设置超时。它们通常会觉得无聊，要么走开，要么攻击你:)

          回复

        2. 如果机器人通过 IPv4 进行连接，那么在服务器开始需要使用共享套接字和其他恼人的连接技巧之前，你只有几千个连接。

          我认为现在要解决这个问题并不难，尤其是如果你使用的是使用 nftables/iptables/eBPF 的 tarpitting 实现，但如果你有一个恼人的中国僵尸农场，有成千上万个 IP 地址轮流攻击你的服务器（华为就喜欢这样做），那么在部署此解决方案之前，你可能需要三思而后行。

          回复

        3. 是的，但你仍然需要保持与它们的连接。不过，这是一种反向 SlowLoris 攻击。

          回复

          1. 如果其他地方需要资源，你可以随时放弃连接。

            (或者说，应该对 tarpit 进行编程，通过最大资源分配或监控可用系统资源来实现这一点）。

            回复

        4. 是的，但同时它也占用了网络服务器上的连接。

          回复

    6. 实际上，所有标准库都为此类请求设置了超时，除非你明确提供了它们会跳过的流。

      回复

    7. 这也行得通，但有时机器人会假装自己不是机器人，所以你偶尔也会对真实用户这样做

      回复

  31. 令人惊讶的是，它竟然能起作用（我还没试过）。Content-Length “的目的只有一个–通过比较响应大小和头值来确保数据完整性。我希望 http 客户端能处理好这个问题，无论是否使用 gzip。不是这样吗？如果是，那么一切都会改变，很多服务器都需要优先更新。

    回复

    1. 您不需要设置内容长度标头，当您关闭连接时，它会认为页面已经完成

      回复

  32. 最难的部分是 isMalicious() 函数的内容。机器人可能会崩溃，但它们很快就会重新启动。

    回复

  33. 谁能解释一下修改器为什么要修改帖子标题？在他们看来这有什么价值？

    回复

  34. 如果有人有兴趣写一份使用 crowdsec 或 fail2ban 设置此功能的指南，我洗耳恭听。

    回复

  35. 你介意分享一下你的 Digital Ocean droplet 的规格吗？我正在尝试以较低的成本安装一个。

    回复

    1. 博客运行在价值 6 美元的数字海洋服务器上。它有 1GB 内存和 25GB 存储空间。文章末尾有一个链接，介绍了它如何处理典型的 HN 流量。目前 CPU 占用率为 5%。

      回复

  36. “在我的服务器上，我添加了一个中间件，用于检查当前请求是否为恶意请求”

    该中间件的准确性如何？很明显，在你使用其他启发式方法进行补充时，会出现假阴性。那么误报呢？只是附带损害吗？

    回复

    1. 我还以为他有自己的违规者名单呢

      回复

      1. 代码显示，“中间件 ”和自定义列表都能把你关进 “淘气箱”。

        回复

  37. 我想不言而喻，首先应该遵循安全最佳实践。快速修补漏洞等，然后再做类似的事情。那样的话，他的第一个网站也许也不会被入侵。

    回复

  38. 我无法想象在处理爬虫的网络请求时，除了使用流接口还能使用什么。

    你不仅需要这样来防止这类恶作剧，还需要防止响应过大或过慢。

    回复

  39. 我喜欢类似的伎俩，即使用代理向恶意访问者发送托管在外部服务器上的超大文件。这些代理通常按带宽收费，因此会增加他们的成本。

    回复

  40. “但当我检测到他们试图注入恶意攻击或正在试探回应时”，你是如何检测到这一点的？介意分享一些伪代码吗？

    回复

  41. 使用 Cloudflare 不是比派人在缺乏适当过滤功能的电脑上痴迷地观察网络服务器日志更省钱吗？

    回复

    1. 在谷歌图片上搜索 “埃菲尔铁塔 ”也比预订飞往巴黎的机票便宜，但很多人喜欢做后者。

      回复

        1. 在游览巴黎时，我曾有过这样的想法，结果却给我带来了惊喜。巴黎是一座可爱而美丽的城市。

          我们不需要三家公司来控制互联网的每个角落。

          回复

  42. 在禁止和/或骚扰机器人方面，有很多有创意的想法。有塔尖、无限迷宫、工作证明、定期挑战、蜜罐等。

    不过，我遇到的大多数机器人都很笨，而且很容易检测和阻止。我通常使用 CrowdSec (https://www.crowdsec.net/)，有了它，你还可以在使用它的所有其他服务器上封禁行为不端的 IP，然后再封禁到你的服务器上。我还试过在网页上使用 turnstile（https://www.cloudflare.com/application-services/products/tur……），它似乎也能起作用，不过我想大多数此类产品都能起作用，因为大多数机器人都相当笨。

    我个人不太愿意使用压缩炸弹，因为这样做对机器人农场造成的损失可能比对我造成的损失要小，而且我觉得直接封禁 IP 比试图玩弄它更有效，尤其是在我知道它行为不端的情况下。

    编辑：当然，作者也可以说，看到一个 IP “安静 ”一会儿的满足感是无价的，这一点无可争议。

    回复

  43. 如果想在赛博朋克中创造网络空间的 ICE，能够摧毁设备……

    回复

  44. 压缩图书馆还不能防炸弹？似乎很容易被发现和忽略，不是吗？

    回复

  45. 那用 Rust 写的机器人呢？这样也能摆脱它们吗？

    回复

    1. Rust 诞生的进程在内存方面是安全的，可以避免堆和栈被类似 C 语言的问题（如流氓指针和使用后释放）破坏，但它们仍然会受到 OOM 条件或其他存储空间耗尽的影响，因此如果不以适当的防御方式编码，很容易被拉链炸弹炸死。

      回复

  46. 操作员：你们好，我是这样抵御黑客的！黑客： 注意了。

    回复

  47. 如果能在 http 中加入工作证明协议，那就太酷了。

    回复

  48. 提供压缩炸弹是非常非法的。无论如何，机器人都会重启进程，然后若无其事地继续运行。

    回复

  50. 这本书读起来很酷，非常有趣。

    回复

  51. 稍微有点意思，但这似乎是在认为两个错误可以做成一个正确的事情，所以让我们提供恶意软件，而不是使用 WAF 或其他现有解决方案来解决僵尸问题。

    回复

    1. 网络上充斥着毫无道德感的恶意行为者。既然循规蹈矩显然行不通，我赞成尽我所能浪费他们的资源。我会更进一步，试图破坏他们的设备，让他们无法继续滥用，但由于这需要我付出更多的努力，所以压缩炸弹是一个很好的低成本解决方案。

      回复

    2. 向恶意流量提供垃圾信息在道德上并无歧义。

      他们提出了请求。请做出相应回应。

      回复

      1. 根据帖子中的例子，这种想法可能需要扩展到 “有人碰巧使用了被屏蔽的 IP”。我不提供压缩炸弹，但多年来我已经封禁了许多使用 VPN IP 的滥用机器人，这些机器人妨碍了使用相同 VPN 的合法用户。

        回复

    3. 对很多人来说，WAF 并不是正确的选择：https://news.ycombinator.com/item?id=43793526

      回复

      1. 至少在默认规则下不是。我读了几天前的那篇讨论，惊讶于很少有人提到 WAF 只是基础架构的一部分，人们真正抱怨的是规则。我认为问题出在 AWS 上运行的应用程序太多，而他们的默认 WAF 规则有一些愚蠢的内容过滤。而他们的 “安全基线 ”规定，你必须使用 WAF 并包含他们的默认规则，因此安全团队就会锁定这些规则，而不会真正考虑这些规则在任何特定场景下是否合理。

        回复

    4. 我最喜欢的一句谚语。

      “伤害别人是不对的，所以受到攻击时不应该自卫”。

      “监禁是错误的，所以我们不应该监禁小偷”。

      此外，罗宾汉的现代故事似乎也广为传颂。

      两个错误不一定能做成一个正确的事情，但往往一个较小的错误是我们避免更大错误的最好办法。

      这句谚语的精神指的是互不相干的错误，尤其是在用一个错误为另一个错误开脱时。

      回复

      1. > “伤害别人是不对的，所以受到攻击时不应该为自己辩护”。

        这正是加州教育工作者在 90 年代告诉那些被欺负的孩子们的话。

        回复

      2. > 较小的错误是我们避免更大错误的最佳手段

        恐怖分子和战犯的逻辑无处不在。

        回复

        1. 我钦佩你对道义的狂热。虽然我并不免除任何人对其行为承担全部责任，但我怀疑恐怖分子所做的不仅仅是避免更大的错误–否则，请让我加入！

          回复

        2. 防御和进攻不一样。

          犯罪和正义也不一样。

          如果你不明白这一点，你就是问题的主要部分。

          继续思考，直到你永远弄明白为止。

          回复

        4. 有时候，一个人眼中的恐怖分子就是另一个人眼中的自由斗士….。(不是为恐怖主义辩护，而是事情没那么简单）

          回复

      1. 我一开始确实试过拉链炸弹。由于亚马逊搜索器的工作架构，它们没有奏效。它只会让请求重试。

        回复

        1. 亚马逊的搜刮器每秒向我的服务器发送多个请求，已经持续了六个多星期，每次请求都被返回 429。

          亚马逊的搜刮器不会退出。Meta、谷歌和其他大多数可识别用户代理的网站都会退出，但亚马逊不会。

          回复

          1. 如果很容易，在返回 429 之前休眠 30 秒。或者 tcpdrop 连接，甚至不发送响应或 tcp 重置。

            回复

              1. 所以我才说，如果容易的话。在某些服务器堆栈中，多打开 30 秒连接没什么大不了的；而在其他服务器堆栈中，你需要尽快完成请求，甚至滥用。

                tcpdrop 不应该自 DOS，因为它使用的资源更少。即使另一端重试，它也会在超时后重试；在此期间，另一端拥有套接字状态，而你没有，这就是胜利。

                回复

        2. 首先，请允许我先说一下，我一般不接受未经我明确允许的网站的 Cookie，我的理由是 “我为什么要将磁盘读/写访问权授予[大多是]不怀好意的行为者，让他们跟踪我？

          (我不认为你的博客属于黑客……但你也不在我的允许列表中）。

          因此，如果我访问 https://anubis.techaro.lol/（从 “阿努比斯 ”链接），我就会看到一个无限循环的动漫猫女刷新页面–老实说，这还不是最糟糕的事情吗？

          但如果我访问 https://xeiaso.net/blog/2025/anubis/ 并点击 “测试阿努比斯，请点击这里”。……就能正常加载。

          我的允许列表中既没有 xeserv.us 也没有 techaro.lol。奇怪的是，那个网站似乎通过了。不知道。

          博文中确实有那张可爱的图……但我怀疑我会在其中循环 “无 cookie”，所以无限的猫女是意料之中的。

          我正在开发一个扩展，它可以非常短暂地存储 Cookie，以应对更恶意的情况，但我觉得它的设计在这里也能用。(内存中的 cookie 罐，在 30 秒后烧毁。持续时间足以加载页面）。

          回复

          1. 你看到的是正在进行的实验。它似乎在起作用，但我还没有获得足够的数据来判断它最终是否成功。

            回复

          2. 仅供参考，临时容器（Firefox 扩展）似乎就是你要找的解决方案。它主要是为你打开的每个标签页生成一个新容器（子标签页可以是新容器，也可以在同一个容器中）。一旦关闭标签页，它就会销毁容器并删除所有浏览数据（包括 cookie）。你仍然可以将某些域列入特定持久容器的白名单。

            我使用 cookie 阻止程序很长时间了，但最后总是不得不将一些网站列入白名单，即使我并不想要它们的 cookie，因为没有它们，网站就会行为不端。现在我不再担心了。

            回复

          3. > 我的允许列表中既没有 xeserv.us 也没有 techaro.lol。奇怪的是，其中一个似乎通过了。不知道。

            您的浏览器是否通过了推荐人？

            回复

        3. 你是否也尝试过传输编码：分块和 HTTP 走私等方法，以向网络浏览器实例提供不同于向爬虫器提供的内容？

          回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注