问题描述
在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”，主机：已删除
我的服务器上没有任何ENV文件，Nginx似乎阻止了请求，因此感觉没有任何危害。重新启动所有的测功机似乎已终止了该活动（基于已经过去的几个小时），但令我担心的是，这些测功似乎是“从室内来的”。这里有什么我应该关注的吗？这是一种机器人利用具有本地访问权限的系统中的错误的情况吗？
解决方法
对/.env的请求绝对是恶意的。
许多应用程序（例如基于Laravel的文件）都使用.env文件来保存非常敏感的数据，例如数据库密码。黑客/他们的自动化脚本试图检查.env是否可以公共访问。
如果他们首先可以将.env文件变成红色，则表明服务器配置不正确，并且服务器管理员以这种不良方式设置了服务器，应视为造成后果的原因...
后果通常是一回事。黑客一旦获得.env数据，便拥有数据库凭据，并且几乎没有嗅探就能找到PhpMyAdmin的URL。因为通常，所以“错误的配置”包括可公开访问的PhpMyAdmin。
您所知道的接下来的一件事，他们会通过电子邮件向您发送电子邮件，告知您数据库已消失并且拥有数据库。除非有备份，否则取回它的唯一方法是支付一些加密货币。
该做什么
首先确保.env不在可公开访问的目录中。
即使是，也要让NGINX拒绝访问它们，例如拒绝访问所有隐藏文件：
location ~ /\. {
deny all;
}
无论您的系统上是否有任何.env文件，都可以确保与在Web上请求它们相关的流量是恶意的。为减少任何CPU负载并阻止他们进一步尝试查找网站漏洞，您可以使用honeypot approach，例如：
location ~ /\.env$ {
include includes/honeypot.conf;
}
...将针对试图读取.env文件的IP触发立即防火墙禁令。
事实证明这很有用，因为.env的利用可能只是许多其他攻击中的一种，而且由于相关IP被阻止，因此无法再尝试了。