偶尔我翻阅我们的（apache）访问日志，我经常碰到试图钓鱼pipe理页面的人。 例如，他们试图访问页面，如：
/wp-login.php /administrator/index.php /admin.php /user 这些页面/目录都不存在，因为它们从来没有，或者我已经把它们重新命名为不太明显的东西。
那么，人们是否积极地阻止了这种要求呢？ 我有时候会这么做，但是我得到了很多，而且我想知道它是否会有所不同。 目前我阻止在我的httpd.conf文件中的主机或IP。
我担心什么都没有？
（仅供参考 – 在基于'linux'的服务器上运行Apache）。
编辑：从“子企业”（中小企业水平）的angular度来看。
在防火墙级阻止这样的请求有一些优点，即：
你提到阻止httpd.conf中的主机。 这是没有用的..机器人无论如何收到一个404，它不利于你也不伤害他们任何发送一个不同的错误代码（这是所有阻止在httpd.conf将要做）
在httpd.conf中拦截的唯一好处是，一个恶意主机现在试图破解一个不存在的页面，可能会在之后尝试破解一个真实的页面。 当然，通过在防火墙级别阻止以及上述其他优点，您也可以获得相同的好处。
tl; dr：使用fail2ban阻止请求，而不使用httpd.conf
有些人阻止了这些请求。 但是，这样做是没有意义的，因为它们是无害的。 爬行者一直在抓取互联网寻找东西，无论是黑客还是要索引的东西。 这些types的扫描是不值得的阻塞的麻烦，并且你的阻止可能实际上最终阻止索引或捕获一个真正的用户与这样一个机器人（很less）共享一个IP。
如果日志条目困扰你，你应该使用日志聚合器; 看日志很烂，你会错过的东西，你会注意到这样的不相干的东西。
在我们的组织中，我们使用Web应用程序防火墙（来自F5的应用程序安全模块[ASM]）来阻止这些types的请求。 它首先学习可接受的URL数据库。 它足够聪明地找出所有的静态链接以及可能是可变的链接。 例如，如果请求中包含令牌或唯一标识，则会根据过去所看到的内容强制限制URL中的标识或唯一标识。 此外，它还有一个定期更新的数据库，其中包括SQL或BASH中的URL或用户代理string。
虽然你现在看到的攻击types可能并不脆弱，但是你不能保证你将来不会受到攻击，或者你很容易遭受到你还没有看到或尚未被发现的东西。 此外，像这样的解决scheme可以帮助防范DDoS攻击。 你知道，你经常被定位，这可能会导致你的基础设施处理成本降低。 如果你知道你经常被定位为1）有人真的很难进入，2）你是一个明显的目标，或3）你是一个高价值的目标。 最常见的是2），最常见的是来源广泛的来源，因此不容易被封锁。
至于是否值得这么做，这确实是一个商业决定。 您必须权衡潜在违规的成本与解决scheme或解决scheme的成本，就像拥有保险单一样。 它可能无法覆盖所有情况，它可能永远不会有回报。 或者它可能是拯救你的东西。