网站篡改历来是站长的噩梦，不仅防不胜防，处理不好更是及其顽固，没完没了。藏书阁笔者从业12年，曾以为处理过不少这方面的问题，特别是在DEDECMS的年代，更是经常要处理篡改问题。今天我们来回顾一下独立站安全：网站被篡改了应该怎么处理？这个问题应该如何解决。
安全问题：页面篡改
涉及站点：3
问题描述：
该安全涉及3个站点，这3个站点因为是我们分公司的站点，并且处于无人打理的状态，所以安排在我手中帮忙维护，但不久后我就发现，其中一个站点常常被篡改（我们将它成为站点A），而篡改后出现了一些情况，这些情况就是：被篡改后的网站会丢失所有的跳转功能，只剩首页可以访问，其它的链接均无法再正常使用，于是我就找到了该站点使用的CMS，并恢复了被篡改的文件，删除了多余文件，然后就不再重视。而C站点在沟通后因为没有了备份文件，托管方也放弃了该站点的运营，所以我们就当它是2个站点吧。
后来同事告知站点B出问题了，我查看后同样是因为页面被篡改了，这个时候我意识到，问题有点大条了，然后就开始找问题，甚至用了1周去研究Web运行日志，防火墙也安排上了，这些问题依然存在，而且我确定B站点的所有有问题的文件我都已经处理了，包括插件也卸载了不少，经过半个月的时间这个问题仍然无法解决。
可能没有处理过安全问题的朋友不是很清楚，这是一个极为复杂且繁琐的过程，当你的三板斧砍出去后仍然无法收到效果，那么你就应该考虑静下心来做好持久战的准备了，因为这不是一时半会能够解决的了，需要分析各方面的原因，侵入口等等方面才能解决。
而在这一次我处理B站点的时候我犯了一个错误，我将重心放在了B站点，我直接锁定B站点的所有文件，它仍然被篡改。这时候我才意识到，有可能是A站点被攻击从而污染了B站点，而事实也是如此。
处理方法：
在意识到A站点是感染源后我开始分析A站点，并查阅它的运行日志，最终我在计划任务里发现了猫腻，原来最根本问题是B站点的篡改是被A站点的计划任务污染篡改的，问题已经定位到了那么我就开始着手处理问题。在试验得到B站点的篡改来源后我发现，入侵者是通过访问B站点的计划任务文件（WP中的cron.php）执行的篡改，并且它的访问来源是A站点，也就是：入侵者通过访问B站点WP计划任务入口->A站点触发了系统级计划任务实现篡改->完成AB站点篡改，这样的一个流程。
而我的处理方式也很简单，由于网站性质的问题，我直接将B站点的Cron.php这个WP的计划任务执行文件给禁用了，在禁用了这个文件后，通过半个月的观察，这两个站点就再也没有被篡改了。
常规安全处理流程
经过完整的案例分析，我们继续说一下外贸独立站被篡改后常规排查要点：
- 删除可疑文件，对比WP文件（可以用Wordfence Security这个插件进行对比查找），在删除前截图记录该文件的生成日期。
- 分析log日志，按截图上的文件日志着重分析该时间段前后。
- 分别设置不同目录权限，避免非写入目录拥有777 （读、写、执行的最高权限）或者755（非管理员账户读、写）权限。
- 观察清理后是否仍然存在被篡改的安全问题。
- 通过结合Log日志的请求URL查找可疑链接，检查所有安装的插件/主题是否存在问题。
- 检查计划任务.
结语： 通过例子分析，我们总结出了一个问题，在处理安全问题中我们应该全面考虑，多关注有问题的所有站点，因为有可能是因为服务器权限失守导致的站点污染。同时也需要及时处理安全方面的问题，不能因该站点缺乏权重而置之不理，否则将会出现更大的问题，亡羊补牢，为时未晚！ 我们也应该定期备份站点文件以及数据库，以备不时之需。
