solr DoS 防护

发布于 2024-10-01 19:37:39 字数 236 浏览 1 评论 0原文

我们的网络应用程序最近成为一些 DDoS 攻击者的目标。我们使用 solr,他们通过每隔几秒搜索“**”来设法生成 100% 的负载。有人可以告诉我为什么该查询需要数十秒才能运行,而其他所有操作只需要几毫秒?此外,代码将用户 ID 附加到搜索中,因此查询为“userid: 10 AND **”,这不会真正减慢速度,因为该用户只有 10 个左右的文档。

有谁知道发生了什么事,以及我们如何才能最好地保护自己免受其影响?

谢谢。

Our web app has recently become the target of some DDoSers. We use solr and they managed to generate 100% load by searching for "**" every few seconds. Can someone tell me why that query takes tens of seconds to run, whereas everything else takes just milliseconds? Also, the code appends the user ID to the search so the query was "userid: 10 AND **", which shouldn't really slow down because that user only has 10 documents or so.

Does anyone know what's going on, and how we can best protect ourselves from it?

Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

太阳公公是暖光 2024-10-08 19:37:39

** 被 Solr 解释为带有前导和结尾通配符的查询,并且由于这些不是定义的字段,因此它会出现在您的默认搜索字段中,该字段(正如您在评论中所说)是一个大文本字段。所以它最终会搜索所有内容,这可能就是它花费这么长时间的原因。

解决方案:在将查询传递给 Solr 之前过滤掉应用程序中的 **。如果您不想允许用户发出任何通配符查询,您甚至可以过滤所有 *

** gets interpreted by Solr as a query with leading and ending wildcard and since these is no defined field it lands on your default search field, which (as your said in the comments) is a big text field. So it ends up searching for everything which is probably why it takes so long.

Solution: filter out ** in your application before passing the query to Solr. You could even filter all * if you don't want to allow your users to issue any wildcard queries.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文