年，我是看着《我的华为十年》这篇文章进入这家公司的，当时我的总监就是这篇文章的作者家俊。转眼云烟，第一份工作做到了现在。上篇主要记录了我工作前几年的经历，如果没有几个重要的事情发生，我很可能在所谓的甲方安全道路上继续磨磨唧唧走下去了。与乏陈可述的前几年比起来，后面几年的经历还算有趣。另外上篇发布后，不少人看标题以为是阿里菜鸟的工程师写的，为了避免不必要的尴尬，我改成了土鳖工程师的奋斗史，为了避免不必要的麻烦，详细的技术指标进行了模糊化描述。
云安全部成立
在很长一段时间，我们没有安全部，安全的职责分散在技术体系下不同部门的几个组里面。早期问题并不大，大家各司其职，但是当公司发展到一定程度后，对外的产品线日趋繁杂，内部的协同配合压力日趋变大。于是在某年某月的某一天，我们几个分散的小组合并成立一个新部门，曰云安全部。人员合并后按照每个人的技能重组团队，我负责基础架构安全的team，曰isec，职责范围包括内部网和生产网。我的核心team成员也是从那个时候一直和我到现在，现在想想也真不容易。
与内网相比，生产网有趣很多，安全工程师的压力也大很多。物理服务器的数量达到数万甚至数十万，虚拟机以及容器数量起步价也是百万级了，出口带宽几百G的机房遍布全球，涉及的产品线更是复杂到令人发指，只要想的到的业务几乎都有，想不到的没准也有。相对内部网，生产网攻击面大很多，毕竟这些业务是7乘24对数亿网名提供服务的。我们面对的最大挑战就是如何在业务不中断，不损失访问流量的情况下保障业务的安全。因此我们的重点一个是安全加固，一个是入侵检测，其中入侵检测是我很喜欢的一个领域。在国内，入侵检测经常被理解为IDS/IPS这样的安全设备。在以web浏览访问以及手机app访问为主要业务形式的互联网公司，入侵检测覆盖分范围非常广泛。
我首先遇到的一个问题其实不是技术上的，如何衡量我们所做的努力对公司安全状况的贡献。换句话来说，就是如何描述我们做的事的产出。在大多数公司，甲方安全都是地道的成本中心，纯成本消耗。如何证明安全团队的价值是非常重要的，即使是在一个超大型互联网公司。我观察到有些同学其实干的也很苦逼，情绪低落，总是抱怨。确实他负责很多小项目，每个事情看似很重要，但是确实也看不到啥产出，感觉做不做其实也一样。于是明显的恶性循环也产生了，一个事情没做成业绩，就继续做另外一个，结果下一个也没做出成绩，继续做下一个，手上一堆烂尾楼，还要抱怨辛苦没人看到。在那个时候，某知名漏洞平台还在，上面报的漏洞公司层面还是非常重视的。于是我想到一个重要的衡量指标，就是安全事故的主动发现比例。比如拿到服务器的webshell，SQL注入点和敏感文件下载，这些都是影响大且容易量化的。如果能够通过我们开发的入侵检测系统，提高我们主动发现入侵事件的比例，这个贡献是非常容易体现的。我们在相当长的一段时间就是从各个维度想办法提高这些指标，其中印象深刻的就是webdir和dbmon。
webdirdbmon
webdir和dbmon是我们内部取的名字，简单讲webdir分析web服务器上的文件，及时发现后门文件，dbmon分析数据库日志，及时发现SQL注入点以及拖库行为。通过这两个项目，我的team从一个安全技术团队开始向一个安全产品团队衍变，除了负责应急响应和渗透测试的的安全工程师，开始出现有安全背景的研发工程师以及负责storm和hive的大数据工程师，人数也开始两位数了。
webdir在一期的时候，主要是依赖收集的样本提炼的文本规则，简单有效，在部署的初期发现了不少case，部署的范围主要集中在重点产品线，量级在一万台左右。我们在二期的时候，重点工作是一方面提高检测能力，一方面是减少发现的延时，另外一个方面是全公司部署，这三方面都是为了提高webshell的主动发现比例。
在检测能力方面，主要是提高准确率和召回率，关于这两个指标的含义，有兴趣的同学可以看下我机器学习的书，里面用小龙虾和鱼来做了形象的比喻。基于文本特征的webshell检测，很难在这两个指标之间做平衡，尤其是我们这种超大规模的公司，即使是每天新增的文件也可能上亿，实验室环境看着还蛮不错的检测效果，误报也会被放大。因此大多数安全工程师的选择就是写极其精准的规则，所谓精准，就是根据搜集的样本写的过于严格苛刻的规则，用于大大降低误报。这导致的结果是，误报确实少了，但是漏报也非常严重。我们仔细研究了下问题所在，主要是由于php语言的高度灵活性，一个很简单的功能可以用多种方式实现，还有不少装逼的语法。单纯在语言文本特征层面做非常吃力。通过调研，我们发现不管文本特征层面如何做绕过我们的检测，最后webshell还是要以php和java的语法来实现，如果我们可以实现php和java的语法，就可以在更底层提取特征，与黑产进行对抗。这个思路也一直影响了我们后面的流量分析产品以及基于机器学习的webshell识别，不过这个是后话了。这个思路也成为我们二期的主要提升点，当时根据我们搜集的数千样本，挑选了专业的安全产品进行测试对比，我们的两个指标综合领先。我们另外的一个挑战是工程上的，我们仅在国内就有大量的机房，每个机房之间的带宽不尽相同，而且使用率也大不相同，即使是固定的两个机房，带宽使用也有明显的时间特征。另外互联网公司大多把服务器的性能压榨的非常腻害，运维部门对我们的性能指标限制的非常死，甚至超过一定的CPU或者内存就会自动把我们进程挂起甚至kill。为了尽可能降低服务器的性能消耗，我们使用云模式，负责的语法解析与规则匹配放到云端，服务器上仅需要完成非常简单的处理和上传逻辑。但是几十万个服务器如果因为上线新版本同时出现新文件需要检测，也可能会出现带宽的异常消耗，于是我们也使用了去中心化的部署方式。一群只玩过单机版syslog-ng分析日志的土鳖，一下子可以有上百台服务器，还用上了大型消息队列和自研的沙箱集群，想想确实很有成就感。二期上线后，无论从部署范围还是检测能力上，都上了一个新台阶，并且由于检测技术上的创新以及客观的评测结果，这个项目获得了公司层面的创新奖。在这个项目上另外一个收获是开发服务器端的程序的经验，在一个如此大规模的集群上部署客户端，还要做到性能消耗小，考虑各种异常情况的处理，考虑各种兼容性问题，这些都是干过才能积累的。
dbmon在一期的时候，依托于公司运维部的DBA团队的现有系统，离线分析公司部门产品线托管的mysql查询日志。检测的效果确实不理想，一堆暴力破解的报警，仔细一查都是密码过期了。检测的重点没有放到SQL这些上，而是更像针对数据库的异常访问检测了，这个其实从实践角度，安全人员很难去定位问题，小同学弄两次就烦了，所以效果一直很差，最后运维系统的同学根本不想看报警了。二期的时候我们聚焦到SQL检测上，相对于waf和流量层面，SQL日志层面做SQL注入点检测非常合适，因为在北京中科白殿风医院怎么样北京治疗最好白癜风权威医院
