【问题标题】:Load spike protection for Django ChannelsDjango 通道的负载尖峰保护
【发布时间】:2017-12-20 17:18:20
【问题描述】:

是否有任何具体措施可以帮助 Django Channels 服务器不易受到轻度或意外 DDoS 攻击或来自 websocket/HTTP 客户端的一般负载增加?由于 Channels 并不是真正的异步(仍然是幕后工作人员),我觉得关闭一个基于 Channels 的网站很容易——即使使用相当简单的硬件也是如此。我目前正在 Django Channels 上构建一个应用程序,稍后将运行一些测试以查看它的运行情况。

Daphne 是否内置了某种形式的节流功能?我应该实施一些应用程序级别的限制吗?这仍然会很慢,因为工作人员仍在处理受限制的请求,但请求可以快得多。我还能做些什么来阻止这些攻击吗?

我的一个想法是始终确保为特定通道指定工作人员 - 这样,如果 websocket 通道过载,HTTP 仍会响应。

编辑:我很清楚低级 DDoS 保护是一种理想的解决方案,并且我了解 DDoS 攻击的工作原理。我正在寻找的是一种内置于通道的解决方案,可以帮助处理像这样增加的负载。也许 Daphne 能够扩大通道并缩小另一个通道以进行补偿,或者可以在某个点之后减少每个请求的权重的节流方法。

我正在寻找一个 daphne/channels 特定的答案 - 关于 DDoS 或一般负载处理的一般答案不是我要寻找的 - 关于 SO 还有很多其他问题。

我还可以根据谁已登录和谁未登录来控制节流 - 未登录用户的节流可能会有所帮助。

再次编辑:请阅读整个问题!我不是在寻找一般的 DDoS 缓解建议或对低级方法的解释。我想知道达芙妮是否支持以下内容:

  • 限制
  • 基于队列大小的动态工作分配
  • 为经过身份验证的请求提供优先级的中间件

或者类似的东西。我还将就此直接与 Channels 社区联系,因为 SO 可能不是解决这个问题的最佳地点。

【问题讨论】:

  • 使用软件防火墙进行 DDOS 保护?我的意见是“敬畏”的想法!在每个请求上读取 60 字节的数据包标头。触发更多拒绝-删除-冻结的功能是system resource 问题。延迟是foregone conclusion。您可能会成功应对低价值攻击,但如何处理系统资源?不能在防火墙上使用任何存储过程,意味着 good_user 与 bad_user 请求。 如果接受了不需要的请求,您将无法保护自己! 如果数据包到达环回 (lo),这并不便宜。

标签: python django websocket django-channels


【解决方案1】:

我只回答第一个问题。所以基本上不可能 100% 保护免受 ddos​​ 攻击,因为它总是归结为资源之战。如果服务器端资源大于攻击者端资源,则服务器不会宕机(虽然可能会降低性能),但如果不是,服务器就会宕机[无需参考]。您可能会问,为什么不可能得到 100% 的保护。所以基本上,如果人们无法连接到它,您的服务器就会“崩溃”[https://en.wikipedia.org/wiki/Crash_(computing)#Web_server_crashes --- Web 服务器崩溃句子 1.]。因此,如果您尝试通过在每秒钟内建立 10000 个连接时将其关闭 5 分钟来保护您的服务器,则 d​​dos​​ 成功。它“崩溃”了你的服务器。我所知道的唯一应该起作用的 ddos​​ 保护是 Cloudfare (https://www.cloudflare.com/lp/ddos-b/?_bt=207028074666&_bk=%2Bddos%20%2Bprotection&_bm=b&_bn=g&gclid=EAIaIQobChMIu5qv4e-Z1QIVlyW9Ch2YGQdiEAAYASAAEgJbQ_D_BwE)。它通过其 10Tbps 的网络主干吸收 ddos​​ 攻击的影响。但即使它不提供 100% 的 ddos​​ 保护,因为一旦它的 10Tbps 关闭,您的服务器也会关闭。所以,我希望这会有所帮助。

【讨论】:

  • 感谢您的回答,@Evgeny,但它并没有真正回答问题。我了解 DDoS 攻击的工作原理,并且我了解您永远不会安全。我也知道存在 Cloudflare 之类的选项,但它们对 websocket 攻击的有效性受到极大限制,因为它们无法提供用户可接受的缓解策略,如 CAPTCHA。我特意询问了使用 Daphne ASGI 服务器构建 Django Channels 站点时的最佳实践。
【解决方案2】:

DDoS = 分布式拒绝服务

“分布式”部分是关键:您无法知道自己受到了“某人”的特别攻击,因为请求来自四面八方。

您的服务器将只接受一定数量的连接。如果攻击者设法创建了太多其他人无法连​​接的连接,那么您就是被 DDoS 攻击了。

因此,从本质上讲,您需要能够检测到不合法的连接,或者您需要能够快速扩展以弥补连接数的限制。

祝你好运!

DDoS 保护实际上应该是您的云提供商提供的负载均衡器级别的服务。

像 OVH 这样的公司使用复杂的机器学习技术来检测非法流量并准实时禁止 IP。 对你来说,构建这样一个检测机器是一项巨大的投资,可能不值得你花时间(除非你的网站非常重要,如果它暂时关闭将损失数百万美元)

【讨论】:

  • 嘿@MrE,当然。我完全理解云级保护更好,但我也在询问负载的意外问题。诸如节流之类的东西会减少每个请求的影响量,或者特定于渠道的东西可以提供帮助,例如允许 Daphne 缩小某个渠道以补偿另一个渠道。 websockets 的问题在于它们很难保护。我会更新我的问题以更清楚一点。
  • 单个 websocket 中的流量实际上取决于您的应用程序,如果您预计流量较低(如聊天频道),那么油门是一个很好的解决方案:暂停或踢出任何正在发送的人许多消息。对于物联网数据等其他事物,您还应该有预期的数据速率。总的来说,节流似乎是个好主意。
  • 但处理未知流量的最佳方法是不使用您的 websocket api 服务器处理任何内容,而是直接将消息发送到消息队列(如 Kafka、RabbitMQ),然后可以处理峰值和将消息推送到实际处理处理的进程。
  • ...这就是频道的作用。再说一次,@MrE 我真的很想从这里的 Django 频道社区中寻找一些见解。
【解决方案3】:

关于 DDOS 有很多事情你不能做。但是有一些巧妙的“技巧”取决于你有多少资源可供使用,以及有多少人想让你下线。

您是否提供需要直接连接到您要保护的资源的全面公共服务?

如果是这样,您只需要利用您拥有的资源“吸收” DDOS,通过扩展和扩展......甚至弹性......无论哪种方式都会让您花钱!

或使攻击者更难消耗您的资源。有很多方法可以做到这一点。

如果您的服务需要某种身份验证,请将您的身份验证服务与您尝试保护的资源分开。

许多应用程序、身份验证和“服务”在同一硬件上运行。那就是等待发生的 DOS。

仅允许完全通过身份验证的用户访问您尝试使用动态防火墙过滤规则保护的资源。如果您已通过身份验证,那么通往资源的大门就会打开(使用受限的 QOS)!如果您是知名且长期受信任的用户,那么请尽情访问该资源。

有一种审计用户资源行为(网络、内存、cpu)的方法,如果您看到特定帐户使用了奇怪的数量,则禁止它们或施加限制,最终导致其流量的防火墙丢弃策略。

与 ISP 合作,该 ISP 的系统可以在 ISP 边界按照您的规范丢弃流量……OVH 是您的最佳选择。一个将过滤器和流量丢弃作为 API 公开的 ISP,我希望它们存在...基本上将您的防火墙过滤规则移至 AS 边界... niiiiice! (幻想)

它不会阻止 DDOS,但会为您提供一些工具,将资源浪费和攻击者的消耗保持在可管理的水平。 DDOS 必须求助于您的身份验证服务器...(可能),或者破坏许多用户帐户...。在已经通过身份验证的用户仍然可以访问 :-)

如果您的 DDOS 占用了您所有的 ISP 带宽,这是一个更难的问题,请移至更大的 ISP!或移动 ISP 的... :-)。隐藏你的主要资源,让它动态移动,继续移动! :-)。

将问题分解成小块...对较小的部分应用 DDOS 控制。 :-)

我尝试了一个最通用的答案,但有很多依赖项,每个 DDOS 缓解都需要一些皮肤,而不是锡方法。真的,你的团队需要一个反 ddos​​ 忍者。 ;-)

看看分布式协议.... DP 可能是 DDOS 的答案。

玩得开心。

【讨论】:

    【解决方案4】:

    让我们对您的问题进行一些分析。 DDoS 类似于 DoS,但有朋友。如果你想避免 DDoS 攻击,你需要尽量减少 DoS 的可能性。很明显,谢谢capitan。

    首先要做的是列出系统中发生的事情以及受影响的资源:

    • 已执行 tcp 握手(SYN_COOKIES 受到影响)
    • 稍后会进行 ssl 握手(熵,cpu)
    • 与通道层建立连接...

    然后监控每个资源并尝试实施对策:

    • 保护 SYN_FLOOD 配置您的内核参数和防火墙
    • 使用熵生成器
    • 配置您的防火墙以在短时间内限制打开/关闭连接(最大限度减少 ssl 握手的简单方法)
    • ...

    将您的大问题 (DDoS) 分成许多简单且易于纠正的任务。困难的部分是获得详细的步骤和资源列表。

    请原谅我的英语不好。

    【讨论】:

    • 队长?船长?
    • 嘿@lasizoillo,感谢您的回复。正如我在其他答案中提到的那样,我真的在寻找有关达芙妮对这种事情的支持的信息。一种处理大型队列的方法,优雅地为特定通道生成更多工作人员,甚至是某种限制。我知道真正的 DDoS 保护是在低得多的级别上完成的,但我正在寻找有关 Daphne 和 Django Channels 应用程序级别支持的信息(想想像 DRF 的节流之类的东西)。
    【解决方案5】:

    我收到了来自Andrew Godwin 的answer。他不使用 StackOverflow,所以我代表他在这里发布。

    嗨,杰米,

    目前 Channels 对限制的支持非常有限 - 它几乎包含用于传入连接的可调整通道大小,当满时将导致服务器返回 503 错误。由于通道设计,工作人员根据可用性进行负载平衡,因此工作人员没有获得比其他工作人员更大的队列的风险。

    提供更高级的 DoS 或 DDoS 保护可能不是我们在 Channels 本身范围内可以做的事情,但我想确保我们提供适当的挂钩。您认为我们可以实现哪些特定的东西来帮助您编写一些您需要的东西?

    (同样值得记住的是,作为重大重写的一部分,现在我们正在实质性地改变工作者/消费者的布局,这意味着在缩放时需要考虑不同的因素,所以我不想给出太精确建议)

    安德鲁

    他还在blog 中写过关于 2.0 迁移的文章。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2010-09-19
      • 2012-04-06
      • 2023-03-27
      • 1970-01-01
      • 2014-05-29
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多