qq3250845

目前全球大部分的企业都在使用云端技术，但是网络的暗处落里隐藏着不可预知的猥亵，本文将浅谈一下云采用者为何需要网络可视性的原因。

当前，每个企业都有充足的理由将目光投向云端。云平台可以支持复杂的新型业务模式，进而带动更高的采用率与使用率，因此云支出比以往呈现更快增长。事实上，Gartner指出，全球公有云服务市场收入预计将从2016年的2196亿美元增至2017年的2602亿美元，增速高达18.5%。这种快速增长的云普及率促使人们对云端数据、应用、工作负载安全性的保障更为关注。

各种云环境的安全性与数据可视性的隐患，与随之而来的担忧随着云技术日益普及不断攀升。但将现有数据与应用迁移至云端只是第一步，IT专家面临的真正挑战在于如何实现全面而完整的云部署可视性。

网络暗处的威胁 云采用者需要网络可视性的重要性

可视性是基础架构管理与安全的基本构件。然而当IT管理者们因对数据持续监控而感到如坐针毡之时，那些可以放心在看不见、摸不着的网络环境中行事的日子想必一定已经成为过去时了。

无惧Reaper
以往经验表明，分布式拒绝服务（DDoS）攻击可以破坏互联网，或者至少击溃目标服务器，正如同去年全球最大型的互联网服务提供商之一 Dyn所遭遇的攻击一样。现在，各企业都在担心诸如Mirai或者最近发现的Reaper之类的僵尸网络。研究人员认为，这些僵尸网络通过瞄准路由器、安全摄像头与数字录像机方面的安全漏洞，已经感染了100多万家企业机构。

编程代码借鉴自Mirai僵尸网络的Reaper让人们对于新一轮DDoS攻击或其他尾随而至的攻击忧心忡忡。近期相关调查显示，除了IT专家担心新型恶意软件攻击其网络之外，绝大部分专家（93%）更担心公有云内的数据与应用安全性。

该调查结果表明，人们的关注点主要集中于数据隐私、合规性、安全攻击、无法控制的数据位置，当然也包括实现全面数据可视性。这些担忧使得对于云端网络可视性的需求，即“能够看到数据位于何处，如何确保它们始终得到保护”不再仅仅是纸上谈兵。各种规模的企业机构必须通过增加预防措施以消除云企业的“心头大患”。可视性不再是“与控制相关”——可视性就是控制。

问题根源——不要成为下一个安全头条
各企业对于安全的担忧不无道理，其根源就在于害怕成为下一个安全漏洞头条。任何一位CEO或是CIO都不希望看到自己公司的名字出现在反复重播的重大网络中断或网络攻击新闻之中，只要试想一下WannaCry勒索软件和NotPetya勒索病毒自然就不难理解。

今天，大多数企业都目睹了因缺少公有云流量可视性而带来的业务影响。对于网络洞察，以及快速辨别数据的能力缺失可能会让用户因惧怕漏洞导致的信任丧失，而不再使用其云端。随着企业着手实施“云优先”战略，持续监测成为阻止这些负面影响并维护企业信誉的必要条件。

不幸的是，云部署也会让IT管理员对其网络内部情况难以了解。云就像是一个不透明的黑盒子，因此在寻找漏洞时，他们无法获得所有信息，也无法快速应对威胁。为了支持安全策略，专家们需要能够查看数据包数据、识别威胁以及采取可执行的自动化可视性与分析工具，以此发现网络漏洞。

网络的暗处落里隐藏着什么？
持续监测网络与云端对于阻止这些负面影响至关重要。当您获得了全面的数据与应用可视性时，您就无需害怕Reaper或者黑暗。当您把黑暗点亮，因不断演变的云环境所带来的威胁就会得到有效扼制。

对于任何IT团队而言，制定、实施与维持复杂的云安全战略都不是一项轻松的任务。但显而易见的是，各企业机构必须控制其数据，以便高度关注安全性及合规性。而全面可视性则是您对客户负责的最佳方式。

qq3250845

DDoS攻击在如今已经层出不穷，一旦遭受DdoS攻击，就意味着整个企业的网络服务暂停了，特别是DNS服务主机，那么在DDoS攻击下保护DNS这问题十分严重。

如果你的服务器主机中运行了DNS服务，那么一定要小心DdoS这个很现实的攻击行为。而如果你的DNS服务遭受到了DdoS攻击，那么可以想象，最低的损失也是丢失电子邮件和暂停Web服务。而如果你的DNS服务主机位于企业内部，并且与企业用户的网络浏览等服务共用网络连接，那么一旦遭受DdoS攻击，就意味着整个企业的网络服务暂停了。就算你的DNS服务只是用于测试或其它有限的目的，一旦被攻击，所波及的范围也会很广。

其它会威胁到DNS的情况还包括对外网开启FTP服务，这个服务本来不应该从企业内部对外开放的。因为管理员都明白，一旦你这样做了，黑客和各种机器人程序会通过各种手段，包括暴力破解方式，来取得FTP的账户和密码。就算你采用了很复杂的密码，当多个暴力破解程序运行时，由此产生的失败的FTP访问流量就足以耗光网络资源。

总之，企业自己搭建和管理DNS总会存在一定程度的安全风险。换句话说，目前公认的较好的解决方案就是DNS服务托管。对于那些还没有为自己管理DNS服务做好**准备的企业来说，唯一的建议就是找个信任ISP或其它专业的托管机构，将这个事儿交给他们去做。

如何保护DDoS攻击下DNS不受影响

DDoS攻击亲身体验
当时的受害者是位于北美的一个小办公室，拥有一个DSL路由器和一个静态IP地址。办公室的服务器对外开启了DNS。被攻击的早期征兆有两点，一是接收到的电子邮件数量比平时有所下降，二是Web浏览速度下降。在经过几天的不良症状后，该办公室再也收不到来自外界的电子邮件了，同时也无法进行网络浏览了。使用最简单的ping命令到互联网大型网站地址，得到的结果要么是失败，要么就是超过1000ms的响应时间，这也基本算是无法连接了。

很明显此时有某个网络进程充斥在DSL连接中。办公室中的每台电脑都关机重启了，并没有解决问题。重启DSL也没有解决问题。但是在重启DNS服务器后，会有短暂的时间恢复到正常的互联网连接状态，几分钟后，这种正常的连接速度再次变得不正常，并很快无法连接任何网站。考虑到可能是电子邮件系统或基于Web的进程出现故障，便先后将服务器中的Exchange服务和Web服务关停，但是没有效果。在接下来的逐项尝试中，我们发现关闭DNS服务会产生明显的效果，于是我们最终将问题锁定在DNS服务上。

但是DNS服务的日志中并没有任何警告事件，而且服务器本身也安装了最新的补丁，包括DNS服务补丁和DoS溢出补丁。另一个找寻线索的位置就是防火墙的日志文件。虽然这个办公室的防火墙没有历史日志文件，但是我们可以查看选定网络协议的实时日志。从实时的防火墙日志可以观察到，有两个互联网上的IP地址在不断向办公室的服务器发送DNS请求数据。这两个IP地址所代表的服务器都位于欧洲，分别属于两个不同的国家，但是它们都在向这个相同的DNS服务地址发送大量的数据。如果有两个或两个以上的远程地址在进行DoS攻击，就可以将其归类为DDoS攻击，即分布式DoS攻击。。

在DDoS攻击下保护DNS
一旦你知道了攻击方的IP地址，就可以简单在防火墙中设置一个IP规则，阻止来自该IP地址的任何数据通过防火墙。在我们阻止了一个IP地址后，ping主流网站的结果已经达到300ms了。当我们将第二个IP地址阻挡后，ping主流网站的结果已经恢复到正常水平，大概30ms，并且所有网络功能恢复了正常。这个办公室很幸运，所遭受的DDoS攻击只有两个攻击源，两个固定IP地址。如果攻击源有几十甚至上百个（或者攻击源IP地址是变化的），该办公室的处境就艰难的多了，同时对日常业务的冲击也会更大。

正如我前面提到的，防止DNS服务器遭遇DDoS攻击的最佳方案是将DNS服务交给DNS服务供应商去实现，比如你的ISP或知名的DNS注册机构，或者可靠的托管机构。虽然这种做法无法从根本上杜绝黑客对于供应商展开DoS攻击的威胁，但是起码能够防止在发生DoS攻击时，你企业的各种网络功能会不受影响。

如果出于某种原因，你必须要在企业内部建立DNS服务，那么一定要制定一个针对DNSDoS攻击的应对策略。比如在不同地点建立多个DNS服务器，使用强化或专用的DNS服务器或应用程序并采用独立的互联网连接线路。Verisign在2011年5月发布了一份DNS可用性状态报告，确认就算是最顶级的电子商务网站，其DNS的可用性也面临潜在风险，尤其是那些自己建立和管理DNS服务的企业。

qq3250845

物联网零散的安全记录长期以来一直是安全界的讨论话题，但2016年10月的Mirai恶意软件攻击事件引起了世界各国的关注。

这是对物联网第一次成功的大规模安全攻击，利用恶意软件将易受攻击的物联网设备变成僵尸网络大军，通过多种大规模DDoS攻击摧毁Netflix、Twitter和Reddit等知名网站。

Mirai并不是一个复杂的恶意软件，它只是在物联网设备上扫描网络上的Telnet开放端口，然后尝试总共61个默认密码，试图获得尽可能多的设备控制权。

这是一个令人担忧的成功策略，有近40万台设备在巅峰时刻连接在一起，足以造成大规模破坏。更重要的是，它提出了一个严重问题，即便是粗糙恶意软件也可以轻松通过薄弱的物联网安全实践。

如何确保物联网安全？应彻底检查以下三个方面

过去的错误
MiRAI恶意软件攻击听起来像是糟糕的情况，但不幸的是，有相当多的物联网设备( Gartner预测，2017年有84亿台连网设备，到2020年将增至204亿台 ) 极易受到这种攻击。

近年来，许多制造商和供应商急于利用物联网市场的快速增长机会，并没有采取强有力的安全措施，以便尽快将产品推向市场。

因此，如今许多设备都有默认密码和凭据，使用不安全的配置，并且众所周知的难以升级。总之，他们很容易被攻击。

新低级协议黑客(如KRACK )的出现，也让潜在攻击者更容易绕过和破坏物联网基础设施，并注入恶意代码，或操纵易受攻击设备中的数据。

这样做可能会产生严重影响。例如，如果设备需要与云应用程序同步，恶意代码或操纵的数据可能被用来感染云或发回不正确的设置或操作，从而带来潜在的破坏性后果。

幸运的是，物联网制造商和供应商正慢慢意识到设备和基础设施保护不足所带来的安全风险。

但是，由于已经有那么多保护不良的设备(并且还在生产中)存在，在进行任何实施之前，从各种不同角度对安全进行全面评估仍然是绝对必要的。

物联网安全的三个关键领域
至少应彻底检查以下三个方面:

软件：在安装任何新设备之前，务必确保制造商从一开始就遵守严格的软件安全措施，而不是事后才采取的措施。其核心是能够远程修补设备，为抵御网络威胁和软件进步提供急需的未来防护。

硬件：物理安全是评估新物联网设备的另一个关键领域。包括物理开关这样简单的东西，允许用户在需要时关闭某些功能(例如，具有麦克风功能的设备静音按钮)。在组件中集成防篡改措施也大大减少了未经许可访问它们的机会。

网络：对于物联网设备与后端管理或存储解决方案之间的任何数据交换，应始终使用HTTPS等安全协议。强身份验证方法也很重要，应提示用户在首次使用时立即将任何默认凭据更改为强大的字母数字替代方法。

与许多新技术一样，制造商和供应商在过去几年物联网热潮中很容易忘记了安全的重要性。 然而，现在蜜月期已经结束，而像Mirai这样危险新型恶意软件构成的威胁变得更加普遍，每个人都需要开始认真对待。

上述基本安全原则将有助于抵御外部威胁。幸运的是，业界已经开始意识到这一点，但在更好的安全措施变得更加普遍之前，对新的物联网实施采取谨慎态度仍然是必不可少的。

qq3250845

.............

qq3250845

UDP_Flood攻击原理
UDP Flood是日渐猖厥的流量型DoS攻击，原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。

100k pps的UDP Flood经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。由于UDP协议是一种无连接的服务，在UDP FLOOD攻击中，攻击者可发送大量伪造源IP地址的小UDP包。但是，由于UDP协议是无连接性的，所以只要开了一个UDP的端口提供相关服务的话，那么就可针对相关的服务进行攻击。

正常应用情况下，UDP包双向流量会基本相等，而且大小和内容都是随机的，变化很大。出现UDP Flood的情况下，针对同一目标IP的UDP包在一侧大量出现，并且内容和大小都比较固定。

UDP_Flood攻击防御
UDP协议与TCP 协议不同，是无连接状态的协议，并且UDP应用协议五花八门，差异极大，因此针对UDP Flood的防护非常困难。其防护要根据具体情况对待：

判断包大小，如果是大包攻击则使用防止UDP碎片方法：根据攻击包大小设定包碎片重组大小，通常不小于1500。在极端情况下，可以考虑丢弃所有UDP碎片。
攻击端口为业务端口：根据该业务UDP最大包长设置UDP最大包大小以过滤异常流量。
攻击端口为非业务端口：一个是丢弃所有UDP包，可能会误伤正常业务；一个是建立UDP连接规则，要求所有去往该端口的UDP包，必须首先与TCP端口建立TCP连接。不过这种方法需要很专业的防火墙或其他防护设备支持。
   

因为大多数IP并不提供UDP服务，直接丢弃UDP流量即可。所以现在纯粹的UDP流量攻击比较少见了，取而代之的是UDP协议承载的DNS Query Flood攻击。简单地说，越上层协议上发动的DDoS攻击越难以防御，因为协议越上层，与业务关联越大，防御系统面临的情况越复杂。

DNS Query Flood攻击原理
UDP DNS Query Flood攻击实质上是UDP Flood的一种，但是由于DNS服务器的不可替代的关键作用，一旦服务器瘫痪，影响一般都很大。

UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。

DNS Query Flood就是攻击者操纵大量傀儡机器，对目标发起海量的域名查询请求。为了防止基于ACL的过滤，必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP地址、随机伪造源端口等参数。在DNS协议层，随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外，还可以降低命中DNS缓存的可能性，尽可能多地消耗DNS服务器的CPU资源。

根据微软的统计数据，一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而我们知道，在一台P3的PC机上可以轻易地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的DNS服务器瘫痪，由此可见DNS 服务器的脆弱性。同时需要注意的是，蠕虫扩散也会带来大量的域名解析请求。

qq3250845

..................

qq3250845

..........................

qq3250845

.................

qq3250845

1.DoS攻击
DoS攻击(Denial of Service,拒绝服务攻击)通过消耗计算机的某种资源,例如计算资源、网络连接等,造成资源耗尽,导致服务端无法为合法用户提供服务或只能提供降级服务。在SDN网络的集中式架构中,控制器是天然的网络中心,负责整个网络的管理和控制工作,很容易成为DoS攻击的目标。

1.1 SDN 网络下的 DoS 攻击
在OpenFlow网络架构中,控制器是网络的核心,承担了整个网络的控制管理工作;控制器需要对整个网络进行不同粒度的管理,网络本身的数据传输需求会对控制层面造成不小的压力;尤其当存在恶意攻击时,控制层面甚至可能无法对合法用户的请求做出响应,形成DoS攻击。虽然目前已有流表合并技术等研究方向能够缓解转发规则过细带来的压力,但是恶意攻击者只需修改数据包头部,增
加流表合并难度,仍会对整个网络造成严重影响。

1.2 饱和攻击
在众多DoS攻击中,有一种攻击为SDN网络所特有;Seungwon Shin将其命名为数据层到控制层的饱和攻击,简称为饱和攻击。该攻击的理论依据及造成的危害具体如下。
当新的流请求到达OpenFlow交换机后,交换机会将该数据流的第一个报文信息与交换机内部的转发规则进行匹配。当所有的流表都不存在与该数据流相匹配的转发规则且交换机设置为reactive模式时,数据包会被交换机封装到Packet-In消息中,并上发给控制器;由控制器进行路由计算并通过Packet_Out消息向交换机下发新的转发规则。当攻击者同时通过不同的交换机,持续地向网络中发送大量交换机无法匹配的数据流,会造成控制器与交换机同时忙于处理攻击者发送的非法数据流,造成无法满足正常用户的合法请求,从而导致DoS攻击。Seungwon Shin提出,在这种机制下,会产生两种攻击效果;首先是由于同时请求的报文过多,大量消耗控制器资源,导致正常数据流的请求无法得到服务或者服务受到影响;其次,由于攻击者伪造了大量的数据流,控制器会向转发层面的交换机发送大量无用的转发规则,导致交换机无法存储正常数据流的流表信息。除此之外,大量报文会占用连接控制器的链路,进一步令正常服务请求难以得到响应。此攻击利用了SDN网络的集中式架构,实施难度小,攻击者只要产生大量无法匹配流表的报文,就能达到同时消耗控制层面资源与数据层面资源的目的。上述方案常见的具体实施方法有两种,一是利用ARP协议,由于OpenFlow交换机只具有简单的转发功能,交换机在收到ARP请求后,会向控制器转发询问,攻击者可以向交换机发送大量伪造的ARP请求实现对控制器的攻击。另一种是利用ICMP报文,当攻击者不断修改自身IP地址,并向网络发送大量ICMP报文,会形成大量新的数据流,导致交换机不断向控制器发送报文,形成DoS攻击。以上两种方式属于利用OpenFlow协议的特点对SDN网络实施攻击的范例。

1.3常见DoS攻击检测方案
主要包括异常流量检测与数据分析检测。

异常流量检测是最常见的一类攻击检测方式。针对DoS攻击的异常流量检测方案可以分为两类:基于特征信息的检测和基于异常行为的检测。

基于特征信息的检测:通过检测数据流量的特征,将其特征与预先定义的攻击类型的特征进行比对,当数据流量的特征与预先定义的攻击特征相匹配,则判断网络中发生了该攻击。

基于异常行为的检测:预先设置网络中正常参数的阈值范围,通过分析网络中相关参数的数值并将其与阈值进行比较,当网络中参数不在正常范围内时,则判定网络出现攻击。

除了异常流量检测法外,目前常见的DoS攻击检测方案还有数据分析检测,通过对流量数据所含有的信息,包含空间信息、时间信息和技术指标信息构成三个维度来对数据流进行分析。针对不同种类的DoS攻击,下表列出了一些常见DoS攻击方式及其数据分析的检测指标。


2.DDOS攻击方式
2.1 SYN Flood攻击
SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。

2.1.1 原理
例如，攻击者首先伪造地址对服务器发起SYN请求（我可以建立连接吗？），服务器就会回应一个ACK+SYN（可以+请确认）。而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，会重试3-5次并且等待一个SYN Time（一般30秒-2分钟）后，丢弃这个连接。
如果攻击者大量发送这种伪造源地址的 SYN请求，服务器端将会消耗非常多的资源来处理这种半连接，保存遍历会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行 SYN+ACK的重试。最后的结果是服务器无暇理睬正常的连接请求—拒绝服务。在服务器上用netstat –an命令查看SYN_RECV状态的话，就可以看到：

可以看到大量的SYN包没有ACK回应。

2.1.2 SYN Flood防护
目 前市面上有些防火墙具有SYN Proxy功能，这种方法一般是定每秒通过指定对象（目标地址和端口、仅目标地址或仅源地址）的SYN片段数的阀值，当来自相同源地址或发往相同目标地址的SYN片段数达到这些阀值之一时，防火墙就开始截取连接请求和代理回复SYN/ACK片段，并将不完全的连接请求存储到连接队列中直到连接完成或请求超时。当防火墙中代理连接的队列被填满时，防火墙拒绝来自相同安全区域（zone）中所有地址的新SYN片段，避免网络主机遭受不完整的三次握手的攻击。但是，这种方法在攻击流量较大的时候，连接出现较大的延迟，网络的负载较高，很多情况下反而成为整个网络的瓶颈；?
Random Drop：随机丢包的方式虽然可以减轻服务器的负载，但是正常连接的成功率也会降低很多；
特征匹配：IPS上会常用的手段，在攻击发生的当时统计攻击报文的特征，定义特征库，例如过滤不带TCP Options 的syn 包等；
早 期攻击工具（例如synkiller，xdos，hgod等）通常是发送64字节的TCP SYN报文，而主机操作系统在发起TCP连接请求时发送SYN 报文是大于64字节的。因此可以在关键节点上设置策略过滤64字节的TCP SYN报文，某些宣传具有防护SYN Flood攻击的产品就是这么做的。随着工具的改进，发出的TCP SYN 报文完全模拟常见的通用操作系统，并且IP头和TCP头的字段完全随机，这时就无法在设备上根据特定的规则来过滤攻击报文。这时就需要根据经验判断IP 包头里TTL值不合理的数据包并阻断，但这种手工的方法成本高、效率低。 图是某攻击工具属性设置。


SYN Cookie：就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个 IP地址来的包会被丢弃。但SYN Cookie依赖于对方使用真实的IP地址，如果攻击者利用SOCK_RAW随机改写IP报文中的源地址，这个方法就没效果了。

2.1.3 商业产品的防护算法
syn cookie/syn proxy类防护算法：这种算法对所有的syn包均主动回应，探测发起syn包的源IP地址是否真实存在；如果该IP地址真实存在，则该IP会回应防护设备的探测包，从而建立TCP连接；大多数的国内外抗拒绝服务产品采用此类算法。
safereset算法：此算法对所有的syn包均主动回应，探测包特意构造错误的字段，真实存在的IP地址会发送rst包给防护设备，然后发起第2次连接，从而建立TCP连接；部分国外产品采用了这样的防护算法。?
syn重传算法：该算法利用了TCP/IP协议的重传特性，来自某个源IP的第一个syn包到达时被直接丢弃并记录状态，在该源IP的第2个syn包到达时进行验证，然后放行。
综合防护算法：结合了以上算法的优点，并引入了IP信誉机制。当来自某个源IP的第一个syn包到达时，如果该IP的信誉值较高，则采用syncookie 算法；而对于信誉值较低的源IP，则基于协议栈行为模式，如果syn包得到验证，则对该连接进入syncookie校验，一旦该IP的连接得到验证则提高其信誉值。有些设备还采用了表结构来存放协议栈行为模式特征值，大大减少了存储量。

2.2 ACK Flood攻击
2.2.1 原理
ACK Flood攻击是在TCP连接建立之后，所有的数据传输TCP报文都是带有ACK标志位的，主机在接收到一个带有ACK标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在。
这里，服务器要做两个动作：查表、回应 ACK/RST。这种攻击方式显然没有SYN Flood给服务器带来的冲击大，因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解，随机源IP的ACK小包应该会被Server很快丢弃，因为在服务器的TCP堆栈中没有这些ACK包的状态信息。但是实际上通过测试，发现有一些TCP服务会对ACK Flood比较敏感，比如说JSP Server，在数量并不多的ACK小包的打击下，JSP Server就很难处理正常的连接请求。对于Apache或者IIS来说，10kpps的ACK Flood不构成危胁，但是更高数量的ACK Flood会造成服务器网卡中断频率过高，负载过重而停止响应。可以肯定的是，ACK Flood不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响。抓包：


如果没有开放端口，服务器将直接丢弃，这将会耗费服务器的CPU资源。如果端口开放，服务器回应RST。

2.2.2 ACK Flood防护
利用对称性判断来分析出是否有攻击存在。所谓对称型判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据，但是目前已知情况来看，很少有单纯使用ACK Flood攻击，都会和其他攻击方法混合使用，因此，很容易产生误判。?
一 些防火墙应对的方法是：建立一个hash表，用来存放TCP连接“状态”，相对于主机的TCP stack实现来说，状态检查的过程相对简化。例如，不作sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过，从而“大致”确定该“连接”是否是“活动的 ”。

2.3 UDP Flood攻击
2.3.1 原理
UDP Flood是日渐猖厥的流量型DoS攻击，原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。 100k pps的UDP Flood经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。由于UDP协议是一种无连接的服务，在UDP FLOOD攻击中，攻击者可发送大量伪造源IP地址的小UDP包。但是，由于UDP协议是无连接性的，所以只要开了一个UDP的端口提供相关服务的话，那么就可针对相关的服务进行攻击。
正常应用情况下，UDP包双向流量会基本相等，而且大小和内容都是随机的，变化很大。出现UDP Flood的情况下，针对同一目标IP的UDP包在一侧大量出现，并且内容和大小都比较固定。


UDP Flood大包攻击（占带宽，分片）：

2.3.2 UDP Flood防护
UDP协议与TCP 协议不同，是无连接状态的协议，并且UDP应用协议五花八门，差异极大，因此针对UDP Flood的防护非常困难。其防护要根据具体情况对待：
判断包大小，如果是大包攻击则使用防止UDP碎片方法：根据攻击包大小设定包碎片重组大小，通常不小于1500。在极端情况下，可以考虑丢弃所有UDP碎片。
攻击端口为业务端口：根据该业务UDP最大包长设置UDP最大包大小以过滤异常流量。
攻击端口为非业务端口：一个是丢弃所有UDP包，可能会误伤正常业务；一个是建立UDP连接规则，要求所有去往该端口的UDP包，必须首先与TCP端口建立TCP连接。不过这种方法需要很专业的防火墙或其他防护设备支持。

2.4 ICMP Flood攻击
2.4.1 原理
ICMP Flood 的攻击原理和ACK Flood原理类似，属于流量型的攻击方式，也是利用大的流量给服务器带来较大的负载，影响服务器的正常服务。由于目前很多防火墙直接过滤ICMP报文，因此ICMP Flood出现的频度较低。比较下面两幅图，就应该可以看出是否有ICMP Flood攻击。


2.4.2 ICMP Flood防护
其防御也很简单，直接过滤ICMP报文。这里就不做详细说明。

2.5 Connection Flood攻击
2.5.1 原理
Connection Flood是典型的并且非常的有效的利用小流量冲击大带宽网络服务的攻击方式，这种攻击方式目前已经越来越猖獗。这种攻击的原理是利用真实的IP地址向服务器发起大量的连接，并且建立连接之后很长时间不释放，占用服务器的资源，造成服务器服务器上残余连接(WAIT状态)过多，效率降低，甚至资源耗尽，无法响应其他客户所发起的连接。
其中一种攻击方法是每秒钟向服务器发起大量的连接请求，这类似于固定源IP的SYN Flood攻击，不同的是采用了真实的源IP地址。通常这可以在防火墙上限制每个源IP地址每秒钟的连接数来达到防护目的。但现在已有工具采用慢速连接的方式，也即几秒钟才和服务器建立一个连接，连接建立成功之后并不释放并定时发送垃圾数据包给服务器使连接得以长时间保持。这样一个IP地址就可以和服务器建立成百上千的连接，而服务器可以承受的连接数是有限的，这就达到了拒绝服务的效果。
另外，蠕虫大规模爆发的时候，由于蠕虫代码则比较简单，传播过程中会出现大量源IP地址相同的包，对于 TCP 蠕虫则表现为大范围扫描行为。这是在判断Connection Flood时需要注意的。
在受攻击的服务器上使用netstat –an来看：

存在大量连接状态，来自少数的几个源。如果统计的话，可以看到连接数对比平时出现异常。并且增长到某一值之后开始波动，说明此时可能已经接近性能极限。因此，对这种攻击的判断：在流量上体现并不大，甚至可能会很小；大量的ESTABLISH状态；新建的ESTABLISH状态总数有波动。

2.5.2 Connection Flood防护
主动清除残余连接。
对恶意连接的IP进行封禁。
限制每个源IP的连接数。
可以对特定的URL进行防护。
反查Proxy后面发起HTTP Get Flood的源。

2.6 HTTP Get攻击
2.6.1 原理
这种攻击主要是针对存在ASP、JSP、PHP、CGI等脚本程序，并调用MSSQLServer、MySQLServer、Oracle等数据库的网站系统而设计的，特征是和服务器建立正常的TCP连接，并不断的向脚本程序提交查询、列表等大量耗费数据库资源的调用，典型的以小博大的攻击方法。一般来说，提交一个GET或POST指令对客户端的耗费和带宽的占用是几乎可以忽略的，而服务器为处理此请求却可能要从上万条记录中去查出某个记录，这种处理过程对资源的耗费是很大的，常见的数据库服务器很少能支持数百个查询指令同时执行，而这对于客户端来说却是轻而易举的，因此攻击者只需通过Proxy代理向主机服务器大量递交查询指令，只需数分钟就会把服务器资源消耗掉而导致拒绝服务，常见的现象就是网站慢如蜗牛、ASP程序失效、PHP连接数据库失败、数据库主程序占用CPU偏高。这种攻击的特点是可以完全绕过普通的防火墙防护，轻松找一些Proxy代理就可实施攻击，缺点是对付只有静态页面的网站效果会大打折扣，并且有些Proxy会暴露攻击者的IP地址。攻击工具：


在遭受攻击的服务器上抓包，大量不同IP在请求资源。在实际情况中，也有可能使用代理地址连接。

2.6.2 HTTP Get防护
对是否HTTP Get的判断，要统计到达每个服务器的每秒钟的GET 请求数，如果远远超过正常值，就要对HTTP协议解码，找出HTTP Get及其参数（例如URL等）。
然后判断某个GET 请求是来自代理服务器还是恶意请求。并回应一个带key的响应要求请求发起端作出相应的回馈。如果发起端并不响应则说明是利用工具发起的请求，这样HTTP Get请求就无法到达服务器，达到防护的效果。


2.7 UDP DNS Query Flood攻击
2.7.1 原理
UDP DNS Query Flood攻击实质上是UDP Flood的一种，但是由于DNS服务器的不可替代的关键作用，一旦服务器瘫痪，影响一般都很大。
UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。
根据微软的统计数据，一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而我们知道，在一台P3的PC机上可以轻易地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的DNS服务器瘫痪，由此可见DNS 服务器的脆弱性。同时需要注意的是，蠕虫扩散也会带来大量的域名解析请求。

2.7.2 UDP DNS Query Flood防护
在UDP Flood的基础上对 UDP DNS Query Flood 攻击进行防护
根据域名 IP 自学习结果主动回应，减轻服务器负载（使用 DNS Cache）
对突然发起大量频度较低的域名解析请求的源 IP 地址进行带宽限制


在攻击发生时降低很少发起域名解析请求的源 IP 地址的优先级
限制每个源 IP 地址每秒的域名解析请求次数


3.网络溯源技术
网络安全不能仅依赖于防护,还应该聚焦于检测与响应,其中进行网络攻击溯源是一种有效的响应方式。进行网络溯源的主要目的是重建攻击路径,这样网络管理员就能够识别攻击者的地址;从而进行追责,最终形成威慑。

溯源技术通常被分为两大类:主动溯源和被动溯源。其中,主动溯源是在报文传输过程中标记报文信息,攻击一旦发生,管理人员就能够利用这些信息去跟踪路由路径并确定攻击源。被动溯源是在判断攻击发生之后才开始采取措施,使用工具分析流量情况等信息进行溯源。

常见的溯源方案有以下四种:链路测试技术、日志记录技术、基于ICMP的报文技术和概率包标记技术。

链路测试技术是逐跳地对路由器进行测试以重建攻击路径。在传统网络中,通常需要安装一个跟踪程序,如DoS Tracker,到靠近攻击者的路由器中,监视传入的数据包,找到攻击路径的上一跳,重复该过程,逐跳回溯,直到找到攻击源。

日志记录技术是在中转设备上存储途经它的报文信息,在需要处理时,使用大数据分析技术对海量数据进行分析,来达到寻找攻击源的目的。
基于ICMP的报文技术由Bellovin提出;数据包在通过路由器时以一定概率生成ICMP traceback(iTrace)消息, 一个iTrace消息由下一跳信息、上一跳信息以及一个时间戳组成,目的主机收到足够数量的iTrace消息后,能构造出消息的转发路
径。
概率包标记技术使用IP分组头部的某些字段,向字段中添加路径信息;这种方法与ICMP溯源法类似,受害者收到足够的分组后重构攻击路径;该方法相对于基于ICMP的报文技术的优势在于不需要生成新的特殊报文。


4.溯源对网络安全的意义
Chris Sanders 指出“预防终将失败”,网络安全应该聚焦到检测和响应上 。网络溯源是一种有效的对网络攻击的响应方式。对网络攻击的响应按照响应时间可以分为两类,一是检测到攻击后立即作出响应,如启动防护方案、迁移功能等;另一种是进行网络溯源,找到攻击源进行事故遏制和取证操作,从源头上解决网络攻击。前一种方法能够快速对攻击作出响应,把攻击隔离在网络之外;但是,这种方式只是对网络进行防护,无法找到攻击的源头,攻击者很难受到惩罚。后一种方法虽然不能快速对网络进行防护,但通过网络溯源找到攻击源,进行取证,进而确认攻击者,才能从根本上解决攻击问题。网络溯源对网络安全具有十分重要的意义,它不仅能够找到攻击者并对其进行屏蔽,并且能够搜集到对攻击者进行法律追究的依据,并形成威慑。因此,从长远考虑,网络攻击溯源对网络安全而言具有重要的意义。

qq3250845

.........................