今天收到某白帽子报告说通过某漏洞把我们的服务器拿下了，一下子让已经忙碌不堪的我更加忙碌了，在这里就只做简单的总结：
1、 原因：YS使用的某kf系统存在上传漏洞，在网上没有搜到任何信息，可能是0day，也可能是未公开的（漏洞细节暂不公开）。
2、 危害：白帽子通过该漏洞上传木马拿下了我们的kf服务器。
3、 风险分析：由于该业务相对独立，且用到了第三方小厂商的软件，当初就感觉风险不可控，故未部署在生产平台而是在体验测试平台，做了单独隔离，业务本身也没有特别敏感的数据，总体风险较高，当相对可控。
4、当前应急处理措施：
（1）、迅速跟开发和运营沟通，发现上传功能用户使用频率低，故马上要求立马打补丁将上传漏洞关闭，但该业务系统不能关闭。
（2）、使用跟踪查杀软件对当前服务器文件查杀木马，经手动确认，发现了一大波木马！从日期上看，该服务器已经被控制一段时间了，感觉无法再继续使用，经询问，之前曾经使用过另外一套某大厂商用户量较大的免费kf系统，故要求开发人员先暂时切到这套系统先用着，也能保障业务的连续性。
（3）、申请新服务器并重新搭建一套新的kf系统，丢弃原有kf系统留作分析用。在新系统中关闭上传功能，并且修改原有kf系统中使用到的所有账户密码（比如数据库连接账户），删除掉所有不相关目录的执行权限（特别是上传目录）。
（4）、在新系统中部署相关入侵检测和日志分析，增强抗攻击能力，增加相应的报警机制。
（5）、平行排查，排查和这台服务器相关联的服务器。同时排查YS使用的所有第三方应用系统，要求进行功能裁剪，定制到最小化，收缩攻击面。
（6）、重新进行深度渗透测试。
总结：
从这次事件看，有很多事情显然是前期没做好导致的后期出现这种问题，可以从SDL流程去看这些问题。
（1）、需求阶段：应当考虑使用大厂商，或者开源的已经很多人在使用的产品，从安全性讲，各方面都比闭源的小厂商项目好很多。
（2）、开发阶段：虽然系统非自研的，但我们完全可以要求厂商定制我们的安全需求，毕竟这是收费项目。比如上面说的功能裁剪也是可行的，当然，如果有魄力的话，也可以要求厂商提供安全开发规范和产品相关安全评估报告。
（3）、测试阶段：虽然也经过安全测试，但显然还没有全身心的投入，否则理论上也应能发现此问题。但人力不足的情况下对于使用的第三方系统往往不会投入过多时间，如上第3点所述，在没有敏感业务数据的情况下，只好做特殊的隔离部署，出现问题时损失也能降低到最少，除此之外，需要尽快部署自动化扫描系统上线来解决人力不足问题。
（4）、运维阶段：虽然在业务隔离上做了文章，但显然入侵检测、日志分析和安全加固等都没做好，公司虽然在安全运维这块投入少得可以忽略不计，但是也是有很多免费的安全防护软件或者开源IDS/IPS可以用的，当然能说服领导上阿里云则更轻松了。
（5）、从大流程讲，安全发布流程存在漏洞，亟需完善和优化，具体细节就不说了。
总而言之，开发、安全渗透组和运维安全组都该拉出去各打50大板！
