分享未来 ^Internet _Technology

最近对Discuz系统的木马清理及防护做了一番学习，对系统安全防护有了如下几点总结。

1. 常规的Linux系统层面的安全防护是基础，不外乎限定公网端口暴露数量以及传统基础服务的安全漏洞修复。

2. 动静态文件的可执行化分离，用户上传的行为文件的有效隔离，确保文件的非可执行。

3. DiscuzX之所以漏洞百出就在于大量使用的eval，exec类系统调用执行函数，同时对用户传递到服务器端的数据没有做统一的类型转换。系统前端有必要增加WAF的接入防护，同时对已经公开的漏洞进行代码级的修复。

4. DiscuzX的系统key都需要进行定期的更换，这两年DiscuzX系统被大规模入侵而导致360搜索引擎被大规模收录非法内容的问题，很多都因为ucenter的key被泄露，导致系统被植入了木马代码。同时dz底层的cookie加密key也有必要定期更换，否则被黑客非法获取后可以在本地搭建还建来模拟任何用户的登录。

5.对于任何PHP的系统都需要做文件MD5值的检查，定时扫描系统所有代码的MD5，避免对文件的直接篡改。

6.黑客对于木马植入不外乎对系统访问权限的渗透，因此除了系统指定的可写目录以外，尽量要避免黑客对非程序代码目录的可侵入性。例如/var/tmp, /tmp 这样的目录，任何权限组都可以写入时也需要定期进行安全扫描，检查这些目录中是否有可疑的文件存在。

7.preg_replace函数中/e 修饰符是非常危险的，在我们的系统中尽量要保证数据传参进来是可控的，如果被黑客利用自定义设定参数给到preg_replace，那么很有可能通过/e修饰符来执行php命令。

8. 黑客入侵修改文件不外乎使用include和requie来调用自己的隐蔽文件，通常为了不明文在代码中包含木马文件地址，会使用pack的手法进行一定的混淆。例如PACK('H*','XXXXX')

这两天线上服务器fpm频繁coredump，strace跟踪到php返回

write(2, "zend_mm_heap corrupted\n", 23) = 23

      用了几年的php今天才注意到在32位环境下php去大数字取模为负数情况存在。在32位php运行环境下，被取模的数字不能大于数字2147483648，除了php手册中说明的采用fmod函数的方式获取正确数值外，现在大部分的服务器已经是64位话，在php编译为64位运行时时，是可以正常支持到更大的取模运算，这时候当数值大于2147483647时取模是不会出现负数的。也就是说当我们php运行在64位环境下同时编译的php为64位版本一般不会出现负数问题，除非你的被取模数字大于9223372036854775808，此时已经超过有符号64位的最大取值范围了。

    注意如果取模数值超过了64位的最大整型值，这时候取模得到的数值都为0。如果更大的数值取模保险的方式还是使用fmod函数，

      今日后端系统发生一次严重的redis cpu 100%异常问题。期初是怀疑系统硬件问题，因为后端代码已经好几天没有发不过，理应是不会突然故障。于是一步步排查，首先从redis本身入手，其本身redis 占用率过高网上的说法也已经概括的比较全面了，不外乎bgsave，keys模糊查找和滥用排序导致redis性能下降。但是从我们本身的系统架构而言，redis的cpu使用率一直都稳定在3%左右，数据大小本身也不高，rdb文件本身也不大只有几百兆，占用的系统内存页也只有整个硬件内存的20%。磁盘io，cpu都很稳定， 

      首先通过strace定位的方法监控php-fpm和redis进程是否有异样，发现php-fpm都卡在和redis的通信上，而redis进程都卡在频繁读写上。info查看redis的total_commands_processed数值，尽然每秒高达20w次左右，我们知道通过redis的benchmark测试redis的性能通常每秒不走pipleline也差不多这个数值了，业务突然能将redis的吞吐能力消耗干净那肯定不外乎受外部大规模的压力攻击或系统内部的死循环导致。

   攻击肯定就谈不上了，nginx上访问日志很正常，通过redis的monitor命令查看redis的实时执行命令，发现全部都是对同一个key进行写入和查询。接着通过get这个key输出的值发现了端倪。继而定位到业务代码中的执行片断。

     问题排查到现在就好解决了，代码级定位发现了原先设计代码中不合理的设计，对于第三方外部接口调用没有采取异常情况的最终返回，导致不停的递归调用了第三方接口，但是第三方接口又因为查询条件的改变，导致始终执行不成功。这样无法缓存正常数据，就导致不停的查缓存和写缓存操作。

    通过这次问题排查和解决，总结了如何使用第三方接口服务的设计原则：

1. 不管如何设计接口切记尽量避免使用递归来请求接口，如果没有捕获到极端异常，有可能导致程序死循环。

2. 所有外部接口都要设计一个最终失败的逻辑。

3. 对第三方接口增加缓存逻辑的同时，一定要对失败的结果也做一份缓存，避免频繁请求第三方接口而导致同步io延时的问题。

4. 千万不要认为大厂的API接口都是极其稳定的，是的！今天遇到的就是百度的云API提供的接口，虽然大厂通常对自己提供的服务接口都有做API自动化测试，但是故障恢复能力并不一定每个业务团队都能及时响应。更不要以为大厂的开发们都是各个经验丰富，知道如何保证API的可用性和稳定性。如果哪天他们升级了代码将接口的传参做了调整，这种对调用方的伤害也是巨大的。一个设计合理的接口一定遵循一点，同版本接口输入和输出必须保证确定性，做了调整的接口一定得区分版本号。