（1）從應(yīng)用層上來看，攻擊者每次攻擊時(shí)，與8300端口都有建立最多兩、三百個(gè)tcp連接。
（2）從防火墻監(jiān)控來看，攻擊的流量非常微小，以至于防火墻的流量報(bào)警都未觸發(fā)。
（3）每次攻擊產(chǎn)生時(shí)，原先的玩家的tcp連接并未斷開（應(yīng)用程序未拋出TCP連接斷開的異常），但服務(wù)端的再也接收不到來自客戶端的任何消息。服務(wù)端進(jìn)程的CPU飆到100%，而內(nèi)存使用未發(fā)現(xiàn)異常。
（4）而且服務(wù)端也從未接收到來自攻擊者的tcp連接的任何消息。
（5）我們對(duì)tcp半連接進(jìn)行了監(jiān)控，排除了基于tcp的半連接攻擊。
（6）重啟服務(wù)端程序后，一切恢復(fù)正常。
我們的動(dòng)作以及思考：
（1）最開始，我們以為是服務(wù)端程序出現(xiàn)問題，導(dǎo)致CPU 100%，后來通過詳細(xì)檢查程序代碼，并使用文本日志定時(shí)記錄程序每個(gè)線程的狀態(tài)（每5秒鐘一次），排除了這一可能性。也就是說，在攻擊的過程中，服務(wù)端內(nèi)的各個(gè)線程的運(yùn)行都是正常的。（后來，我們進(jìn)一步確認(rèn)了這一點(diǎn) -- 我們?cè)谟螒蚍⻊?wù)器前加了一個(gè)簡(jiǎn)單的tcp代理服務(wù)器，游戲服務(wù)器不再對(duì)外暴露，所有客戶端都與代理服務(wù)器連接，由代理服務(wù)器在游戲服務(wù)器和客戶端之間轉(zhuǎn)發(fā)所有的數(shù)據(jù)，結(jié)果代理服務(wù)器被攻擊，代理服務(wù)器的代理程序進(jìn)程的cpu達(dá)到100%（也是重啟代理程序即恢復(fù)正常），而游戲服務(wù)器進(jìn)程一直正常）。
（2）排除程序的問題后，我們開始懷疑攻擊者攻擊的是TCP/IP協(xié)議棧（也許是根據(jù)TCP/IP的一些漏洞進(jìn)行攻擊），而導(dǎo)致操作系統(tǒng)在處理底層的TCP/IP數(shù)據(jù)報(bào)時(shí)，陷入忙碌的狀態(tài)，而導(dǎo)致CPU 100%，而當(dāng)?shù)讓酉萑朊β档臅r(shí)候，來自客戶端的正常消息就來不及接收或者來不及提交到應(yīng)用層（即我們的服務(wù)端程序）了。
我們還未確定，攻擊的方式究竟是什么？以前我們碰到的大多是流量攻擊，而針對(duì)這種低帶寬的攻擊或TCP/IP漏洞攻擊，沒有任何經(jīng)驗(yàn)。不知哪位大俠碰到過類似的情況，能夠指點(diǎn)一二，感激不盡了，呵呵
附：我在網(wǎng)上找到了一些可能與我們的攻擊有關(guān)系的TCP/IP攻擊相關(guān)的資料，與大家共享一下：
（1）TCP協(xié)議堵塞窗口算法攻擊技術(shù) ： http://sec.chinabyte.com/207/8816207.shtml
（2）TCP RST攻擊 ：http://baike.baidu.com/view/1044719.htm
（3）低速率拒絕服務(wù)攻擊原理 ： http://blog.chinaunix.com/u/12592/showart_2058363.html
（4）TCP漏洞可導(dǎo)致致命DoS攻擊 ：http://sec.chinabyte.com/279/8339279.shtml
（5）淚滴攻擊 ： http://baike.soso.com/v4492311.htm
（6）Land攻擊 ： http://baike.soso.com/v4194619.htm?pid=baike.box
喜歡 
頂
難過
囧
圍觀
無聊
