☰

处理 Nginx http 站点上的目录/路径遍历攻击的最佳方法

tag-icon • tag-icon nginx security
处理 Nginx http 站点上的目录/路径遍历攻击的最佳方法

我有一个 Node.js 驱动的网站在 Docker 容器中运行，还有一个由 Nginx 服务器驱动的面向公众的代理网站，它将流量重定向到 dockerized Node.js 网站。研究 Nginx 日志，我发现各种路径上都存在大量目录/路径遍历攻击：

GET /.env
GET /phpmyadmin/index.php
GET /owa/auth/logon.aspx
GET /+CSCOE+/logon.html
GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application
GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f
GET /core/.env
GET /.vscode/sftp.json
GET /.git/config
GET /info.php
GET /config.json
etc.

目前，所有这些尝试都已得到妥善处理并返回 http 404 响应。但是，我不喜欢用所有这些虚假请求来打扰 dockerized 站点，因此我开始在代理站点的 Nginx 配置中包含一长串位置指令：

    location = /phpmyadmin/index.php {
        return 404;
    }
    location = /.env {
        return 404;
    }

但实际上，为他们提供正确的 404 响应难道不是太过荣幸吗？也许他们应该得到一些更狡猾的响应，比如永远无法正确完成的响应，或者其他类似的东西。此外，用新类型的路径更新网站配置也有点累人。使用正则表达式可以稍微缩短它，但不会缩短太多。

什么方法被认为是处理此类攻击最合适的方法？

答案1

这不是攻击，只是对可能位于 Web 根目录中的常见文件进行（可能自动）搜索，类似于使用端口扫描检查开放端口的方式。这既不罕见，也并非天生危险。

如果你想尽早拒绝此类请求，那么最好的方法是列出一个路径白名单，想由 Node.js 服务器处理。例如，如果所有有效路径都以 开头/api，则为location该路径创建一个块并拒绝所有其他带有 404 响应的请求。此外，作为预防措施，您可以将特定路径列入黑名单，以.git防止敏感文件在意外进入 Web 根目录后被提供。

发送“不正当”的响应并不是一个好主意。首先，完全合法的客户端（甚至可能是您自己的应用程序）可能会发送无效请求。总是可能存在错误或配置错误，并且白名单或黑名单在一段时间后可能会不同步。在这种情况下，您需要一个适当的响应来检测和修复问题。其次，自动扫描器会寻找有趣的响应。如果您的服务器发送了标准 4XX 响应以外的内容，您最终可能会引起更多关注并引发实际攻击。

相关内容