logging - 将 NGINX 中的 403 错误重定向为 null 或静默

Question

我没有在网上找到这方面的帮助，也没有找到我需要做的事情的文档……这个问题是一个几乎和问题一样多的解决方案。现在我需要一个解决方案。任何关于如何控制 nginx 错误输出的文档的答案或链接都会很棒。

初步解决方案及情况:
我有一个 PCI 安全网络服务器。对它的攻击是家常便饭。一切都很好，处理负载低，日志文件只有 30-40MB，直到 OpenVAS 在网络上发布。

然后我的服务器流量激增，nginx 使用率上升了 400%，PHP 后端使用率上升了 5000%。日志跃升至 130+MB。这一增长完全是许多新的 IPS 使用新工具包探测盒子的结果。它淹没了后端，我不得不用一些激烈的东西来回应......

现在 cron 会定期检查日志；任何 IP 在一小时内请求 >X00 个请求、请求已知的 URL hack 或其他逻辑；被添加到阻止列表并重新加载 nginx 以消除攻击。在此之后，大多数事情都恢复了正常。

新问题:

我需要帮助，是 nginx 如何处理拒绝。

当我过去查看我的错误日志时，我发现了 10-100 行错误或通知，我需要查看、更正并向上推以保持盒子的安全和整洁。

然而，Nginx 认为每次拒绝都是一个错误……我的每周错误日志现在是 300,000 行:

2015/11/15 23:01:30 [error] 22040#0: *432212 access forbidden by rule, client: z.z.z.z, server: secure.mydomain.com, request: "GET /cadcd01153160add.aspx HTTP/1.1", host: "x.x.x.x"

有 100 行错误，我需要解决其中的一些问题......

是的，我可以过滤掉它们，但是这个函数现在将访问日志中的条目复制到错误日志中，因此原来的 35MB 访问 + 100 个错误行日志现在定期为 270MB。如果这种情况继续下去，我可能需要为日志获取单独的驱动器! (因为攻击正在增加)所以单个盒子可以处理负载并阻止攻击，但造成了日志文件大小限制的致命弱点。

如何将“403”抑制或重定向为不是错误并防止它淹没日志文件，以便我可以减少重复条目、日志大小(错误日志)并更轻松地执行我的例程？

Answer 1

我们在创建 CMS Effcore 时遇到了这样的问题。决定使用结构“deny all; error_log off;”。其应用示例如下所示。

server {
  listen 127.0.0.1:80;
  server_name 127.0.0.1;
# block access to "web.config"
  location ~ /web.config$ {deny all; error_log off;}
# block access to ".htaccess", ".git" and etc.
  location ~ /\. {deny all; error_log off;}
# single entry point to index.php?q={REQUEST_URI}
  location / {
    root %%_root;
    fastcgi_index index.php;
    fastcgi_pass 127.0.0.1:9000;
    include %%_include;
    fastcgi_param SCRIPT_NAME /index.php;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
  }
}