我有一个电子商务网站（基于 OpenCart 2.0.3.1 构建）。我正在使用一个 SEO pack 插件，它保存了 404 错误列表，因此我们可以进行重定向。
从几周前开始，我不断看到大量看起来甚至不像链接的 404 错误：
- 999999.9 //统一//全部 /**/sElEcT 0x393133353134353632312e39
- 999999.9 //统一//全部 /**/sElEcT 0x393133353134353632312e39,0x393133353134353632322e39
- 999999.9 //uNiOn//全部 /**/sElEcT 0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39
- ...依此类推，直到达到：
- 999999.9“//uNiOn//全部/**/sElEcT 0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x39 3133353134353632362e39,0x393133353134353632372e39,0x393133353134353632382e39,0x393133353134353632392e39,0x39313335313435363231302e39,0x3931
这种情况不止发生一次，每个例子中发生过 30-50 次。最新的 404 报告中有超过 1600 行此类错误。
现在，我知道如何对“正常”的断开链接进行重定向，但我甚至不知道从哪里开始解决这个问题。
有什么建议吗？
答案1
如果可以的话，请设置一个不区分大小写的过滤器，如果方法与“选择”匹配，则直接完全断开连接并禁止违规者的 IP。
甚至不要回复。很有可能这是一个正在工作的机器人，如果它开始出现连接失败，那么很有可能它会转向其他人。
答案2
从您使用的工具中，您只能看到 404 Not Found 错误。从安全角度来看，这些是您最不需要担心的。此类活动是自动扫描随机网站以查找内容管理系统、网上商店和类似平台中的漏洞。
这些漏洞大多是过时版本中已知的漏洞。可能有一个 PHP 文件，其中包含一个来自 GET 或 POST 数据的变量，该变量在用作 SQL 查询之前未经清理。虽然问题中的这些行似乎只从数据库中选择信息，本身不会造成任何直接损害，但其目的可能是在实际攻击之前收集易受攻击的站点的信息。
404 Not Found 错误表明他们试图利用的文件根本不存在。如果您处于危险之中，那么它可能已经超出了您的过滤器的范围，被记录为正常的 200 响应，或者可能导致其他问题，例如 500 内部服务器错误。您在错误的地方看到了正确的东西。
可以自动拒绝 HTTP 查询中包含“SELECT”或其他可能恶意的关键字的请求。然后，您可以应用Fail2ban在达到一定数量的请求后阻止某个 IP 的规则。
但是，首先要做的是安装所有安全更新。您提到您使用的是 OpenCart 2.0.3.1。这是两年前的版本！从那时起，修复了很多错误，例如2.1.0.0以及 XSS 问题2.1.0.2，当前版本为 2016 年 8 月发布的 2.3.0.2。至少一些模块在此之后仍存在已知漏洞。兼容性不是借口：您应该首先关注安全性，然后再修复不兼容的组件。