发布新日志

  • 输入验证攻击

    2009-05-06 16:30:12

    一.缓冲区溢出
    二.转义攻击
    三.脚本攻击
    四.边界检查
    五.操纵应用程序行为
    六.SQL注入和数据存储攻击
    七.执行命令
    八.编码滥用
    九.PHP全局变量
  • SuperScan使用详解

    2009-05-06 15:48:10

    http://tieba.baidu.com/f?kz=77683947
  • SYN flood网络攻击的原理及其防御方法(转)

    2009-05-05 23:15:29

    SYN flood网络攻击的原理及其防御方法

    作者: 来源: 冰盾科技 日期: 2006-8-6 9:38

    摘要 

      介绍了SYN Flood攻击的基本原理,详细地描述了目前几种比较有效的两种防御措施:SYN-cookie技术和地址状态监控技术。

    关键词   SYN Flood攻击  拒绝服务攻击  SYN cookie

      1 SYN Flood攻击介绍:

      拒绝服务攻击(Denial of Service,DoS)是目前比较有效而又非常难于防御的一种网络攻击方式,它的目的就是使服务器不能够为正常访问的用户提供服务。所以,DoS对一些紧密依靠互联网开展业务的企业和组织带来了致命的威胁。

      SYN Flood是最为有效和流行的一种DoS攻击形式。它利用TCP三次握手协议的缺陷,向目标主机发送大量的伪造源地址的SYN连接请求,消耗目标主机的资源,从而不能够为正常用户提供服务。

      1.1 TCP连接建立的过程

      要掌握SYN Flood攻击的基本原理,必须先介绍TCP的三次握手机制。
      TCP三次握手过程如下:
      1)客户端向服务器端发送一个SYN置位的TCP报文,包含客户端使用的端口号和初始序列号x;

      2)服务器端收到客户端发送来的SYN报文后,向客户端发送一个SYN和ACK都置位的TCP报文,包含确认号为x+1和服务器的初始序列号y;

      3)


    TCP客户端
    客户端端口
    (1024-65535)
     
    TCP服务器端

    服务器端口
    (1-1023)
    SYN
    SYN/ACK
    ACK

      客户端收到服务器返回的SYN+ACK报文后,向服务器返回一个确认号为y+1序号为x+1的ACK报文,一个标准的TCP连接完成。如图1所示:

    body.clientHeight)this.width=body.clientHeight" border=0>

     

    1.2 攻击原理

      在SYN Flood攻击中,黑客机器向受害主机发送大量伪造源地址的TCP SYN报文,受害主机分配必要的资源,然后向源地址返回SYN+ACK包,并等待源端返回ACK包,如图2所示。由于源地址是伪造的,所以源端永远都不会返回ACK报文,受害主机继续发送SYN+ACK包,并将半连接放入端口的积压队列中,虽然一般的主机都有超时机制和默认的重传次数,但怯捎诙丝诘陌肓佣恿械某ざ仁怯邢薜模绻欢系南蚴芎χ骰⑺痛罅康腡CP SYN报文,半连接队列就会很快填满,服务器拒绝新的连接,将导致该端口无法响应其他机器进行的连接请求,最终使受害主机的资源耗尽。

    body.clientHeight)this.width=body.clientHeight" border=0>

     TCP客户端
    客户端端口
    (1024-65535)
     
    TCP服务器端
     
    服务器端口
    (1-1023)
    SYN
    SYN/ACK
     
    伪造源地址

      2  几种防御技术

      SYN Flood攻击给互联网造成重大影响后,针对如何防御SYN Flood攻击出现了几种比较有效的技术。

    2.1   SYN-cookie技术

      一般情况下,当服务器收到一个TCP SYN报文后,马上为该连接请求分配缓冲区,然后返回一个SYN+ACK报文,这时形成一个半连接。SYN Flood正是利用了这一点,发送大量的伪造源地址的SYN连接请求,而不完成连接。这样就大量的消耗的服务器的资源。

      SYN-cookie技术针对标准TCP连接建立过程资源分配上的这一缺陷,改变了资源分配的策略。当服务器收到一个SYN报文后,不立即分配缓冲区,而是利用连接的信息生成一个cookie,并将这个cookie作为将要返回的SYN+ACK报文的初始序列号。当客户端返回一个ACK报文时,根据包头信息计算cookie,与返回的确认序列号(初始的序列号+1)的前24位进行对比,如果相同,则是一个正常连接,然后,分配资源,建立连接。

      该技术的巧妙之点在于避免了在连接信息未完全到达前进行资源分配,使SYN Flood攻击的资源消耗失效。实现的关键之处在于cookie的计算。cookie的计算应该做到包含本次连接的状态信息,使攻击者不能伪造cookie。cookie的计算过程如下:

      1)服务器收到一个SYN包后,计算一个消息摘要mac:
    mac = MAC(A,k);
    MAC是密码学中的一个消息认证码函数,也就是满足某种安全性质的带密钥的hash函数,它能够提供cookie计算中需要的安全性。
    A为客户和服务器双方的IP地址和端口号以及参数t的串联组合:
    A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t
    K为服务器独有的密钥;
    时间参数t为32比特长的时间计数器,每64秒加1;

      2)生成cookie:
    cookie = mac(0:24):表示取mac值的第0到24比特位;

      3)设置将要返回的SYN+ACK报文的初始序列号,设置过程如下:
        i.              高24位用cookie代替;
       ii.              接下来的3比特位用客户要求的最大报文长度MMS代替;
       iii.              最后5比特位为t mod 32。
      客户端收到来自服务器SYN+ACK报文后,返回一个ACK报文,这个ACK报文将带一个cookie(确认号为服务器发送过来的SYN ACK报文的初始序列号加1,所以不影响高24位),在服务器端重新计算cookie,与确认号的前24位比较,如果相同,则说明未被修改,连接合法,然后,服务器完成连接的建立过程。

      SYN-cookie技术由于在连接建立过程中不需要在服务器端保存任何信息,实现了无状态的三次握手,从而有效的防御了SYN Flood攻击。但是该方法也存在一些弱点。由于cookie的计算只涉及了包头的部分信心,在连接建立过程中不在服务器端保存任何信息,所以失去了协议的许多功能,比如,超时重传。此外,由于计算cookie有一定的运算量,增加了连接建立的延迟时间,因此,SYN-cookie技术不能作为高性能服务器的防御手段。通常采用动态资源分配机制,当分配了一定的资源后再采用cookie技术,Linux就是这样实现的。还有一个问题是,当我们避免了SYN Flood攻击的同时,同时也提供了另一种拒绝服务攻击方式,攻击者发送大量的ACK报文,使服务器忙于计算验证。尽管如此,在预防SYN Flood攻击方面,SYN-cookie技术仍然是一种有效的技术。

    2.2  地址状态监控的解决方法

      地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控,并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。

    每个源地址都有一个状态与之对应,总共有四种状态:
    初态:任何源地址刚开始的状态;
    NEW状态:第一次出现或出现多次也不能断定存在的源地址的状态;
    GOOD状态:断定存在的源地址所处的状态;
    BAD状态:源地址不存在或不可达时所处的状态。
    具体的动作和状态转换根据TCP头中的位码值决定:

      1)监听到SYN包,如果源地址是第一次出现,则置该源地址的状态为NEW状态;如果是NEW状态或BAD状态;则将该包的RST位置1然后重新发出去,如果是GOOD状态不作任何处理。

      2)监听到ACK或RST包,如果源地址的状态为NEW状态,则转为GOOD状态;如果是GOOD状态则不变;如果是BAD状态则转为NEW状态;如果是BAD状态则转为NEW状态。

      3)监听到从服务器来的SYN ACK报文(目的地址为addr),表明服务器已经为从addr发来的连接请求建立了一个半连接,为防止建立的半连接过多,向服务器发送一个ACK包,建立连接,同时,开始计时,如果超时,还未收到ACK报文,证明addr不可达,如果此时addr的状态为GOOD则转为NEW状态;如果addr的状态为NEW状态则转为BAD状态;如果为addr的状态为BAD状态则不变。
    状态的转换图如图3所示:

    body.clientHeight)this.width=body.clientHeight" border=0>

    初态
    GOOD
    NEW
    BAD
    ACK/RST
    SYN
    ACK/RST
     
    ACK包确认超时
    ACK/RST
     
    ACK包确认超时

    下面分析一下基于地址状态监控的方法如何能够防御SYN Flood攻击。

      1)对于一个伪造源地址的SYN报文,若源地址第一次出现,则源地址的状态为NEW状态,当监听到服务器的SYN+ACK报文,表明服务器已经为该源地址的连接请求建立了半连接。此时,监控程序代源地址发送一个ACK报文完成连接。这样,半连接队列中的半连接数不是很多。计时器开始计时,由于源地址是伪造的,所以不会收到ACK报文,超时后,监控程序发送RST数据包,服务器释放该连接,该源地址的状态转为BAD状态。之后,对于每一个来自该源地址的SYN报文,监控程序都会主动发送一个RST报文。

      2)对于一个合法的SYN报文,若源地址第一次出现,则源地址的状态为NEW状态,服务器响应请求,发送SYN+ACK报文,监控程序发送ACK报文,连接建立完毕。之后,来自客户端的ACK很快会到达,该源地址的状态转为GOOD状态。服务器可以很好的处理重复到达的ACK包。
    从以上分析可以看出,基于监控的方法可以很好的防御SYN Flood攻击,而不影响正常用户的连接。

      3   小结

      本文介绍了SYN Flood攻击的基本原理,然后详细描述了两种比较有效和方便实施的防御方法:SYN-cookie技术和基于监控的源地址状态技术。SYN-cookie技术实现了无状态的握手,避免了SYN Flood的资源消耗。基于监控的源地址状态技术能够对每一个连接服务器的IP地址的状态进行监控,主动采取措施避免SYN Flood攻击的影响。这两种技术是目前所有的防御SYN Flood攻击的最为成熟和可行的技术。

  • Fraggle攻击模式

    2009-05-05 23:13:39

    Fraggle攻击Smurf攻击作了简单的修改,使用的是UDP应答消息而非ICMP
      防御:在防火墙上过滤掉UDP应答消息。
      已CISCO的ASA为例
      class-map fraggle -------------定义端口号和协议号
      match port udp eq echo
      policy-map fraggle --------------策略匹配,设置最大连接数为1
      class fraggle
      set connection conn-max 1
      service-policy fraggle interface inside ----------------在接口上应用
  • Smurf攻击模型

    2009-05-05 22:57:53

    一个简单的Smurf攻击原理就是:通过使用将回复地址设置成受害网络的广播地址的ICMP应答请求(ping)数据包来淹没受害主机的方式进行。最终导致该网络的所有主机都对此ICMP应答请求作出答复,导致网络阻塞。它比ping of death洪水的流量高出1或2个数量级。更加复杂的Smurf将源地址改为第三方的受害者,最终导致第三方崩溃。

      利用IP路由漏洞的攻击方法。攻击通常分为以下五步: 

       1>黑客锁定一个被攻击的主机(通常是一些Web服务器); 
       2>黑客寻找可做为中间代理的站点,用来对攻击实施放大(通常会选择多个,以便更好地隐藏自己,伪装攻击); 
       3>黑客给中间代理站点的广播地址发送大量的ICMP包(主要是指Ping命令的回应包)。这些数据包全都以被攻击的主机的IP地址做为IP包的源地址; 
       4>中间代理向其所在的子网上的所有主机发送源IP地址欺骗的数据包; 
       5>中间代理主机对被攻击的网络进行响应。

        这时你可能会问,“一个小小的Ping包是如何使一个网站瘫痪的?”。在这儿举例解释一下。假设黑客拥有调制解调器,或者其它的能快速上网方式,能以1Mbps的速度向中间代理机器发送ICMP数据包;再假设中间代理站点有150台主机对这些ICMP包做出了反应。这样,一下子就有150Mbps的攻击数据从中间代理拥向被攻击的主机。黑客可以控制这个过程直到他自己连接到中间代理机器上,并且控制中间代理持续向被攻击主机发送ICMP包。

  • 拒绝服务攻击

    2009-05-05 22:55:20

       拒绝服务攻击即攻击者想办法让目标机器停止提供服务或资源访问,是黑客常用的攻击手段之一。这些资源包括磁盘空间、内存、进程甚至网络带宽,从而阻止正常用户的访问。其实对网络带宽进行的消耗性攻击只是拒绝服务攻击的一小部分,只要能够对目标造成麻烦,使某些服务被暂停甚至主机死机,都属于拒绝服务攻击。拒绝服务攻击问题也一直得不到合理的解决,究其原因是因为这是由于网络协议本身的安全缺陷造成的,从而拒绝服务攻击也成为了攻击者的终极手法。攻击者进行拒绝服务攻击,实际上让服务器实现两种效果:一是迫使服务器的缓冲区满,不接收新的请求;二是使用IP欺骗,迫使服务器把合法用户的连接复位,影响合法用户的连接。
      拒绝服务攻击的原理
      1.SYN Flood
      SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(Distributed Denial Of Service分布式拒绝服务攻击)的方式之一,这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,使被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。
      SYN Flood攻击的过程在TCP协议中被称为三次握手(Three-way Handshake),而SYN Flood拒绝服务攻击就是通过三次握手而实现的。
      (1) 攻击者向被攻击服务器发送一个包含SYN标志的TCP报文,SYN(Synchronize)即同步报文。同步报文会指明客户端使用的端口以及TCP连接的初始序号。这时同被攻击服务器建立了第一次握手。
      (2) 受害服务器在收到攻击者的SYN报文后,将返回一个SYN+ACK的报文,表示攻击者的请求被接受,同时TCP序号被加一,ACK(Acknowledgment)即确认,这样就同被攻击服务器建立了第二次握手。
      (3) 攻击者也返回一个确认报文ACK给受害服务器,同样TCP序列号被加一,到此一个TCP连接完成,三次握手完成。
      具体原理是:TCP连接的三次握手中,假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接。这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒~2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况(伪造IP地址),服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源。即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃—— 即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况就称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。
      SYN COOKIE 防火墙是SYN cookie的一个扩展,SYN cookie是建立在TCP堆栈上的,他为linux操作系统提供保护。SYN cookie防火墙是linux的 一大特色,你可以使用一个防火墙来保护你的网络以避免遭受SYN洪水攻击。
      下面是SYN cookie防火墙的原理
      client firewall server
      ------ ---------- ------
      1. SYN----------- - - - - - - - - - ->
      2. <------------SYN-ACK(cookie)
      3. ACK----------- - - - - - - - - - ->
      4. - - - - - - -SYN--------------->
      5. <- - - - - - - - - ------------SYN-ACK
      6. - - - - - - -ACK--------------->
      7. -----------> relay the ------->
      <----------- connection <-------
      1:一个SYN包从C发送到S
      2:防火墙在这里扮演了S的角色来回应一个带SYN cookie的SYN-ACK包给C
      3:C发送ACK包,接着防火墙和C的连接就建立了。
      4:防火墙这个时候扮演C的角色发送一个SYN给S
      5:S返回一个SYN给C
      6:防火墙扮演C发送一个ACK确认包给S,这个时候防火墙和S的连接也就建立了
      7:防火墙转发C和S间的数据
      如果系统遭受SYN Flood,那么第三步就不会有,而且无论在防火墙还是S都不会收到相应在第一步的SYN包,所以我们就击退了这次SYN洪水攻 击。
      2.IP欺骗DOS攻击
      这种攻击利用RST位来实现。假设现在有一个合法用户(61.61.61.61)已经同服务器建立了正常的连接,攻击者构造攻击的TCP数据,伪装自己的IP为61.61.61.61,并向服务器发送一个带有RST位的TCP数据段。服务器接收到这样的数据后,认为从61.61.61.61发送的连接有错误,就会清空缓冲区中建立好的连接。这时,如果合法用户61.61.61.61再发送合法数据,服务器就已经没有这样的连接了,该用户就必须从新开始建立连接。攻击时,攻击者会伪造大量的IP地址,向目标发送RST数据,使服务器不对合法用户服务,从而实现了对受害服务器的拒绝服务攻击。
      3. UDP洪水攻击
      攻击者利用简单的TCP/IP服务,如Chargen和Echo来传送毫无用处的占满带宽的数据。通过伪造与某一主机的Chargen服务之间的一次的UDP连接,回复地址指向开着Echo服务的一台主机,这样就生成在两台主机之间存在很多的无用数据流,这些无用数据流就会导致带宽的服务攻击。
      4. Ping洪流攻击
      由于在早期的阶段,路由器对包的最大尺寸都有限制。许多操作系统对TCP/IP栈的实现在ICMP包上都是规定64KB,并且在对包的标题头进行读取之后,要根据该标题头里包含的信息来为有效载荷生成缓冲区。当产生畸形的,声称自己的尺寸超过ICMP上限的包也就是加载的尺寸超过64K上限时,就会出现内存分配错误,导致TCP/IP堆栈崩溃,致使接受方死机。
      5. 泪滴(teardrop)攻击
      泪滴攻击是利用在TCP/IP堆栈中实现信任IP碎片中的包的标题头所包含的信息来实现自己的攻击。IP分段含有指明该分段所包含的是原包的哪一段的信息,某些TCP/IP(包括service pack 4以前的NT)在收到含有重叠偏移的伪造分段时将崩溃。
      6. Land攻击
      Land攻击原理是:用一个特别打造的SYN包,它的原地址和目标地址都被设置成某一个服务器地址。此举将导致接受服务器向它自己的地址发送SYN-ACK消息,结果这个地址又发回ACK消息并创建一个空连接。被攻击的服务器每接收一个这样的连接都将保留,直到超时,对Land攻击反应不同,许多UNIX实现将崩溃,NT变的极其缓慢(大约持续5分钟)。
      7. Smurf攻击
      一个简单的Smurf攻击原理就是:通过使用将回复地址设置成受害网络的广播地址的ICMP应答请求(ping)数据包来淹没受害主机的方式进行。最终导致该网络的所有主机都对此 ICMP应答请求作出答复,导致网络阻塞。它比ping of death洪水的流量高出1或2个数量级。更加复杂的Smurf将源地址改为第三方的受害者,最终导致第三方崩溃。
      8.Fraggle攻击
      原理:Fraggle攻击实际上就是对Smurf攻击作了简单的修改,使用的是UDP应答消息而非ICMP。
      拒绝服务攻击的属性分类法
      J.Mirkovic和P. Reiher [Mirkovic04]提出了拒绝服务攻击的属性分类法,即将攻击属性分为攻击静态属性、攻击动态属性和攻击交互属性三类,根据DoS攻击的这些属性的不同,就可以对攻击进行详细的分类。凡是在攻击开始前就已经确定,在一次连续的攻击中通常不会再发生改变的属性,称为攻击静态属性。攻击静态属性是由攻击者和攻击本身所确定的,是攻击基本的属性。那些在攻击过程中可以进行动态改变的属性,如攻击的目标选取、时间选择、使用源地址的方式,称为攻击动态属性。而那些不仅与攻击者相关而且与具体受害者的配置、检测与服务能力也有关系的属性,称为攻击交互属性。
      1.攻击静态属性(Static)
      攻击静态属性主要包括攻击控制模式、攻击通信模式、攻击技术原理、攻击协议和攻击协议层等。
      (1)攻击控制方式(ControlMode)
      攻击控制方式直接关系到攻击源的隐蔽程度。根据攻击者控制攻击机的方式可以分为以下三个等级:直接控制方式(Direct)、间接控制方式(Indirect)和自动控制方式(Auto)。
      最早的拒绝服务攻击通常是手工直接进行的,即对目标的确定、攻击的发起和中止都是由用户直接在攻击主机上进行手工操作的。这种攻击追踪起来相对容易,如果能对攻击包进行准确的追踪,通常就能找到攻击者所在的位置。由于直接控制方式存在的缺点和攻击者想要控制大量攻击机发起更大规模攻击的需求,攻击者开始构建多层结构的攻击网络。多层结构的攻击网络给针对这种攻击的追踪带来很大困难,受害者在追踪到攻击机之后,还需要从攻击机出发继续追踪控制器,如果攻击者到最后一层控制器之间存在多重跳板时,还需要进行多次追踪才能最终找到攻击者,这种追踪不仅需要人工进行操作,耗费时间长,而且对技术也有很高的要求。这种攻击模式,是目前最常用的一种攻击模式。自动攻击方式,是在释放的蠕虫或攻击程序中预先设定了攻击模式,使其在特定时刻对指定目标发起攻击。这种方式的攻击,从攻击机往往难以对攻击者进行追踪,但是这种控制方式的攻击对技术要求也很高。Mydoom蠕虫对SCO网站和Microsoft网站的攻击就属于第三种类型[TA04-028A]。
      (2)攻击通信方式(CommMode)
      在间接控制的攻击中,控制者和攻击机之间可以使用多种通信方式,它们之间使用的通信方式也是影响追踪难度的重要因素之一。攻击通信方式可以分为三种方式,分别是:双向通信方式(bi)、单向通信方式(mono)和间接通信方式(indirection)。
      双向通信方式是指根据攻击端接收到的控制数据包中包含了控制者的真实IP地址,例如当控制器使用TCP与攻击机连接时,该通信方式就是双向通信。这种通信方式,可以很容易地从攻击机查找到其上一级的控制器。
      单向通信方式指的是攻击者向攻击机发送指令时的数据包并不包含发送者的真实地址信息,例如用伪造IP地址的UDP包向攻击机发送指令。这一类的攻击很难从攻击机查找到控制器,只有通过包标记等IP追踪手段,才有可能查找到给攻击机发送指令的机器的真实地址。但是,这种通信方式在控制上存在若干局限性,例如控制者难以得到攻击机的信息反馈和状态。
      间接通信方式是一种通过第三者进行交换的双向通信方式,这种通信方式具有隐蔽性强、难以追踪、难以监控和过滤等特点,对攻击机的审计和追踪往往只能追溯到某个被用于通信中介的公用服务器上就再难以继续进行。这种通信方式目前已发现的主要是通过IRC(Internet Relay Chat)进行通信[Jose Nazario],从2000年8月出现的名为Trinity的DDoS攻击工具开始,已经有多种DDoS攻击工具及蠕虫采纳了这种通信方式。在基于IRC的傀儡网络中,若干攻击者连接到Internet上的某个IRC服务器上,并通过服务器的聊天程序向傀儡主机发送指令。
      (3)攻击原理(Principle)
      DoS攻击原理主要分为两种,分别是:语义攻击(Semantic)和暴力攻击(Brute)。
      语义攻击指的是利用目标系统实现时的缺陷和漏洞,对目标主机进行的拒绝服务攻击,这种攻击往往不需要攻击者具有很高的攻击带宽,有时只需要发送1个数据包就可以达到攻击目的,对这种攻击的防范只需要修补系统中存在的缺陷即可。暴力攻击指的是不需要目标系统存在漏洞或缺陷,而是仅仅靠发送超过目标系统服务能力的服务请求数量来达到攻击的目的,也就是通常所说的风暴攻击。所以防御这类攻击必须借助于受害者上游路由器等的帮助,对攻击数据进行过滤或分流。某些攻击方式,兼具语义和暴力两种攻击的特征,比如SYN风暴攻击,虽然利用了TCP协议本身的缺陷,但仍然需要攻击者发送大量的攻击请求,用户要防御这种攻击,不仅需要对系统本身进行增强,而且也需要增大资源的服务能力。还有一些攻击方式,是利用系统设计缺陷,产生比攻击者带宽更高的通信数据来进行暴力攻击的,如DNS请求攻击和Smurf攻击,参见4.2.3节以及文献[IN-2000-04]和[CA-1998-01]。这些攻击方式在对协议和系统进行改进后可以消除或减轻危害,所以可把它们归于语义攻击的范畴。
      (4)攻击协议层(ProLayer)
      攻击所在的TCP/IP协议层可以分为以下四类:数据链路层、网络层、传输层和应用层。
      数据链路层的拒绝服务攻击[Convery] [Fischbach01][Fischbach02]受协议本身限制,只能发生在局域网内部,这种类型的攻击比较少见。针对IP层的攻击主要是针对目标系统处理IP包时所出现的漏洞进行的,如IP碎片攻击[Anderson01],针对传输层的攻击在实际中出现较多,SYN风暴、ACK风暴等都是这类攻击,面向应用层的攻击也较多,剧毒包攻击中很多利用应用程序漏洞的(例如缓冲区溢出的攻击)都属于此类型。
      (5)攻击协议(ProName)
      攻击所涉及的最高层的具体协议,如SMTP、ICMP、UDP、HTTP等。攻击所涉及的协议层越高,则受害者对攻击包进行分析所需消耗的计算资源就越大。
      2.攻击动态属性(Dynamic)
      攻击动态属性主要包括攻击源地址类型、攻击包数据生成模式和攻击目标类型。
      (1)攻击源地址类型(SourceIP)
      攻击者在攻击包中使用的源地址类型可以分为三种:真实地址(True)、伪造合法地址(Forge Legal)和伪造非法地址(Forge Illegal)。
      攻击时攻击者可以使用合法的IP地址,也可以使用伪造的IP地址。伪造的IP地址可以使攻击者更容易逃避追踪,同时增大受害者对攻击包进行鉴别、过滤的难度,但某些类型的攻击必须使用真实的IP地址,例如连接耗尽攻击。使用真实IP地址的攻击方式由于易被追踪和防御等原因,近些年来使用比例逐渐下降。使用伪造IP地址的攻击又分为两种情况:一种是使用网络中已存在的IP地址,这种伪造方式也是反射攻击所必需的源地址类型;另外一种是使用网络中尚未分配或者是保留的IP地址(例如192.168.0.0/16、172.16.0.0/12等内部网络保留地址[RFC1918])。
      (2)攻击包数据生成模式(DataMode)
      攻击包中包含的数据信息模式主要有5种:不需要生成数据(None)、统一生成模式(Unique)、随机生成模式(Random)、字典模式(Dictionary)和生成函数模式(Function)。
      在攻击者实施风暴式拒绝服务攻击时,攻击者需要发送大量的数据包到目标主机,这些数据包所包含的数据信息载荷可以有多种生成模式,不同的生成模式对受害者在攻击包的检测和过滤能力方面有很大的影响。某些攻击包不需要包含载荷或者只需包含适当的固定的载荷,例如SYN风暴攻击和ACK风暴攻击,这两种攻击发送的数据包中的载荷都是空的,所以这种攻击是无法通过载荷进行分析的。但是对于另外一些类型的攻击包,就需要携带相应的载荷。
      攻击包载荷的生成方式可以分为4种:第一种是发送带有相同载荷的包,这样的包由于带有明显的特征,很容易被检测出来。第二种是发送带有随机生成的载荷的包,这种随机生成的载荷虽然难以用模式识别的方式来检测,然而随机生成的载荷在某些应用中可能生成大量没有实际意义的包,这些没有意义的包也很容易被过滤掉,但是攻击者仍然可以精心设计载荷的随机生成方式,使得受害者只有解析到应用层协议才能识别出攻击数据包,从而增加了过滤的困难性。第三种方式是攻击者从若干有意义载荷的集合中按照某种规则每次取出一个填充到攻击包中,这种方式当集合的规模较小时,也比较容易被检测出来。最后一种方式是按照某种规则每次生成不同的载荷,这种方式依生成函数的不同,其检测的难度也是不同的。
      (3)攻击目标类型(Target)
      攻击目标类型可以分为以下6类:应用程序(Application)、系统(System)、网络关键资源(Critical)、网络(Network)、网络基础设施(Infrastructure)和因特网(Internet)。
      针对特定应用程序的攻击是较为常见的攻击方式,其中以剧毒包攻击较多,它包括针对特定程序的,利用应用程序漏洞进行的拒绝服务攻击,以及针对一类应用的,使用连接耗尽方式进行的拒绝服务攻击。针对系统的攻击也很常见,像SYN风暴、UDP风暴[CA-1996-01]以及可以导致系统崩溃、重启的剧毒包攻击都可以导致整个系统难以提供服务。针对网络关键资源的攻击包括对特定DNS、路由器的攻击。而面向网络的攻击指的是将整个局域网的所有主机作为目标进行的攻击。针对网络基础设施的攻击需要攻击者拥有相当的资源和技术,攻击目标是根域名服务器、主干网核心路由器、大型证书服务器等网络基础设施,这种攻击发生次数虽然不多,但一旦攻击成功,造成的损失是难以估量的[Naraine02]。针对Internet的攻击是指通过蠕虫、病毒发起的,在整个Internet上蔓延并导致大量主机、网络拒绝服务的攻击,这种攻击的损失尤为严重。
      3.交互属性(Mutual)
      攻击的动态属性不仅与攻击者的攻击方式、能力有关,也与受害者的能力有关。主要包括攻击的可检测程度和攻击影响。
      (1)可检测程度(Detective)
      根据能否对攻击数据包进行检测和过滤,受害者对攻击数据的检测能力从低到高分为以下三个等级:可过滤(Filterable)、有特征但无法过滤(Unfilterable)和无法识别(Noncharacterizable)。
      第一种情况是,对于受害者来说,攻击包具有较为明显的可识别特征,而且通过过滤具有这些特征的数据包,可以有效地防御攻击,保证服务的持续进行。第二种情况是,对于受害者来说,攻击包虽然具有较为明显的可识别特征,但是如果过滤具有这些特征的数据包,虽然可以阻断攻击包,但同时也会影响到服务的持续进行,从而无法从根本上防止拒绝服务。第三种情况是,对于受害者来说,攻击包与其他正常的数据包之间,没有明显的特征可以区分,也就是说,所有的包,在受害者看来,都是正常的。
      (2)攻击影响(Impact)
      根据攻击对目标造成的破坏程度,攻击影响自低向高可以分为:无效(None)、服务降低(Degrade)、可自恢复的服务破坏(Self-recoverable)、可人工恢复的服务破坏(Manu-recoverable)以及不可恢复的服务破坏(Non-recoverable)。
      如果目标系统在拒绝服务攻击发生时,仍然可以提供正常服务,则该攻击是无效的攻击。如果攻击能力不足以导致目标完全拒绝服务,但造成了目标的服务能力降低,这种效果称之为服务降低。而当攻击能力达到一定程度时,攻击就可以使目标完全丧失服务能力,称之为服务破坏。服务破坏又可以分为可恢复的服务破坏和不可恢复的服务破坏,目前网络拒绝服务攻击所造成的服务破坏通常都是可恢复的。一般来说,风暴型的DDoS攻击所导致的服务破坏都是可以自恢复的,当攻击数据流消失时,目标就可以恢复正常工作状态。而某些利用系统漏洞的攻击可以导致目标主机崩溃、重启,这时就需要对系统进行人工恢复;还有一些攻击利用目标系统的漏洞对目标的文件系统进行破坏,导致系统的关键数据丢失,往往会导致不可恢复的服务破坏,即使系统重新提供服务,仍然无法恢复到破坏之前的服务状态。
  • Base64 编码介绍

    2009-05-05 22:33:13

     Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一,大家可以查看RFC2045~RFC2049,上面有MIME的详细规范。
      Base64编码可用于在HTTP环境下传递较长的标识信息。例如,在Java Persistence系统Hibernate中,就采用了Base64来将一个较长的唯一标识符(一般为128-bit的UUID)编码为一个字符串,用作HTTP表单和HTTP GET URL中的参数。在其他应用程序中,也常常需要把二进制数据编码为适合放在URL(包括隐藏表单域)中的形式。此时,采用Base64编码不仅比较简短,同时也具有不可读性,即所编码的数据不会被人用肉眼所直接看到。
      然而,标准的Base64并不适合直接放在URL里传输,因为URL编码器会把标准Base64中的“/”和“+”字符变为形如“%XX”的形式,而这些“%”号在存入数据库时还需要再进行转换,因为ANSI SQL中已将“%”号用作通配符。
      为解决此问题,可采用一种用于URL的改进Base64编码,它不在末尾填充'='号,并将标准Base64中的“+”和“/”分别改成了“*”和“-”,这样就免去了在URL编解码和数据库存储时所要作的转换,避免了编码信息长度在此过程中的增加,并统一了数据库、表单等处对象标识符的格式。
      另有一种用于正则表达式的改进Base64变种,它将“+”和“/”改成了“!”和“-”,因为“+”,“*”以及前面在IRCu中用到的“[”和“]”在正则表达式中都可能具有特殊含义。
      此外还有一些变种,它们将“+/”改为“_-”或“._”(用作编程语言中的标识符名称)或“.-”(用于XML中的Nmtoken)甚至“_:”(用于XML中的Name)。
      Base64要求把每三个8Bit的字节转换为四个6Bit的字节(3*8 = 4*6 = 24),然后把6Bit再添两位高位0,组成四个8Bit的字节,也就是说,转换后的字符串理论上将要比原来的长1/3。
      这样说会不会太抽象了?不怕,我们来看一个例子:
      转换前 aaaaaabb ccccdddd eeffffff
      转换后 00aaaaaa 00bbcccc 00ddddee 00ffffff
      应该很清楚了吧?上面的三个字节是原文,下面的四个字节是转换后的Base64编码,其前两位均为0。
      转换后,我们用一个码表来得到我们想要的字符串(也就是最终的Base64编码),这个表是这样的:(摘自RFC2045)
      Table 1: The Base64 Alphabet
      Value Encoding Value Encoding Value Encoding Value Encoding
      0 A 17 R 34 i 51 z
      1 B 18 S 35 j 52 0
      2 C 19 T 36 k 53 1
      3 D 20 U 37 l 54 2
      4 E 21 V 38 m 55 3
      5 F 22 W 39 n 56 4
      6 G 23 X 40 o 57 5
      7 H 24 Y 41 p 58 6
      8 I 25 Z 42 q 59 7
      9 J 26 a 43 r 60 8
      10 K 27 b 44 s 61 9
      11 L 28 c 45 t 62 +
      12 M 29 d 46 u 63 /
      13 N 30 e 47 v
      14 O 31 f 48 w (pad) =
      15 P 32 g 49 x
      16 Q 33 h 50 y
      
    索引 对应字符 索引 对应字符
      
    索引 对应字符
      
    索引 对应字符
    0 A 17 R 34 i 51 z
    1 B 18 S 35 j 52 0
    2 C 19 T 36 k 53 1
    3 D 20 U 37 l 54 2
    4 E 21 V 38 m 55 3
    5 F 22 W 39 n 56 4
    6 G 23 X 40 o 57 5
    7 H 24 Y 41 p 58 6
    8
      
    I 25 Z 42 q 59 7
    9
      
    J 26 a 43 r 60 8
    10
      
    K 27 b 44 s 61 9
    11
      
    L 28 c 45 t 62 +
    12
      
    M 29 d 46 u 63 /
    13 N 30 e 47 v
      
     
    14 O 31 f 48 w    
    15 P 32 g 49 x    
    16 Q 33 h 50 y    

      让我们再来看一个实际的例子,加深印象!
      转换前 10101101 10111010 01110110
      转换后 00101011 00011011 00101001 00110110
      十进制 43 27 41 54
      对应码表中的值 r b p 2
      所以上面的24位编码,编码后的Base64值为 rbp2
      解码同理,把 rbq2 的二进制位连接上再重组得到三个8位值,得出原码。
      (解码只是编码的逆过程,在此我就不多说了,另外有关MIME的RFC还是有很多的,如果需要详细情况请自行查找。)
      用更接近于编程的思维来说,编码的过程是这样的:
      第一个字符通过右移2位获得第一个目标字符的Base64表位置,根据这个数值取到表上相应的字符,就是第一个目标字符。
      然后将第一个字符左移4位加上第二个字符右移4位,即获得第二个目标字符。
      再将第二个字符左移2位加上第三个字符右移6位,获得第三个目标字符。
      最后取第三个字符的右6位即获得第四个目标字符。
      在以上的每一个步骤之后,再把结果与 0x3F 进行 AND 位操作,就可以得到编码后的字符了。
      可是等等……聪明的你可能会问到,原文的字节数量应该是3的倍数啊,如果这个条件不能满足的话,那该怎么办呢?
      我们的解决办法是这样的:原文的字节不够的地方可以用全0来补足,转换时Base64编码用=号来代替。这就是为什么有些Base64编码会以一个或两个等号结束的原因,但等号最多只有两个。因为:
      余数 = 原文字节数 MOD 3
      所以余数任何情况下都只可能是0,1,2这三个数中的一个。如果余数是0的话,就表示原文字节数正好是3的倍数(最理想的情况啦)。如果是1的话,为了让Base64编码是4的倍数,就要补2个等号;同理,如果是2的话,就要补1个等号。
  • HTTP 认证模式

    2009-05-05 22:09:45

    一.基本认证模式
    客户向服务器发送请求,服务器返回401(未授权),要求认证。401消息的头里面带了挑战信息。realm用以区分要不同认证的部分。客户端收到401后,将用户名密码和挑战信息用BASE64加密形成证书,发送回服务器认证。语法如下:

           challenge   = "Basic" realm
          credentials = "Basic" basic-credentials

    二.摘要访问认证
    为了防止重放攻击,采用摘要访问认证。在客户发送请求后,收到一个401(未授权)消息,包含一个Challenge。消息里面有一个唯一的字符串:nonce,每次请求都不一样。客户将用户名密码和401消息返回的挑战一起加密后传给服务器。这样即使有窃听,他也无法通过每次认证,不能重放攻击。Http并不是一个安全的协议。其内容都是明文传输。因此不要指望Http有多安全。

    语法:

          challenge        =  "Digest" digest-challenge

          digest-challenge  = 1#( realm | [ domain ] | nonce |
                              [ opaque ] |[ stale ] | [ algorithm ] |
                              [ qop-options ] | [auth-param] )


          domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
          URI               = absoluteURI | abs_path
          nonce             = "nonce" "=" nonce-value
          nonce-value       = quoted-string
          opaque            = "opaque" "=" quoted-string
          stale             = "stale" "=" ( "true" | "false" )
          algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
                               token )
          qop-options       = "qop" "=" <"> 1#qop-value <">
          qop-value         = "auth" | "auth-int" | token


    realm:让客户知道使用哪个用户名和密码的字符串。不同的领域可能密码不一样。至少告诉用户是什么主机做认证,他可能会提示用哪个用户名登录,类似一个Email。
    domain:一个URI列表,指示要保护的域。可能是一个列表。提示用户这些URI采用一样的认证。如果为空或忽略则为整个服务器。
    nonce:随机字符串,每次401都不一样。跟算法有关。算法类似Base64加密:time-stamp H(time-stamp ":" ETag ":" private-key) 。time-stamp为服务器时钟,ETag为请求的Etag头。private-key为服务器知道的一个值。
    opaque:服务器产生的由客户下去请求时原样返回。最好是Base64串或十六进制字符串。
    auth-param:为扩展用的,现阶段忽略。
    其他域请参考RFC2617。

    授权头语法:


           credentials      = "Digest" digest-response
           digest-response  = 1#( username | realm | nonce | digest-uri
                           | response | [ algorithm ] | [cnonce] |
                           [opaque] | [message-qop] |
                               [nonce-count]  | [auth-param] )

           username         = "username" "=" username-value
           username-value   = quoted-string
           digest-uri       = "uri" "=" digest-uri-value
           digest-uri-value = request-uri   ; As specified by HTTP/1.1
           message-qop      = "qop" "=" qop-value
           cnonce           = "cnonce" "=" cnonce-value
           cnonce-value     = nonce-value
           nonce-count      = "nc" "=" nc-value
           nc-value         = 8LHEX
           response         = "response" "=" request-digest
           request-digest = <"> 32LHEX <">
           LHEX             =  "0" | "1" | "2" | "3" |
                               "4" | "5" | "6" | "7" |
                               "8" | "9" | "a" | "b" |
                               "c" | "d" | "e" | "f"


    response:加密后的密码
    digest-uri:拷贝Request-Line,用于Proxy
    cnonce:如果qop设置,才设置,用于双向认证,防止攻击。
    nonce-count:如果服务器看到同样的计数,就是一次重放。

     

     

  • HTTP协议(收藏)

    2009-05-05 18:05:05

    引言                                        
    HTTP是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。它于1990年提出,经过几年的
    使用与发展,得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-
    NG(Next Generation of HTTP)的建议已经提出。
    HTTP协议的主要特点可概括如下:
    1.支持客户/服务器模式。
    2.简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服
    务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
    3.灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
    4.无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方
    式可以节省传输时间。
    5.无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则
    它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。

    一、HTTP协议详解之URL篇

        http(超文本传输协议)是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方
    式,HTTP1.1版本中给出一种持续连接的机制,绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。

    HTTP URL (URL是一种特殊类型的URI,包含了用于查找某个资源的足够的信息)的格式如下:
    http://host[":"port][abs_path]
    http表示要通过HTTP协议来定位网络资源;host表示合法的Internet主机域名或者IP地址;port指定一个端口号,
    为空则使用缺省端口80;abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI
    时,必须以“/”的形式给出,通常这个工作浏览器自动帮我们完成。
    eg:
    1、输入:www.guet.edu.cn
    浏览器自动转换成:http://www.guet.edu.cn/
    2、http:192.168.0.116:8080/index.jsp 

    二、HTTP协议详解之请求篇

        http请求由三部分组成,分别是:请求行、消息报头、请求正文

    1、请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本,格式如下:Method Request-
    URI HTTP-Version CRLF  
    其中 Method表示请求方法;Request-URI是一个统一资源标识符;HTTP-Version表示请求的HTTP协议版本;
    CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。

    请求方法(所有方法全为大写)有多种,各个方法的解释如下:
    GET     请求获取Request-URI所标识的资源
    POST    在Request-URI所标识的资源后附加新的数据
    HEAD    请求获取由Request-URI所标识的资源的响应消息报头
    PUT     请求服务器存储一个资源,并用Request-URI作为其标识
    DELETE  请求服务器删除Request-URI所标识的资源
    TRACE   请求服务器回送收到的请求信息,主要用于测试或诊断
    CONNECT 保留将来使用
    OPTIONS 请求查询服务器的性能,或者查询与资源相关的选项和需求
    应用举例:
    GET方法:在浏览器的地址栏中输入网址的方式访问网页时,浏览器采用GET方法向服务器获取资源,
    eg:GET /form.html HTTP/1.1 (CRLF)

    POST方法要求被请求服务器接受附在请求后面的数据,常用于提交表单。
    eg:POST /reg.jsp HTTP/ (CRLF)
    Accept:image/gif,image/x-xbit,... (CRLF)
    ...
    HOST:www.guet.edu.cn (CRLF)
    Content-Length:22 (CRLF)
    Connection:Keep-Alive (CRLF)
    Cache-Control:no-cache (CRLF)
    (CRLF)         //该CRLF表示消息报头已经结束,在此之前为消息报头
    user=jeffrey&pwd=1234  //此行以下为提交的数据

    HEAD方法与GET方法几乎是一样的,对于HEAD请求的回应部分来说,它的HTTP头部中包含的信息与通过
    GET请求所得到的信息是相同的。利用这个方法,不必传输整个资源内容,就可以得到Request-URI所标识的资
    源的信息。该方法常用于测试超链接的有效性,是否可以访问,以及最近是否更新。
    2、请求报头后述
    3、请求正文(略) 

    三、HTTP协议详解之响应篇

        在接收和解释请求消息后,服务器返回一个HTTP响应消息。

    HTTP响应也是由三个部分组成,分别是:状态行、消息报头、响应正文
    1、状态行格式如下:
    HTTP-Version Status-Code Reason-Phrase CRLF
    其中,HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;Reason-Phrase
    表示状态代码的文本描述。
    状态代码有三位数字组成,第一个数字定义了响应的类别,且有五种可能取值:
    1xx:指示信息--表示请求已接收,继续处理
    2xx:成功--表示请求已被成功接收、理解、接受
    3xx:重定向--要完成请求必须进行更进一步的操作
    4xx:客户端错误--请求有语法错误或请求无法实现
    5xx:服务器端错误--服务器未能实现合法的请求
    常见状态代码、状态描述、说明:
    200 OK      //客户端请求成功
    400 Bad Request  //客户端请求有语法错误,不能被服务器所理解
    401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报                 //头域一起使用 
    403 Forbidden  //服务器收到请求,但是拒绝提供服务
    404 Not Found  //请求资源不存在,eg:输入了错误的URL
    500 Internal Server Error //服务器发生不可预期的错误
    503 Server Unavailable  //服务器当前不能处理客户端的请求,一段时间后,                         //可能恢复正常
    eg:HTTP/1.1 200 OK (CRLF)

    2、响应报头后述

    3、响应正文就是服务器返回的资源的内容 

    四、HTTP协议详解之消息报头篇

        HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行(对
    于请求消息,开始行就是请求行,对于响应消息,开始行就是状态行),消息报头(可选),空行(只有
    CRLF的行),消息正文(可选)组成。

    HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。
    每一个报头域都是由名字+“:”+空格+值 组成,消息报头域的名字是大小写无关的。

    1、普通报头
    在普通报头中,有少数报头域用于所有的请求和响应消息,但并不用于被传输的实体,只用于传输的消息。
    eg:
    Cache-Control   用于指定缓存指令,缓存指令是单向的(响应中出现的缓存指令在请求中未必会出现),且是
    独立的(一个消息的缓存指令不会影响另一个消息处理的缓存机制),HTTP1.0使用的类似的报头域为Pragma。
    请求时的缓存指令包括:no-cache(用于指示请求或响应消息不能缓存)、no-store、max-age、max-stale、min-
    fresh、only-if-cached;
    响应时的缓存指令包括:public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、
    max-age、s-maxage.
    eg:为了指示IE浏览器(客户端)不要缓存页面,服务器端的JSP程序可以编写如下:response.sehHeader
    ("Cache-Control","no-cache");
    //response.setHeader("Pragma","no-cache");作用相当于上述代码,通常两者//合用
    这句代码将在发送的响应消息中设置普通报头域:Cache-Control:no-cache


    Date普通报头域表示消息产生的日期和时间

    Connection普通报头域允许发送指定连接的选项。例如指定连接是连续,或者指定“close”选项,通知服务
    器,在响应完成后,关闭连接

    2、请求报头
    请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
    常用的请求报头
    Accept
    Accept请求报头域用于指定客户端接受哪些类型的信息。eg:Accept:image/gif,表明客户端希望接受GIF图象
    格式的资源;Accept:text/html,表明客户端希望接受html文本。
    Accept-Charset
    Accept-Charset请求报头域用于指定客户端接受的字符集。eg:Accept-Charset:iso-8859-1,gb2312.如果在请求消
    息中没有设置这个域,缺省是任何字符集都可以接受。
    Accept-Encoding
    Accept-Encoding请求报头域类似于Accept,但是它是用于指定可接受的内容编码。eg:Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。
    Accept-Language
    Accept-Language请求报头域类似于Accept,但是它是用于指定一种自然语言。eg:Accept-Language:zh-cn.如果请
    求消息中没有设置这个报头域,服务器假定客户端对各种语言都可以接受。
    Authorization
    Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时,如果收到服务器
    的响应代码为401(未授权),可以发送一个包含Authorization请求报头域的请求,要求服务器对其进行验证。
    Host(发送请求时,该报头域是必需的)
    Host请求报头域主要用于指定被请求资源的Internet主机和端口号,它通常从HTTP URL中提取出来的,eg:
    我们在浏览器中输入:http://www.guet.edu.cn/index.html
    浏览器发送的请求消息中,就会包含Host请求报头域,如下:
    Host:www.guet.edu.cn
    此处使用缺省端口号80,若指定了端口号,则变成:Host:www.guet.edu.cn:指定端口号
    User-Agent
    我们上网登陆论坛的时候,往往会看到一些欢迎信息,其中列出了你的操作系统的名称和版本,你所使用的
    浏览器的名称和版本,这往往让很多人感到很神奇,实际上,服务器应用程序就是从User-Agent这个请求报头
    域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不
    过,这个报头域不是必需的,如果我们自己编写一个浏览器,不使用User-Agent请求报头域,那么服务器端就
    无法得知我们的信息了。
    请求报头举例:
    GET /form.html HTTP/1.1 (CRLF)
    Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-
    powerpoint,application/msword,*/* (CRLF)
    Accept-Language:zh-cn (CRLF)
    Accept-Encoding:gzip,deflate (CRLF)
    If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
    If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
    User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
    Host:www.guet.edu.cn (CRLF)
    Connection:Keep-Alive (CRLF)
    (CRLF)

    3、响应报头
    响应报头允许服务器传递不能放在状态行中的附加响应信息,以及关于服务器的信息和对Request-URI所标识
    的资源进行下一步访问的信息。
    常用的响应报头
    Location
    Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。
    Server
    Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是
    Server响应报头域的一个例子:
    Server:Apache-Coyote/1.1
    WWW-Authenticate
    WWW-Authenticate响应报头域必须被包含在401(未授权的)响应消息中,客户端收到401响应消息时候,并发
    送Authorization报头域请求服务器对其进行验证时,服务端响应报头就包含该报头域。
    eg:WWW-Authenticate:Basic realm="Basic Auth Test!"  //可以看出服务器对请求资源采用的是基本验证机制。


    4、实体报头
    请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成,但并不是说实体报头域和实体正文要在一起发送,可以只发送实体报头域。实体报头定义了关于实体正文(eg:有无实体正文)和请求所标识的资源的元信息。
    常用的实体报头
    Content-Encoding
    Content-Encoding实体报头域被用作媒体类型的修饰符,它的值指示了已经被应用到实体正文的附加内容的编
    码,因而要获得Content-Type报头域中所引用的媒体类型,必须采用相应的解码机制。Content-Encoding这样用
    于记录文档的压缩方法,eg:Content-Encoding:gzip
    Content-Language
    Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言
    阅读
    者。eg:Content-Language:da
    Content-Length
    Content-Length实体报头域用于指明实体正文的长度,以字节方式存储的十进制数字来表示。
    Content-Type
    Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg:
    Content-Type:text/html;charset=ISO-8859-1
    Content-Type:text/html;charset=GB2312
    Last-Modified
    Last-Modified实体报头域用于指示资源的最后修改日期和时间。
    Expires
    Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次
    访问曾访问过的页面时,直接从缓存中加载,缩短响应时间和降低服务器负载)的页面,我们可以使用Expires
    实体报头域指定页面过期的时间。eg:Expires:Thu,15 Sep 2006 16:23:12 GMT
    HTTP1.1的客户端和缓存必须将其他非法的日期格式(包括0)看作已经过期。eg:为了让浏览器不要缓存页
    面,我们也可以利用Expires实体报头域,设置为0,jsp中程序如下:response.setDateHeader("Expires","0");

    五、利用telnet观察http协议的通讯过程

        实验目的及原理:
        利用MS的telnet工具,通过手动输入http请求信息的方式,向服务器发出请求,服务器接收、解释和接受请求
    后,会返回一个响应,该响应会在telnet窗口上显示出来,从而从感性上加深对http协议的通讯过程的认识。

        实验步骤:

    1、打开telnet
    1.1 打开telnet
    运行-->cmd-->telnet

    1.2 打开telnet回显功能
    set localecho

    2、连接服务器并发送请求
    2.1 open www.guet.edu.cn 80  //注意端口号不能省略

        HEAD /index.asp HTTP/1.0
        Host:www.guet.edu.cn
        
       /*我们可以变换请求方法,请求桂林电子主页内容,输入消息如下*/
        open www.guet.edu.cn 80 
       
        GET /index.asp HTTP/1.0  //请求资源的内容
        Host:www.guet.edu.cn  

    2.2 open www.sina.com.cn 80  //在命令提示符号下直接输入telnet www.sina.com.cn 80
        HEAD /index.asp HTTP/1.0
        Host:www.sina.com.cn
     

    3 实验结果:

    3.1 请求信息2.1得到的响应是:

    HTTP/1.1 200 OK                                              //请求成功
    Server: Microsoft-IIS/5.0                                    //web服务器
    Date: Thu,08 Mar 200707:17:51 GMT
    Connection: Keep-Alive                                 
    Content-Length: 23330
    Content-Type: text/html
    Expries: Thu,08 Mar 2007 07:16:51 GMT
    Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
    Cache-control: private

    //资源内容省略

    3.2 请求信息2.2得到的响应是:

    HTTP/1.0 404 Not Found       //请求失败
    Date: Thu, 08 Mar 2007 07:50:50 GMT
    Server: Apache/2.0.54 <Unix>
    Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT
    ETag: "6277a-415-e7c76980"
    Accept-Ranges: bytes
    X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
    Vary: Accept-Encoding
    Content-Type: text/html
    X-Cache: MISS from zjm152-78.sina.com.cn
    Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>
    X-Cache: MISS from th-143.sina.com.cn
    Connection: close


    失去了跟主机的连接

    按任意键继续...


    4 .注意事项:1、出现输入错误,则请求不会成功。
              2、报头域不分大小写。
              3、更深一步了解HTTP协议,可以查看RFC2616,在http://www.letf.org/rfc上找到该文件。
              4、开发后台程序必须掌握http协议

     

    六、HTTP协议相关技术补充

        1、基础:
        高层协议有:文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和
    HTTP协议等
    中介由三种:代理(Proxy)、网关(Gateway)和通道(Tunnel),一个代理根据URI的绝对格式来接受请求,重写全部
    或部分消息,通过 URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理,作为一些其它服务
    器的上层,并且如果必须的话,可以把请求翻译给下层的服务器协议。一 个通道作为不改变消息的两个连接
    之间的中继点。当通讯需要通过一个中介(例如:防火墙等)或者是中介不能识别消息的内容时,通道经常被使
    用。
         代理(Proxy):一个中间程序,它可以充当一个服务器,也可以充当一个客户机,为其它客户机建立请求。
    请求是通过可能的翻译在内部或经过传递到其它的 服务器中。一个代理在发送请求信息之前,必须解释并且
    如果可能重写它。代理经常作为通过防火墙的客户机端的门户,代理还可以作为一个帮助应用来通过协议处 
    理没有被用户代理完成的请求。
    网关(Gateway):一个作为其它服务器中间媒介的服务器。与代理不同的是,网关接受请求就好象对被请求的
    资源来说它就是源服务器;发出请求的客户机并没有意识到它在同网关打交道。
      网关经常作为通过防火墙的服务器端的门户,网关还可以作为一个协议翻译器以便存取那些存储在非
    HTTP系统中的资源。
        通道(Tunnel):是作为两个连接中继的中介程序。一旦激活,通道便被认为不属于HTTP通讯,尽管通道可能
    是被一个HTTP请求初始化的。当被中继 的连接两端关闭时,通道便消失。当一个门户(Portal)必须存在或中介
    (Intermediary)不能解释中继的通讯时通道被经常使用。


    2、协议分析的优势—HTTP分析器检测网络攻击
    以模块化的方式对高层协议进行分析处理,将是未来入侵检测的方向。
    HTTP及其代理的常用端口80、3128和8080在network部分用port标签进行了规定

    3、HTTP协议Content Lenth限制漏洞导致拒绝服务攻击
    使用POST方法时,可以设置ContentLenth来定义需要传送的数据长度,例如ContentLenth:999999999,在传送完
    成前,内 存不会释放,攻击者可以利用这个缺陷,连续向WEB服务器发送垃圾数据直至WEB服务器内存耗
    尽。这种攻击方法基本不会留下痕迹。
    http://www.cnpaf.net/Class/HTTP/0532918532667330.html


    4、利用HTTP协议的特性进行拒绝服务攻击的一些构思
    服务器端忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之
    小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称作:服务器端受到了SYNFlood攻击(SYN洪水攻击)。
    而Smurf、TearDrop等是利用ICMP报文来Flood和IP碎片攻击的。本文用“正常连接”的方法来产生拒绝服务攻击。
    19端口在早期已经有人用来做Chargen攻击了,即Chargen_Denial_of_Service,但是!他们用的方法是在两台
    Chargen 服务器之间产生UDP连接,让服务器处理过多信息而DOWN掉,那么,干掉一台WEB服务器的条件就
    必须有2个:1.有Chargen服务2.有HTTP 服务
    方法:攻击者伪造源IP给N台Chargen发送连接请求(Connect),Chargen接收到连接后就会返回每秒72字节的
    字符流(实际上根据网络实际情况,这个速度更快)给服务器。


    5、Http指纹识别技术
       Http指纹识别的原理大致上也是相同的:记录不同服务器对Http协议执行中的微小差别进行识别.Http指纹识
    别比TCP/IP堆栈指纹识别复杂许 多,理由是定制Http服务器的配置文件、增加插件或组件使得更改Http的响应
    信息变的很容易,这样使得识别变的困难;然而定制TCP/IP堆栈的行为 需要对核心层进行修改,所以就容易识
    别.
          要让服务器返回不同的Banner信息的设置是很简单的,象Apache这样的开放源代码的Http服务器,用户可以在
    源代码里修改Banner信息,然 后重起Http服务就生效了;对于没有公开源代码的Http服务器比如微软的IIS或者
    是Netscape,可以在存放Banner信息的Dll文件中修 改,相关的文章有讨论的,这里不再赘述,当然这样的修改的效果
    还是不错的.另外一种模糊Banner信息的方法是使用插件。
    常用测试请求:
    1:HEAD/Http/1.0发送基本的Http请求
    2:DELETE/Http/1.0发送那些不被允许的请求,比如Delete请求
    3:GET/Http/3.0发送一个非法版本的Http协议请求
    4:GET/JUNK/1.0发送一个不正确规格的Http协议请求
    Http指纹识别工具Httprint,它通过运用统计学原理,组合模糊的逻辑学技术,能很有效的确定Http服务器的类型.它
    可以被用来收集和分析不同Http服务器产生的签名。


    6、其他:为了提高用户使用浏览器时的性能,现代浏览器还支持并发的访问方式,浏览一个网页时同时建立
    多个连接,以迅速获得一个网页上的多个图标,这样能更快速完成整个网页的传输。
    HTTP1.1中提供了这种持续连接的方式,而下一代HTTP协议:HTTP-NG更增加了有关会话控制、丰富的内容
    协商等方式的支持,来提供
    更高效率的连接。
  • HTTP Status-Code

    2009-05-05 17:34:40

    Status-Code的第一个数字定义响应的类别,后两个数字没有分类的作用。第一个数字可能取5个不同的值:

    1**:请求收到,继续处理
    2**:操作成功收到,分析、接受
    3**:完成此请求必须进一步处理
    4**:请求包含一个错误语法或不能完成
    5**:服务器执行一个完全有效请求失败

    100——客户必须继续发出请求
    101——客户要求服务器根据请求转换HTTP协议版本

    200——交易成功
    201——提示知道新文件的URL
    202——接受和处理、但处理未完成
    203——返回信息不确定或不完整
    204——请求收到,但返回信息为空
    205——服务器完成了请求,用户代理必须复位当前已经浏览过的文件
    206——服务器已经完成了部分用户的GET请求

    300——请求的资源可在多处得到
    301——删除请求数据
    302——在其他地址发现了请求数据
    303——建议客户访问其他URL或访问方式
    304——客户端已经执行了GET,但文件未变化
    305——请求的资源必须从服务器指定的地址得到
    306——前一版本HTTP中使用的代码,现行版本中不再使用
    307——申明请求的资源临时性删除 

    400——错误请求,如语法错误
    401——请求授权失败
    402——保留有效ChargeTo头响应
    403——请求不允许
    404——没有发现文件、查询或URl
    405——用户在Request-Line字段定义的方法不允许
    406——根据用户发送的Accept拖,请求资源不可访问
    407——类似401,用户必须首先在代理服务器上得到授权
    408——客户端没有在用户指定的饿时间内完成请求
    409——对当前资源状态,请求不能完成
    410——服务器上不再有此资源且无进一步的参考地址
    411——服务器拒绝用户定义的Content-Length属性请求
    412——一个或多个请求头字段在当前请求中错误
    413——请求的资源大于服务器允许的大小
    414——请求的资源URL长于服务器允许的长度
    415——请求资源不支持请求项目格式
    416——请求中包含Range请求头字段,在当前请求资源范围内没有range指示值,请求
    也不包含If-Range请求头字段
    417——服务器不满足请求Expect头字段指定的期望值,如果是代理服务器,可能是下
    一级服务器不能满足请求

    500——服务器产生内部错误
    501——服务器不支持请求的函数
    502——服务器暂时不可用,有时是为了防止发生系统过载
    503——服务器过载或暂停维修
    504——关口过载,服务器使用另一个关口或服务来响应用户,等待时间设定值较长
    505——服务器不支持或拒绝支请求头中指定的HTTP版本

  • 介绍HTTP标示URL

    2009-05-05 17:24:01

    URL的一般格式为(带方括号[]的为可选项):
      protocol :// hostname[:port] / path / [;parameters][?query]#fragment
      例如:
      http://www.imailtone.com:80/WebApplication1/WebForm1.aspx?name=tom&age=20#resume
      格式说明:
      1、protocol(协议):指定使用的传输协议,下表列出 protocol 属性的有效方案名称。 最常用的是HTTP协议,它也是目前WWW中应用最广的协议。
      file 资源是本地计算机上的文件。格式file://
      ftp 通过 FTP访问资源。格式 FTP://
      gopher 通过 Gopher 协议访问该资源。
      http 通过 HTTP 访问该资源。 格式 HTTP://
      https 通过安全的 HTTPS 访问该资源。 格式 HTTPS://
      mailto 资源为电子邮件地址,通过 SMTP 访问。 格式 mailto:
      MMS 通过 支持MMS(流媒体)协议的播放该资源。(代表软件:Windows Media Player)格式 MMS://
      ed2k 通过 支持ed2k(专用下载链接)协议的P2P软件访问该资源。(代表软件:电驴) 格式 ed2k://
      Flashget 通过 支持Flashget:(专用下载链接)协议的P2P软件访问该资源。(代表软件:快车) 格式 Flashget://
      thunder 通过 支持thunder(专用下载链接)协议的P2P软件访问该资源。(代表软件:迅雷) 格式 thunder://
      news 通过 NNTP 访问该资源。
      tencent 通过支持tencent(专用聊天连接) 协议和用户对话。(代表软件:QQ、TM)格式 tencent://message/?uin=号码&Site=&Menu=yes
      msnim 通过支持msnim(专用聊天连接) 协议和用户对话。(代表软件:MSN、WLM) 格式 msnim:chat?contact=邮箱地址
      2、hostname(主机名):是指存放资源的服务器的域名系统 (DNS) 主机名或 IP 地址。有时,在主机名前也可以包含连接到服务器所需的用户名和密码(格式:username@password)。
      3、port(端口号):整数,可选,省略时使用方案的默认端口,各种传输协议都有默认的端口号,如http的默认端口为80。如果输入时省略,则使用默认端口号。有时候出于安全或其他考虑,可以在服务器上对端口进行重定义,即采用非标准端口号,此时,URL中就不能省略端口号这一项。
      4、path(路径):由零或多个“/”符号隔开的字符串,一般用来表示主机上的一个目录或文件地址。
      5、;parameters(参数):这是用于指定特殊参数的可选项。
      6、?query(查询):可选,用于给动态网页(如使用CGI、ISAPI、PHP/JSP/ASP/ASP.NET等技术制作的网页)传递参数,可有多个参数,用“&”符号隔开,每个参数的名和值用“=”符号隔开。
      7、fragment,信息片断,字符串,用于指定网络资源中的片断。例如一个网页中有多个名词解释,可使用fragment直接定位到某一名词解释。
      注意,Windows 主机不区分 URL 大小写,但是,Unix/Linux 主机区分大小写。
      URL定位标识说明
      下面列表是常见的URL中定位和标识的服务或文件:
      http:文件在WEB服务器上.
      file:文件在您自己的局部系统或匿名服务器上
      ftp:文件在FTP服务器上
      gopher:文件在gopher服务器上
      wais:文件在wais服务器上
      news:文件在Usenet服务器上
      telnet:连接到一个支持Telnet远程登录的服务器上


  • zhuan

    2009-03-25 11:28:59

    第一章:B/S架构体系安全渗透测试基础
    1. HTTP协议基本概念
    (1)介绍HTTP标示URL
    (2)HTTP响应状态码
    (3)HTTP协议传输内容
    2. WEB应用认证基本概念
    (1)HTTP常见认证机制
    (2)BASE64编码介绍
    3. B/S架构常见安全问题
    (1)拒绝服务攻击基础
    (2)Smurf攻击模型
    (3)Fraggle攻击模型
    (4)SynFlooding攻击模型
    (5)碎片攻击
    4. 嗅探理论基础
    (1)网络嗅探原理
    (2)密码嗅探介绍
    (3)协议分析基础介绍
    第二章:B/S架构体系安全渗透测试攻击基础
    1. B/S架构结构端口扫描分析
    (1)SuperScan工具
    (2)Nmap端口扫描工具

    2. 输入验证攻击基础知识
    (1)输入验证攻击基本概念
    (2)Unicode漏洞介绍
    (3)输入验证二次解码漏洞介绍
    3. ASP脚本注入基础知识
    (1)ASP脚本注入基本概念
    (2)ASP脚本注入检测
    (3)ASP脚本注入信息获取
    (4)AASP脚本注入提权
    4. PHP脚本注入基础知识
    (1)PHP脚本注入基本概念
    (2)PHP脚本注入检测
    (3)PHP脚本注入信息获取
    (4)PHP脚本注入提权
    5.跨站脚本原理及防御
    (1)跨站脚本基本概念
    (2)跨站脚本实例
    (3)跨站脚本解决方法
    6、 Web权限提升分析
    (1)Web权限提升基本概念
    (2)WeBShell上传方法
    (3)Web权限提升7大方法:密码破解、本地提权、Gina木马…
    7.APR嗅探基础
    (1)APR协议概念
    (2)APR欺骗攻击
    (3) 交换域网络嗅探
    第三章:B/S架构体系安全渗透测试攻击与测试工具
    1、 攻击工具介绍
    (1)注入攻击工具原理
    (2)注入攻击工具分析
    (3)攻击测试平台搭建
    2.注入攻击工具使用练习(ASP+SQL Server注入攻击实战)
    (1)注入攻击工具使用
    (2)域名检查攻击工具使用及域名信息查询用
    3.拒绝服务攻击工具使用练习
    (1)SynFlooding攻击工具测试
    (2)UDPflood攻击工具测试
    (3)畸形DDOS攻击工具
    4.嗅探攻击工具使用练习
    (1)ARP欺骗攻击工具 密码嗅探练习
    (2)嗅探协议分析练习
    5. B/S安全评估工具使用练习
    (1)Web脚本评估工具安装
    (2)B/S架构扫描
    (3)评估报告分析撰写模版
Open Toolbar