››面对DDOS这种只能缓解而不能完全防御的攻击，有篇技术贴如下
面对DDOS这种只能缓解而不能完全防御的攻击，有篇技术贴如下
扫一扫分享文章到微信
扫一扫关注官方公众号至顶头条
DDOS是一类攻击而并不是一种攻击，并且DDOS的防御是一个可以做到相对自动化但做不到绝对自动化的过程，很多演进的攻击方式自动化不一定能识别，还是需要进一步的专家肉眼判断，本文简单讲解了应对T级攻防的大规模DDOS防御架构。
作者：乌云漏洞平台
来源：ZD至顶网安全频道
0x01 DDOS分类
在讲防御之前简单介绍一下各类攻击，因为DDOS是一类攻击而并不是一种攻击，并且DDOS的防御是一个可以做到相对自动化但做不到绝对自动化的过程，很多演进的攻击方式自动化不一定能识别，还是需要进一步的专家肉眼判断。
网络层攻击
利用TCP建立连接时3次握手的&漏洞&，通过原始套接字发送源地址虚假的SYN报文，使目标主机永远无法完成3次握手，占满了系统的协议栈队列，资源得不到释放，进而拒绝服务，是互联网中最主要的DDOS攻击形式之一。网上有一些加固的方法，例如调整内核参数的方法，可以减少等待及重试，加速资源释放，在小流量syn-flood的情况下可以缓解，但流量稍大时完全不抵用。防御syn-flood的常见方法有：syn proxy、syn cookies、首包（第一次请求的syn包）丢弃等。
对于虚假的ACK包，目标设备会直接回复RST包丢弃连接，所以伤害值远不如syn-flood。DDOS的一种原始方式。
使用原始套接字伪造大量虚假源地址的UDP包，目前以DNS协议为主。
ICMP-flood
Ping洪水，比较古老的方式。
应用层攻击
ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDOS设备-&黑洞&，通过botnet的傀儡主机或寻找匿名代理服务器，向目标发起大量真实的http请求，最终消耗掉大量的并发资源，拖慢整个网站甚至彻底拒绝服务。
互联网的架构追求扩展性本质上是为了提高并发能力，各种SQL性能优化措施：消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗，而CC大有反其道而行之的意味，占满服务器并发连接数，尽可能使请求避开缓存而直接读数据库，读数据库要找最消耗资源的查询，最好无法利用索引，每个查询都全表扫描，这样就能用最小的攻击资源起到最大的拒绝服务效果。
互联网产品和服务依靠数据分析来驱动改进和持续运营，所以除了前端的APP、中间件和数据库这类OLTP系统，后面还有OLAP，从日志收集，存储到数据处理和分析的大数据平台，当CC攻击发生时，不仅OLTP的部分受到了影响，实际上CC会产生大量日志，直接会对后面的OLAP产生影响，影响包括两个层面，一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。
CC是目前应用层攻击的主要手段之一，在防御上有一些方法，但不能完美解决这个问题。
伪造源地址的海量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请求都是基于相同的原理。
有些服务器程序存在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层就是防御机制的全部，再没有其他手段了。跟厂商们的市场宣传可能有所不同，大流量攻击的防护并不是像某些厂商宣称的那样靠厂商单方面就能解决的，而是多层共同参与防御的结果。
这一层通常对最终用户不可见，如果只是中小企业，那这一层可能真的不会接触到。但如果是大型互联网公司，公有云厂商，甚至是云清洗厂商，这层是必不可少的。因为当流量超过自己能处理的极限时必须要借助电信运营商的能力。大型互联网公司虽然自身储备的带宽比较大，但还没到达轻松抵抗大流量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递归生效。
目前国内厂商华为的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在客户端和服务端中间鉴别流入的数据包是否包含指纹。
这是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类服务，攻击发生时终端用户可以有一定的延迟容忍，在防御机制上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的大数据资源（如果你能得到的话）物理定位攻击者
陪叔叔们上门抓捕
上法庭诉讼
如果这个人没有特殊身份，也许你就能如愿，但假如遇到一些特殊人物，你几个月都白忙乎。而黑吃黑的能力则依赖于安全团队本身的渗透能力比较强，且有闲情逸致做这事。这个过程对很多企业来说成本还是有点高，光有实力的安全团队这条门槛就足以砍掉绝大多数公司。笔者过去也只是恰好有缘遇到了这么一个团队。
(没有帐户？)
使用第三方帐号登录:
如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅ZDNet技术邮件将是您的最佳途径之一。
北京第二十六维信息技术有限公司（ZD至顶网）版权所有. 京ICP证010391号 京ICP备号-159 京公网安备：【图文】网络攻击与防御_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
网络攻击与防御
上传于||暂无简介
大小：1.32MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢入侵防御系统_百度百科
入侵防御系统
本词条缺少名片图，补充相关内容使词条更完整，还能快速升级，赶紧来吧！
入侵防御系统（IPS）,位于防火墙和网络的设备之间，依靠对数据包的检测进行防御（检查入网的数据包，确定数据包的真正用途，然后决定是否允许其进入内网）
入侵防御系统系统介绍
全球最佳的新一代IPS (): HP TippingPoint　　
TippingPoint的主动式入侵防御系统能够阻止、病毒、木马、、间谍软件、VOIP攻击以及点到点应用滥用。通过深达第七层的流量侦测，TippingPoint的入侵防御系统在发生损失之前阻断恶意流量。利用TippingPoint提供的服务，入侵防御系统能得到及时的特征、漏洞过滤器、协议异常过滤器和统计异常过滤器更新从而主动地防御最新的攻击。此外，TippingPoint的入侵防御系统是目前能够提供微秒级时延、高达5G的吞吐能力和带宽管理能力的最强大的入侵防御系统。
通过全面的数据包侦测，TippingPoint的入侵防御系统提供吉比特速率上的应用、网络架构和性能保护功能。应用保护能力针对来自内部和外部的攻击提供快速、精准、可靠的防护。由于具有网络架构保护能力，TippingPoint的入侵防御系统保护VOIP系统、路由器、交换机、DNS和其他网络基础免遭恶意攻击和防止流量异动。TippingPoint的入侵防御系统的性能保护能力帮助客户来遏制非关键业务抢夺宝贵的带宽和IT资源，从而确保网路资源的合理配置并保证关键业务的性能。
　　　　TippingPoint 应用情境：
　　1、网络忽快忽慢，不知原因　　2、经常AD lock，无法登入网域　　3、防火墙常被塞爆　　4、上微软(补丁)却没时间重开机　　5、希望虚拟化环境中，提供IPS保护　　6、希望管理上网行为
入侵防御系统特点及规格
　　TippingPoint 基于 ASIC 防御引擎
UnityOne 无可比拟的性能、稳定性和准确率都是透过 TippingPoint 的工程师和科学家所开发的专利技术发展出来的。这些优势展现于 TippingPoint 的 TSE 威胁防御引擎（ Threat Suppression Engine ）上。 UnityOne 是由最新型的网络处理器技术组成的一个高度专业化的硬件式入侵检测防御平台。 TippingPoint 拥有整套自行开发的 FPGA (Layer 7) 及 Layer 4 (ASIC) 模块。 TSE(威胁防御引擎 ) 是一个能实现所有防御所需要的全部功能的硬件线速引擎，主要功能包括 IP 碎片重组、 TCP 流重组、攻击行为统计分析、带宽管理、恶意封包阻挡、流量状态追踪和超过 170 种的应用层分析。
TSE 重组与检测数据包的内容并分析至网络的应用层。当每一个新的数据包随着数据流到达 TSE 时，就会重新检测这个数据流是否含有有害的内容，如果实时检测出这个数据包含有害内容，那么这个数据包以及随后而来属于这个数据流的数据包将会被阻挡。这样可以正确地保证攻击不会到达攻击目的地。
这种领先的 IPS 技术只有结合高速的及定制化的 ASIC 芯片才有可能实现。这种高度专业的技术可以使IPS 在具有千兆处理速度的同时处理延迟不到一微秒 (Latency under Microsecond) ，且具有高度的检测和阻挡准确性。不像软件式的或其它竞争对手宣称拥有千兆处理速度的入侵防御系统，其处理性能会受到 Filter 安装多寡而受到严重的影响，同时处理延时却高达数秒甚至数十秒之多。 UnityOne 具有高度扩充能力的硬件防护引擎可以允许上万笔的 Filter 同时运行而不影响其性能与准确性。
UnityOne 运用 TSE 突破性的扩充性与高性能，实时侦测通讯协议异常与流量统计异常，防护 DDoS 攻击以及阻挡或限制未经授权的应用程序的带宽。
　　TippingPoint 三大入侵防御功能
UnityOne 提供业界最完整的入侵侦测防御功能，远远超出传统 IPS 的能力。 TippingPoint 定义的三大入侵侦测防御功能包括：应用程序防护、网络架构防护与性能保护。这三大功能可提供最强大且最完整的保护以防御各种形式的网络攻击行为，如：病毒、、与非法的入侵和访问。
应用程序防护 -UnityOne 提供扩展至用户端、服务器、及第二至第七层的网络型攻击防护，如：病毒、蠕虫与。利用深层检测应用层数据包的技术， UnityOne 可以分辨出合法与有害的封包内容。最新型的攻击可以透过伪装成合法应用的技术，轻易的穿透防火墙。而 UnityOne 运用重组 TCP 流量以检视应用层数据包内容的方式，以辨识合法与恶意的数据流。大部分的入侵防御系统都是针对已知的攻击进行防御，然而 UnityOne 运用漏洞基础的过滤机制，可以防范所有已知与未知形式的攻击。
网络架构防护 - 路由器、交换器、 DNS 服务器以及防火墙都是有可能被攻击的网络设备，如果这些网络设备被攻击导致停机，那么所有企业中的关键应用程序也会随之停摆。而 UnityOne 的网络架构防护机制提供了一系列的过滤器以保护网络设备免于遭受攻击。此外， UnityOne 也提供异常流量统计机制的过滤器，对于超过 ” 基准线 ” 的正常，可以针对其通讯协议或应用程序特性来进行警示、限制流量或阻绝流量等行动。如此一来可以预防 DDoS 及其它溢出式所造成的网络断线或阻塞。
性能保护 - 是用来保护及主机性能，免于被非法的应用程序占用正常的网络性能。如果网络链路壅塞，那么重要的应用程序数据将无法在网络上传输。非商用的应用程序，如 (P2P) 应用 或实时通讯软件 (IM) 将会快速的耗尽网络的带宽，因此 UnityOne 提供带宽保护 (Traffic / Rate Shaping) 的功能，协助企业仔细的辨识出非法使用的应用程序流量并降低或限制其带宽的使用量。
　　TippingPoint 三大入侵侦测防御机制
TippingPoint 的 UnityOne IPS 产品线可同时运作三个独立但互补的入侵侦测防御机制：弱点过滤器，攻击特征过滤器和流量异常过滤器。 TippingPoint 可以同时运作这三个机制的能力就是来自于这组特别开发的 ASIC 。
弱点过滤器 主要是保护操作系统与应用程序。这种过滤器行为就像是一种网络型的补丁程序，保护主机免于遭受利用未修补的漏洞来进行的网络型攻击。新的漏洞一旦发现开始被骇客攻击利用，弱点过滤器就会被实时启动，进行漏洞保护。这个过滤机制的运作模式是重组第七层的信息，从而可以完整地检测应用层的流量。过滤规则可以指定特别的条件，如检测应用程序的运作流程（如：的应用程序异常）或通讯协议的规范（如： RFC 异常）。
流量异常过滤器 是用来侦测在流量模式方面的变化。 这些过滤机制可以调整与学习 UnityOne 所在的特别环境中“正常流量 ” 的模式。一旦正常流量被设定为基准，这些过滤机制将依据可调整的门限阀值来侦测统计异常的。流量异常过滤机制可以有效的阻挡分布式的阻断服务的攻击 () 、未知的、异常的应用程序流量与其它零时差闪电攻击。此外 UnityOne 一个重要的特殊功能是可以依据应用程序的种类、通讯协议与 IP 进行最合适网络流量分配。
攻击特征过滤器 主要是针对不需要利用安全漏洞的攻击方式，如病毒或木马。这个过滤方式必须全盘了解已知攻击的特征，且可以侦测并制作出防御的特征数据库。目前 TippingPoint 拥有一个专业团队 7X24 全年无休地分析来自于全球的各种攻击威胁，并与 SANS 、 CERT 、 SECURITEAM 等知名的信息安全团队合作，在第一时间透过在线更新，让全球每个角落的 UnityOne 配备最新的攻击特征数据库。
TippingPoing 在线更新机制
苏州众里数码会和HP在企业信息安全这块一起努力。在每周提供 SANS 漏洞分析的同时， TippingPoint 的安全团队也同步制作出针对漏洞的过滤器数据库并混入到数字疫苗（ Digital Vaccines ）中，数字疫苗不只针对特定的攻击制作过滤器，还包括对变种攻击与零时差闪电攻击进行阻挡。为了拥有最大的安全涵盖范围，数字疫苗除了每周定时在线更新过滤器数据库外，并随时对有严重威胁的漏洞或攻击生成新的过滤器，数字疫苗也会自动地部署新的过滤器至全球的 UnityOne IPS 上。
为了防御最新的弱点与攻击，最新的过滤器会持续的更新至 IPS 上。每一条过滤都可以被视为网络上的补丁程序，以保护内部的主机免于被攻击。任何企图运用于特定漏洞的有害流量将会被实时侦测与阻挡。换句话说，这个方式就是运用一个虚拟的修丁程序来保护上千个未修补漏洞的系统。
TippingPoint 的安全专家是被世界公认的，全球超过二十五万个安全管理者及专家都订阅了 TippingPoint 所编辑的SAN @RISK 分析报告。相同的分析也运用到数字疫苗的开发上，优先制作出保护 TippingPoint 客户的最佳过滤器。
TippingPoint 拥有最完整的可靠性机制
UnityOne 的设计理念是，无论是网络发生什么故障、设备内部与系统发生什么错误、甚至设备完全失去电源，保证网络永不断线、并保证维持线速的运作。 UnityOne 运用系统内部备份机制与网络状态备份机制，并相互补充的模式来确保最大的网络可用性。
UnityOne 有多种内建的备份机制：一、所有的设备都具有两个相互备份，可的电源适配器。二、（watchdog timers ）会持续的监控安全与管理引擎，一旦系统错误被侦测到， UnityOne 可以自动或手动的切换成 Layer 2的设备，确保网络不断线。此外， TippingPoint 还提供了一个外接式电源适配器（ Zero Power High Availability ），当整个机房或数据中心失去电源时，所有的流量会自动切换 (Power Bypass) 由这个设备运作。
企业信用信息}