此篇文章，意在通过记录这次HW事件，然后事后针对突发情况，产生思考，然后查阅相关资料，对知识进行一次总结，很多内容来源于一些原文，我觉得写得不错，比我好,若有不足之处，敬请谅解。

在攻防的过程中，我使用的是IPS（具体型号，厂商，不便告知）。通过这台入侵防御系统，可以实现对流经数据和流量的监控，进而可以深度分析，最后达到主动防御的效果。当大量的数据流经时，CPU和内存将会消耗相应的资源来处理这次事件。简言之，数据量越多，CPU和内存消耗越高。最后当CPU和内存的消耗超过一定阈值时，设备会发出告警，这时需要人工来采取相应的策略来解决问题。

对于第一个问题，我通过和后台工程师交流了一下，原因是：设备获取数据的方式，是在5分钟内，随机获取一个值，然后通过这个值与阈值进行对比，然后判断是否发出警告。可以这样解释，前端的图像，是对整个时间段的CPU消耗的数据呈现，假设，当前CPU消耗最高到80%，阈值设定为20%，那么我们看到的画面是80%的高峰，但是从中随机获取一个值，15%，低于阈值，所以也就不会报警。

这样的设计，对于客户来说，需要改进；对于厂商，这样的设计，也有一定的道理。对此，不在今天的话题范围内。

对于第二个问题，设备的处理方式是，首先检查数据的接口信息，判断是否存在丢包；然后关闭系统的一些不必要的端口和应用，联系后台处理；最后可以bypass，不对数据进行拦截。

这样的处理方式，在业界属于比较普遍的现象。同时，也反映出，当前dos攻击的防御存在很大的限制，并且也说明IPS存在一定的瓶颈（数据流量的瓶颈，此问题，我已了解，后面会在总结中，说明这一切）。至于其他厂商如何解决的，这是今天的重点。

相关知识链接：
DOS——腾讯云
DOS——阿里云
ddos,全称是分布式拒绝服务（distributed denial of service,简称ddos）将多台计算机联合起来作为攻击平台，通过远程连接利用恶意程序，对一个或多个目标发起ddos攻击，消耗目标服务器性能或网络带宽，从而造成服务器无法正常地提供服务。

通常，攻击者使用一个非法账号将DDoS主控程序安装在一台计算机上，并在网络上的多台计算机上安装代理程序。在所设定的时间内，主控程序与大量代理程序进行通讯，代理程序收到指令时对目标发动攻击，主控程序甚至能在几秒钟内激活成百上千次代理程序的运行。

畸形报文：畸形报文主要包括Frag Flood、Smurf、Stream Flood、Land Flood、IP畸形报文、TCP畸形报文、UDP畸形报文等。畸形报文攻击指通过向目标系统发送有缺陷的IP报文，使得目标系统在处理这样的报文时出现崩溃，从而达到拒绝服务的攻击目的。
传输层DDOS攻击：传输层DDoS攻击主要包括Syn Flood、Ack Flood、UDP Flood、ICMP Flood、RstFlood等。以Syn Flood攻击为例，它利用了TCP协议的三次握手机制，当服务端接收到一个Syn请求时，服务端必须使用一个监听队列将该连接保存一定时间。因此，通过向服务端不停发送Syn请求，但不响应Syn+Ack报文，从而消耗服务端的资源。当监听队列被占满时，服务端将无法响应正常用户的请求，达到拒绝服务攻击的目的。
DNS DDOS攻击：DNS DDoS攻击主要包括DNS Request Flood、DNS Response Flood、虚假源+真实源DNS Query Flood、权威服务器攻击和Local服务器攻击等。以DNS Query Flood攻击为例，其本质上执行的是真实的Query请求，属于正常业务行为。但如果多台傀儡机同时发起海量的域名查询请求，服务端无法响应正常的Query请求，从而导致拒绝服务。
Web应用层DDoS攻击：Web应用层攻击主要是指HTTP Get Flood、HTTP Post Flood、CC等攻击。通常应用层攻击完全模拟用户请求，类似于各种搜索引擎和爬虫一样，这些攻击行为和正常的业务并没有严格的边界，难以辨别。
Web服务中一些资源消耗较大的事务和页面。例如，Web应用中的分页和分表，如果控制页面的参数过大，频繁的翻页将会占用较多的Web服务资源。尤其在高并发频繁调用的情况下，类似这样的事务就成了早期CC攻击的目标。
由于现在的攻击大都是混合型的，因此模拟用户行为的频繁操作都可以被认为是CC攻击。例如，各种刷票软件对网站的访问，从某种程度上来说就是CC攻击。
CC攻击瞄准的是Web应用的后端业务，除了导致拒绝服务外，还会直接影响Web应用的功能和性能，包括Web响应时间、数据库服务、磁盘读写等。
连接型DDoS攻击：连接型DDoS攻击主要是指TCP慢速连接攻击、连接耗尽攻击、Loic、Hoic、Slowloris、 Pyloris、Xoic等慢速攻击。以Slowloris攻击为例，其攻击目标是Web服务器的并发上限。当Web服务器的连接并发数达到上限后，Web服务即无法接受新的请求。Web服务接收到新的HTTP请求时，建立新的连接来处理请求，并在处理完成后关闭这个连接。如果该连接一直处于连接状态，收到新的HTTP请求时则需要建立新的连接进行处理。而当所有连接都处于连接状态时，Web将无法处理任何新的请求。

出现以下情况时，您的业务可能已遭受DDoS攻击：

相关文档链接：攻击态势报告
通过阿里云栖社区报告《2019年上半年DDOS攻击态势报告》，这篇文档，详细介绍了这些年来DDOS的发展过程。其中核心部分是：
相比过去，目前的主要表现是

近期最大的新闻就是美国电信网络遭遇DDoS攻击，全国网络几乎瘫痪，网络、电话、短信均已无法正常使用。这也是源于DDoS在进行攻击时，可以对源IP地址进行伪造，对攻击进行检测是非常困难的，因此这种攻击方式也成为了非常难以防范的攻击，所以政府、事业单位官网都很难避免。
闹得比较热的，是任天堂事件。，2TB的文件泄露，Resetera网站用户Atheerios密切关注了此次事件，推测黑客是通过攻击BroadOn的服务器，一家和任天堂合作的公司服务器。黑客拿到了Wii主机的所有源代码、数据表、设计框图，几乎都是公司机密文件，这一事，直接影响了任天堂游戏布局。
此前，世界上最大比特币交易所Mt.Gox，承担着超过全球3/4的比特币交易。2013年，这个交易所被盗85万个比特币，市值达4.6亿美元。紧接着不到一年这家交易所就宣布破产了。完美演绎钱来钱走，全靠黑客的一副键盘的神话。

当网络流量超过清洗阈值的时候，阿里云开始对攻击流量进行清洗，并尽可能保障业务的正常可用；清洗的过程是，将流量从原始网络路径中重定向到清洗设备上，通过清洗设备对该IP的流量成分进行正常和异常判断，丢弃异常流量，并对最终到达服务器的流量实施限流，减轻攻击对服务器造成的损害，但是流量中正常的部分可能造成损失。当网络流量超过最大的防御能力时，则会触发黑洞机制，服务器的外网访问将被暂时屏蔽。

云盾充分利用其全球清洗中心的能力，采用分布式技术将DDOS攻击流量自动牵引至距离攻击源最近的清洗中心进行清洗，同时具备多机房自动容灾的能力。

面临DDOS攻击越来越复杂的环境，云盾高防产品通过四点来御敌。

腾讯应对DDOS的解决方案是，使用高仿IP，高仿CDN——SCDN等。通过这样的高防服务器，简单说，就是以盾制攻。
腾讯安全联合实验室，从多个方面提供防护DDos的解决方案。包含IP 画像、行为分析、Cookie 挑战、等多维算法，拥有领先的DDoS识别清晰能力，可以做到99.995%+的清洗成功率，并不断快速进化算法，以应对不停变更的攻击。腾讯安全采用高防IP的方式，隐藏业务真实IP，在攻击流量和业务流量同时到达时，客户把腾讯云高防IP作为业务IP，将攻击流量引流至腾讯高防机房，清洗后回源到客户源站。且腾讯高防包可做到用户业务零变更秒级接入高防，不影响任何原有的业务。

这种高防包，具有两个显著的特点：高带宽和流量牵引。高带宽往往是企业用户重视的因素之一，因为DoS等攻击会占用大量资源，只有带宽充足时这种攻击才不会有很大的影响。而另外一个特点就是流量牵引，在租用高防服务器后，IDC运营商会对流量攻击的防御有一个硬防范围，在这个范围内高防服务器的牵引系统会对进入服务器的流量进行识别，只要攻击流量没有超过保护的范围，都不会影响用户的网站。高防服务器的防御标准要在100G以上。
另外高防包，支持多类型防护、防护对象可切换、安全防护策略、封堵自助解除、防护统计报表等。

其实这一部分有很多，这里不便写多，给大家一个链接
DOS——腾讯云
这里提到了DDOS攻击和防护的本质是攻防双方资源的对抗，一方面不断囤积大量资源具备超大流量输出，一方要不断建设能够抗住超大流量的带宽；当然对于一些顶级的，就涉及到技术对抗。
在腾讯云的宙斯盾发展过程中，提到了几个比较经典的场景。

这里应该是我们学习的重点，确切说，是我学习的重点。

当流量被运送到DDOS防护清洗中心时，通过流量清洗技术，将正常流量和恶意流量区分开，正常的流量回注客户网站。
那么问题来了，对于恶意流量如何处理的？
将恶意流量区分成基础架构攻击流量或者应用层攻击流量。通过特征和向量不断划分，最后采用相应的专属技术来处理。

对于DDOS的防护，来至阿里云安全专家的建议：企业不应该再对“限速+黑名单就能一招制敌”抱有幻想，而应该采用更为纵深、智能的防护手段：
1.丰富攻击流量识别的维度，将每个请求实时的解析出多维度的检测单元；
2.防护策略的执行需要与多维度的识别相匹配，需要有精细、灵活、丰富的访问控制单元，让各个维度有机组合，层层过滤攻击流量；
3.机器智能替代人工排查，提升响应速度，降低业务中断时间。
——IPS——
关于IPS的本身缺陷
1.单点故障问题
解决方案：采用主主、主备的模型。
2.流量瓶颈问题
解决方案：轮询的polling技术，环形的队列数据结构设计，多个虚拟CPU，各自负责各个的任务。

此篇文章，意在通过记录这次HW事件，然后事后针对突发情况，产生思考，然后查阅相关资料，对知识进行一次总结，很多内容来源于一些原文，我觉得写得不错，比我好,若有不足之处，敬请谅解。

对于第一个问题，我通过和后台工程师交流了一下，原因是：设备获取数据的方式，是在5分钟内，随机获取一个值，然后通过这个值与阈值进行对比，然后判断是否发出警告。可以这样解释，前端的图像，是对整个时间段的CPU消耗的数据呈现，假设，当前CPU消耗最高到80%，阈值设定为20%，那么我们看到的画面是80%的高峰，但是从中随机获取一个值，15%，低于阈值，所以也就不会报警。

对于第二个问题，设备的处理方式是，首先检查数据的接口信息，判断是否存在丢包；然后关闭系统的一些不必要的端口和应用，联系后台处理；最后可以bypass，不对数据进行拦截。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！