2018美团技术—运维系列

1 .

2 . 序 春节已近，年味渐浓。 又到了我们献上技术年货的时候。 不久前，我们已经给大家分享了技术沙龙大套餐，汇集了过去一年我们线上线下技术沙龙 99位讲师，85 个演讲，70+小时 分享。  今天出场的，同样重磅——技术博客全年大合集。 2018年，是美团技术团队官方博客第5个年头， 博客网站 全年独立访问用户累计超过300万，微信公众  号（meituantech）的关注数也超过了15万。 由衷地感谢大家一直以来对我们的鼓励和陪伴！ 在2019年春节到来之际，我们再次精选了114篇技术干货，制作成一本厚达1200多页的电子书呈送给大 家。 这本电子书主要包括前端、后台、系统、算法、测试、运维、工程师成长等7个板块。疑义相与析，大家 在阅读中如果发现Bug、问题，欢迎扫描文末二维码，通过微信公众号与我们交流。 也欢迎大家转给有相同兴趣的同事、朋友，一起切磋，共同成长。 最后祝大家，新春快乐，阖家幸福。 

3 . 目录 - 运维篇 互联网企业数据安全体系建设 ...................................................................... 4 SQL解析在美团的应用 ...................................................................... 13 浅谈大型互联网企业入侵检测及防护策略 ...................................................................... 23 美团针对Redis Rehash机制的探索和实践 ...................................................................... 36 Redis 高负载下的中断优化 ...................................................................... 54 初探下一代网络隔离与访问控制 ...................................................................... 75 互联网公司数据安全保护新探索 ...................................................................... 82 数据库智能运维探索与实践 ...................................................................... 88 新一代数据库TiDB在美团的实践 ...................................................................... 99 Android Hook技术防范漫谈 ...................................................................... 109 美团数据平台Kerberos优化实战 ...................................................................... 119 镣铐之舞：美团安全工程师Black Hat USA演讲 ...................................................................... 131 

4 . 互联网企业数据安全体系建设 - 美团技术团队 互联网企业数据安全体系建设 作者: 赵彦 一、背景 Facebook数据泄露事件一度成为互联网行业的焦点，几百亿美元市值瞬间蒸发，这个代价足以在地球上 养活一支绝对庞大的安全团队，甚至可以直接收购几家规模比较大的安全公司了。 虽然媒体上发表了很多谴责的言论，但实事求是地讲，Facebook面临是一个业界难题，任何一家千亿美 元的互联网公司面对这种问题，可能都没有太大的抵抗力，仅仅是因为全球区域的法律和国情不同，暂时 不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私，在安全领域中，数据安全这个子领域也重 新被提到了一个新的高度，所以笔者就借机来说一下数据安全建设。（按照惯例，本文涉及敏感信息的部 分会进行省略处理或者一笔带过。） 二、概念 这里特别强调一下，“隐私保护”和“数据安全”是两个完全不同的概念，隐私保护对于安全专业人员来说 是一个更加偏向合规的事情，主要是指数据过度收集和数据滥用方面对法律法规的遵从性，对很多把自身 的盈利模式建立在数据之上的互联网公司而言，这个问题特别有挑战。有些公司甚至把自己定义为数据公 司，如果不用数据来做点什么，要么用户体验大打折扣，要么商业价值减半。GDPR即将实施，有些公司 或将离场欧洲，就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司，他们很大 程度上并不能真正代表用户意愿，而只是因为自家没有数据或缺少数据，随口说说而已。 数据安全是实现隐私保护的最重要手段之一。对安全有一定了解的读者可能也会察觉到，数据安全并不是 一个独立的要素，而是需要连同网络安全、系统安全、业务安全等多种因素，只有全部都做好了，才能最 终达到数据安全的效果。所以本文尽可能的以数据安全为核心，但没有把跟数据安全弱相关的传统安全体 系防护全部列出来，对于数据安全这个命题而言尽可能的系统化，又避免啰嗦。另外笔者也打算在夏季和 秋季把其他子领域的话题单独成文，譬如海量IDC下的入侵防御体系等，敬请期待。 三、全生命周期建设 尽管业内也有同学表示数据是没有边界的，如果按照泄露途径去做可能起不到“根治”的效果，但事实上 以目前的技术是做不到无边界数据安全的。下图汇总了一个全生命周期内的数据安全措施： 

5 . 互联网企业数据安全体系建设 - 美团技术团队 四、数据采集 数据泄露有一部分原因是用户会话流量被复制，尽管有点技术门槛，但也是发生频率比较高的安全事件之 一，只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。 流量保护 全站HTTPS是目前互联网的主流趋势，它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第 三方掠走的问题。这些问题其实是比较严重的，比如电信运营商内部偶有舞弊现象，各种导流劫持插广告 （当然也可以存数据，插木马），甚至连AWS也被劫持DNS请求，对于掌握链路资源的人来说无异于可 以发动一次“核战争”。即使目标对象IDC入侵防御做的好，攻击者也可以不通过正面渗透，而是直接复制 流量，甚至定向APT，最终只是看操纵流量后达到目的的收益是否具有性价比。 HTTPS是一个表面现象，它暗示着任何互联网上未加密的流量都是没有隐私和数据安全的，同时，也不 是说有了HTTPS就一定安全。HTTPS本身也有各种安全问题，比如使用不安全的协议TLS1.0、SSL3，采 用已经过时的弱加密算法套件，实现框架安全漏洞如心脏滴血，还有很多的数字证书本身导致的安全问 题。 全站HTTPS会带来的附带问题是CDN和高防IP。历史上有家很大的互联网公司被NSA嗅探获取了用户数 据，原因是CDN回源时没有使用加密，即用户浏览器到CDN是加密的，但CDN到IDC源站是明文的。如 果CDN到源站加密就需要把网站的证书私钥给到CDN厂商，这对于没有完全自建CDN的公司而言也是一 个很大的安全隐患，所以后来衍生出了Keyless CDN技术，无需给出自己的证书就可以实现CDN回源加 密。 广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步，对应的解决方案 是跨IDC流量自动加密、TLS隧道化。 业务安全属性 在用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全，只要账号泄露（撞库&爆 破）到达一定数量级，把这些账号的数据汇总一下，就必定可以产生批量数据泄露的效果。 第二个问题是反爬，爬虫的问题存在于一切可通过页面、接口获取数据的场合，大概1小时爬个几百万条 数据是一点问题都没有的，对于没有彻底脱敏的数据，爬虫的效果有时候等价于“黑掉”服务器。账号主 动地或被动地泄露+爬虫技术，培育了不少黑产和数据获取的灰色地带。 UUID UUID最大的作用是建立中间映射层，屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按 需自主授权只能读取UUID，但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据，因为实 名制，手机号越来越能代表个人标识，且一般绑定了各种账号，更改成本很高，找到手机号就能对上这个 人，因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标 识一个品牌和店名的时候，这个原本用于程序检索的数据结构也一下子变成了个体识别数据，也都需要纳 入保护范畴。 

6 . 互联网企业数据安全体系建设 - 美团技术团队 五、前台业务处理 鉴权模型 在很多企业的应用架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后面的事务处理不再会出 现用户鉴权，进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害，还包括各种 K/V、RDS（关系型数据库）、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。 在数据层只知道请求来自一个数据访问层中间件，来自一个RPC调用，但完全不知道来自哪个用户，还是 哪个诸如客服系统或其他上游应用，无法判断究竟对当前的数据（对象）是否拥有完整的访问权限。绝大 多数互联网公司都用开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具 备很弱的安全特性，以至于完全不适用于海量IDC规模下的4A模型（认证、授权、管理、审计）。外面防 御做的很好，而在内网可以随意读写，这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹 性计算的问题，关于这个问题的解决方案可以参考笔者的另外一篇文章 《初探下一代网络隔离与访问控 制》 ，其中提到Google的方法是内网RPC鉴权，由于Google的内网只有RPC一种协议，所以就规避了  上述大多数安全问题。 对于业务流的鉴权模型，本质上是需要做到Data和App分离，建立Data默认不信任App的模型，而应用中 的全程Ticket和逐级鉴权是这种思想下的具体实现方法。 服务化 服务化并不能认为是一个安全机制，但安全却是服务化的受益者。我们再来温习一下当年Bezos在 Amazon推行服务化的一纸号令： 1）所有团队今后将通过服务接口公开他们的数据和功能。 2）团队必须通过这些接口相互通信。 3）不 允许使用其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不支持共享内 存模式，无后门。唯一允许的通信是通过网络上的服务接口调用。 4）他们使用什么技术并不重要。 HTTP，Corba，Pubsub，自定义协议 - 无关紧要。贝索斯不在乎。 5）所有服务接口无一例外都必须从 头开始设计为可外部化。也就是说，团队必须规划和设计能够将接口展示给外部开发人员。没有例外。 6）任何不这样做的人都会被解雇。 服务化的结果在安全上的意义是必须通过接口访问数据，屏蔽了各种直接访问数据的途径，有了API控制 和审计就会方便很多。 内网加密 一些业界Top的公司甚至在IDC内网里也做到了加密，也就是在后台的组件之间的数据传输都是加密的， 譬如Goolge的RPC加密和Amazon的TLS。由于IDC内网的流量比公网大得多，所以这里是比较考验工程 能力的地方。对于大多数主营业务迭代仍然感觉有压力的公司而言，这个需求可能有点苛刻了，所以笔者 认为用这些指标来衡量一家公司的安全能力属于哪一个档位是合理的。私有协议算不算？如果私有协议里 不含有标准TLS（SHA256）以上强度的加密，或者只是信息不对称的哈希，笔者认为都不算。 数据库审计 

7 . 互联网企业数据安全体系建设 - 美团技术团队 数据库审计/数据库防火墙是一个入侵检测/防御组件，是一个强对抗领域的产品，但是在数据安全方面它 的意义也是明显的：防止SQL注入批量拉取数据，检测API鉴权类漏洞和爬虫的成功访问。 除此之外，对数据库的审计还有一层含义，是指内部人员对数据库的操作，要避免某个RD或DBA为了泄 愤，把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件，通过这个组 件，可以审计、控制危险操作。 六、数据存储 数据存储之于数据安全最大的部分是数据加密。Amazon CTO Werner Vogels曾经总结：“AWS所有的新 服务，在原型设计阶段就会考虑到对数据加密的支持。”国外的互联网公司中普遍比较重视数据加密。 HSM/KMS 业界的普遍问题是不加密，或者加密了但没有使用正确的方法：使用自定义UDF，算法选用不正确或加密 强度不合适，或随机数问题，或者密钥没有Rotation机制，密钥没有存储在KMS中。数据加密的正确方 法本身就是可信计算的思路，信任根存储在HSM中，加密采用分层密钥结构，以方便动态转换和过期失 效。当Intel CPU普遍开始支持SGX安全特性时，密钥、指纹、凭证等数据的处理也将以更加平民化的方 式使用类似Trustzone的芯片级隔离技术。 结构化数据 这里主要是指结构化数据静态加密，以对称加密算法对诸如手机、身份证、银行卡等需要保密的字段加密 持久化，另外除了数据库外，数仓里的加密也是类似的。比如，在 Amazon Redshift 服务中，每一个数 据块都通过一个随机的密钥进行加密，而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这 个主密钥，这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。鉴于这部分属于比较常用的 技术，不再展开。 文件加密 对单个文件独立加密，一般情况下采用分块加密，典型的场景譬如在《互联网企业安全高级指南》一书中 提到的iCloud将手机备份分块加密后存储于AWS的S3，每一个文件切块用随机密钥加密后放在文件的 meta data中，meta data再用file key包裹，file key再用特定类型的data key（涉及数据类型和访问权 限）加密，然后data key被master key包裹。 文件系统加密 文件系统加密由于对应用来说是透明的，所以只要应用具备访问权限，那么文件系统加密对用户来说也 是“无感知”的。它解决的主要是冷数据持久化后存储介质可访问的问题，即使去机房拔一块硬盘，或者 从一块报废的硬盘上尝试恢复数据，都是没有用的。但是对于API鉴权漏洞或者SQL注入而言，显然文件 系统的加密是透明的，只要App有权限，漏洞利用也有权限。 七、访问和运维 

8 . 互联网企业数据安全体系建设 - 美团技术团队 在这个环节，主要阐述防止内部人员越权的一些措施。 角色分离 研发和运维要分离，密钥持有者和数据运维者要分离，运维角色和审计角色要分离。特权账号须回收，满 足最小权限，多权分立的审计原则。 运维审计 堡垒机（跳板机）是一种针对人肉运维的常规审计手段，随着大型IDC中运维自动化的加深，运维操作都 被API化，所以针对这些API的调用也需要被列入审计范畴，数量级比较大的情况下需要使用数据挖掘的 方法。 工具链脱敏 典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中，通常由于运维和安全的监控系统 包含了全站用户流量，对用户Token和敏感数据需要脱敏，同时这些系统也可能通过简单的计算得出一些 运营数据，譬如模糊的交易数目，这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV 码等比较严重的安全事件，因此都是需要注意的数据泄漏点。 生产转测试 生产环境和测试环境必须有严格定义和分离，如特殊情况生产数据需要转测试，必须经过脱敏、匿名化。 八、后台数据处理 数仓安全 目前大数据处理基本是每个互联网公司的必需品，通常承载了公司所有的用户数据，甚至有的公司用于数 据处理的算力超过用于前台事务处理的算力。以Hadoop为代表的开源平台本身不太具备很强的安全能 力，因此在成为公有云服务前需要做很多改造。在公司比较小的时候可以选择内部信任模式，不去过于纠 结开源平台本身的安全，但在公司规模比较大，数据RD和BI分析师成千上万的时候，内部信任模式就需 要被抛弃了，这时候需要的是一站式的授权&审计平台，需要看到数据的血缘继承关系，需要高敏数据仍 然被加密。在这种规模下，工具链的成熟度会决定数据本地化的需求，工具链越成熟数据就越不需要落到 开发者本地，这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化，尽可能避免人工 操作。 对于数据的分类标识、分布和加工，以及访问状况需要有一个全局的大盘视图，结合数据使用者的行为建 立“态势感知”的能力。 因为数仓是最大的数据集散地，因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态： 放逐+检测型 or 隔离+管控型。 匿名化算法 

9 . 互联网企业数据安全体系建设 - 美团技术团队 匿名化算法更大的意义其实在于隐私保护而不在于数据安全（关于隐私保护部分笔者打算另外单独写一 篇），如果说对数据安全有意义，匿名化可能在于减少数据被滥用的可能性，以及减弱数据泄漏后的影响 面。 九、展示和使用 这个环节泛指大量的应用系统后台、运营报表以及所有可以展示和看到数据的地方，都可能是数据泄露的 重灾区。 展示脱敏 对页面上需要展示的敏感信息进行脱敏。一种是完全脱敏，部分字段打码后不再展示完整的信息和字段， 另一种是不完全脱敏，默认展示脱敏后的信息，但仍然保留查看明细的按钮（API），这样所有的查看明 细都会有一条Log，对应审计需求。具体用哪种脱敏需要考虑工作场景和效率综合评估。 水印 水印主要用在截图的场景，分为明水印和暗水印，明水印是肉眼可见的，暗水印是肉眼不可见暗藏在图片 里的识别信息。水印的形式也有很多种，有抵抗截屏的，也有抵抗拍照的。这里面也涉及很多对抗元素不 一一展开。 安全边界 这里的边界其实是办公网和生产网组成的公司数据边界，由于办公移动化程度的加深，这种边界被进一步 模糊化，所以这种边界实际上是逻辑的，而非物理上的，它等价于公司办公网络，生产网络和支持MDM 的认证移动设备。对这个边界内的数据，使用DLP来做检测，DLP这个名词很早就有，但实际上它的产品 形态和技术已经发生了变化，用于应对大规模环境下重检测，轻阻断的数据保护模式。 除了DLP之外，整个办公网络会采用BeyondCorp的“零信任”架构，对整个的OA类应用实现动态访问控 制，全面去除匿名化访问，全部HTTPS，根据角色最小权限化，也就是每个账号即使泄露能访问到的也 有限。同时提高账号泄露的成本（多因素认证）和检测手段，一旦检测到泄露提供远程擦除的能力。 堡垒机 堡垒机作为一种备选的方式主要用来解决局部场景下避免操作和开发人员将敏感数据下载到本地的方法， 这种方法跟VDI类似，比较厚重，使用门槛不高，不适合大面积普遍推广。 十、共享和再分发 对于业务盘子比较大的公司而言，其数据都不会是只在自己的系统内流转，通常都有开放平台，有贯穿整 个产业链的上下游数据应用。Facebook事件曝光其实就属于这类问题，不开放是不可能的，因为这影响 了公司的内核—-赖以生存的商业价值。 所以这个问题的解决方案等价于：1）内核有限妥协（为保障用户隐私牺牲一部分商业利益）；2）一站式 数据安全服务。 

10 . 互联网企业数据安全体系建设 - 美团技术团队 防止下游数据沉淀 首先，所有被第三方调用的数据，如非必要一律脱敏和加密。如果部分场景有必要查询明细数据，设置单 独的API，并对账号行为及API查询做风控。 其次如果自身有云基础设施，公有云平台，可以推动第三方上云，从而进行（1）安全赋能，避免一些因 自身能力不足引起的安全问题；（2）数据集中化，在云上集中之后利于实施一站式整体安全解决方案 （数据加密，风控，反爬和数据泄露检测类服务），大幅度降低外部风险并在一定程度上降低作恶和监守 自盗的问题。 反爬 反爬在这里主要是针对公开页面，或通过接口爬取的信息，因为脱敏这件事不可能在所有的环节做的很彻 底，所以即便通过大量的“公开”信息也可以进行汇聚和数据挖掘，最终形成一些诸如用户关系链，经营 数据或辅助决策类数据，造成过度信息披露的影响。 授权审核 设置专门的团队对开放平台的第三方进行机器审核及人工审核，禁止“无照经营”和虚假三方，提高恶意 第三方接入的门槛，同时给开发者/合作方公司信誉评级提供基础。 法律条款 所有的第三方接入必须有严格的用户协议，明确数据使用权利，数据披露限制和隐私保护的要求。像 GDPR一样，明确数据处理者角色和惩罚条约。 十一、数据销毁 数据销毁主要是指安全删除，这里特别强调是，往往数据的主实例容易在视野范围内，而把备份类的数据 忽略掉。 如果希望做到快速的安全删除，最好使用加密数据的方法，因为完整覆写不太可能在短时间内 完成，但是加密数据的安全删除只要删除密钥即可。 十二、数据的边界 数据治理常常涉及到“边界”问题，不管你承不承认，边界其实总是存在的，只不过表达方式不一样，如 果真的没有边界，也就不存在数据安全一说。 企业内部 在不超越网络安全法和隐私保护规定的情况下，法律上企业对内部的数据都拥有绝对控制权，这使得企业 内部的数据安全建设实际上最后会转化为一项运营类的工作，挑战难度也无非是各个业务方推动落地的成 本。但对规模比较大的公司而言，光企业内部自治可能是不够的，所以数据安全会衍生出产业链上闭环的 需求。 生态建设 

11 . 互联网企业数据安全体系建设 - 美团技术团队 为了能让数据安全建设在企业内部价值链之外的部分更加平坦化，大型企业可能需要通过投资收购等手段 获得上下游企业的数据控制权及标准制定权，从而在大生态里将自己的数据安全标准推行到底。如果不能 掌控数据，数据安全也无从谈起。在话语权不足的情况下，现实选择是提供更多的工具给合作方，也是一 种数据控制能力的延伸。 十三、ROI和建设次第 对于很多规模不大的公司而言，上述数据安全建设手段可能真的有点多，对于小一点公司即便什么事不干 可能也消化不了那么多需求，因为开源软件和大多数的开发框架都不具备这些能力，需要DIY的成分很 高，所以我们梳理一下前置条件，优先级和ROI，让数据安全这件事对任何人都是可以接受的，当然这种 情况其实也对应了一些创业空间。 基础 账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础，但能体现为优势 的部分：基础架构统一，应用架构统一，如果这两者高度统一，数据安全建设能事半功倍。 日志收集 日志是做数据风控的基础，但这里面也有两个比较重要的因素： 1. 办公网络是否BeyondCorp化，这给数据风控提供了极大地便利。 2. 服务化，所有的数据调用皆以API的形式，给日志记录提供了统一的形式。 数据风控 在数据安全中，“放之四海皆准”的工作就是数据风控，适用于各类企业，结合设备信息、账号行为、查 询/爬(读)取行为做风控模型。对于面向2C用户类，2B第三方合作类，OA员工账号类都是适用的。具体 的策略思想笔者打算在后续文章《入侵防御体系建设》中详细描述。 作者简介 赵彦，现任美团集团安全部高级总监，负责集团旗下全线业务的信息安全与隐私保护。加盟美团前，曾任 华为云安全首席架构师，奇虎360企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽 子时代是Ph4nt0m Security Team的核心成员，互联网安全领域第一代资深从业者。 关于美团安全 美团安全部的大多数核心人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司 的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏 CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。 目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据 分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数 十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施， 

12 . 互联网企业数据安全体系建设 - 美团技术团队 包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web 应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造 成业界最前沿的内置式安全架构和纵深防御体系。 随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界 最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领 域不断探索的机会。 招聘信息 美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入 我们，欢迎简历请发至邮箱 zhaoyan17@meituan.com  具体职位信息可参考这里： https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw  美团安全应急响应中心MTSRC主页： security.meituan.com  

13 . SQL解析在美团的应用 - 美团技术团队 SQL解析在美团的应用 作者: 广友 数据库作为核心的基础组件，是需要重点保护的对象。任何一个线上的不慎操作，都有可能给数据库带来 严重的故障，从而给业务造成巨大的损失。为了避免这种损失，一般会在管理上下功夫。比如为研发人员 制定数据库开发规范；新上线的SQL，需要DBA进行审核；维护操作需要经过领导审批等等。而且如果希 望能够有效地管理这些措施，需要有效的数据库培训，还需要DBA细心的进行SQL审核。很多中小型创业 公司，可以通过设定规范、进行培训、完善审核流程来管理数据库。 随着美团的业务不断发展和壮大，上述措施的实施成本越来越高。如何更多的依赖技术手段，来提高效 率，越来越受到重视。业界已有不少基于MySQL源码开发的SQL审核、优化建议等工具，极大的减轻了 DBA的SQL审核负担。那么我们能否继续扩展MySQL的源码，来辅助DBA和研发人员来进一步提高效率 呢？比如，更全面的SQL优化功能；多维度的慢查询分析；辅助故障分析等。要实现上述功能，其中最核 心的技术之一就是SQL解析。 现状与场景 SQL解析是一项复杂的技术，一般都是由数据库厂商来掌握，当然也有公司专门提供 SQL解析的API 。  由于这几年MySQL数据库中间件的兴起，需要支持读写分离、分库分表等功能，就必须从SQL中抽出表 名、库名以及相关字段的值。因此像Java语言编写的Druid，C语言编写的MaxScale，Go语言编写的 Kingshard等，都会对SQL进行部分解析。而真正把SQL解析技术用于数据库维护的产品较少，主要有如 下几个: 美团开源的SQLAdvisor 。它基于MySQL原生态词法解析，结合分析SQL中的where条件、聚合条件、多表Join关  系给出索引优化建议。 去哪儿开源的Inception 。侧重于根据内置的规则，对SQL进行审核。  阿里的Cloud DBA 。根据官方文档介绍，其也是提供SQL优化建议和改写。  上述产品都有非常合适的应用场景，在业界也被广泛使用。但是SQL解析的应用场景远远没有被充分发 掘，比如： 基于表粒度的慢查询报表。比如，一个Schema中包含了属于不同业务线的数据表，那么从业务线的角度来说，其希 望提供表粒度的慢查询报表。 生成SQL特征。将SQL语句中的值替换成问号，方便SQL归类。虽然可以使用正则表达式实现相同的功能，但是其 Bug较多，可以参考pt-query-digest。比如pt-query-digest中，会把遇到的数字都替换成“?”，导致无法区别不同 数字后缀的表。 高危操作确认与规避。比如，DBA不小心Drop数据表，而此类操作，目前还无有效的工具进行回滚，尤其是大表， 其后果将是灾难性的。 SQL合法性判断。为了安全、审计、控制等方面的原因，美团不会让研发人员直接操作数据库，而是提供RDS服务。 尤其是对于数据变更，需要研发人员的上级主管进行业务上的审批。如果研发人员，写了一条语法错误的SQL，而 RDS无法判断该SQL是否合法，就会造成不必要的沟通成本。 

14 . SQL解析在美团的应用 - 美团技术团队 因此为了让所有有需要的业务都能方便的使用SQL解析功能，我们认为应该具有如下特性。 直接暴露SQL解析接口，使用尽量简单。比如，输入SQL，则输出表名、特征和优化建议。 接口的使用不依赖于特定的语言，否则维护和使用的代价太高。比如，以HTTP等方式提供服务。 千里之行，始于足下。下面我先介绍下SQL的解析原理。 原理 SQL解析与优化是属于编译器范畴，和C等其他语言的解析没有本质的区别。其中分为，词法分析、语法 和语义分析、优化、执行代码生成。对应到MySQL的部分，如下图 图1 SQL解析原理 词法分析 SQL解析由词法分析和语法/语义分析两个部分组成。词法分析主要是把输入转化成一个个Token。其中 Token中包含Keyword（也称symbol）和非Keyword。例如，SQL语句 select username from userinfo，在分析之后，会得到4个Token，其中有2个Keyword，分别为select和from： 关键字 非关键字 关键字 非关键字 select username from userinfo 通常情况下，词法分析可以使用 Flex 来生成，但是MySQL并未使用该工具，而是手写了词法分析部分  （据说是为了效率和灵活性，参考 此文 ）。具体代码在sql/lex.h和sql/sql_lex.cc文件中。  MySQL中的Keyword定义在sql/lex.h中，如下为部分Keyword： { "&&", SYM(AND_AND_SYM)}, { "<", SYM(LT)}, { "<=", SYM(LE)}, { "<>", SYM(NE)}, { "!=", SYM(NE)}, { "=", SYM(EQ)}, { ">", SYM(GT_SYM)}, { ">=", SYM(GE)}, 

15 . SQL解析在美团的应用 - 美团技术团队 { "<<", SYM(SHIFT_LEFT)}, { ">>", SYM(SHIFT_RIGHT)}, { "<=>", SYM(EQUAL_SYM)}, { "ACCESSIBLE", SYM(ACCESSIBLE_SYM)}, { "ACTION", SYM(ACTION)}, { "ADD", SYM(ADD)}, { "AFTER", SYM(AFTER_SYM)}, { "AGAINST", SYM(AGAINST)}, { "AGGREGATE", SYM(AGGREGATE_SYM)}, { "ALL", SYM(ALL)}, 词法分析的核心代码在sql/sql_lex.c文件中的，MySQLLex→lex_one_Token，有兴趣的同学可以下载源 码研究。 语法分析 语法分析就是生成语法树的过程。这是整个解析过程中最精华，最复杂的部分，不过这部分MySQL使用 了Bison来完成。即使如此，如何设计合适的数据结构以及相关算法，去存储和遍历所有的信息，也是值 得在这里研究的。 语法分析树 SQL语句： select username, ismale from userinfo where age > 20 and level > 5 and 1 = 1 会生成如下语法树。 图2 语法树 对于未接触过编译器实现的同学，肯定会好奇如何才能生成这样的语法树。其背后的原理都是编译器的范 畴，可以参考维基百科的一篇 文章 ，以及该链接中的参考书籍。本人也是在学习MySQL源码过程中，  阅读了部分内容。由于编译器涉及的内容过多，本人精力和时间有限，不做过多探究。从工程的角度来 说，学会如何使用Bison去构建语法树，来解决实际问题，对我们的工作也许有更大帮助。下面我就以 Bison为基础，探讨该过程。 MySQL语法分析树生成过程 全部的源码在sql/sql_yacc.yy中，在MySQL5.6中有17K行左右代码。这里列出涉及到SQL： 

16 . SQL解析在美团的应用 - 美团技术团队 select username, ismale from userinfo where age > 20 and level > 5 and 1 = 1 解析过程的部分代码摘录出来。其实有了Bison之后，SQL解析的难度也没有想象的那么大。特别是这里 给出了解析的脉络之后。 select /*select 语句入口*/: select_init { LEX *lex= Lex; lex->sql_command= SQLCOM_SELECT; } ; select_init: SELECT_SYM /*select 关键字*/ select_init2 | '(' select_paren ')' union_opt ; select_init2: select_part2 { LEX *lex= Lex; SELECT_LEX * sel= lex->current_select; if (lex->current_select->set_braces(0)) { my_parse_error(ER(ER_SYNTAX_ERROR)); MYSQL_YYABORT; } if (sel->linkage == UNION_TYPE && sel->master_unit()->first_select()->braces) { my_parse_error(ER(ER_SYNTAX_ERROR)); MYSQL_YYABORT; } } union_clause ; select_part2: { LEX *lex= Lex; SELECT_LEX *sel= lex->current_select; if (sel->linkage != UNION_TYPE) mysql_init_select(lex); lex->current_select->parsing_place= SELECT_LIST; } select_options select_item_list /* 解析列名*/ { Select->parsing_place= NO_MATTER; } select_into select_lock_type ; select_into: opt_order_clause opt_limit_clause {} | into | select_from /*from 字句 */ | into select_from | select_from into ; select_from: FROM join_table_list /* 解析表名 字句 */ where_clause /*where */ group_clause having_clause opt_order_clause opt_limit_clause procedure_analyse_clause { Select->context.table_list= Select->context.first_name_resolution_table= Select->table_list.first; } | FROM DUAL_SYM where_clause opt_limit_clause /* oracle compatibility: oracle always requires FROM clause, and DUAL is system table without fields. Is "SELECT 1 FROM DUAL" any better than "SELECT 1" ? 

17 . SQL解析在美团的应用 - 美团技术团队 Hmmm :) */ ; where_clause: /* empty */ { Select->where= 0; } | WHERE { Select->parsing_place= IN_WHERE; } expr /* 各种表达式 */ { SELECT_LEX *select= Select; select->where= $3; select->parsing_place= NO_MATTER; if ($3) $3->top_level_item(); } ; /* all possible expressions */ expr: | expr and expr %prec AND_SYM { /* See comments in rule expr: expr or expr */ Item_cond_and *item1; Item_cond_and *item3; if (is_cond_and($1)) { item1= (Item_cond_and*) $1; if (is_cond_and($3)) { item3= (Item_cond_and*) $3; /* (X1 AND X2) AND (Y1 AND Y2) ==> AND (X1, X2, Y1, Y2) */ item3->add_at_head(item1->argument_list()); $$ = $3; } else { /* (X1 AND X2) AND Y ==> AND (X1, X2, Y) */ item1->add($3); $$ = $1; } } else if (is_cond_and($3)) { item3= (Item_cond_and*) $3; /* X AND (Y1 AND Y2) ==> AND (X, Y1, Y2) */ item3->add_at_head($1); $$ = $3; } else { /* X AND Y */ $$ = new (YYTHD->mem_root) Item_cond_and($1, $3); if ($$ == NULL) MYSQL_YYABORT; } } 在大家浏览上述代码的过程，会发现Bison中嵌入了C++的代码。通过C++代码，把解析到的信息存储到 相关对象中。例如表信息会存储到TABLE_LIST中，order_list存储order by子句里的信息，where字句存 储在Item中。有了这些信息，再辅助以相应的算法就可以对SQL进行更进一步的处理了。 核心数据结构及其关系 在SQL解析中，最核心的结构是SELECT_LEX，其定义在sql/sql_lex.h中。下面仅列出与上述例子相关的 部分。 

18 . SQL解析在美团的应用 - 美团技术团队 图3 SQL解析树结构 上面图示中，列名username、ismale存储在item_list中，表名存储在table_list中，条件存储在where 中。其中以where条件中的Item层次结构最深，表达也较为复杂，如下图所示。 图4 where条件 SQL解析的应用 为了更深入的了解SQL解析器，这里给出2个应用SQL解析的例子。 无用条件去除 无用条件去除属于优化器的逻辑优化范畴，可以仅仅根据SQL本身以及表结构即可完成，其优化的情况也 是较多的，代码在sql/sql_optimizer.cc文件中的remove_eq_conds函数。为了避免过于繁琐的描述，以 及大段代码的粘贴，这里通过图来分析以下四种情况。 a）1=1 and (m > 3 and n > 4) b）1=2 and (m > 3 and n > 4) c）1=1 or (m > 3 and n > 4) d）1=2 or (m > 3 and n > 4) 

19 .SQL解析在美团的应用 - 美团技术团队 图5 无用条件去除a 图6 无用条件去除b 

20 . SQL解析在美团的应用 - 美团技术团队 图7 无用条件去除c 图8 无用条件去除d 如果对其代码实现有兴趣的同学，需要对MySQL中的一个重要数据结构Item类有所了解。因为其比较复 杂，所以MySQL官方文档，专门介绍了 Item类 。阿里的MySQL小组，也有类似的 文章 。如需更详   细的了解，就需要去查看源码中sql/item_*等文件。 SQL特征生成 

21 . SQL解析在美团的应用 - 美团技术团队 为了确保数据库，这一系统基础组件稳定、高效运行，业界有很多辅助系统。比如慢查询系统、中间件系 统。这些系统采集、收到SQL之后，需要对SQL进行归类，以便统计信息或者应用相关策略。归类时，通 常需要获取SQL特征。比如SQL: ； select username, ismale from userinfo where age > 20 and level > 5 ``` 特征为： SQL ```sql select username, ismale from userinfo where age > ? and level > ? 业界著名的慢查询分析工具pt-query-digest，通过正则表达式实现这个功能但是这类处理办法Bug较 多。接下来就介绍如何使用SQL解析，完成SQL特征的生成。 SQL特征生成分两部分组成。 a) 生成Token数组 b) 根据Token数组，生成SQL特征 首先回顾在词法解析章节，我们介绍了SQL中的关键字，并且每个关键字都有一个16位的整数对应，而非 关键字统一用ident表示，其也对应了一个16位整数。如下表： 标识 select from where > ? and ident 整数 728 448 878 463 893 272 476 将一个SQL转换成特征的过程： 原SQL select username from userinfo where age > 20 SQL特征 select ident:length:value from ident:length:value where ident:length:value > ? 在SQL解析过程中，可以很方便的完成Token数组的生成。而一旦完成Token数组的生成，就可以很简单 的完成SQL特征的生成。SQL特征被广泛用于各个系统中，比如pt-query-digest需要根据特征对SQL归 类，然而其基于正则表达式的实现有诸多bug。下面列举几个已知Bug： 原始SQL pt-query-digest生成的特征 SQL解析器生成的特征 select * from select * from mail_template？ where id = select * from email_template2 where email_template2 ？ id = ？ where id = 1 REPLACE INTO a replace into a values(\‘insert into foo replace into a values （?） VALUES(‘INSERT values(?+) INTO foo VALUES (1),(2)’) 因此可以看出SQL解析的优势是很明显的。 

22 . SQL解析在美团的应用 - 美团技术团队 学习建议 最近，在对SQL解析器和优化器探索的过程中，从一开始的茫然无措到有章可循，也总结了一些心得体 会，在这里跟大家分享一下。 首先，阅读相关图书书籍。图书能给我们系统认识解析器和优化器的角度。但是针对MySQL的此类图书市面上很 少，目前中文作品可以看一看《数据库查询优化器的艺术：原理解析与SQL性能优化》。 其次，要阅读源码，但是最好以某个版本为基础，比如MySQL5.6.23，因为SQL解析、优化部分的代码在不断变 化。尤其是在跨越大的版本时，改动力度大。 再次，多使用GDB调试，验证自己的猜测，检验阅读质量。 最后，需要写相关代码验证，只有写出来了才能算真正的掌握。 作者简介 广友，美团到店综合事业群MySQL DBA专家，2012年毕业于中国科学技术大学，2017年加入美团，长期致力于 MySQL及周边工具的研究。 金龙，2014年加入美团，主要从事相关的数据库运维、高可用和相关的运维平台建设。对运维高可用与架构相关感兴 趣的同学可以关注个人微信公众号“自己的设计师”，定期推送运维相关原创内容。 邢帆，美团到店综合事业群MySQL DBA，2017年研究生毕业后加入美团，目前已经对MySQL运维有一定经验，并 编写了一些自动化脚本。 招聘信息 美团DBA团队招聘各类DBA人才，base北京上海均可。我们致力于为公司提供稳定、可靠、高效的在线 存储服务，打造业界领先的数据库团队。这里有基于Redis Cluster构建的大规模分布式缓存系统 Squirrel，也有基于Tair进行大刀阔斧改进的分布式KV存储系统Cellar，还有数千各类架构的MySQL实 例，每天提供万亿级的OLTP访问请求。真正的海量、分布式、高并发环境。欢迎各位朋友推荐或自荐至 jinlong.cai#dianping.com。 

23 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 浅谈大型互联网企业入侵检测及防护策略 作者: 弼政 前言 如何知道自己所在的企业是否被入侵了？是没人来“黑”，还是因自身感知能力不足，暂时还无法发现？ 其实，入侵检测是每一个大型互联网企业都要面对的严峻挑战。价值越高的公司，面临入侵的威胁也越 大，即便是Yahoo这样的互联网鼻祖，在落幕（被收购）时仍遭遇全量数据失窃的事情。安全无小事，一 旦互联网公司被成功“入侵”，其后果将不堪想象。 基于“攻防对抗”的考量，本文不会提及具体的入侵检测模型、算法和策略，那些希望直接照搬“入侵策 略”的同学可能会感到失望。但是我们会将一部分运营思路分享出来，请各位同行指点，如能对后来者起 到帮助的作用，那就更好了，也欢迎大家跟我们交流探讨。 入侵的定义 典型的入侵场景：  黑客在很远的地方，通过网络远程控制目标的笔记本电脑/手机/服务器/网络设备，进而随意地 读取目标的隐私数据，又或者使用目标系统上的功能，包括但不限于使用手机的麦克风监听目 标，使用摄像头偷窥监控目标，使用目标设备的计算能力挖矿，使用目标设备的网络能力发动 DDoS攻击等等。亦或是破解了一个服务的密码，进去查看敏感资料、控制门禁/红绿灯。以上 这些都属于经典的入侵场景。 

24 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 我们可以给入侵下一个定义：就是黑客在未经授权的情况下，控制、使用我方资源（包括但不限于读写数 据、执行命令、控制资源等）达到各种目的。从广义上讲，黑客利用SQL注入漏洞窃取数据，或者拿到了 目标域名在ISP中的帐号密码，以篡改DNS指向一个黑页，又或者找到了目标的社交帐号，在微博/QQ/ 邮箱上，对虚拟资产进行非授权的控制，都属于入侵的范畴。 针对企业的入侵检测 企业入侵检测的范围，多数情况下比较狭义：一般特指黑客对PC、系统、服务器、网络（包括办公网、 生产网）控制的行为。 黑客对PC、服务器等主机资产的控制，最常见的方法是通过Shell去执行指令，获得Shell的这个动作叫做 GetShell。 比如通过Web服务的上传漏洞，拿到WebShell，或者利用RCE漏洞直接执行命令/代码（RCE环境变相的 提供了一个Shell）。另外，通过某种方式先植入“木马后门”，后续直接利用木马集成的SHELL功能对目 标远程控制，这个也比较典型。 因此，入侵检测可以重点关注GetShell这个动作，以及GetShell成功之后的恶意行为（为了扩大战果，黑 客多半会利用Shell进行探测、翻找窃取、横向移动攻击其它内部目标，这些区别于好人的特性也可以作 为重要的特征）。 有一些同行（包括商业产品），喜欢报告GetShell之前的一些“外部扫描、攻击探测和尝试行为”，并美其 名曰“态势感知”，告诉企业有人正在“试图攻击”。在笔者看来，实战价值并不大。包括美团在内的很多 企业，基本上无时无刻都在遭受“不明身份”的攻击，知道了有人在“尝试”攻击，如果并不能有效地去行 动，无法有效地对行动进行告警，除了耗费心力之外，并没有太大的实际价值。 当我们习惯“攻击”是常态之后，就会在这样的常态下去解决问题，可以使用什么加固策略，哪些可以实 现常态化的运营，如果有什么策略无法常态化运营，比如需要很多人加班临时突击守着，那这个策略多半 在不久之后就会逐渐消逝掉。跟我们做不做这个策略，并没有本质上的区别。 类似于SQL注入、XSS等一些不直接GetShell的Web攻击，暂时不在狭义的“入侵检测”考虑范围，建议可 以划入“漏洞”、“威胁感知”等领域，另行再做探讨。当然，利用SQL注入、XSS等入口，进行了GetShell 操作的，我们仍抓GetShell这个关键点，不必在乎漏洞入口在何处。 “入侵”和“内鬼” 与入侵接近的一种场景是“内鬼”。入侵本身是手段，GetShell只是起点，黑客GetShell的目标是为了之后 对资源的控制和数据的窃取。而“内鬼”天然拥有合法的权限，可以合法接触敏感资产，但是基于工作以 外的目的，他们对这些资源进行非法的处置，包括拷贝副本、转移外泄、篡改数据牟利等。 

25 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 内鬼的行为不在“入侵检测”的范畴，一般从内部风险控制的视角进行管理和审计，比如职责分离、双人 审计等。也有数据防泄密产品（DLP）对其进行辅助，这里不展开细说。 有时候，黑客知道员工A有权限接触目标资产，便定向攻击A，再利用A的权限把数据窃取走，也定性 为“入侵”。毕竟A不是主观恶意的“内鬼”。如果不能在黑客攻击A的那一刻捕获，或者无法区分黑客控制 的A窃取数据和正常员工A的访问数据，那这个入侵检测也是失败的。 入侵检测的本质 前文已经讲过，入侵就是黑客可以不经过我们的同意，来操作我们的资产，在手段上并没有任何的限制。 那么如何找出入侵行为和合法正常行为的区别，将其跟合法行为进行分开，就是“入侵发现”。在算法模 型上，这算是一个标记问题（入侵、非入侵）。 可惜的是，入侵这种动作的“黑”样本特别稀少，想通过大量的带标签的数据，有监督的训练入侵检测模 型，找出入侵的规律比较难。因此，入侵检测策略开发人员，往往需要投入大量的时间，去提炼更精准的 表达模型，或者花更多的精力去构造“类似入侵”的模拟数据。 一个经典的例子是，为了检测出WebShell，安全从业人员可以去GitHub上搜索一些公开的WebShell样 本，数量大约不到1000个。而对于机器学习动辄百万级的训练需求，这些数据远远不够。况且GitHub上 的这些样本集，从技术手法上来看，有单一技术手法生成的大量类似样本，也有一些对抗的手法样本缺 失。因此，这样的训练，试图让AI去通过“大量的样本”掌握WebShell的特征并区分出它们，原则上不太 可能完美地去实现。 此时，针对已知样本做技术分类，提炼更精准的表达模型，被称为传统的特征工程。而传统的特征工程往 往被视为效率低下的重复劳动，但效果往往比较稳定，毕竟加一个技术特征就可以稳定发现一类 WebShell。而构造大量的恶意样本，虽然有机器学习、AI等光环加持，但在实际环境中往往难以获得成 功：自动生成的样本很难描述WebShell本来的含义，多半描述的是自动生成的算法特征。 

26 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 另一个方面，入侵的区别是看行为本身是否“授权”，而授权与否本身是没有任何显著的区分特征的。因 此，做入侵对抗的时候，如果能够通过某种加固，将合法的访问收敛到有限的通道，并且给该通道做出强 有力的区分，也就能大大的降低入侵检测的成本。例如，对访问来源进行严格的认证，无论是自然人，还 是程序API，都要求持有合法票据，而派发票据时，针对不同情况做多纬度的认证和授权，再用IAM针对 这些票据记录和监控它们可以访问的范围，还能产生更底层的Log做异常访问模型感知。 这个全生命周期的风控模型，也是Google的BeyondCorp无边界网络得以实施的前提和基础。 因此，入侵检测的主要思路也就有2种： 根据黑特征进行模式匹配（例如WebShell关键字匹配）。 根据业务历史行为（生成基线模型），对入侵行为做异常对比（非白既黑），如果业务的历史行为不够收敛，就用加 固的手段对其进行收敛，再挑出不合规的小众异常行为。 入侵检测与攻击向量 根据目标不同，可能暴露给黑客的攻击面会不同，黑客可能采用的入侵手法也就完全不同。比如，入侵我 们的PC/笔记本电脑，还有入侵部署在机房/云上的服务器，攻击和防御的方法都有挺大的区别。 针对一个明确的“目标”，它被访问的渠道可能是有限集，被攻击的必经路径也有限。“攻击方法”+“目标 的攻击面”的组合，被称为“攻击向量”。 因此，谈入侵检测模型效果时，需要先明确攻击向量，针对不同的攻击路径，采集对应的日志（数据）， 才可能做对应的检测模型。比如，基于SSH登录后的Shell命令数据集，是不能用于检测WebShell的行 为。而基于网络流量采集的数据，也不可能感知黑客是否在SSH后的Shell环境中执行了什么命令。 基于此，如果有企业不提具体的场景，就说做好了APT感知模型，显然就是在“吹嘘”了。 所以，入侵检测得先把各类攻击向量罗列出来，每一个细分场景分别采集数据 （HIDS+NIDS+WAF+RASP+应用层日志+系统日志+PC……），再结合公司的实际数据特性，作出适应 公司实际情况的对应检测模型。不同公司的技术栈、数据规模、暴露的攻击面，都会对模型产生重大的影 响。比如很多安全工作者特别擅长PHP下的WebShell检测，但是到了一个Java系的公司…… 常见的入侵手法与应对 如果对黑客的常见入侵手法理解不足，就很难有的放矢，有时候甚至会陷入“政治正确”的陷阱里。比如 渗透测试团队说，我们做了A动作，你们竟然没有发现，所以你们不行。而实际情况是，该场景可能不是 一个完备的入侵链条，就算不发现该动作，对入侵检测效果可能也没有什么影响。每一个攻击向量对公司 造成的危害，发生的概率如何进行排序，解决它耗费的成本和带来的收益如何，都需要有专业经验来做支 撑与决策。 

27 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 现在简单介绍一下，黑客入侵教程里的经典流程（完整过程可以参考杀伤链模型）： 入侵一个目标之前，黑客对该目标可能还不够了解，所以第一件事往往是“踩点”，也就是搜集信息，加 深了解。比如，黑客需要知道，目标有哪些资产（域名、IP、服务），它们各自的状态如何，是否存在已 知的漏洞，管理他们的人有谁（以及如何合法的管理的），存在哪些已知的泄漏信息（比如社工库里的密 码等）…… 一旦踩点完成，熟练的黑客就会针对各种资产的特性，酝酿和逐个验证“攻击向量”的可行性，下文列举 了常见的攻击方式和防御建议。 高危服务入侵 所有的公共服务都是“高危服务”，因为该协议或者实现该协议的开源组件，可能存在已知的攻击方法 （高级的攻击者甚至拥有对应的0day），只要你的价值足够高，黑客有足够的动力和资源去挖掘，那么 当你把高危服务开启到互联网，面向所有人都打开的那一刻，就相当于为黑客打开了“大门”。 比如SSH、RDP这些运维管理相关的服务，是设计给管理员用的，只要知道密码/秘钥，任何人都能登录 到服务器端，进而完成入侵。而黑客可能通过猜解密码（结合社工库的信息泄露、网盘检索或者暴力破 解），获得凭据。事实上这类攻击由于过于常见，黑客早就做成了全自动化的全互联网扫描的蠕虫类工 具，云上购买的一个主机如果设置了一个弱口令，往往在几分钟内就会感染蠕虫病毒，就是因为这类自动 化的攻击者实在是太多了。 或许，你的密码设置得非常强壮，但是这并不是你可以把该服务继续暴露在互联网的理由，我们应该把这 些端口限制好，只允许自己的IP（或者内部的堡垒主机）访问，彻底断掉黑客通过它入侵我们的可能。 与此类似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync等等，凡是自己用来管理服务器或者数据 库、文件的服务，都不应该针对互联网无限制的开放。否则，蠕虫化的攻击工具会在短短几分钟内攻破我 

28 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 们的服务，甚至直接加密我们的数据，甚至要求我们支付比特币，进行敲诈勒索。 还有一些高危服务存在RCE漏洞（远程命令执行），只要端口开放，黑客就能利用现成的exploit，直接 GetShell，完成入侵。 防御建议： 针对每一个高危服务做入侵检测的成本较高，因为高危服务的具体所指非常的多，不一定存 在通用的特征。所以，通过加固方式，收敛攻击入口性价比更高。禁止所有高危端口对互联网开放可能， 这样能够减少90%以上的入侵概率。 Web入侵 随着高危端口的加固，黑客知识库里的攻击手法很多都会失效了。但是Web服务是现代互联网公司的主 要服务形式，不可能都关掉。于是，基于PHP、Java、ASP、ASP.NET、Node、C写的CGI等等动态的 Web服务漏洞，就变成了黑客入侵的最主要入口。 比如，利用上传功能直接上传一个WebShell，利用文件包含功能，直接引用执行一个远程的 WebShell（或者代码），然后利用代码执行的功能，直接当作Shell的入口执行任意命令，解析一些图 片、视频的服务，上传一个恶意的样本，触发解析库的漏洞…… Web服务下的应用安全是一个专门的领域（道哥还专门写了本《白帽子讲Web安全》），具体的攻防场 景和对抗已经发展得非常成熟了。当然，由于它们都是由Web服务做为入口，所以入侵行为也会存在某 种意义上的共性。相对而言，我们比较容易能够找到黑客GetShell和正常业务行为的一些区别。 针对Web服务的入侵痕迹检测，可以考虑采集WAF日志、Access Log、Auditd记录的系统调用，或者 Shell指令，以及网络层面Response相关的数据，提炼出被攻击成功的特征，建议我们将主要的精力放在 这些方面。 0day入侵 通过泄漏的工具包来看，早些年NSA是拥有直接攻击Apache、Nginx这些服务的0day武器的。这意味着 对手很可能完全不用在乎我们的代码和服务写成什么样，拿0day一打，神不知鬼不觉就GetShell了。 但是对于入侵检测而言，这并不可怕：因为无论对手利用什么漏洞当入口，它所使用的Shellcode和之后 的行为本身依然有共性。Apache存在0day漏洞被攻击，还是一个PHP页面存在低级的代码漏洞被利用， 从入侵的行为上来看，说不定是完全一样的，入侵检测模型还可以通用。 所以，把精力聚焦在有黑客GetShell入口和之后的行为上，可能比关注漏洞入口更有价值。当然，具体的 漏洞利用还是要实际跟进，然后验证其行为是否符合预期。 办公终端入侵 绝大多数APT报告里，黑客是先对人（办公终端）下手，比如发个邮件，哄骗我们打开后，控制我们的 PC，再进行长期的观察/翻阅，拿到我们的合法凭据后，再到内网漫游。所以这些报告，多数集中在描述 黑客用的木马行为以及家族代码相似度上。而反APT的产品、解决方案，多数也是在办公终端的系统调用 层面，用类似的方法，检验“免杀木马”的行为。 

29 . 浅谈大型互联网企业入侵检测及防护策略 - 美团技术团队 因此，EDR类的产品+邮件安全网关+办公网出口的行为审计+APT产品的沙箱等，联合起来，可以采集到 对应的数据，并作出相似的入侵检测感知模型。而最重要的一点，是黑客喜欢关注内部的重要基础设施， 包括但不限于AD域控、邮件服务器、密码管理系统、权限管理系统等，一旦拿下，就相当于成为了内网 的“上帝”，可以为所欲为。所以对公司来说，重要基础设施要有针对性的攻防加固讨论，微软针对AD的 攻防甚至还发过专门的加固白皮书。 入侵检测基本原则 不能把每一条告警都彻底跟进的模型，等同于无效模型。入侵发生后，再辩解之前其实有告警，只是太多 了没跟过来/没查彻底，这是“马后炮”，等同于不具备发现能力，所以对于日均告警成千上万的产品，安 全运营人员往往表示很无奈。 我们必须屏蔽一些重复发生的相似告警，以集中精力把每一个告警都闭环掉。这会产生白名单，也就是漏 报，因此模型的漏报是不可避免的。 由于任何模型都会存在漏报，所以我们必须在多个纬度上做多个模型，形成关联和纵深。假设WebShell 静态文本分析被黑客变形绕过了，在RASP（运行时环境）的恶意调用还可以进行监控，这样可以选择接 受单个模型的漏报，但在整体上仍然具备发现能力。 既然每一个单一场景的模型都有误报漏报，我们做什么场景，不做什么场景，就需要考虑“性价比”。比 如某些变形的WebShell可以写成跟业务代码非常相似，人的肉眼几乎无法识别，再追求一定要在文本分 析上进行对抗，就是性价比很差的决策。如果通过RASP的检测方案，其性价比更高一些，也更具可行性 一些。 我们不太容易知道黑客所有的攻击手法，也不太可能针对每一种手法都建设策略（考虑到资源总是稀缺 的）。所以针对重点业务，需要可以通过加固的方式（还需要常态化监控加固的有效性），让黑客能攻击 的路径极度收敛，仅在关键环节进行对抗。起码能针对核心业务具备兜底的保护能力。 基于上述几个原则，我们可以知道一个事实，或许我们永远不可能在单点上做到100%发现入侵，但是我 们可以通过一些组合方式，让攻击者很难绕过所有的点。 当老板或者蓝军挑战，某个单点的检测能力有缺失时，如果为了“政治正确”，在这个单点上进行无止境 的投入，试图把单点做到100%能发现的能力，很多时候可能只是在试图制造一个“永动机”，纯粹浪费人 力、资源，而不产生实际的收益。将节省下来的资源，高性价比的布置更多的纵深防御链条，效果显然会 更好。 入侵检测产品的主流形态 入侵检测终究是要基于数据去建模，比如针对WebShell的检测，首先要识别Web目录，再对Web目录下 的文件进行文本分析，这需要做一个采集器。基于Shell命令的入侵检测模型，需要获取所有Shell命令， 这可能要Hook系统调用或者劫持Shell。基于网络IP信誉、流量payload进行检测，或者基于邮件网关对 内容的检查，可能要植入网络边界中，对流量进行旁路采集。