Ruby China

部署 爬虫引起的服务器日志泛滥

046569 · 2013年05月29日 · 最后由 huacnlee 回复于 2014年09月10日 · 4712 次阅读

不知道大家遇到过没有: 经常有些爬虫或者扫描器之类的搞的日志很乱 (经常是阿里云的云盾我会乱说么),正常日志被湮没，比如：

Started GET "/register.php" for 110.75.186.226 at 2013-05-23 05:47:32 +0800

ActionController::RoutingError (No route matches [GET] "/register.php"):
  actionpack (3.2.13) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.13) lib/rails/rack/logger.rb:32:in `call_app'
  railties (3.2.13) lib/rails/rack/logger.rb:16:in `block in call'
  activesupport (3.2.13) lib/active_support/tagged_logging.rb:22:in `tagged'
  railties (3.2.13) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  rack (1.4.5) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.5) lib/rack/runtime.rb:17:in `call'
  activesupport (3.2.13) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  rack (1.4.5) lib/rack/lock.rb:15:in `call'
  rack-cache (1.2) lib/rack/cache/context.rb:136:in `forward'
  rack-cache (1.2) lib/rack/cache/context.rb:245:in `fetch'
  rack-cache (1.2) lib/rack/cache/context.rb:185:in `lookup'
  rack-cache (1.2) lib/rack/cache/context.rb:66:in `call!'
  rack-cache (1.2) lib/rack/cache/context.rb:51:in `call'
  railties (3.2.13) lib/rails/engine.rb:479:in `call'
  railties (3.2.13) lib/rails/application.rb:223:in `call'
  railties (3.2.13) lib/rails/railtie/configurable.rb:30:in `method_missing'
  thin (1.5.1) lib/thin/connection.rb:81:in `block in pre_process'
                                                                                     690,3          5%
  railties (3.2.13) lib/rails/railtie/configurable.rb:30:in `method_missing'
  thin (1.5.1) lib/thin/connection.rb:81:in `block in pre_process'
  thin (1.5.1) lib/thin/connection.rb:79:in `catch'
  thin (1.5.1) lib/thin/connection.rb:79:in `pre_process'
  thin (1.5.1) lib/thin/connection.rb:54:in `process'
  thin (1.5.1) lib/thin/connection.rb:39:in `receive_data'
  eventmachine (1.0.3) lib/eventmachine.rb:187:in `run_machine'
  eventmachine (1.0.3) lib/eventmachine.rb:187:in `run'
  thin (1.5.1) lib/thin/backends/base.rb:63:in `start'
  thin (1.5.1) lib/thin/server.rb:159:in `start'
  thin (1.5.1) lib/thin/controllers/controller.rb:86:in `start'
  thin (1.5.1) lib/thin/runner.rb:187:in `run_command'
  thin (1.5.1) lib/thin/runner.rb:152:in `run!'
  thin (1.5.1) bin/thin:6:in `<top (required)>'
  /usr/local/rvm/gems/ruby-2.0.0-p195/bin/thin:23:in `load'
  /usr/local/rvm/gems/ruby-2.0.0-p195/bin/thin:23:in `<main>'
  /usr/local/rvm/gems/ruby-2.0.0-p195/bin/ruby_noexec_wrapper:14:in `eval'
  /usr/local/rvm/gems/ruby-2.0.0-p195/bin/ruby_noexec_wrapper:14:in `<main>'

有没有什么好方法解决呢？设定个规则触发几次 404 就锁 IP???

3 个赞
ywencn #1 2013年05月29日

一个 404 而已，无所谓

046569 #2 2013年05月29日

#1 楼 @ywencn 不是一个 404，而是意味着每周 6 位数以上的无效日志。

leopku #3 2013年05月29日

#2 楼 @046569

这种确实烦人 1、可以装带 lua 的 nginx，用 lua 脚本实现一个几次 404 锁 IP 2、装个 fail2ban，也可以很简单就实现。具体请放狗。

leopku #4 2013年05月29日

此外，可以向大的搜索引擎提交 sitemap

huacnlee #5 2013年05月29日

不知道有没有 Nginx 插件可以屏蔽掉这类无效的请求

KoALa #6 2013年05月29日

这种情况下配置 robots.txt 是否有用？

huaoguo #7 2013年05月29日

#2 楼 @046569 LZ，你做的网站吗？还是博客

tim_lang #8 2013年05月29日

配置下 robots.txt，正规的爬虫都会遵循里面的准则，当然个人写的爬虫的话。。

kgen #9 2013年05月29日

随着网站访问量增大，无效请求的过滤会越来越难，扫到你的各种奇葩扫瞄器越来越多。 fail2ban 能解决同一 IP 的扫瞄，但是有些扫瞄器借助大量 IP 分散开，自动化的工具就搞不定了。 无视它吧，你会习惯的 >_<

046569 #10 2013年05月29日

#3 楼 @leopku 在反代上封锁是个思路，只是学习 lua 要付出额外的时间成本. fail2ban 肯定是不行，像云盾都是虚拟的 IP，会不停的变换。

#5 楼 @huacnlee 暂时没找到

#6 楼 @KoALa #8 楼 @Tim_Lang 应该没用，哪个扫描器还检查你 robots 啊

#7 楼 @huaoguo 网站

#9 楼 @kgen 现在没法无视，分析日志的时候比较烦人

046569 #12 2013年05月29日

#11 楼 @huaoguo 只有个雏形，一键配置 Web 环境。支持 Debian 6.0(完整测试),Ubuntu 12.04 (部分测试). https://ymate.me

leopku #14 2013年05月29日

#10 楼 @046569 fail2ban 用好了很强大 可以设置解封等

reus #15 2013年05月29日

每个网站都会这样的，各种蠢得不行的扫描器，跟它们搏斗很烦也没有必要，因为日志压缩后也不会占多少空间，而且需要分析时可以先手工过滤掉，而不需要从禁止入手。毕竟日志就是日志，发生了什么就记录什么才是正道 比如这个请求的模式就很容易描述，GET ".*\.php$"，过滤掉这个模式的条目再分析就可以了

aptx4869 #16 2013年05月29日

#15 楼 @reus 其实直接在 nginx 里面禁掉好了…… Sending them into the rails server doesn't even make any sense

location ~ ^/.*\.(php|php5)$ {
deny all;
access_log off;
}
1 个赞
reus #17 2013年05月29日

#16 楼 @aptx4869 需要跟踪安全事件时，这些看似无用的记录有可能提供线索的

aptx4869 #18 2013年05月29日

#17 楼 @reus 那把 access_log off 去掉呗，反正不应该让 rails 来处理

046569 #19 2013年05月29日

#14 楼 @leopku 啊，看来我还得认真学学才行. #16 楼 @aptx4869 这办法不错，受教了。

wuwx #20 2013年05月29日

fastcgi_cache_valid 404 60m;

046569 #21 2013年05月29日

#20 楼 @wuwx 还是让 Nginx 直接拒绝掉好些，不应该转发给后端。

sevk #22 2013年05月29日

要求登陆，不然就加限制。锁 ip. 登陆的人也要限制。

046569 #23 2013年05月29日

#22 楼 @sevk 维基之类的让登陆不太好吧

需要 登录 后方可回复, 如果你还没有账号请 注册新账号