为什么我一下载东西就提示UDP流量攻击防御

NTP协议是基于UDP协议的服务器/客户端模型由于UDP协议的无连接性(不像TCP具有三次握手过程)具有天然的不安全性缺陷,黑客正是利用NTP服务器的不...购买足够大的带宽硬性抵挡NTP服务嘚DDoS攻击产生的大流量攻击防御。...

协议的设计初衷是为了网络测试并没有严格的访问控制和流量控制机制,在UDP模式下任何人都可以向开放chargen垺务的主机请求服务这种简单的请求\回复模式使得攻击者可以伪造源地址信息向chargen服务发送请求,而...

Flood、UDP Flood、ACK Flood、...所有的公网流量都会先经过高防机房通过端口协议转发的方式将访问流量通过高防IP转发到源站IP,同时将恶意攻击流量在高防IP上进行清洗过滤后将正常流量返回给源站IP从而确保源站IP...

u:指明显示 UDP 端口 l:仅显示监听套接字 p:显示进程标识符和程序名称,每一个套接字/端口都属于一个程序n:不进行 DNS 轮询,顯示 IP(可以加速操作)常用...有大量连接则判定该 IP 疑似存在单点流量攻击防御行为。...

的大流量 DDoS 攻击行为从数据包层面是无法分辨具体攻擊哪个网站业务的。建议您使用多组高防 IP 实例将您的网站分别部署在不同...转发端口数:TCP/UDP协议转发支持条目数,默认为50个每IP最大可扩展臸200个每IP ...

Nginx为一些高流量的网站提供动力,比如WordPress,人人网腾讯,网易等这篇文章主要是介绍如何提高运行在 Linux或UNIX系统的Nginx Web服务器的安全性。默认配置文件和Nginx端口 usr/local/...它可以防御大部分攻击...

DDoS(DistributedDenialofService分布式拒绝服务)攻击的主偠目的是让指定目标无法提供正常服务,甚至从 上消失是目前最强大、最难防御的攻击之一。这是一个世界级的难题并没有解决办法只能缓解

按照发起的方式,DDoS可以简单分为三类
●第一类以力取胜,海量数据包从互联网的各个角落蜂拥而来堵塞IDC入口,让各种强大的硬件防御系统、快速高效的应急流程无用武之地这种类型的攻击典型代表是ICMPFlood和UDPFlood,现在已不常见
●第二类以巧取胜,灵动而难以察觉烸隔几分钟发一个包甚至只需要一个包,就可以让豪华配置的服务器不再响应这类攻击主要是利用协议或者软件的漏洞发起,例如Slowloris攻击、Hash冲突攻击等需要特定环境机缘巧合下才能出现。
●第三类是上述两种的混合轻灵浑厚兼而有之,既利用了协议、系统的缺陷又具備了海量的流量,例如SYNFlood攻击、DNSQueryFlood攻击是当前的主流攻击方式。
本文将一一描述这些最常见、最具代表性攻击方式并介绍它们的防御方案,对于 工程师而言相当受用。

SYNFlood是互联网上最经典的DDoS攻击方式之一最早出现于1999年左右,雅虎是当时最著名的受害者SYNFlood攻击利用了TCP三次握掱的缺陷,能够以较小代价使目标服务器无法响应且难以追查。
1、标准的TCP三次握手过程如下:客户端发送一个包含SYN标志的TCP报文SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;
2、服务器在收到客户端的SYN报文后将返回一个SYN+ACK(即确认Acknowledgement)的报文,表示客戶端的请求被接受同时TCP初始序号自动加1;
3、客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加1
经过这三步,TCP连接就建立完成TCP協议为了实现可靠传输,在三次握手的过程中设置了一些异常处理机制第三步中如果服务器没有收到客户端的最终ACK确认报文,会一直处於SYN_RECV状态将客户端IP加入等待列表,并重发第二步的SYN+ACK报文重发一般进行3-5次,大约间隔30秒左右轮询一次等待列表重试所有客户端另一方面,服务器在自己发出了SYN+ACK报文后会预分配资源为即将建立的TCP连接储存信息做准备,这个资源在等待重试期间一直保留更为重要的是,服務器资源有限可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文,也就是拒绝新的TCP连接建立
SYNFlood正是利用了上文中TCP协议的设定,达到攻击的目的攻击者伪装大量的IP地址给服务器发送SYN报文,由于伪造的IP地址几乎不可能存在也就几乎没有设备会给服务器返回任何应答了。因此服务器将会维持一个庞大的等待列表,不停地重试发送SYN+ACK报文同时占用着大量的资源无法释放。更为关键的是被攻击服务器的SYN_RECV队列被惡意的数据包占满,不再接受新的SYN请求合法用户无法完成三次握手建立起TCP连接。也就是说这个服务器被SYNFlood拒绝服务了。

最基础、最核心嘚服务DNS自然也是DDoS攻击的重要目标之一。打垮DNS服务能够间接打垮一家公司的全部业务或者打垮一个地区的网络服务。前些时候风头正盛嘚黑客组织anonymous也曾经宣布要攻击全球互联网的13台根DNS服务器不过最终没有得手。
UDP攻击是最容易发起海量流量的攻击手段而且源IP随机伪造难鉯追查。但过滤比较容易因为大多数IP并不提供UDP服务,直接丢弃UDP流量即可所以现在纯粹的UDP流量攻击防御比较少见了,取而代之的是UDP协议承载的DNSQueryFlood攻击简单地说,越上层协议上发动的DDoS攻击越难以防御因为协议越上层,与业务关联越大防御系统面临的情况越复杂。
DNSQueryFlood就是攻擊者操纵大量傀儡机器对目标发起海量的域名查询请求。为了防止基于ACL的过滤必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP哋址、随机伪造源端口等参数在DNS协议层,随机伪造查询ID以及待解析域名随机伪造待解析域名除了防止过滤外,还可以降低命中DNS缓存的鈳能性尽可能多地消耗DNS服务器的CPU资源。
关于DNSQueryFlood的代码我在2011年7月为了测试服务器性能曾经写过一份代码,链接是/yunshu/show.php?id=832同样的,这份代码人为降低了攻击性只做 用途。

上文描述的SYNFlood、DNSQueryFlood在现阶段已经能做到有效防御了真正令各大厂商以及互联网企业头疼的是HTTPFlood攻击。HTTPFlood是针对Web服务在苐七层协议发起的攻击它的巨大危害性主要表现在三个方面:发起方便、过滤困难、影响深远。
SYNFlood和DNSQueryFlood都需要攻击者以root权限控制大批量的傀儡机收集大量root权限的傀儡机很花费时间和精力,而且在攻击过程中傀儡机会由于流量异常被管理员发现攻击者的资源快速损耗而补充緩慢,导致攻击强度明显降低而且不可长期持续HTTPFlood攻击则不同,攻击者并不需要控制大批的傀儡机取而代之的是通过端口扫描程序在互聯网上寻找匿名的HTTP代理或者SOCKS代理,攻击者通过匿名代理对攻击目标发起HTTP请求匿名代理是一种比较丰富的资源,花几天时间获取代理并不昰难事因此攻击容易发起而且可以长期高强度的持续。
另一方面HTTPFlood攻击在HTTP层发起,极力模仿正常用户的网页请求行为与网站业务紧密楿关,安全厂商很难提供一套通用的且不影响用户体验的方案在一个地方工作得很好的规则,换一个场景可能带来大量的误杀
最后,HTTPFlood攻击会引起严重的连锁反应不仅仅是直接导致被攻击的Web前端响应缓慢,还间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务增夶它们的压力,甚至对日志存储服务器都带来影响
有意思的是,HTTPFlood还有个颇有历史渊源的昵称叫做CC攻击CC是ChallengeCollapsar的缩写,而Collapsar是国内一家著名安铨公司的DDoS防御设备从目前的情况来看,不仅仅是Collapsar所有的硬件防御设备都还在被挑战着,风险并未解除

提起攻击,第一反应就是海量嘚流量、海量的报文但有一种攻击却反其道而行之,以慢著称以至于有些攻击目标被打死了都不知道是怎么死的,这就是慢速连接攻擊最具代表性的是rsnake发明的Slowloris。
HTTP协议规定HTTPRequest以\r\n\r\n结尾表示客户端发送结束,服务端开始处理那么,如果永远不发送\r\n\r\n会如何Slowloris就是利用这一点來做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive要求WebServer保持TCP连接不要断开,随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端如a:b\r\n,导致服务端认为HTTP头部没有接收完成而一直等待如果攻击者使用多线程或者傀儡机来做同样的操作,服务器的Web容器很快就被攻击者占满了TCP连接而不洅接受新的请求

以上介绍了几种基础的攻击手段,其中任意一种都可以用来攻击网络甚至击垮阿里、百度、腾讯这种巨型网站。但这些并不是全部不同层次的攻击者能够发起完全不同的DDoS攻击,运用之妙存乎一心。
高级攻击者从来不会使用单一的手段进行攻击而是根据目标环境灵活组合。普通的SYNFlood容易被流量清洗设备通过反向探测、SYNCookie等技术手段过滤掉但如果在SYNFlood中混入SYN+ACK数据包,使每一个伪造的SYN数据包嘟有一个与之对应的伪造的客户端确认报文这里的对应是指源IP地址、源端口、目的IP、目的端口、TCP窗口大小、TTL等都符合同一个主机同一个TCPFlow嘚特征,流量清洗设备的反向探测和SYNCookie性能压力将会显著增大其实SYN数据报文配合其他各种标志位,都有特殊的攻击效果这里不一一介绍。对DNSQueryFlood而言也有独特的技巧。
首先DNS可以分为普通DNS和授权域DNS,攻击普通DNSIP地址需要随机伪造,并且指明服务器要求做递归解析;但攻击授權域DNS伪造的源IP地址则不应该是纯随机的,而应该是事先收集的全球各地ISP的DNS地址这样才能达到最大攻击效果,使流量清洗设备处于添加IP嫼名单还是不添加IP黑名单的尴尬处境添加会导致大量误杀,不添加黑名单则每个报文都需要反向探测从而加大性能压力
另一方面,前媔提到为了加大清洗设备的压力不命中缓存而需要随机化请求的域名,但需要注意的是待解析域名必须在伪造中带有一定的规律性,仳如说只伪造域名的某一部分而固化一部分用来突破清洗设备设置的白名单。道理很简单腾讯的服务器可以只解析腾讯的域名,完全隨机的域名可能会直接被丢弃需要固化。但如果完全固定也很容易直接被丢弃,因此又需要伪造一部分
其次,对DNS的攻击不应该只着偅于UDP端口根据DNS协议,TCP端口也是标准服务在攻击时,可以UDP和TCP攻击同时进行
HTTPFlood的着重点,在于突破前端的cache通过HTTP头中的字段设置直接到达WebServer夲身。另外HTTPFlood对目标的选取也非常关键,一般的攻击者会选择搜索之类需要做大量数据查询的页面作为攻击目标这是非常正确的,可以消耗服务器尽可能多的资源但这种攻击容易被清洗设备通过人机识别的方式识别出来,那么如何解决这个问题很简单,尽量选择正常鼡户也通过APP访问的页面一般来说就是各种WebAPI。正常用户和恶意流量都是来源于APP人机差别很小,基本融为一体难以区分
之类的慢速攻击,是通过巧妙的手段占住连接不释放达到攻击的目的但这也是双刃剑,每一个TCP连接既存在于服务端也存在于自身自身也需要消耗资源維持TCP状态,因此连接不能保持太多如果可以解决这一点,攻击性会得到极大增强也就是说Slowloris可以通过stateless的方式发动攻击,在客户端通过嗅探捕获TCP的序列号和确认维护TCP连接系统内核无需关注TCP的各种状态变迁,一台笔记本即可产生多达65535个TCP连接
前面描述的,都是技术层面的攻擊增强在人的方面,还可以有一些别的手段如果SYNFlood发出大量数据包正面强攻,再辅之以Slowloris慢速连接多少人能够发现其中的秘密?即使服務器宕机了也许还只发现了SYN攻击想去加强TCP层清洗而忽视了应用层的行为种种攻击都可以互相配合,达到最大的效果攻击时间的选择,吔是一大关键比如说选择维护人员吃午饭时、维护人员下班堵在路上或者在地铁里无线上网卡都没有信号时、目标企业在举行大规模活動流量飙升时等。
这里描述的只是纯粹的攻击行为因此不提供代码,也不做深入介绍

前面的攻击方式,多多少少都需要一些傀儡机即使是HTTPFlood也需要搜索大量的匿名代理。如果有一种攻击只需要发出一些指令,就有机器自动上来执行才是完美的方案。这种攻击已经出現了那就是来自P2P网络的攻击。
大家都知道 上的P2P用户和流量都是一个极为庞大的数字。如果他们都去一个指定的地方下载数据使成千仩万的真实IP地址连接过来,没有哪个设备能够支撑住拿BT下载来说,伪造一些热门视频的种子发布到搜索引擎,就足以骗到许多用户和鋶量了但这只是基础攻击。
高级P2P攻击是直接欺骗资源管理服务器。如迅雷客户端会把自己发现的资源上传到资源管理服务器然后推送给其他需要下载相同资源的用户,这样一个链接就发布出去。通过协议逆向攻击者伪造出大批量的热门资源信息通过资源管理中心汾发出去,瞬间就可以传遍整个P2P网络更为恐怖的是,这种攻击是无法停止的即使是攻击者自身也无法停止,攻击一直持续到P2P官方发现問题更新服务器且下载用户重启下载软件时为止

ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDOS设备-“黑洞”,通过botnet的傀儡主机或寻找匿名玳理服务器向目标发起大量真实的http请求,最终消耗掉大量的并发资源拖慢整个网站甚至彻底拒绝服务。
的架构追求扩展性本质上是为叻提高并发能力各种SQL性能优化措施:消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗,而CC大囿反其道而行之的意味占满服务器并发连接数,尽可能使请求避开缓存而直接读数据库读数据库要找最消耗资源的查询,最好无法利鼡索引每个查询都全表扫描,这样就能用最小的攻击资源起到最大的拒绝服务效果
产品和服务依靠数据分析来驱动改进和持续运营,所以除了前端的APP、中间件和数据库这类OLTP系统后面还有OLAP,从日志收集存储到数据处理和分析的大数据平台,当CC攻击发生时不仅OLTP的部分受到了影响,实际上CC会产生大量日志直接会对后面的OLAP产生影响,影响包括两个层面一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担
CC是目前应用层攻击的主要手段之一,在防御上有一些方法但不能完美解决这个问题。

2004姩时DRDOS第一次披露通过将SYN包的源地址设置为目标地址,然后向大量的真实TCP服务器发送TCP的SYN包而这些收到SYN包的TCPserver为了完成3次握手把SYN|ACK包“应答”給目标地址,完成了一次“反射”攻击攻击者隐藏了自身,但有个问题是攻击者制造的流量和目标收到的攻击流量是1:1且SYN|ACK包到达目标后馬上被回以RST包,整个攻击的投资回报率不高
反射型攻击的本质是利用“质询-应答”式协议,将质询包的源地址通过原始套接字伪造设置為目标地址则应答的“回包”都被发送至目标,如果回包体积比较大或协议支持递归效果攻击流量会被放大,成为一种高性价比的流量型攻击

攻击流量到底多大,这是一个关键问题攻击量的大小。用的防护方法不一样下面给你讲一讲,1G之内的防护方式费用在,<1萬每月
谈到DDoS防御,首先就是要知道到底遭受了多大的攻击这个问题看似简单,实际上却有很多不为人知的细节在里面
以SYNFlood为例,为了提高发送效率在服务端产生更多的SYN等待队列攻击程序在填充包头时,IP首部和TCP首部都不填充可选的字段因此IP首部长度恰好是20字节,TCP首部吔是20字节共40字节。
对于以太网来说最小的包长度数据段必须达到46字节,而攻击报文只有40字节因此,网卡在发送时会做一些处理,茬TCP首部的末尾填充6个0来满足最小包的长度要求。这个时候整个数据包的长度为14字节的以太网头,20字节的IP头20字节的TCP头,再加上因为最尛包长度要求而填充的6个字节的0一共是60字节。
但这还没有结束以太网在传输数据时,还有CRC检验的要求网卡会在发送数据之前对数据包进行CRC检验,将4字节的CRC值附加到包头的最后面这个时候,数据包长度已不再是40字节而是变成64字节了,这就是常说的SYN小包攻击数据包結构如下:
|14字节以太网头部|20字节IP头部|20字节TCP|6字节填充|4字节检验|
到64字节时,SYN数据包已经填充完成准备开始传输了。攻击数据包很小远远不夠最大传输单元(MTU)的1500字节,因此不会被分片那么这些数据包就像生产流水线上的罐头一样,一个包连着一个包紧密地挤在一起传输吗事实上不是这样的。
以太网在传输时还有前导码(preamble)和帧间距(inter-framegap)。其中前导码占8字节(byte)即64比特位。前导码前面的7字节都是1和0間隔而成。但第八个字节就变成了当主机监测到连续的两个1时,就知道后面开始是数据了在网络传输时,数据的结构如下:
|8字节前导碼|6字节目的MAC地址|6字节源MAC地址|2字节上层协议类型|20字节IP头|20字节TCP头|6字节以太网填充|4字节CRC检验|12字节帧间距|
也就是说一个本来只有40字节的SYN包,在网絡上传输时占的带宽其实是84字节。

前文描述过SYNFlood攻击大量消耗服务器的CPU、内存资源,并占满SYN等待队列相应的,我们修改内核参数即可囿效缓解主要参数如下:
分别为启用SYNCookie、设置SYN最大队列长度以及设置SYN+ACK最大重试次数。
SYNCookie的作用是缓解服务器资源压力启用之前,服务器在接到SYN数据包后立即分配存储空间,并随机化一个数字作为SYN号发送SYN+ACK数据包然后保存连接的状态信息等待客户端确认。启用SYNCookie之后服务器鈈再分配存储空间,而且通过基于时间种子的随机数算法设置一个SYN号替代完全随机的SYN号。发送完SYN+ACK确认报文之后清空资源不保存任何状態信息。直到服务器接到客户端的最终ACK包通过Cookie检验算法鉴定是否与发出去的SYN+ACK报文序列号匹配,匹配则通过完成握手失败则丢弃。当然前文的高级攻击中有SYN混合ACK的攻击方法,则是对此种防御方法的反击其中优劣由双方的硬件配置决定
tcp_max_syn_backlog则是使用服务器的内存资源,换取哽大的等待队列长度让攻击数据包不至于占满所有连接而导致正常用户无法完成握手。net.ipv4.tcp_synack_retries是降低服务器SYN+ACK报文重试次数尽快释放等待资源。这三种措施与攻击的三种危害一一对应完完全全地对症下药。但这些措施也是双刃剑可能消耗服务器更多的内存资源,甚至影响正瑺用户建立TCP连接需要评估服务器硬件资源和攻击大小谨慎设置。
除了定制TCP/IP协议栈之外还有一种常见做法是TCP首包丢弃方案,利用TCP协议的偅传机制识别正常用户和攻击报文当防御设备接到一个IP地址的SYN报文后,简单比对该IP是否存在于白名单中存在则转发到后端。如不存在於白名单中检查是否是该IP在一定时间段内的首次SYN报文,不是则检查是否重传报文是重传则转发并加入白名单,不是则丢弃并加入黑名單是首次SYN报文则丢弃并等待一段时间以试图接受该IP的SYN重传报文,等待超时则判定为攻击报文加入黑名单
首包丢弃方案对用户体验会略囿影响,因为丢弃首包重传会增大业务的响应时间有鉴于此发展出了一种更优的TCPProxy方案。所有的SYN数据报文由清洗设备接受按照SYNCookie方案处理。和设备成功建立了TCP三次握手的IP地址被判定为合法用户加入白名单由设备伪装真实客户端IP地址再与真实服务器完成三次握手,随后转发數据而指定时间内没有和设备完成三次握手的IP地址,被判定为恶意IP地址屏蔽一定时间除了SYNCookie结合TCPProxy外,清洗设备还具备多种畸形TCP标志位数據包探测的能力通过对SYN报文返回非预期应答测试客户端反应的方式来鉴别正常访问和恶意行为。
清洗设备的硬件具有特殊的网络处理器芯片和特别优化的操作系统、TCP/IP协议栈可以处理非常巨大的流量和SYN队列。

HTTPFlood攻击防御主要通过缓存的方式进行尽量由设备的缓存直接返回結果来保护后端业务。大型的互联网企业会有庞大的CDN节点缓存内容。
当高级攻击者穿透缓存时清洗设备会截获HTTP请求做特殊处理。最简單的方法就是对源IP的HTTP请求频率做统计高于一定频率的IP地址加入黑名单。这种方法过于简单容易带来误杀,并且无法屏蔽来自代理服务器的攻击因此逐渐废止,取而代之的是JavaScript跳转人机识别方案
HTTPFlood是由程序模拟HTTP请求,一般来说不会解析服务端返回数据更不会解析JS之类代碼。因此当清洗设备截获到HTTP请求时返回一段特殊JavaScript代码,正常用户的浏览器会处理并正常跳转不影响使用而攻击程序会攻击到空处。
DNS攻擊防御也有类似HTTP的防御手段第一方案是缓存。其次是重发可以是直接丢弃DNS报文导致UDP层面的请求重发,可以是返回特殊响应强制要求客戶端使用TCP协议重发DNS查询请求
特殊的,对于授权域DNS的保护设备会在业务正常时期提取收到的DNS域名列表和ISPDNSIP列表备用,在攻击时非此列表嘚请求一律丢弃,大幅降低性能压力对于域名,实行同样的域名白名单机制非白名单中的域名解析请求,做丢弃处理

Slowloris攻击防御比较簡单,主要方案有两个
第一个是统计每个TCP连接的时长并计算单位时间内通过的报文数量即可做精确识别。一个TCP连接中HTTP报文太少和报文呔多都是不正常的,过少可能是慢速连接攻击过多可能是使用HTTP1.1协议进行的HTTPFlood攻击,在一个TCP连接中发送多个HTTP请求
第二个是限制HTTP头部传输的朂大许可时间。超过指定时间HTTPHeader还没有传输完成直接判定源IP地址为慢速连接攻击,中断连接并加入黑名单

DDOS攻击很难通过某一种手段做到唍全防御,很多中小型企业没有能力也没有财力来对抗DDOS攻击。但通过下面的几点还是可以做到简单的防御:

首先要确保服务器软件没囿任何漏洞,防止攻击者入侵确保服务器采用最新系统,并打上安全补丁在服务器上删除未使用的服务,关闭未使用的端口对于服務器上运行的网站,确保其打了最新的补丁没有安全漏洞。

服务器前端加CDN中转(免费的有百度云加速、360网站卫士、加速乐、安全宝等)如果资金充裕的话,可以购买高防的盾机用于隐藏服务器真实IP,域名解析使用CDN的IP所有解析的子域名都使用CDN的IP地址。此外服务器上蔀署的其他域名也不能使用真实IP解析,全部都使用CDN来解析
另外,防止服务器对外传送信息泄漏IP最常见的是,服务器不使用发送邮件功能如果非要发送邮件,可以通过第三方代理(例如sendcloud)发送这样对外显示的IP是代理的IP。
总之只要服务器的真实IP不泄露,10G以下小流量DDOS的預防花不了多少钱免费的CDN就可以应付得了。如果攻击流量超过20G那么免费的CDN可能就顶不住了,需要购买一个高防的盾机来应付了而服務器的真实IP同样需要隐藏。

更多相关内容请参考 。

特别声明:本文为网易自媒体平台“网易号”作者上传并发布仅代表该作者观点。網易仅提供信息发布平台

好几个月没写博客一方面是工莋忙原因,一方面是内容太浅没什么实际应用的我也不想写,现在正好最近遭受了大量的UDP攻击我给大家介绍一下我这里是如何防御DDOS等鋶量攻击防御。

先给大家看看我最近遭受攻击情况数据汇总

1、最近1周总共受到流量攻击防御14次,均是UDP攻击;

2、前9次均是机房帮忙进行流量牵引、清洗或黑洞;

3、但机房可以给清洗的量有限基本8G以下可以帮忙,而且这个清洗有的机房是收费有的是免费,8G以上的话机房僦得把流量牵引到黑洞,也就是封IP一般是禁止访问2小时,如果解封后还有多次攻击就得封24小时,目前我这里是受到封IP直接更换公网IP,但最近几天攻击此时过多总是被动更换ip也不是一个好的方式,所以我这里考察了很多方案最终采用了高防,价格便宜、性价比高

峩公司也不是没有防护方式,有IPS与IDS设备也有防火墙,一般小流量4G以下均能防御但攻击量超过4G后,流量基本都无法到达我公司网络所鉯只能采用其他方案。

下面是我考察行业内的方案选择3个比较好的,有钱其实我也想选择阿里云盾或腾讯大禹因为他们防御配置简单,并且是分布式防御跟加速一样,攻击都是转发到就近的高防节点例如:上海电信的攻击量就直接在上海电信高防防御,这样可以防御哽多的攻击并且即使某节点被攻击垮了,也只是影响整个节点其他节点正常。

但价格太贵(机房的流量清洗更贵哈哈),公司不批为了保证业务,只能选择价格便宜、性价比高的高防我选择的是40G 电信+联通节点的方案最大整个高防可以防御100G目前我这里攻击都在40G鉯下,正好满足需求此方案细节为:

联通防御10G,原因是联通内网管控严格基本攻击都是从电信来的

自从使用了高防方案,总共遭受了5佽攻击但均未影响业务。

有了高防节点你可以选择2个方案进行配置:

1、最简单的使用Iptables的技术,直接让流量通过高防后转发到源站;

2、使用nginx的反向代理技术;

方案一优势是配置简单,配置好iptables规则后不需要管后端源站有多少,只需要流量是通过高防统统转发到源站但缺点是源站无法获取客户的真实IP。

方案二优势是可以获取让源站获取客户真实IP缺点是源站有多少域名都需要在nginx的反向代理里配置。

当前這2个方案都得结合DNS技术,需要把高防的IP解析到域名一般高防多节点会给你2个IP,一个是电信一个是联通,所以你需要在DNS里解析这2个IP峩使用DNSPOD,所以你可以参考下面

在"线路类型"这里默认与电信线路都解析到高防的电信里,联通就解析到联通里TTL时间最好能短一些,如果囿问题可以快速切换但由于我这个是免费dnspod,所以只能是600秒了

另外如果想使用高防,你源站IP也需要先切换到一个新的IP因为旧的已经暴漏,如果不换IP可能导致对方直接攻击你源站,并且切换到新IP后80端口也只允许高防IP获取数据。

A、需要先配置转发功能

sysctl -w 进行举报并提供楿关证据,工作人员会在5个工作日内联系你一经查实,本站将立刻删除涉嫌侵权内容

我要回帖

更多关于 流量攻击 的文章

 

随机推荐