use*_*143 4 php security nginx heroku websecurity
在 Heroku 托管站点上遇到一些间歇性 5xx 错误后，我只是在查看我们的日志，在那里我发现了许多来自 localhost 的错误，这些错误是对隐藏文件的请求，通常是 .env 以及诸如“.well”之类的东西-known/assetlinks.json”，偶尔在不存在的子文件夹中包含 .env。
请求不频繁（每天 15 - 30 个），但似乎已经持续了一周。他们还遇到了“规则禁止访问”，据我所知是 nginx。
该请求类似于：
2020/09/28 14:37:44 [错误] 160#0：*1928 规则禁止访问，客户端：10.45.153.152，服务器：localhost，请求：“GET /.env HTTP/1.1”，主机：REMOVED
我服务器上没有任何 ENV 文件，而且 nginx 似乎阻止了请求，所以感觉没有任何危害。重新启动所有 dynos 似乎已经终止了活动（基于已经过去了几个小时），但让我担心的是这些似乎是“来自房子内部”。这里有什么值得我关注的吗？这是一个机器人利用具有本地访问权限的系统中的错误的案例吗？
请求绝对/.env是恶意的。
许多应用程序（例如基于 Laravel 的）使用.env文件来保存非常敏感的数据，例如数据库密码。黑客/他们的自动化脚本试图检查是否.env可以公开访问。
如果他们首先可以红色.env文件，这表明服务器配置不当，服务器管理员以如此糟糕的方式设置服务器，应承担后果......
结果通常是一回事。黑客一旦获得了.env数据，就拥有了数据库凭据，并且几乎不需要嗅探，就能找到 PhpMyAdmin 的 URL。因为通常，“错误配置”包括可公开访问的 PhpMyAdmin。
接下来你知道，他们通过电子邮件告诉你你的数据库已经消失，他们拥有它。取回它的唯一方法，除非你有备份，否则就是支付一些加密货币。
首先确保.env不在可公开访问的目录中。即使它们是，让 NGINX 拒绝访问它们，例如拒绝访问所有隐藏文件：
location ~ /\. {
deny all;
}
无论您.env的系统上是否有任何文件，您都可以确定与在 Web 上请求它们相关的流量是恶意的。为了减少任何 CPU 负载并防止他们进一步尝试查找网站漏洞，您可以使用蜜罐方法，例如：
location ~ /\.env$ {
include includes/honeypot.conf;
}
... 将立即触发防火墙禁止试图读取.env文件的 IP 。这证明是有用的，因为.env利用可能只是许多可能的其他攻击中的一种，而且由于相关的 IP 被阻止，它不能再尝试了。