摘要：# Ruby on Rails应用被CC攻击？别慌，Rack攻击中间件是你的“守门员” 前两天跟一个做电商的朋友聊天，他愁眉苦脸地说：“网站突然就卡死了，后台一看，全是同一个IP在疯狂刷商品详情页，这算啥攻击啊？” 我一看，这不就是典型的CC攻击嘛——不…

Ruby on Rails应用被CC攻击？别慌，Rack攻击中间件是你的“守门员”

前两天跟一个做电商的朋友聊天，他愁眉苦脸地说：“网站突然就卡死了，后台一看，全是同一个IP在疯狂刷商品详情页，这算啥攻击啊？” 我一看，这不就是典型的CC攻击嘛——不搞垮你服务器，但就是要让你的正常用户打不开页面。

说实话，很多中小型Rails应用，一开始根本没考虑过这种“耍流氓”式的攻击。等真遇到了，要么手忙脚乱加防火墙，要么临时抱佛脚去查资料，结果业务已经受影响半天了。

今天咱不聊那些云里雾里的“高级防护方案”，就聚焦一个最直接、最轻量、也最容易被忽视的防线：Rack攻击中间件。它就像你应用门口的“守门员”，配置好了，能帮你挡掉一大波瞎胡闹的请求。

一、CC攻击到底在攻击啥？先搞清对手

别被术语吓到。CC攻击（Challenge Collapsar），说白了，就是攻击者控制一堆“肉鸡”（可能是被入侵的电脑、服务器，甚至是不安全的IoT设备），模拟成大量正常用户，不停地访问你网站上最消耗资源的页面。

比如：

• 疯狂刷新你的商品详情页（因为要查数据库、加载图片）。
• 不断提交搜索请求（尤其是那种全表模糊搜索）。
• 对准你的登录接口，一遍遍尝试密码（虽然这更像暴力破解，但效果类似）。

它的目标不是打穿你的服务器，而是“堵路”。让你的CPU、数据库连接池、带宽这些资源，被这些垃圾请求占满，导致真正的用户请求排不上队，页面加载慢如蜗牛，或者直接返回5xx错误。

很多刚起步的团队会觉得：“我网站又不大，谁会攻击我啊？” 嘿，还真别这么想。现在攻击成本太低了，有自动化的工具在全网扫描，专找你这种防护薄弱的站点下手，可能是为了练手，也可能是同行使坏。你源站要是还“裸奔”，心里其实已经有答案了吧？

二、为什么Rack攻击中间件是Rails应用的首选“守门员”？

遇到CC攻击，很多人的第一反应是：“快，上高防IP、上WAF！” 这些当然有效，尤其是面对超大流量时。但问题是：

1. 成本高：对于创业公司或小项目，这是一笔不小的开销。
2. 有延迟：配置、调度需要时间，攻击可不会等你。
3. 可能误杀：规则配置不好，反而把正常用户给拦了。

而 Rack::Attack 这个中间件，它的优势就在于 “轻量、快速、精准”。

它直接集成在你的Rails应用里，在HTTP请求刚进来、还没进入你复杂的业务逻辑（比如ActiveRecord查询）之前，就进行判断和过滤。这意味着：

• 零额外成本：就是一个Gem包，不花钱。
• 零延迟生效：代码一改，重启服务，规则立刻生效。
• 规则你定：你可以非常精细地设定，比如“同一个IP，1分钟内访问/products/*路径超过60次，就把它暂时关进小黑屋”。

说白了，它解决的是 “应用层逻辑攻击” 的第一道门槛。把那些明显不怀好意、行为异常的请求，在门口就拦下来，避免它们消耗你宝贵的应用资源。

（我自己看过不少出问题的站点，问题往往不是没上防护，而是防护配错了地方。用高射炮打蚊子，效果不一定好，还费钱。）

三、手把手配置Rack::Attack：给你的Rails应用装上“智能门禁”

好了，干货来了。咱们不谈理论，直接上代码，看看怎么把这个“守门员”请进门。

第一步：请“守门员”入职 在你的 Gemfile 里加上：

gem 'rack-attack'

然后执行 bundle install。

第二步：给“守门员”制定工作手册 创建一个配置文件，比如 config/initializers/rack_attack.rb。核心规则就写在这里。

我来分享几个最实用、能立刻上手的规则配置：

1. 限流规则（Rate Limiting）：对付刷单、爬虫利器 这是最核心的。比如，你想限制对商品API的疯狂请求。

Rack::Attack.throttle('req/ip/product', limit: 300, period: 5.minutes) do |req|
  if req.path.start_with?('/api/v1/products') && req.get?
    req.ip
  end
end

解读一下：这条规则的意思是，同一个IP地址，在5分钟之内，访问 /api/v1/products 开头的GET接口，不能超过300次。超过了？对不起，第301次请求开始，直接返回429（Too Many Requests）状态码，并告诉你稍后再试。

你可以根据自己站点的承受能力，调整 limit 和 period。对于登录接口，限制应该更严格，比如 limit: 5, period: 1.minute。

2. 黑名单（Blacklist）：对付已知的“坏蛋” 如果你已经知道某些IP或网段就是攻击源，直接拉黑，一劳永逸。

Rack::Attack.blocklist('block bad bots') do |req|
  # 匹配User-Agent里包含已知恶意爬虫标识的请求
  req.user_agent =~ /(BadBot|Scanner|HackerTool)/i
end

Rack::Attack.blocklist('block malicious ip') do |req|
  # 直接封禁特定IP
  '123.45.67.89' == req.ip
end

3. 白名单（Safelist）：给自家服务开绿灯 千万别把自己人或者重要的内部服务（比如健康检查、监控爬虫）给误伤了。

Rack::Attack.safelist('allow from localhost') do |req|
  '127.0.0.1' == req.ip || '::1' == req.ip
end

Rack::Attack.safelist('allow our monitoring service') do |req|
  req.ip.start_with?('10.0.1.') # 假设你的监控服务器内网IP是10.0.1.x网段
end

顺序很重要！ Rack::Attack会按 白名单 -> 黑名单 -> 限流 的顺序检查。白名单的请求直接通过，不参与后续检查。

4. 自定义响应：别给攻击者冷冰冰的默认页 默认被限制或阻止的请求，返回的页面可能很丑。我们可以定制一下，让它更友好（或者说，更“气人”）。

Rack::Attack.throttled_response = lambda do |env|
  # 记录日志，方便后续分析
  Rails.logger.warn("[Rack::Attack] Throttled IP: #{env['rack.attack.match_discriminator']}")
  # 返回一个自定义的429响应
  [ 429, { 'Content-Type' => 'text/plain' }, ['嘿，您操作得太快了，请休息一分钟再回来看看吧。']]
end

Rack::Attack.blocklisted_response = lambda do |env|
  [ 403, { 'Content-Type' => 'text/plain' }, ['禁止访问']]
end

四、配置好了就完事了？这些“坑”你得留心

配置不难，但真想让它发挥最大作用，不给自己添乱，有几个点必须注意：

• 别把正常用户给“误杀”了：这是最大的坑。比如，你们公司用的是固定公网IP出口，几十号人都从这个IP访问后台。如果你把对这个IP的限流设得太低，第一个人用得好好的，第二个人可能就被拦了。解决方案：对于后台等高权限路径，最好结合用户登录态（req.session['user_id']）而不是IP来限流。
• 动态IP和代理池：高级点的攻击者会用代理IP池，让你的IP限制规则效果打折扣。这时候，Rack::Attack可以结合一些更复杂的标识，比如对未登录用户，检查其会话ID（Session ID）或某个特殊Cookie的访问频率。虽然不能根治，但能大幅提高攻击成本。
• 别忘了监控和日志：一定要把 Rack::Attack 触发的事件记到日志里。这样当有用户反馈访问不了时，你才能快速定位是不是被规则误伤了，也能分析攻击的模式。上面自定义响应里的 Rails.logger.warn 就是干这个的。
• 它只是“守门员”，不是“钢铁侠”：再强调一遍，Rack::Attack主要防的是应用层的CC攻击。如果对方发起的是超大流量的DDoS（直接堵你的网络带宽），或者专门针对数据库的慢查询攻击，这个中间件就力不从心了。那时候，你需要考虑的是高防IP、高防CDN这些网络层防护，以及优化你的数据库和代码。

五、实战组合拳：Rack::Attack只是第一道菜

在实际的防护体系里，Rack::Attack应该扮演一个精准的、轻量的补充角色。一个比较务实的防护架构是这样的：

1. 最外层（网络/流量层）：如果业务重要且预算允许，上高防IP/高防CDN。它们能清洗掉大部分网络层和传输层的洪水攻击，把“脏流量”挡在机房外面。很多云服务商（比如阿里云、腾讯云）都提供，按量计费其实也没想象中那么贵。
2. 中间层（应用入口）：在你的Rails应用前，用 Nginx 做反向代理。在Nginx里可以做一些更简单的、基于连接数和请求频率的全局限制（limit_req_zone, limit_conn_zone），减轻应用服务器的压力。
3. 最内层（应用逻辑）：这就是 Rack::Attack 的舞台了。进行最精细的、基于业务逻辑的规则判断（比如针对登录接口、搜索接口、API接口的特定限流）。
4. 最后防线（代码和数据库）：做好SQL注入防护（Rails的ActiveRecord其实做得不错）、避免N+1查询、对耗时操作进行缓存。攻击有时候会利用你的慢接口来放大攻击效果。

说白了，安全是个系统工程。Rack::Attack是你工具箱里一把非常锋利、趁手的好刀，但别指望靠它解决所有问题。

写在最后

防止CC攻击，尤其是对于Ruby on Rails应用，真没必要一开始就如临大敌、重金投入。从集成 Rack::Attack 开始，花上半天时间，配置好几条关键的限流和黑名单规则，你就能建立起一道有效的“门槛”。

很多所谓的“全面防护方案”，PPT上写得天花乱坠，真遇到攻击时，可能因为配置复杂反而掉链子。不如就从这种简单、可控、见效快的地方做起。

先把“门”看好，让应用能稳稳地跑起来。等业务真做大了，再根据实际情况，一步步升级你的防护体系，也完全来得及。

行了，代码和思路都给你了，赶紧去看看你的 config/initializers 目录，动手给应用加把锁吧。