这是Jim"Elwood"O'Gorman的客座帖子，他是Kali Linux的维护者之一。kalilinux是一个基于Debian的GNU/Linux发行版，在安全研究中很流行社区。卡利Linux今年六岁了！在这一次，Kali已经成为事实上的标准开源渗透测试平台。我们每季度为多个平台、预配置的虚拟机、Kali Docker、WSL、Azure、AWS映像、大量ARM设备、Kali NetHunter等发布更新的iso。这使得卡利受到信任，并一直依赖于安全专业人士和爱好者差不多。但是这种流行总是导致一个复杂的问题：如何让卡利给人们？有这么多不同的下载，再加上apt存储库，我们必须移动大量数据。为了实现这一目标，我们一直依靠我们的第一方和第三方网络镜子这样做的方式是，我们运行一个主服务器，将其推送到多个镜像。然后，我们付费托管多个地理位置分散的服务器，并将它们用作第一方镜像。然后，许多第三方捐赠存储和带宽来操作第三方镜像，从而确保我们拥有更多地理位置靠近您的系统。当你去下载时，你点击了一个重定向器，它会把你发送到一个离你很近的镜像，理想情况下允许你下载你的文件快点。这个解决方案一直都很不错，但也有一些缺点。首先，我们的第一方镜像网络非常昂贵。第二，有些镜子不如其他镜子好。没有什么比下载Kali并被发送到一个慢镜像更糟糕的了，在那里你的下载可能会拖上几个小时。第三，随着卡利的不断成长，我们总是需要更多的镜子人气。这个多亏了一些非常慷慨的外联活动，这种情况导致我们遇到了Cloudflarehttps://t.co/k6m5uzzhwf我们可以更多地讨论您的具体用例。-Justin（@xxdesmus）2018年6月29日老实说，我们是一群安全呆子，所以一开始我们有点怀疑。我们有一些非常独特的需求，我们使用大量的带宽，将一个apt存储库同步到CDN不是一个小任务，而且，我们很偏执。我们每个月平均有1000000次下载，仅在我们的ISO映像上。加上我们的apt回购，你说的是一些严重的，严重的流量。那么我们到底能从Cloudflare得到多少帮助呢？我们真的能把它用上吗？或者这只是我们网站的一个漂亮的前端，而不是其他什么？另一方面，这是一个使用新的和有光泽的东西的机会，而且这是一个昂贵的产品，所以我们当然直接跳进去玩开始的时候我们有一些同步问题。包存储库是静态数据（二进制和源包）和动态数据（包列表每6小时更新一次）的混合体。更糟的是，元数据的加密密封意味着我们需要对所有元数据进行原子更新（签名的顶级"Release"文件包含所有二进制和源包列表的校验和）。CDN的默认行为不适合于此目的，因为它在获取所有文件后会在一定时间内缓存所有文件第一次。这意味着您可能在缓存中拥有不同版本的各种元数据文件，从而导致apt get返回无效的校验和错误。因此，我们必须实施一些调整，使其发挥作用，并充分利用Cloudflare的CDN网络。第一我们添加了一个"Expires"HTTP头来禁用所有永远不会更改的文件的过期。然后，我们添加了另一个HTTP头来标记所有的元数据文件，这样我们就可以通过一个API调用从CDN缓存中手动清除这些文件，我们在后端的存储库更新过程结束时集成了这个API调用服务器。使用nginx在我们的后端，配置如下此：位置/卡利/距离/{添加_头缓存标签元数据，dists；}位置/卡利/项目/跟踪/{添加_头缓存标签元数据，跟踪；过期1小时；}位置/卡利/泳池/{添加_头缓存标签池；位置~\.（deb | udeb | dsc |变更| xz | gz | bz2）${最大过期时间；}}API调用是一个简单的shell脚本，由存储库镜像脚本的钩子启动：#！/垃圾箱/垃圾箱卷曲-sS-X柱"https://api.cloudflare.com/client/v4/zones/xxxxxxxxxxx/purge_缓存" \-H"含量-类型：application/json" \-H"X认证-密钥：XXXXXXXXXXXX" \-H"X-Auth-Email:your-account@example.net" \--数据{"tags"：元数据"]}"通过这个简单而强大的特性，我们确保CDN缓存始终包含元数据文件的一致版本。进一步说，我们可能需要配置预取，以便在用户下载顶级"Release"时Cloudflare立即下载所有包列表文件.In简而言之，我们使用这个系统的方式从来不是有意的，但它是有效的！这确实减少了后端的负载，因为一台服务器可以为整个CDN提供数据。将文件放在靠近用户的地理位置上，允许经典的apt dist升级比以前任何时候都快得多。这是一个巨大的好处，实际上并不是很多工作要设置。在整个过程中，塞维基·哈西尔奇一直陪伴着我们，确保我们提出的任何问题都能得到及时的回答。伟大的赢了。不过，只有一个问题。看在我们的日志中，虽然apt repo运行得很好，但我们的图像分布并不是很好。这些图像都没有被缓存，我们的原始服务器快死了。说话在Sevki中，Cloudflare缓存的文件大小是有限制的。他提高了我们对系统容量的限制，但这仍然不足以满足我们的一些图像有多大。在这一点上，我们只是假设——我们可以将这个解决方案用于回购，但对于我们的图像分发来说，它没有帮助。但是，塞夫基让我们等一会儿。他在工作中有个惊喜我们。之后在开发过程中，Cloudflare推出了一个更新来解决我们的问题，允许我们缓存非常大的文件。有了这一点，一切工作都没有额外的调整。即使是使用下载加速器的用户进行部分下载之类的项目也能很好地工作。太神了！为了展示这个结果的一个例子，让我们看看一些图表。一旦添加了非常大的文件支持，并且我们开始通过Cloudflare推出图像，您可以看到在请求：但是，看带宽有一个明确的增加：之后实施了一段时间，我们看到了一个清晰的图案。这个把我们从一周80 TB左右的容量推到了我们刚刚回购的时候，到现在每月430 TB左右的回购和镜像。可以想象，对于像这样的开源项目来说，这是一个惊人的带宽节约我们的。表演很好，而且缓存命中率超过97%（考虑到回购中的文件更改的频率和频率，这是惊人的高），我们不可能做到更快乐。所以下一步是什么？这是我们在问自己的问题。这个解决方案非常有效，我们正在寻找其他方法来利用它，并且有很多选择。有一件事是肯定的，我们还没有结束这个。谢谢感谢Cloudflare、Sevki、Justin和Matthew，感谢他们在这条道路上帮助我们。公平地说，这是对卡利的最大贡献，这是我们在进攻的支持之外得到的最大贡献安全。支持我们从Cloudflare那里收到的信息非常棒。Kali项目和社区每次更新发行版或下载图片时都会非常感谢您。