精华内容
下载资源
问答
  • 从2013年3月的300Gbps到2014年2月的400Gbps,DDoS攻击以惊人的速度进入200-400Gbps时代。面对如此规模的DDoS攻击开发者究竟该如何应对?这里我们不妨看看阿里云的分享。DDoS(DistributedDenialofService,分布式...
  • 一种分布式的DDoS攻击防御系统模型的研究,邹存强,,分布式拒绝服务攻击(DDoS)是最主要的网络安全威胁之一,具有很强的破坏力,难以防范。本文在研究现有防御机制的基础上,提出一��
  • DDos攻击防御策略

    千次阅读 2020-06-23 22:43:21
    DDOS攻击防御策略 DDOS(DDOS:Distributed Denial of Service) 分布式拒绝服务攻击. 在信息安全三要素里面—保密性,完整性,可用性,中DDOS(分布式拒绝服务攻击),针对的是目标机器的可用性,这种攻击方式是利用目标系统...

    DDOS攻击防御策略
    DDOS(DDOS:Distributed Denial of Service) 分布式拒绝服务攻击.
    在信息安全三要素里面—保密性,完整性,可用性,中DDOS(分布式拒绝服务攻击),针对的是目标机器的可用性,这种攻击方式是利用目标系统网络系统功能的的欠缺或者直接消耗其资源,是目标机器木法正常提供服务.
    拒绝服务攻击示意图:
    在这里插入图片描述DDOS是一类攻击而不是一种攻击类型,并且DDOS的防御是一个可以做到相对自动化但是做不到绝对的自动化,很多攻击过程自动化并不能识别.
    网络层的攻击
    Syn-flood
    利用TCP建立连接时3次握手的”漏洞”,通过原始套接字发送源地虚假地址SYN报文,使用目标主机永远无法完成3次握手,占满了系统的协议队列,资源得不到释放,进而形成拒绝服务攻击,是互联网中最主要的DDOS攻击形式之一.网上有一些加固的方法,例如调整内核参数的方法,可以减少等待重试,加速资源释放,在小流量的syn-flood的情况下可以缓解,单流量稍大时完全不抵用.防御syn-flood的常见方法有:syn-proxy,syn cookies.首包(第一次请求的syn包)丢弃等.
    ACK-flood
    对于虚假的ACK包,目标设备会直接回复RST包丢弃连接,所以伤害值远不如syn-floo.DDOS的一种原始方式.
    UDP-flood
    使用原始套接字伪造大量虚假源地址的UDP包,目前DNS协议为主.
    ICMP-flood
    Ping洪水,比较古老的方式.
    应用层攻击
    CC
    ChallengeCollapsar的名字源于挑战国内知名的安全厂商绿盟的抗DDOS设备”黑洞”,通过boenet的傀儡机或寻找匿名代理服务器,向目标发起大量真实的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 service列表.对于源地址伪造成ISP DNS的请求,可以通过TTL值进一步判断.
    慢速连接攻击
    针对http协议,以知名的slowloris攻击为起源:先建立一个http连接,设置一个比较大的content-length,每次只发送很少的字节,让服务器一直以为http头没有传输完成,这样的连接一多很快就会出现连接耗尽.
    目前出现了一些变种,http慢速的post请求和慢速的read请求都是基于相同的原理.
    DOS攻击
    有些服务器程序存在bug.安全漏洞或架构缺陷,攻击者可以通过构造的畸形请求发送给服务器,服务器因不能正确处理恶意请求而陷入僵死状态,导致拒绝服务攻击.例如某些版本app服务器中存在缓存区溢出,漏洞可以触发但无法拿到shell,攻击者可以改变程序执行流程使其跳转到空指针或无法处理的地址,用户态的错误会导致进程挂起,如果错误不能被内核回收则可能使系统当掉.
    这类问题效果也表现为拒绝服务攻击,但本质上属于漏洞,可以通过patch程序的新版本解决,我认为这不属于DDOS的范围.
    攻击方式
    混合型
    在实际大流量的攻击中,通常并不是上述一种数据类型来攻击的,往往是混杂了TCP和UDP流量,网络层和应用层攻击同时进行.
    反射型
    2004年时DRDOS(是英文Distributed Reflection Denial of Service的缩写,中文意思是分布式反射服务攻击,与DOS和DDOS不同,该方式考的是发送大量带有被害者IP地址的数据包给攻击攻击主机,让后攻击主机对IP地址源做出大量的回应,形成拒绝服务)
    通过将SYN包的原地址设置为目标地址,然后向大量的真实TCP服务器发送的SYN包,而这些收到SYN包的TCP service为了完成3次握手包SYN|ack包”应答”给目标地址,完成一次”反射”攻击,攻击者隐藏了自身,但有个问题是攻击者制造的流浪和目标收到的攻击量是1:1的,且SYN|ack包导弹目标后被回以rst包,整个攻击的投资回报率不高.
    反射型攻击的本质是利用”咨询-应答”式协议,将质询包的原地址通过套接字伪造设置为目标地址,则应答的”回包”都被发送至目标,如果回包提交比较大或协议支持递归效果,攻击流量会被放大,成为一种高性价比的流量型攻击.
    反射型攻击利用的协议有NTP,chargen,SSDP,DNS,RPC portmap等等.
    流量放大型
    以上面提到的DRDOS中常见的SSDP协议为例子,攻击者将search type设all,搜索所有可用的设备和服务,这种壁柜效果产生的放大背书是非常大的,攻击者只需要以较小的伪造源地址的查询流浪就可以制造出几十甚至上百倍的回应流量发送到目标.
    脉冲型
    很多攻击持续时间非常短,通常5分钟以内,流浪图上表现为突出状的脉冲.
    所以这种攻击流行是因为”打打停停”效果比较好,刚触发防御阀值,防御机制开始生效就停止攻击,周而复始.蚊子不叮你,却在你耳边非,刚开灯打他他就没影了,当你关灯他有出来了.
    自动化的防御机制大部分都是依靠设置阀值来触发的.尽管很多厂商宣称自己的防御措施都是秒级响应,但实际上比较难.
    网络层的攻击检测通常分为逐流和逐包,前者是根据netflow以一定的抽样比例(例如1000:1)检测网络是否存在doos攻击,这种方式因为是抽样比例,所以精确率会比较低,做不到秒级响应,第二种逐包检测,检测精度和响应时间比较短但是成本比较高,一般厂商都不会无视TCO全部部署这类方案,其防御清洗策略的启动也依赖与阀值,加上洗流设备一般情况下不会串联部署,触发清洗后需要引流,因此大部分场景可以做秒级检测但是做不到秒级防御,近源洗流尚且如此,云清洗的触发和转换过程就更慢了,所以利用防御规则的生效过度期,在触发防御前完成攻击会有不错的效果,在结果上表现为脉冲.
    链路泛洪
    随着DDOS攻击技术的发展,有出现了一种新型的攻击方式link-flooding attack,这种方式不直接攻击目标网络traceroute的倒数第二跳,即上联路由,致使链路拥塞.国内ISP目前未开放anycast,所以这种攻击方式的必要性有待观望.
    对一级ISP和IXP的攻击都可以使链路拥塞.
    多层防御结构
    DDOS攻击本质上是一种只能缓解而不能根本防御的攻击,它不像漏洞那样打个补丁就把问题解决了,DDOS就算购买和部署了当前市场上比较有竞争力的防御解决方案也谈不上彻底防御.防火墙,IPS,waf这些安全产品都号称自己有一定的抗D能力,而实际上他们只针对小流浪下,应用层的攻击比较有效,对于稍大流浪的DDOS攻击则无济于事.
    以2015年年中的情况威力,国内的DDOS攻击在一个月内攻击流量到达300G的就将近10-20次,这个数值将随着国内家庭宽带网速提升而进一步放大.对于200-500G的攻击流量该如何防御.完整的防御模型有四层.
    这四层不是严格意义上的宗申防御关系,也不是在所有的防御中4层都会参与,可能有时候只是其中的2层参与防御,但对于超大流量的攻击而言,4层就是防御急着的全部,在没有其他解决手段.跟厂商的市场宣传可能有所不同,大流量攻击的防护并不是像某些厂商宣称的那样靠单方面就能解决的,而是多层共同参与防御的结果.
    ISP/WAN层
    这一层通常是对用户不可见,如果只是中小企业,那这一层可能真的不会决出到.但如果是大型互联网公司或者云厂商,甚至云洗流厂商,这层是必不可少的.因为当前流量超过自己能处理的极限时必须要借助电信运用商的能力.大型互联网公司虽然自身储备的带宽比较大,但还没有达到轻松抵抗大流量DDOS的程度,毕竟带宽是所有IDC成本中最贵的资源没有之一.无论是云计算厂商,大型互联网公司对外宣称的成功抵御200G以上攻击的新闻背后都有运用到了运营商的抗D能力,另外像第三方云清洗平台他们实际上或多或少的依赖电信运营商,如果只靠自身的清洗能力,都是非常有限的.
    目前如中国电信的专门做抗D的云堤提供了(近源洗流)和(流量压制)的服务,对于购买其服务器的厂商来说可以自定义需要黑洞路由的IP与电信的设备联动,黑洞路由是一种简单粗暴的方法,处理攻击流量,部分真实用户的访问也会被黑洞吃掉,对于用户体验大打折扣的行为,本质上属于为了保障留给其余用户的链路框框的弃卒保帅的做法,之前还会有这种收费服务是因为加入不这么做,全站服务器会对所有用户彻底无法访问.对于云清洗厂商而言,实际上也需要借助黑洞路由与电信联动.
    相比之下,对攻击流量的牵引,清洗,回注的防御方式对用户体验的敲诈你没那么大,但是跟黑洞路由比防御方成本比较高,且触发到响应的延时较大.
    在运营商防御这一层的主要的参与者是大型互联网公司,公有云厂商,云清洗厂商,其最大的意义在于应对超过自身带宽储备和自身DDOS防御能力之外的超大攻击流量时作为补充性的缓解措施.
    CDN/intent层
    CDN并不是一种抗D的产品,但对于web类服务而言,他却正好有一定的扛D能力,以大型电商的抢购为例,这个王文量非常大,从很多指标上看不言语DDOS的CC,而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求,最后到达数据库的请求只占整体请求量的很小一部分.
    对http CC类型的DDOS,不会直接到源站,CDN会先通过自身的带宽硬抗,抗不了的或者穿透CDN的动态请求会到元湛,如果源站前段的抗D能力或者源站前的带宽比较有钱,就会被彻底的D崩.
    云清洗厂商提出的策略是,预先设置好网站的CNAME,将域名指向云清洗的DNS服务器,在一般情况下,云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站,在检测到攻击发生时,域名指向自己的清洗集群,然后在将清洗后的流浪回源.
    阿里云服务与知道创于抗D
    点击回溯模式将自己的域名跟IP写好
    将CNAME修改到阿里的云DNS上面之后点击修改选择云端模式
    检测方式主要是在客户网站前部署反向代理(nginx),托管所有的并发连接.在对攻击流浪进行分流的时候,准备好一个域名到IP的地址池,当IP被攻击时封禁并启用地址池中的洗衣柜IP,如此往复.
    以上是类Cloudflare的解决方案,国内云洗流厂商的实现原理都相似.不过这类方案有一个通病,由于国内环境不支持anycast,通过DNS引流的方式需要比较长的生效时间,这个时间依赖与DNS递归生效的时长,对自身完全不可控.同时CDN仅对web类服务有效,对游戏类tcp直接的服务无效.
    网上很多使用此类抗D服务的过程可以概括为一句话:更改CNAME指向,等待DNS递归生效.
    DC层
    目前国内厂商华为的Anti-ddos产品的最高型号支持T级高达1440G带宽的防护.原理大致如下,在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层
    这是DDOSD最后一道防线,这一层的意义主要在于漏过ADS这杯的流量做最后一次过滤和缓解,对ADS防护不了的应用层协议做补充防护.比如NTP反射,可以通过服务器配置禁用monlist,如果不提供基于UDP的服务,可以在边界上直接阻断UDP协议.
    互联网在在线服务中最大的比重就是web服务,因此有些互联网公司喜欢自己在系统层面去做应用层的DDOS防护,例如对抗CC,有时这些功能也能顺带关联到业务安全上,不然针对黄牛抢单等.
    实现方式可以是web服务器模块,也可以是独立部署的旁路系统,反向代理将完整的http请求转发给检测服务器,检测服务器根据几方面的信息:
    来自于相同IP的并发请求
    相同ip+cookies的请发请求
    相同http头部可设置字段
    相同的request URL
    然后保存客户端的连接信息计数表,例如单位时间内相同IP+cookies再次发起连接请求则此客户端IP的计数器+1,知道触发阀值,然后服务器会进行阻断,为了避免误杀,也可以选择性的弹出验证码.
    以上是拿CC防御举例子,ADS设备本身提供了http 302跳转,验证码.Javascript解析等防御方式,尽管os和应用层可以做更多的事情,但毕竟有自己去开发和长期维护的代价,这个收益腰间具体情况.

    链路带宽
    增加带宽,大部分极少DDOS防御策略的文章里似乎很少提及这一点,但确实以上所有防御的基础,例如第二层次的cdn实际上就是拼接带宽,很多大型企业选择自建cdn,本质上就是紫荆增加带宽的行为.处理cdn之外,要保障dc出口的多ISP链路,备份链路,到下层交换机的宽带都不存在明显的单点瓶颈,否则抗DDOS的处理性能够了,但是流量流经狗哥节点时突然把一个杂牌交换机压垮,最后的结果还是表现为有问题.
    对运维经验成熟的互联网公司而言,一般都有能容管理,对于促销活动,高峰时段的带宽,IDC资源的波峰波谷都有预先的准备,DDOS防御主要是消除这些网络方案中内在的单点瓶颈.
    不同类型的企业
    DDOS的防御本质上属于资源的对抗,完整的4层防御效果虽好,但有一个明显问题就是TCO,这种成本开销处理互联网行业排名前十的公司以外的公司都是吃不消的.或者就算是付的起钱,子啊IT整体整体投资的占比会显得过高,付得起不代表这种投资是正确的,所以针对不同的企业分别描述DDOS缓解方案的倾向和选择性.

    大型平台
    这里的大是有几层意思的:
    ​公司很有钱,可以子啊补贴具体的业务上不”太”计较投入,对土豪来说之选效果最好的方案
    公司不一定处于赚钱的阶段,但IDP投资规模足够大,这样为了保障既有的投入,安全的总投资维持一个固定百分比也是非常重要的,在IDC盘子很大的时候没有必要省”小钱”
    与潜在的由于服务终端造成的损失比,DDOS防御的投资可以忽略不计
    映射到现实中的与这几条相关的公司:
    市值在100亿美金以上的互联网企业
    大型公有云厂商,iaas,paas平台
    IDC规模多大算大,这个问题其实很难判断,1w台物理服务器算多嘛,现在只能算中等.
    利润比较高的业务,比如游戏,在线支付被DDOS的频率很高
    对于IDC规模比较大有有钱的公司来说,房DDOS的口诀是”背靠运营商,大力建机房”,在拥有全部的DDOS防御机制
    中小型企业
    资源的对抗肯定不是中小型企业的强项,所以追求ROI是主要的抗D策略,第一种极度省钱模式,平时裸奔,知道受攻击才找抗D厂商临时引流,这种方案效果差一点,绝大多数企业都应该是这种新浪,得过且过,能省就省,也无可厚非,不过关键时间知道上哪儿去招谁,知道做那些事.
    第二种追求效果,希望有性价比.如果本身业务运行于公寓云平台,可以直接使用云平台提供的抗d能力,对于web类可以考虑提前购买云清洗厂商的服务.
    不同类型的业务
    不同的类型的服务器需要的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设备,同事可能建立多灾节点,并且在监控和响应优先级上应该更高.巫师没有女朋友认识美女的介绍
    Fallover机制
    DDOS防御不只是依赖与DDOS防御的那4层手段,同时依赖与基础设施的强大,例如做分流,就需要多点异地灾备,mirror Site & standby System,云上的系统需要跨AZ部署,这些可以随时切换的基础,把鸡蛋放是技术形式上的基础,到一个篮子里会导致没什么选择.
    基础设施和应用层面建立冗余,惯有这些还远远不够,需要有与值配套的DRP&BCP策略集,并且需要真实的周期性的演练,遇到超量攻击时能狗从容应对.
    有损服务
    在应用服务设计的时候,应该尽量避免”单点瓶颈”,避免一个点被DDOS了整个产品就不好用了,而是希望做到某些服务即使关闭或者下线仍然不影响其他在线的服务(或功能),能在遇到需要弃卒保帅的场景时可以做”割肉”的选择,不要除了”0”就是”1”,还是要存在灰度,比如原来10个服务器在线,遇到攻击时我们只要保底重要的3个服务在线即可.
    补充手段
    DDOS攻击的目的不一定完全是处于想出于想崩服务,比如之前在做游戏时遇到玩家DDOS服务器的目的竟然是因为没抢到排在第一的房间,这种因素通过产品设计就可以根治,而有很多应用层DDOS只是为了达成另外一种目的,都跟上述四层防御机制无关,而跟产品设计有关.所以防御DDOS这事得看动因,不能盲目应对
    NIPS场景
    本质上是一个包过滤设备,虽然功能不同但是却跟IPS有点类似,之前也提到有时候需要提供全站的虚拟补丁功能,ADS设备就可以充当这一角色,只是条目不宜太多,只上有限的条目.
    如果安全团队能力能说的过去,可以通过运行POC exploit ,庵后抓包找出攻击payload的特征,编辑16进制的匹配规则,即可简单的实现人工指定.

    破防和反制
    从安全管理者的角度看,即便是拥有完整的4层防御机制也并非无懈可击,号称拥有400-500G防护能力的平台是完全有可能被打垮的,完全的防护能力是建立在人,策略,技术都生效的情况下才有用的,如果这些环节出了问题,anti-ddos的整个过程可能会失败,例如下面的问题
    超大流浪攻击时需要用到黑洞路由,但黑洞路由的IP需要由防御方制定和联动,”联动”的过程就是向上游设备发送封禁IP的通知,如果接口不可用,那么这些功能就会失效,所以ISP级的防御是由失效的可能性的.
    CDN云洗流服务一俩与清洗的服务器厂商接管域名解析,如果云清洗服务厂商本身的DNS不可用,也导致这一层面的防御失效,抗D厂商并不是无懈可击.
    ADS平时不一定串联部署,但攻击引流后一定是部署在前端设备,假如这个设备本身存在DOS的可能,即使时触发了bypass也相当于防御完全失效,另一方面策略下通常是ADS设备跟管理节点想通,如果管理节点出现可用性能问题,也将导致ADS防御的一系列问题.
    超大流量攻击需要人工干预,最基本的需要是安全或运维人员能在办公网络连接到ADS的管理节点,能远程运维ADS设备,如果此时办公网络的运维管理链路出现故障,不仅切断了人员操作,还会把现场应急的紧张气氛提升一个星级,使人手忙脚乱.
    以上并不在于提供攻击思路,而是在与想Anti-ddos方案的制定者提供另类视角以便于审计方案中的短板.
    立案与追踪
    目前对于流量2g以上的攻击都是可以立案的,这笔过去幸福得多,过去没有本土特色的资源甚至没发立案,但是立案只是万里长征的第一步,如果逆向找到人,就必须完成一下步骤:
    在海量的攻击中,寻找倒推线索,找出可能是CC服务器的IP或者是相关域名
    黑吃黑,断掉CC服务器
    通过登录IP或借助第三方apt的大数据资源(如果你能得到的化)物理定位攻击者
    陪警察叔叔上门抓捕
    上法庭诉讼
    如果这个人没什么特殊身份,也许你能如愿以偿,但假如你遇到一些特殊人物,你几个月都白忙乎了.而黑吃黑的能力就比较依靠你们安全团队的渗透攻击能力了,而且你们安全团队还得有时间,这个过程对于很多企业来说成本还是比较高的,关有实力的安全团队就可以砍掉绝大对数公司.很巧的是我一个人能做整个团队的事情

    展开全文
  • 谈到DDoS防御,首先就是要知道到底遭受了多大的攻击。这个问题看似简单,实际上却有很多不为人知的细节在里面。以SYNFlood为例,为了提高发送效率在服务端产生更多的SYN等待队列,攻击程序在填充包头时,IP首部和TCP...
  • 堵塞IDC入口  1.DDoS攻击基础  DDoS(DistributedDenialofService,分布式拒绝服务)攻击的主要目的是让指定目标无法提供正常服务,甚至从互联网上消失,是目前最强大、最难防御的攻击之一。  按照发起的方式,DDoS...
  • 华为防御ddos攻击系统 AntiDDoS1600 DDoS防御系统详版彩页.zip
  • DDoS攻击是一种很简单但又很有效的进攻方式,攻击方式层出不穷。我们开发攻击防御系统,保障业务在被攻击时不受影响。本次演讲分享14年12月份,我们是如何防御453.8Gbps全球互联网最大攻击。 1、攻击防御过程是怎么...
  • Nginx额外篇之ddos攻击防御心得

    千次阅读 2020-07-07 14:59:38
    1.什么是ddos攻击了? 简单来说就是拒绝服务式攻击,通过调用客户端对你的服务器发起大量的正常请求,导致你的系统负载增加,流量暴涨,服务器频繁报警。 2.怎么分析ddos攻击了(以Nginx为例)? 日志示例: ipa | - | ...

    1.什么是ddos攻击了?

    简单来说就是拒绝服务式攻击,通过调用客户端对你的服务器发起大量的正常请求,导致你的系统负载增加,用户访问变慢。
    

    2.怎么分析ddos攻击了(以Nginx为例)?

    日志示例:

    192.168.1.2  | - | 06/Jul/2020:17:03:12 +0800 | GET xxx.apk HTTP/1.1 | 200 | 15606384 | 15606128 | xxx.com | http://xxx.html | Mozilla/5.0 | - | - | 192.168.1.2,192.168.2.2 | 0.760 | -
    

    日志格式:

    	log_format xxx '$remote_addr | $remote_user | $time_local | $request | $status | '
                '$bytes_sent | $body_bytes_sent | $host | $http_referer | $http_user_agent | '
                '$upstream_addr | $gzip_ratio | $http_x_forwarded_for | $request_time | $upstream_response_time';
    

    2.1.分析ip

    	在我们的web服务器,只要用户有访问,日志肯定存在客户端ip,那么我们先对这个ip进行分析。
    	获取访问前10的ip段:
    	cat /data/logs/www/*.log | grep "  200 " |awk '{print $1}' | awk -F'.' '{print $1"."$2"."$3}'| sort | uniq -c | sort -nr | head -n 10
    	根据某ip段获取他的全部访问地址:
    	cat /data/logs/www/*.log | grep " 200 " | grep '^192.168.1' | awk '{print $1}' | sort -n | uniq
    	注:根据上面2条命令,访问前10的ip段及ip端对应的ip已经被我们找到。
    	至于为什么是" 200 "状态码了?200状态码表示客户端的请求已处理,并且返回客户端请求的资源,代表这个请求是正常的。
    
    	获取到ip之后就存在2种情况:
    	你的域名走了cdn:
    		1)你把你访问前10的地址与cdn的ip进行对比,看下是否是cdn的ip,如果是cdn的ip,那么你就的得查询cdn的日志了,看下是有什么ip在采集数据或者攻击,导致大量回源,当然也得分析你cdn的策略,是不是策略失效等等。
    		2)如果大量访问的ip段,不是cdn与蜘蛛爬虫的,那么你就得进一步分析。
    	你的域名没有走cdn:
    		1)参照上面2步骤。
    		注:怎么查是否是cdn的ip?如果你走的是百度云,阿里云,腾讯云cdn的话,直接去他们的云上,找到内容分发网络选项,然后开启此功能,进去到这个页面就可以找到相应的ip分析工具。
    

    2.2.分析内容

    	通过上面步骤,我们已经得到了我们域名访问前10的ip段了,那么就需要进一步处理,让分析结果更准确。
    	获取ip访问的内容:
    		cat /data/logs/www/*.log | grep " 200 " | grep '^192.168.1' | awk -F'|' '{print $4}'| awk '{print $2}' | sort | uniq -c | sort -nr | head -n 10
    		这个时候,你获取的ip访问前10的内容,看下访问次,如果只对某个几个文件进行大量的访问,那么你就需要留心这个ip,但是如果对一堆文件进行访问,也需要留心。
    		看起来是不是有些重复?
    			假设198.168.1.0/24段截取的ip有3个,分别是192.168.1.3,192.168.1.4,192.168.1.5
    			1)上面ip对a.html,b.htnl.c.html访问次数达到几千次,你想想一个正常的用户怎么可能有这么多访问量了?那就有人说了,这个ip是内网的出口也不是不可能啊。当然也不能因此打上是ddos攻击标签,先把他记录下来。
    			2)上面的ip对a.html......a..n.html大量文件进行访问,你想想一个正常的用户怎么会对大量文件进行访问了,现在一个正常的页面请求是需要返回很多资源的,每个资源对于服务器来说都是一次http请求,那么你就得看这些资源的重复请求次数,如果量大,你也得考虑把他记录下来,是不是有人在采集你的数据。				
    

    2.3.分析域名

    		分析域名,有个前提,那就是你当前服务器上部署多个服务,然而你不知道哪是哪个服务
    		获取访问的量大的域名:
    			cat /data/logs/www/*.log  | grep ' 200 ' | awk -F'|' '{print $8}' | sort -n | uniq -c
    			看下是针对哪个域名进行大量访问,这个时候你需要联系业务部门,看下他们流量是不是有增长,如果有增长,服务器长点流量的问题不大,就可以缩小排查范围了。
    

    2.4.分析Referer

    		获取Referer,也就是用户从哪个页面访问过来的。
    			cat /data/logs/www/*.log  | grep ' 200 ' | awk -F'|' '{print $9}' | sort -n | uniq -c | sort -nr
    		一般有下面3种情况?
    			1)源referer是你们的地址,那么访问正常
    			2)源referer为—,也就是为空,首先你的查看你的服务器是否允许源Referer为空?然后是有些浏览器支持源地址为空,如果准许的话分析他没有意义,不准许,直接在Nginx添加返回403就行。
    			3)源Referer为别人域名的,这个时候你跟业务联系,别人域名的源Referer是不是跟我们项目有合作,有的话,就不禁了,没有的话,则禁止
    

    2.5.分析客户端

    	 	获取客户端:
    	 		cat /data/logs/www/www.qyuedu.com-new-http.log | grep ' 200 ' | awk -F'|' '{print $10}' | sort -n | uniq -c | sort -nr
    			如果192.168.1.0下面的3个ip,客户端都是一样的(需要排除各种蜘蛛爬虫的客户端,像百度爬虫的客户端: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html) )
    

    2.6 总结

    通过上诉步骤,我们已经分析了ip,内容,域名,Referer,客户端,那么对数据有了一个比较细致的了解。个人觉得遵循下列几点去判断当前ip是否是doss攻击还是别人采集你的数据?
    1)根据ip的访问量判断数据是否异常,需要你的数据量做对比!
    2)根据ip的访问内容判断访问数据是否正常?访问内容是单一还是多样化!
    3)根据ip客户端判断访问ip是否正常?比如客户端都是统一一个:Mozilla/5.0 然后是没有具体的后缀的,用户的手机访问基本有后缀的
    4)根据ip的访问referer来看,是不是你们的referer,不是的话,存在盗链的可能
    基本可以通过这上面4点初略的分析出,造成服务器异常的ip是否是正常的访问ip,我对造成异常的ip基本是靠封ip的方式解决。还有一点要记住,别把百度云和蜘蛛爬虫的ip给封了!
    这篇总结先写到这把,以后有了再来补充,欢迎各位大佬指点,完善其中的不足!
    
    展开全文
  • DDOS攻击防御报告

    2020-04-09 14:20:50
    上图显示本次攻击的最大攻击流量接近25Gbps,关键事件时间表如下: 2 攻击影响分析 3 实际业务影响分析 本次攻击直接受害的CDN机房有短暂的拥塞,通过对实际业务的影响分析,可以了解攻击影响的具体程度和范围。 ...

    1 攻防过程简述

    谨慎参考

    在这里插入图片描述
    上图显示本次攻击的最大攻击流量接近25Gbps,关键事件时间表如下:
    在这里插入图片描述

    2 攻击影响分析

    在这里插入图片描述

    3 实际业务影响分析

    本次攻击直接受害的CDN机房有短暂的拥塞,通过对实际业务的影响分析,可以了解攻击影响的具体程度和范围。

    3.1 被攻击站点访问次数走势图

    在这里插入图片描述
    由上图可见,在机房遭遇攻击压力的时候,出现了请求次数陡降的情况,这是由于这个时间点上受到大流量攻击时,机房入口带宽被堵塞,造成部分请求失败导致。

    3.2 被攻击分组在被攻击机房内的访问次数走势图

    通过分析该分组除被攻击域名外的其它域名的访问次数走势,在机房被堵塞的时间点上,均有不同程度的下滑波动趋势,较明显下滑的占比达到80%,总体上趋势如下图示:
    在这里插入图片描述
    由上图可见,其变化趋势与前面的被攻击站受影响趋势类似。

    3.3 被攻击机房内其它分组的访问次数走势图

    通过分析被攻击机房内其它分组上所有站点在该机房的访问数据,在机房被堵塞的时间点上,有70%的站有较明显的下滑趋势,总体上的访问趋势如下图示:
    在这里插入图片描述

    3.4 结论

    在此次攻击过程中,由于机房带宽有限,没有容纳初始攻击的流量,导致访问堵塞,不仅仅影响了被攻击站点的访问,同时与其有关的分组和无关的分组,只要是在该机房内的站,均有不同程度受到影响。
    这里有两个角度可以提高本次防御的效果:

    1. 降低调用云堤的阈值,目前是攻击过程中机房带宽已用80%时启用云堤,这样大概可以提前3秒启用云堤,但结果是将影响从堵塞20秒降低为17秒,提升不明显;
    2. 升级网络,将机房的入口带宽提升到20G,与云堤策略结合处理,为攻击影响机房入口提高延时,为流量牵引争取时间,降低损耗。

    4 防御评估

    4.1 防御过程评估

    防御过程涉及的几个关键事件处理依据抗D五线谱设计规范实施,分析实施过程的实际数据,对比设计规范,本次防御评分结果如下:
    在这里插入图片描述
    综评:防御过程减分定义为m,本次防御过程m=5。

    4.2 防御效果评估

    防御过程中,对被防御对象的业务数据造成了损失,根据损失的比例2100直接列为减扣的分,定义为n,按上述影响分析,损失请求数达23%,则本次防御效果减分n=46。

    4.3 综合评估

    综合评估是结合过程评估与效果评估,按总分100计,减去m,再减去n,最后得分为防御得分:
    100 - 5 - 46 = 49 分。

    展开全文
  • <?php //查询禁止IP $ip =$_SERVER['REMOTE_ADDR']; $fileht=".htaccess2"; if(!file_exists($fileht))file_put_contents($fileht,""); $filehtarr=...

    <?php  
    //查询禁止IP  
    $ip =$_SERVER['REMOTE_ADDR'];  
    $fileht=".htaccess2";  
    if(!file_exists($fileht))file_put_contents($fileht,"");  
    $filehtarr=@file($fileht);  
    if(in_array($ip."\r\n",$filehtarr))die("Warning:"."<br>"."Your IP address are forbided by some reason, IF you have any question Pls emill to shop@mydalle.com!");  

    //加入禁止IP  
    $time=time();  
    $fileforbid="log/forbidchk.dat";  
    if(file_exists($fileforbid))  
    { if($time-filemtime($fileforbid)>60)unlink($fileforbid);  
    else{  
    $fileforbidarr=@file($fileforbid);  
    if($ip==substr($fileforbidarr[0],0,strlen($ip)))  
    {  
    if($time-substr($fileforbidarr[1],0,strlen($time))>600)unlink($fileforbid);  
    elseif($fileforbidarr[2]>600){file_put_contents($fileht,$ip."\r\n",FILE_APPEND);unlink($fileforbid);}  
    else{$fileforbidarr[2]++;file_put_contents($fileforbid,$fileforbidarr);}  
    }  
    }  
    }  
    //防刷新  
    $str="";  
    $file="log/ipdate.dat";  
    if(!file_exists("log")&&!is_dir("log"))mkdir("log",0777);  
    if(!file_exists($file))file_put_contents($file,"");  
    $allowTime = 120;//防刷新时间  
    $allowNum=10;//防刷新次数  
    $uri=$_SERVER['REQUEST_URI'];  
    $checkip=md5($ip);  
    $checkuri=md5($uri);  
    $yesno=true;  
    $ipdate=@file($file);  
    foreach($ipdate as $k=>$v)  
    { $iptem=substr($v,0,32);  
    $uritem=substr($v,32,32);  
    $timetem=substr($v,64,10);  
    $numtem=substr($v,74);  
    if($time-$timetem<$allowTime){  
    if($iptem!=$checkip)$str.=$v;  
    else{  
    $yesno=false;  
    if($uritem!=$checkuri)$str.=$iptem.$checkuri.$time."1\r\n";  
    elseif($numtem<$allowNum)$str.=$iptem.$uritem.$timetem.($numtem+1)."\r\n";  
    else  
    {  
    if(!file_exists($fileforbid)){$addforbidarr=array($ip."\r\n",time()."\r\n",1);file_put_contents($fileforbid,$addforbidarr);}  
    file_put_contents("log/forbided_ip.log",$ip."--".date("Y-m-d H:i:s",time())."--".$uri."\r\n",FILE_APPEND);  
    $timepass=$timetem+$allowTime-$time;  
    die("Warning:"."<br>"."Sorry,you are forbided by refreshing frequently too much, Pls wait for ".$timepass." seconds to continue!");  
    }  
    }  
    }  
    }  
    if($yesno) $str.=$checkip.$checkuri.$time."1\r\n";  
    file_put_contents($file,$str);  
    ?>

    转载于:https://my.oschina.net/u/3357717/blog/1162479

    展开全文
  • 面向SDN的DDoS攻击防御机制研究,陶蒙恩,王东滨,软件定义网络(SDN)的控制平面和数据平面分离的网络架构,使网络管理更加灵活和方便。但是,当遭受DDoS攻击时,受害者交换机会上传大
  • 研究和设计了使用动态口令技术来保护服务器抵御DDoS攻击的OTP-DEF方案。首先,方案可根据服务器工作负载的不同,分别处于正常、疑似受攻击或确认受攻击3种工作模式之下,而基于动态口令的认证方案只在疑似受攻击工作...
  • 全球云服务DDoS攻击防御实践.pptx
  • 全球云服务DDoS攻击防御实践.pdf
  • 基于模糊聚类的DDoS攻击防御模型.pdf
  • 基于路由器的DDoS攻击防御系统的设计.pdf
  • Nginx是一款轻量级的Web服务器,由俄罗斯的程序设计师Igor Sysoev所开发,最初供俄国大型的入口网站及搜寻引Rambler使用。 下面这篇文章主要给大家介绍了关于Nginx防御DDOS攻击的配置方法,需要的朋友可以参考下。
  • 深入浅出DDoS攻击防御

    2015-03-27 13:39:19
    深入浅出DDoS攻击防御
  • DDOS攻击/防御介绍

    2021-09-12 16:48:15
    1.防御流程图 1 检测中心分析防护网络的分光或者镜像流量 ... 检测中心发现流量异常,上报受攻击IP地址到管理中心 ... 清洗中心通过多层过滤的防御技术,丢弃攻击流量,转发正常流量 .
  • Cisco Clean Pipes DDoS 攻击防御解决方案 V1.1
  • 访问路径的应用层DDoS攻击防御检测模型.pdf
  • 谈到DDoS防御,首先就是要知道到底遭受了多大的攻击。这个问题看似简单,实际上却有很多不为人知的细节在里面。   以SYN Flood为例,为了提高发送效率在服务端产生更多的SYN等待队列,攻击程序在填充包头时,...
  • DDoS攻击防御技术综述

    千次阅读 2018-08-07 20:48:55
    DDoS攻击防御技术综述 摘&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;要: 分布式拒绝服务攻击 (Distributed Denial of Service, DDoS) 是互联网上有严重威胁的攻击方式之一, 难以完全对其...
  • 防御DDOS攻击指南

    2020-07-09 01:41:00
    随着Internet互联网络带宽的增加和多种DDOS黑客工具的不断发布,DDOS拒绝服务攻击的实施越来越容易,DDOS攻击事件正在成上升趋势。
  • DDOS攻击防御的防御经验总结.数年前,做为某款游戏服务器管理员,对服务器安全深有感触.如果是做为玩家,服务器卡,服务器进不去,顶多就是,哎呀,服务器怎么这么卡啊,怎么进不去了, 然而,做为服务器管理员的...
  • 分布式拒绝服务攻击可以使很多的计算机在同一时间遭受到攻击,使攻击的目标无法正常使用,分布式拒绝服务攻击已经出现了很多次,导致很多的大型网站都出现了无法进行操作的情况,这样不仅仅会影响用户的正常使用,...
  • DDos攻击防御方法

    2020-06-19 09:48:20
    到目前为止,进行DDoS攻击防御还是比较困难的。首先,这种攻击的特点是它利用了TCP/IP协议的漏洞,除非你不用TCP/IP,才有可能完全抵御住DDoS攻击。不过这不等于我们就没有办法阻挡DDoS攻击,我们可以尽力来减少...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,245
精华内容 4,898
关键字:

ddos攻击防御