在介紹這個方法之前，讓我們復習一下HTTP是怎樣工作的：
由于HTTP協議是基于請求/響應范式的（相當于客戶機/服務器）。一個客戶機與服務器建立連接后，發送一個請求給服務器，請求方式的格式為：統一資源標識符(URL)、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
留意這行文字：“服務器接到請求后，給予相應的響應信息，其格式為一個狀態行”，這是HTTP協議的一個重要特性，我們可以做個實驗：
用TELNET或任何一個能建立HTTP連接的程序連接到某服務器的80端口，手工輸入：
GET/index.htmHTTP/1.0（必須確保這個工具能自動產生兩個換行符，否則服務器會認為你沒有輸入完全！）
假如index.htm存在，你會看到類似以下的報文：
HTTP/1.1200OK
Server:Microsoft-IIS/5.0
Content-Location:http://www.******.com/index.htm
Date:Sat,20Jul200223:32:03GMT
Content-Type:text/Html
Accept-Ranges:bytes
Last-Modified:Wed,03Jul200209:50:05GMT
ETag:"8e2ba27722c21:850"
Content-Length:3292
<html>
<head>
<title>青澀寶貝主題站－－SGfans的世界！！！</title>
<metahttp-equiv="Content-Type"content="text/html;charset=gb2312">
<linkrel="stylesheet"href="all.CSS"type="text/css">
.......
這是正常的訪問方法，但是假如我們胡亂輸入請求呢？看：
HTTP/1.1400BadRequest
Server:Microsoft-IIS/5.0
Date:Sat,20Jul200223:37:59GMT
Content-Type:text/html
Content-Length:87
<html><head><title>Error</title></head><body>Theparameterisincorrect.</body></html>
呵呵，HTTP400-錯誤請求，其實就是HTTP語法錯誤，服務器老老實實給我們返回了。
可以得出結論：無論你輸入了什么，服務器根據HTTP協議，總會返回信息
通常用得最多的DOS方法主要有SYN、Smurf、Land、TearDrop等，其中SYN的資料如下（抄來的資料~~呵呵）
假設一個用戶向服務器發送了SYN報文后忽然死機或掉線，那么服務器在發出SYN+ACK應答報文后是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下服務器端一般會重試（再次發送SYN+ACK給客戶端）并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYNTimeout，一般來說這個時間是分鐘的數量級（大約為30秒-2分鐘）；一個用戶出現異常導致服務器的一個線程等待1分鐘并不是什么很大的問題，但假如有一個惡意的攻擊者大量模擬這種情況，服務器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接，即使是簡單的保存并遍歷也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的ip進行SYN+ACK的重試。實際上假如服務器的TCP/IP棧不夠強大，最后的結果往往是堆棧溢出崩潰---即使服務器端的系統足夠強大，服務器端也將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求（究竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，服務器失去響應，這種情況我們稱作：服務器端受到了SYNFlood攻擊（SYN洪水攻擊）。
而Smurf、TearDrop等是利用ICMP報文來Flood和IP碎片攻擊的。
但是以上的DOS方法的目的無非都是讓服務器大量消耗資源和超時連接，那么除了超時連接，能不能用“正常連接”的方法來產生拒絕服務攻擊呢？
再來看看19端口的定義：
字符產生器協議（CharacterGeneratorPRotocol）
字符產生器服務器一個有用的調試工具。無論接收到的是什么，它都返回特定的數據。
基于TCP的字符產生器服務
此服務可以是一個基于TCP的服務，TCP端口19是用于此服務的。一旦連接建立，服務器會傳送一個字符流。接收到的信息會被拋棄。字符流會在用戶請求下中止。用戶可能會非正常中止一個連接，因此此服務必須預備處理這種情況。傳輸的速度會由TCP流控制機制負責，用戶不必關心數據太快，而用戶來不及處理。
19端口在早期已經有人用來做Chargen攻擊了，即Chargen_Denial_of_Service，但是！他們用的方法是在兩臺Chargen服務器之間產生UDP連接，讓服務器處理過多信息而DOWN掉，那么，干掉一臺WEB服務器的條件就必須有2個：1.有Chargen服務2.有HTTP服務
實際上，現在是無法找到這么多同時開放兩個這兩個服務的服務器的。
看看開頭的HTTP協議特性，和Chargen比較一下，你發現了什么？哈哈~~~沒錯！一個是無論接收到什么報文都會回應，一個是一旦連接建立就會發送報文，看看示意圖：
發送請求------------------------------------->
客戶端----------------------------------------------------------服務器
<-------------------------------------------回應
假如把客戶端改為Chargen，就是以下情況：
字符流--------------------------------------->
Chargen----------------------------------------------------------服務器
<-----------------------------------400BadRequest
也就是說，這兩者會產生利害沖突，可以這樣比喻：兩個人吵架，你罵一句，他還一句，這就是循環過程，除非有一方停止或第三者干涉，否則這將是個Do...Loop循環！
搬到HTTP和Chargen來說，就是因為這兩者的特性正好天生一對，那好，就從這里下手：
攻擊者偽造源IP給N臺Chargen發送連接請求（Connect），如有必要還可以發送（Send）個“FUCkyou”報文過去，Chargen接收到連接后就會返回每秒72字節的字符流（實際上根據網絡實際情況，這個速度更快）給服務器，HTTP協議處理這個報文時當然會識別為400BadRequest而返回一條錯誤說明給它，接下來的情況嘛………………自己發揮想像力，別問我。
我用自己的機器（640kbpsADSL）+VBWinsock程序做測試，只用了3秒鐘，程序就因為內存溢出而崩潰了（主要是TextBox的問題，它接受文本的最大范圍為64KB），就是說，3秒鐘內Chargen就發送了大于64KB的字符流！假如用大于10臺的Chargen一起發起攻擊，其速度足以大量消耗服務器資源和帶寬，使服務器回應緩慢甚至DOWN掉！
新聞熱點
疑難解答
