浅析大规模DDOS防护架构-应对T级攻防

时间 2019-12-05

标签浅析大规模 ddos 防护架构应对攻防栏目网络爬虫繁體版

原文原文链接

ayazero · 2015/09/18 0:57前端

文章转载自：www.ayazero.com/?p=75nginx

0x00 导读

0x01 DDOS分类

在讲防护以前简单介绍一下各种攻击，由于DDOS是一类攻击而并非一种攻击，而且DDOS的防护是一个能够作到相对自动化但作不到绝对自动化的过程，不少演进的攻击方式自动化不必定能识别，仍是须要进一步的专家肉眼判断。web

网络层攻击算法
- Syn-floodshell
  利用TCP创建链接时3次握手的“漏洞”，经过原始套接字发送源地址虚假的SYN报文，使目标主机永远没法完成3次握手，占满了系统的协议栈队列，资源得不到释放，进而拒绝服务，是互联网中最主要的DDOS攻击形式之一。网上有一些加固的方法，例如调整内核参数的方法，能够减小等待及重试，加速资源释放，在小流量syn-flood的状况下能够缓解，但流量稍大时彻底不抵用。防护syn-flood的常见方法有：syn proxy、syn cookies、首包（第一次请求的syn包）丢弃等。数据库
- ACK-flood后端
  对于虚假的ACK包，目标设备会直接回复RST包丢弃链接，因此伤害值远不如syn-flood。DDOS的一种原始方式。api
- UDP-flood缓存
  使用原始套接字伪造大量虚假源地址的UDP包，目前以DNS协议为主。安全
- ICMP-flood
  Ping洪水，比较古老的方式。
应用层攻击
- CC
  ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDOS设备-“黑洞”，经过botnet的傀儡主机或寻找匿名代理服务器，向目标发起大量真实的http请求，最终消耗掉大量的并发资源，拖慢整个网站甚至完全拒绝服务。
  互联网的架构追求扩展性本质上是为了提升并发能力，各类SQL性能优化措施：消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗，而CC大有反其道而行之的意味，占满服务器并发链接数，尽量使请求避开缓存而直接读数据库，读数据库要找最消耗资源的查询，最好没法利用索引，每一个查询都全表扫描，这样就能用最小的攻击资源起到最大的拒绝服务效果。
  互联网产品和服务依靠数据分析来驱动改进和持续运营，因此除了前端的APP、中间件和数据库这类OLTP系统，后面还有OLAP，从日志收集，存储到数据处理和分析的大数据平台，当CC攻击发生时，不只OLTP的部分受到了影响，实际上CC会产生大量日志，直接会对后面的OLAP产生影响，影响包括两个层面，一个当日的数据统计彻底是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。
  CC是目前应用层攻击的主要手段之一，在防护上有一些方法，但不能完美解决这个问题。
- DNS flood
  伪造源地址的海量DNS请求，用因而淹没目标的DNS服务器。对于攻击特定企业权威DNS的场景，能够将源地址设置为各大ISP DNS服务器的ip地址以突破白名单限制，将查询的内容改成针对目标企业的域名作随机化处理，当查询没法命中缓存时，服务器负载会进一步增大。
  DNS不仅在UDP-53提供服务，一样在TCP协议提供服务，因此防护的一种思路就是将UDP的查询强制转为TCP，要求溯源，若是是假的源地址，就再也不回应。对于企业自有权威DNS服务器而言，正常请求多来自于ISP的域名递归解析，因此将白名单设置为ISP的DNS server列表。对于源地址伪形成ISP DNS的请求，能够经过TTL值进一步判断。
- 慢速链接攻击
  针对http协议，以知名的slowloris攻击为起源：先创建http链接，设置一个较大的content-length，每次只发送不多的字节，让服务器一直觉得http头部没有传输完成，这样的链接一多很快就会出现链接耗尽。
  目前出现了一些变种，http慢速的post请求和慢速的read请求都是基于相同的原理。
- DOS攻击
  有些服务器程序存在bug、安全漏洞，或架构性缺陷，攻击者能够经过构造的畸形请求发送给服务器，服务器因不能正确处理恶意请求而陷入僵死状态，致使拒绝服务。例如某些版本的app服务器程序存在缓冲区溢出，漏洞能够触发但没法获得shell，攻击者能够改变程序执行流程使其跳转到空指针或没法处理的地址，用户态的错误会致使进程挂起，若是错误不能被内核回收则可能使系统当掉。
  这类问题效果也表现为拒绝服务，但本质上属于漏洞，能够经过patch程序的最新版本解决，笔者认为不属于DDOS的范畴。
攻击方式
- 混合型
  在实际大流量的攻击中，一般并非以上述一种数据类型来攻击，每每是混杂了TCP和UDP流量，网络层和应用层攻击同时进行。
- 反射型
  2004年时DRDOS第一次披露，经过将SYN包的源地址设置为目标地址，而后向大量的
  真实TCP服务器发送TCP的SYN包，而这些收到SYN包的TCP server为了完成3次握手把SYN|ACK包“应答”给目标地址，完成了一次“反射”攻击，攻击者隐藏了自身，但有个问题是攻击者制造的流量和目标收到的攻击流量是1:1，且SYN|ACK包到达目标后立刻被回以RST包，整个攻击的投资回报率不高。
  反射型攻击的本质是利用“质询-应答”式协议，将质询包的源地址经过原始套接字伪造设置为目标地址，则应答的“回包”都被发送至目标，若是回包体积比较大或协议支持递归效果，攻击流量会被放大，成为一种高性价比的流量型攻击。
  反射型攻击利用的协议目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。
- 流量放大型
  以上面提到的DRDOS中常见的SSDP协议为例，攻击者将Search type设置为ALL，搜索全部可用的设备和服务，这种递归效果产生的放大倍数是很是大的，攻击者只须要以较小的伪造源地址的查询流量就能够制造出几十甚至上百倍的应答流量发送至目标。
- 脉冲型
  不少攻击持续的时间很是短，一般5分钟之内，流量图上表现为突刺状的脉冲。
  之因此这样的攻击流行是由于“打-打-停-停”的效果最好，刚触发防护阈值，防护机制开始生效攻击就停了，周而复始。蚊子不叮你，却在耳边飞，刚开灯想打它就跑没影了，当你刚关灯它又来了，你就无法睡觉。
  自动化的防护机制大部分都是依靠设置阈值来触发。尽管不少厂商宣称本身的防护措施都是秒级响应，但实际上比较难。
  网络层的攻击检测一般分为逐流和逐包，前者根据netflow以必定的抽样比例（例如1000:1）检测网络是否存在ddos攻击，这种方式由于是抽样比例，因此精确度较低，作不到秒级响应。第二种逐包检测，检测精度和响应时间较短，但成本比较高，通常厂商都不会无视TCO所有部署这类方案。即使是逐包检测，其防护清洗策略的启动也依赖于阈值，加上清洗设备通常状况下不会串联部署，触发清洗后须要引流，所以大部分场景能够作秒级检测但作不到秒级防护，近源清洗尚且如此，云清洗的触发和转换过程就更慢了。因此利用防护规则的生效灰度期，在触发防护前完成攻击会有不错的效果，在结果上就表现为脉冲。
- 链路泛洪
  随着DDOS攻击技术的发展，又出现了一种新型的攻击方式link-flooding attack，这种方式不直接攻击目标而是以堵塞目标网络的上一级链路为目的。对于使用了ip anycast的企业网络来讲，常规的DDOS攻击流量会被“分摊”到不一样地址的基础设施，这样能有效缓解大流量攻击，因此攻击者发明了一种新方法，攻击至目标网络traceroute的倒数第二跳，即上联路由，导致链路拥塞。国内ISP目前未开放anycast，因此这种攻击方式的必要性有待观望。
  对一级ISP和IXP的攻击均可以使链路拥塞。

0x02 多层防护结构

DDOS攻击本质上是一种只能缓解而不能彻底防护的攻击，它不像漏洞那样打个补丁解决了就是解决了，DDOS就算购买和部署了当前市场上比较有竞争力的防护解决方案也彻底谈不上完全根治。防火墙、IPS、WAF这些安全产品都号称本身有必定的抗DDOS能力，而实际上他们只针对小流量下，应用层的攻击比较有效，对于稍大流量的DDOS攻击则无济于事。

以2015年年中的状况为例，国内的DDOS攻击在一个月内攻击流量达到300G的就将近10-20次，这个数值将随着国内家庭宽带网速提高而进一步放大。对于200~500G的攻击流量该如何防护，下来将展现完整的防护结构，一般能够分为4层。

这4层不是严格意义上的纵深防护关系，也不是在全部的防护中4层都会参与，可能有时候只是其中的2层参与防护。但对于超大流量攻击而言，4层就是防护机制的所有，再没有其余手段了。跟厂商们的市场宣传可能有所不一样，大流量攻击的防御并非像某些厂商宣称的那样靠厂商单方面就能解决的，而是多层共同参与防护的结果。

ISP/WAN层
这一层一般对最终用户不可见，若是只是中小企业，那这一层可能真的不会接触到。但若是是大型互联网公司，公有云厂商，甚至是云清洗厂商，这层是必不可少的。由于当流量超过本身能处理的极限时必需要借助电信运营商的能力。大型互联网公司虽然自身储备的带宽比较大，但还没到达轻松抵抗大流量DDOS的程度，毕竟带宽是全部IDC成本中最贵的资源没有之一。目前不管是云计算厂商，大型互联网公司向外宣称的成功抵御200G以上攻击的新闻背后都用到了运营商的抗D能力，另外像第三方的云清洗平台他们实际上或多或少的依赖电信运营商，若是只依靠自己的清洗能力，都是很是有限的。
目前如中国电信的专门作抗DDOS的云堤提供了[近源清洗]和[流量压制]的服务，对于购买其服务的厂商来讲能够自定义须要黑洞路由的IP与电信的设备联动，黑洞路由是一种简单粗暴的方法，除了攻击流量，部分真实用户的访问也会被一块儿黑洞掉，对用户体验是一种打折扣的行为，本质上属于为了保障留给其他用户的链路带宽的弃卒保帅的作法，之因此还会有这种收费服务是由于假如不这么作，全站服务会对全部用户完全没法访问。对于云清洗厂商而言，实际上也须要借助黑洞路由与电信联动。
相比之下，对攻击流量的牵引，清洗，回注的防护方式对用户体验的挑战没那么大，可是跟黑洞路由比防护方的成本比较高，且触发到响应的延时较大。
在运营商防护这一层的主要的参与者是大型互联网公司，公有云厂商，云清洗厂商，其最大的意义在于应对超过自身带宽储备和自身DDOS防护能力以外的超大攻击流量时做为补充性的缓解措施。
CDN/Internet层
CDN并非一种抗DDOS的产品，但对于web类服务而言，他却正好有必定的抗DDOS能力，以大型电商的抢购为例，这个访问量很是大，从不少指标上看不亚于DDOS的CC，而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求，最后到达数据库的请求只占总体请求量的很小一部分。
对http CC类型的DDOS，不会直接到源站，CDN会先经过自身的带宽硬抗，抗不了的或者穿透CDN的动态请求会到源站，若是源站前端的抗DDOS能力或者源站前的带宽比较有限，就会被完全DDOS。
云清洗厂商提出的策略是，预先设置好网站的CNAME，将域名指向云清洗厂商的DNS服务器，在通常状况下，云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站，在检测到攻击发生时，域名指向本身的清洗集群，而后再将清洗后的流量回源。
检测方式主要是在客户网站前部署反向代理（nginx），托管全部的并发链接。在对攻击流量进行分流的时候，准备好一个域名到IP的地址池，当IP被攻击时封禁并启用地址池中的下一个IP，如此往复。
以上是类Cloudflare的解决方案，国内云清洗厂商的实现原理都类似。不过这类方案都有一个通病，因为国内环境不支持anycast，经过DNS引流的方式须要比较长的生效时间，这个时间依赖于DNS递归生效的时长，对自身彻底不可控。同时CDN仅对web类服务有效，对游戏类TCP直连的服务无效。
网上不少使用此类抗D服务的过程能够归纳为一句话：更改CNAME指向，等待DNS递归生效。
DC层
目前国内厂商华为的Anti-ddos产品的最高型号支持T级高达1440Gbps带宽的防御。原理大体以下图所示，在DC出口以镜像或分光部署DDOS探针（检测设备），当检测到攻击发生时，将流量牵引到旁路部署的DDOS清洗设备，再将通过清洗的正常流量回注到业务主机，以此完成一轮闭环。
部署设备自己并无太大的技术含量，有技术含量的部分都已经被当作防护算法封装在产品盒子里了。不过要指出的一点是，目前市场上的ADS盒子既有的算法和学习能力是有限的，他仍然须要人的介入，好比：
- 对业务流量基线的自适应学习能力是有限的，例如电商行业双11大促日子的流量模型可能就超越了ADS的学习能力，正常流量已经触发攻击断定
- 自动化触发机制创建在阈值之上，就意味着不是彻底的自动化，由于阈值是一个经验和业务场景相关的值
- 全局策略是通用性策略，不能对每个子业务起到很好的防护效果，有可能子业务已经被D了，全局策略还没触发
- 常见的DDOS类型ADS能够自动处理，但变换形式的DDOS类型可能还须要人工识别
- 默认的模板策略可能不适用于某些业务，须要自定义
DDOS防护除了总体架构设计外，比较须要专业技能的地方就是在上述例子的场景中。目前在ADS设备里覆盖了3-4,7这三层的解决方案。
通常状况下ADS设备能够缓解大部分常见的DDOS攻击类型，相对而言3-4层的攻击手法比较固定，而7层的攻击，因为涉及的协议较多，手法变化层出不穷，因此ADS有时候对7层的防御作不到面面俱到，好比对CC，ADS提供了http 302，验证码等，但仍是不能很好的解决这个问题。应用层的防御须要结合业务来作，ADS则在能利用的场景下承担辅助角色，好比对于游戏封包的私有协议，经过给packet添加指纹的方式，ADS在客户端和服务端中间鉴别流入的数据包是否包含指纹。
OS/APP层
这是DDOS的最后一道防线。这一层的意义主要在于漏过ADS设备的流量作最后一次过滤和缓解，对ADS防御不了的应用层协议作补充防御。好比NTP反射，能够经过服务器配置禁用monlist，若是不提供基于UDP的服务，能够在边界上直接阻断UDP协议。
互联网在线服务中最大的比重就是web服务，所以有些互联网公司喜欢本身在系统层面去作应用层的DDOS防御，例如对抗CC，有时这些功能也能顺带关联到业务安全上，好比针对黄牛抢单等。
实现方式能够是web服务器模块，也能够是独立部署的旁路系统，反向代理将完整的http请求转发给检测服务器，检测服务器根据几方面的信息：
- 来自相同IP的并发请求
- 相同ip+cookie的并发请求
- 相同http头部可设置字段
- 相同的request URL
而后保存客户端的链接信息计数表，例如单位时间内相同IP+cookie再次发起链接请求则此客户端IP的计数器+1，直到触发阈值，而后服务器会进行阻断，为了不误杀，也能够选择性的弹出验证码。
以上是拿CC防护举了个例子，ADS设备自己提供了http 302跳转，验证码，Javascript解析等防护方式，尽管OS和应用层能够作更多的事情，但毕竟有本身去开发和长期维护的代价，这个收益要看具体状况。
链路带宽
增长带宽，大部分介绍DDOS防护策略的文章里彷佛不多说起这一点，但倒是以上全部防护的基础，例如第二层次的CDN实际上就是拼带宽，不少大型企业选择自建CDN，本质上就是本身增长带宽的行为。除了CDN以外，要保障DC出口的多ISP链路、备份链路，到下层机柜交换机的带宽都不存在明显的单点瓶颈，不然抗DDOS的处理性可以了，可是流量流经某个节点时忽然把一个杂牌交换机压垮了，最后的结果仍是表现为有问题。
对运维经验成熟的互联网公司而言，通常都有能容管理，对于促销活动，高峰时段的带宽，IDC资源的波峰波谷都有预先的准备，DDOS防护主要是消除这些网络方案中内在的单点瓶颈。

0x03 不一样类型的企业

DDOS的防护本质上属于资源的对抗，完整的4层防护效果虽好，但有一个明显问题就是TCO，这种成本开销除了互联网行业排名TOP10之外的公司基本都吃不消。或者就算付得起这钱，在IT总体投资的占比会显得太高，付得起不表明这种投资是正确的。因此针对不一样的企业分别描述DDOS缓解方案的倾向和选择性。

大型平台
这里的“大”有几层意思：
- 公司颇有钱，能够在补贴具体的业务上不“太”计较投入，对土豪来讲只选效果最优方案
- 公司不必定处在很赚钱的阶段，但IDC投资规模足够大，这样为了保障既有的投入，安全的总投资维持一个固定百分比也是很是有必要的，在IDC盘子很大的时候不必省“小钱”
- 与潜在的因为服务中断形成的损失比，DDOS防护的投资能够忽略不计
映射到现实中与这几条相关的公司：
- 市值100亿美圆以上互联网公司
- 大型公有云厂商，IaaS、PaaS平台
- IDC规模多少算大呢，这个问题其实很难判断，1w台物理服务器算多么，如今应该只能算中等吧
- 利润比较高的业务，好比游戏、在线支付假如被DDOS的频率较高
对于IDC规模比较大又有钱的公司来讲，防DDOS的口诀就是“背靠运营商，大力建机房”，在拥有所有的DDOS防护机制的前提下，不断的提升IDC基础设施的壁垒给攻击者制造更高的门槛，对于网络流量比较高的公司而言，抗DDOS是有先天优点的，由于业务急速增加而带来的基础设施的扩容无心识间就成了一种防护能力，但对于没有那么大业务流量的公司，空买一堆带宽烧钱恐怕也没人愿意。
对于比较有钱，但没那么多线上服务器的公司而言，本身投入太多IDC建设多是不必的，此时应该转向经过购买的手段尽量的得到所有的DDOS防护机制。
中小企业
资源的对抗确定不是中小企业的强项，因此追求ROI是主要的抗DDOS策略。第一种极度省钱模式，平时裸奔，直到受攻击才找抗DDOS厂商临时引流，这种方案效果差一点，绝大多数企业应该都是这种心理，得过且过，能省则省，也无可厚非，不过关键时间知道上哪儿去找谁，知道作哪些事。
第二种追求效果，但愿有性价比。若是自己业务运行于公有云平台，能够直接使用云平台提供的抗DDOS能力，对于web类能够考虑提早购买云清洗厂商的服务。

0x04 不一样类型的业务

不一样的类型的服务所须要的DDOS防护机制不彻底相同，因此不能直接拿前述4层生搬硬套。

Web
对于web类服务，攻击发生时终端用户能够有必定的延迟容忍，在防护机制上4层所有适用，大型平台的通常都是4层所有拥有，规模小一点的企业通常购买云清洗，cloudflare类的服务便可。
游戏类
Web api形式的轻游戏跟web服务相似，而对于TCP socket类型的大型网游，稍有延迟很影响用户体验，甚至很容易掉线。云WAF、CDN等措施由于是针对web的所在在该场景下无效，只有经过DNS引流和ADS来清洗，ADS不能完美防护的部分能够经过修改客户端、服务端的通讯协议作一些辅助性的小动做，例如封包加tag标签，检测到没有tag的包一概丢弃，防护机制基本都是依赖于信息不对称的小技巧。DNS引流的部分对于有httpdns的厂商能够借助其缓解DNS递归生效的时间。
服务策略
- 分级策略
  对于平台而言，有些服务被DDOS会致使全站服务不可用，例如DNS不可用则至关于全线服务不可用，对于强帐号体系应用例如电商、游戏等若是SSO登录不可用则全线服务不可用，攻击者只要击垮这些服务就能“擒贼擒王”，因此安全上也须要考虑针对不一样的资产使用不一样等级的保护策略，根据BCM的要求，先将资产分类分级，划分出不一样的可用性SLA要求，而后根据不一样的SLA实施不一样级别的防御，在具体防御策略上，能形成平台级SPOF（单点故障）的服务或功能应投入更高成本的防护措施，所谓更高成本不只指购买更多的ADS设备，同时可能创建多灾备节点，而且在监控和响应优先级上应该更高。
- Failover机制
  DDOS防护不仅是依赖于DDOS防护的那4层手段，同时依赖于基础设施的强大，例如作分流，就须要多点异地灾备，mirror site & hot site & standby system，云上的系统须要跨AZ部署，这些能够随时切换的基础。把鸡蛋放在一个篮子里会致使没什么选择。
  基础设施和应用层面创建冗余是技术形式上的基础，光有这些还远远不够，须要有与之配套的DRP&BCP策略集，而且须要真实的周期性的演练，意在遇到超大流量攻击时可以从容应对。
- 有损服务
  在应用服务设计的时候，应该尽可能避免“单点瓶颈”，避免一个点被DDOS了整个产品就很差用了，而是但愿作到某些服务即便关闭或下线了仍然不影响其余在线的服务（或功能），能在遇到须要弃卒保帅的场景时有能够“割肉”的选择，不要除了“0”就是“1”，仍是要存在灰度，好比原来10个服务在线，遇到攻击时我只要保底重要的3个服务在线便可。
补充手段

DDOS攻击的目的不必定彻底是出于想打垮服务，好比之前在作游戏时遇到玩家DDOS服务器的目的居然是由于没抢到排在第一的房间，这种因素经过产品设计就能够根治，而有不少应用层DDOS只是为了达成另一种目的，都跟上述4层防护机制无关，而跟产品设计有关。因此防护DDOS这事得看一下动因，不能盲目应对。

0x05 NIPS场景

ADS本质上是一个包过滤设备，虽功用不一样却跟IPS有点类似，以前也提到有时候须要提供全站IPS的虚拟补丁功能，ADS设备就能够充当这一角色，只是条目不宜多，只上有限的条目，下面的是NSFOCUS的ADS设备的规则编辑界面，payload可自定义

通常安全团队能力尚可的话，能够经过运行POC exploit，而后抓包找出攻击payload的特征，编辑16进制的匹配规则，便可简单的实现人工定制。

0x06 破防和反制

从安全管理者的角度看，即使是拥有完整的4层防护机制也并不是无懈可击，号称拥有400-500G防御能力的平台是彻底有可能被打垮的，彻底的防御能力是创建在人、策略、技术手段都生效的状况才有的，若是这些环节出了问题，anti-ddos的整个过程可能会失败。例以下面提到的这些问题：

超大流量攻击时须要用到黑洞路由，但黑洞路由的IP须要由防护方定义和联动，“联动”的过程就是向上游设备发送封禁IP的通知，若是接口不可用，那么此功能会失效，因此ISP级的防护是有失效可能性的
CDN云清洗服务依赖于清洗服务商接管域名解析，若是云清洗服务商自己的DNS不可用，也将致使这一层面的防护失效，诸如此类的问题还有很多，这些抗D厂商自身并不是无懈可击
ADS平时不必定串联部署，但攻击发生引流后必定是业务的前端设备，假如这个设备自己存在DOS的可能，即便是触发了bypass也至关于防护彻底失效了，另外一方面策略下发一般是ADS设备跟管理节点互通，若是管理节点出现可用性问题，也将致使ADS防护的一系列问题。
超大流量攻击须要人工干预时，最基本的需求是安全或运维人员能在办公网络链接到ADS的管理节点，能远程运维ADS设备，若是此时办公网络的运维管理链路出现故障，不只切断了人员操做，还会把现场应急的紧张气氛提高一个量级，令人更加手忙脚乱。

以上并不在于提供新的攻击的思路，而在于向anti-ddos方案的制定者提供另类视角以便于审视方案中的短板。

0x07 立案和追踪

目前对于流量在100G以上的攻击是能够立案的，这比过去幸福了不少。过去没有本土特点的资源甚至都无法立案，可是立案只是万里长征的第一步，若是你想找到人，必须成功完成如下步骤：

在海量的攻击中，寻找倒推的线索，找出多是C&C服务器的IP或相关域名等
“黑”吃“黑”，端掉C&C服务器
经过登陆IP或借助第三方APT的大数据资源（若是你能获得的话）物理定位攻击者
陪叔叔们上门抓捕
上法庭诉讼

若是这我的没有特殊身份，也许你就能如愿，但假如遇到一些特殊人物，你几个月都白忙乎。而黑吃黑的能力则依赖于安全团队自己的渗透能力比较强，且有闲情逸致作这事。这个过程对不少企业来讲成本仍是有点高，光有实力的安全团队这条门槛就足以砍掉绝大多数公司。笔者过去也只是刚好有缘遇到了这么一个团队。