问题标签 [rackattack]

我试图了解rack-attack如何使用 memcached 来限制连接。

据我所知，没有简单的方法来管理 memcached 中的列表，也没有办法通过 prefix 搜索键。然而，机架攻击以某种方式将列表计数保留在缓存中，但我盯着源代码却不知道它是如何工作的？

https://github.com/kickstarter/rack-attack/blob/master/lib/rack/attack/throttle.rb https://github.com/kickstarter/rack-attack/blob/master/lib/rack/attack /cache.rb

我已经gem rack-attack为我的应用程序设置了。我想开始限制基于 IP 的基本身份验证。

我的基本身份验证代码设置如下：

我想我的机架攻击将包含以下内容：

我正在我的 rails 应用程序中实现 Kickstarter 的 Rack-attack。

白名单/黑名单过滤工作正常，但我在使用 Allow2Ban 锁定影响我的登录（设计）页面的 IP 地址时遇到问题。注意：我在本地对此进行了测试，并已将 localhost 从白名单中删除。

在 Rack-attack 文档中，它明确指出限制功能需要缓存，即：

，但它没有为 Allow2Ban 说明这一点。任何人都知道 Allow2Ban 是否需要缓存，或者我是否在 Devise 登录页面上使用上面的代码错误地实现了

我正在尝试创建一个 IP 地址数组，以便在运行应用程序时，Rack-Attack 可以从允许访问应用程序的 IP 地址集中识别。所以我所做的如下：

上面的工作，所以本地主机可以访问应用程序，但我已经尝试了以下似乎无法正常工作的以下内容：

有人可以解释这样做的正确方法是什么。你可以看到我创建了一个数组。我想Rack::Attack检测阵列中的IP地址是否可以访问。

Rails 应用，使用 Kickstarter 的rack-attack

在我的 config/rack-attack.rb 文件中，我有：

在我开始使用 CloudFlare 之前，这一直很好。req.ip 现在是 Cloudflare IP 与实际最终用户的 IP

尝试将用户的 IP 保存到我的服务器日志（正在保存 Cloudflare IP）时，我遇到了类似的问题。为了解决这个问题，我在我的应用程序控制器中添加了以下内容：

为了在机架攻击中使用 HTTP_CF_CONNECTING_IP 作为 req.ip 是否有类似的过程？

我有兴趣使用https://github.com/kickstarter/rack-attack来扼杀滥用者和暴力攻击者。我的应用程序在多个 dyno 上运行，所以我认为 Rails 默认 FileStore 并不完全有效，因为每个 dyno 都有一个文件系统，并且节流需要是两者的总和。

如果我要使用 memcached 插件服务Rails.cache，如果 memcached 服务出现故障（例如，对 FileStore 来说），Rails 中是否有内置的“回退”？

如果没有，随着 memcached 服务的中断，rails 应用程序是否会崩溃或用户无法访问（与优雅地处理错误相比）？

我正在使用https://github.com/kickstarter/rack-attack/#throttles来限制对某些 url 的请求。

Rack-attack 文档展示了如何通过请求 IP 或请求参数来限制，但我想做的是限制每个用户的请求。因此，无论 IP 是什么，用户都应该能够在特定时间范围内发出不超过 n 个请求。

我们使用设计进行身份验证，我想不出一种简单的方法来根据请求唯一识别用户。

我应该将用户 ID 存储在会话/cookie 中吗？也许是一个独特的哈希？你对最好的方法有什么看法？

我已经按照高级配置说明设置了机架攻击配置。我正在使用 Heroku 并确认 env 变量包含所有 url 并且所有内容都正确格式化。

我什至进入 Heroku 的控制台并运行以下命令：

然后测试：

我得到：

但在我对谷歌的分析中，推荐人充满了我列表中的每个网址。我错过了什么？

我的配置包括这个非常标准的块：

HEROKU_VARIABLE =>

首先让我说我是我为确保 SQL 注入攻击失败而采取的措施的知己。所有 SQL 查询值都是通过活动记录准备语句完成的，所有运算符（如果不是硬编码）都是通过数字白名单系统完成的。这意味着如果有人想通过“ILIKE”搜索，他们将传递 6，如果他们想通过“=”搜索，他们将传递 1，等等。

我还定期使用Brakeman和Rails SQL 注入指南来审查代码。

因此，我想阻止尝试的 SQL 注入器还有三个剩余的原因。

1. 我们有很多脚本小子试图破解我们。其中大多数已经至少被阻止一次，因为我们有一个文件扩展名白名单系统，当他们尝试请求 php 文件时会阻止其中的大部分。虽然他们第一次被列入黑名单，但在第二轮他们通常会试图向我们扔 SQL 注入书。所以我想尽早标记这些小子以节省带宽，如果一个真正的演员在哪里攻击我们，很容易将它们从所有脚本小子中分类出来。
2. 放慢任何探索我们防御的尝试。这不会真正影响复杂的分布式攻击，但可能会减慢介于脚本小子和超级黑客之间的演员。
3. 标记所有被阻止的请求并设置日志通知，然后我们的日志服务将通知我们，以提高我们的安全意识。

目前我的想法是针对请求路径和参数运行一个简单的正则表达式匹配，以标记最公然的 SQL 注入尝试并将这些 ip 列入黑名单，所以像这样，使用rack-attack。

我的问题是创建一个正确标记简单 SQL 注入尝试的正则表达式，但不会对普通用户造成任何问题。我认为一些误报是可以的，这就是为什么上述黑名单系统在第一场比赛后没有列入黑名单的原因。

在我的搜索中，我发现了一些关于这个主题的问题，但它们似乎都像这样，有人问关于使用正则表达式检测 SQL 注入的问题，另一个人回答你不应该以这种方式停止 SQL 注入，提出问题的人回答说他们不会使用正则表达式来停止，而只是为了检测，然后一堆无用的评论随之而来。

那么，这样的正则表达式是否有可能仅作为一种检测手段起作用，并且误报率极低，或者这是一个不值得努力的兔子整体吗？

我使用 Rack::Attack 的示例节流代码。

这在我们的暂存服务器上效果很好，但立即遇到了生产限制，因为 req.ip 返回的是负载均衡器的 IP 地址，而不是客户端的 remote_ip。

请注意，remote_ip 是 ActionDispatch::Request 中的一个方法，但不是 Rack::Attack::Request 中的一个方法。

我们在 Ruby 2.2 上使用 Rails 3.2.2。