[摘要]近些年，標(biāo)準(zhǔn)化社區(qū)已經(jīng)開(kāi)發(fā)出一些UDP穿透NAT/防火墻的技術(shù)（也就是，在NAT之后的主機(jī)之間建立UDP流）。然而，由于TCP連接建立的不對(duì)稱特點(diǎn)，TCP的NAT穿透要困難的多。最近，研究者們提出了多種TCP穿透NAT的途徑，然而，這些方法中，成功的都依賴于NAT對(duì)各種TCP（和TCMP）包的序列如何響應(yīng)的。本文對(duì)TCP穿透主流商用NAT產(chǎn)品的主要技術(shù)進(jìn)行了首次深入、廣泛的研究。我們開(kāi)發(fā)了一套公開(kāi)、有效的軟件測(cè)試套件用來(lái)測(cè)定NAT對(duì)各種獨(dú)立探測(cè)以及完整的TCP連接建立的響應(yīng)。我們?cè)趯?shí)驗(yàn)室測(cè)試了16個(gè)NAT產(chǎn)品，在公網(wǎng)上測(cè)試了93個(gè)家用NAT產(chǎn)品。根據(jù)這些測(cè)試結(jié)果，如同NAT產(chǎn)品的市場(chǎng)宣傳那樣，我們?cè)u(píng)估了家用網(wǎng)絡(luò)中NAT穿透成功的可能性。本文的另外一個(gè)出發(fā)點(diǎn)，就是可以給TCP穿透NAT協(xié)議的設(shè)計(jì)和NAT/防火墻行為的標(biāo)準(zhǔn)化工作給與指導(dǎo)，包括IPv6過(guò)渡期間IPv4與IPv6之間穿透NAT的鑒定。

    1 緒論

    NAT和防火墻通過(guò)阻止外部主機(jī)主動(dòng)連接一個(gè)受保護(hù)的內(nèi)網(wǎng)1主機(jī)的方式破壞了IP連通性模型。如果兩個(gè)終端都被他們各自的NAT或防火墻保護(hù)著，由于發(fā)起連接的終端在另一終端的NAT2之外，通常的TCP連接是不能建立的，除非各自的防火墻安全策略允許這樣的連接。例如，防火墻策略是這樣的：內(nèi)部主機(jī)可以發(fā)起TCP連接，而且兩個(gè)主機(jī)都希望發(fā)起連接。近來(lái)的研究工作已經(jīng)集中在不使用代理或隧道來(lái)建立TCP連接。通過(guò)在NAT上設(shè)置必要的連接狀態(tài)，并仔細(xì)、巧妙地交換TCP包的方式來(lái)建立TCP連接，確實(shí)很輕巧。然而，并不是公網(wǎng)上的所有NAT都用同樣的方式響應(yīng)，所以，造成這些方式在很多情況下失敗。理解NAT的這種行為，測(cè)定他們對(duì)Internet中普遍連通性的原始目標(biāo)的偏移有多少，對(duì)于把他們干凈利索地集成到這種架構(gòu)中是至關(guān)重要的。

    今天的Internet架構(gòu)于TCP/IP設(shè)計(jì)之初的環(huán)境已經(jīng)大不相同。防火墻和NAT經(jīng)常是的建立一個(gè)連接成為不可能，即使連接沒(méi)有違反任何安全策略。例如，通過(guò)隱藏在一個(gè)NAT后面或配置他們的防火墻阻止外入的SYN包，Alice和Bob可能都不允許未授權(quán)的連接。然而，當(dāng)Alice和Bob都同意建立連接的時(shí)候，如果不重新配置他們的NAT，他們也沒(méi)有辦法建立了，因?yàn)锳lice的SYN包會(huì)被Bob的NAT阻止，Bob的SYN包也會(huì)被Alice的NAT阻止。雖然如此，但NAT和防火墻已經(jīng)成為網(wǎng)絡(luò)架構(gòu)中的永久一部分了，而且，很長(zhǎng)一段時(shí)間內(nèi)，仍將會(huì)是。即使IPv6已經(jīng)在全球展開(kāi)，但在過(guò)渡期間，IPv4與IPv6之間的NAT仍將是必須的，而且，為了安全，IPv6防火墻仍將是必須的。因此，使得NAT后面的同意連接的主機(jī)之間能夠彼此通訊的機(jī)制，是必須的。

    通過(guò)STUN，已經(jīng)解決了UDP方式的穿透問(wèn)題。使用STUN，Alice發(fā)送一個(gè)UDP包給Bob，盡管這個(gè)包被Bob的NAT阻止，但卻使Alice的NAT創(chuàng)建了一個(gè)本地狀態(tài)，該狀態(tài)允許Bob的回應(yīng)包到達(dá)Alice而不被Alice的NAT阻止。然后，Bob發(fā)送一個(gè)UDP包給Alice，Alice的NAT認(rèn)為這個(gè)包是第一個(gè)包的網(wǎng)絡(luò)流的一部份，所以路由它通過(guò)；同樣，Bob的NAT把第二個(gè)包（Bob發(fā)給Alice的包）當(dāng)作一個(gè)連接發(fā)起，因此創(chuàng)建本地狀態(tài)并路由Alice的回應(yīng)包。流行的VoIP應(yīng)用程序Skype就是使用的這種方式。不幸的是，建立TCP連接要比這復(fù)雜的多。一旦Alice發(fā)送了她的SYN包，她的操作系統(tǒng)就如同她的NAT一樣，期望從Bob接收到一個(gè)SYNACK包作為回應(yīng)。然而，由于Alice的SYN包被Bob的NAT阻止，Bob的協(xié)議棧根本不會(huì)產(chǎn)生SYNACK。解決這個(gè)問(wèn)題的建議工作很復(fù)雜，因?yàn)閺V域網(wǎng)中與NAT的交互很難理解，而且他們解決該問(wèn)題建議的可行性也是未知的。因此，像Skype中文件傳輸模塊這樣的應(yīng)用程序，就是用了與UDP類似的受限協(xié)議。雖然這種途徑也許可以工作，但我們相信，無(wú)論如何，只要可能，應(yīng)用程序使用本地操作系統(tǒng)的TCP協(xié)議棧是很重要的。這是避免增加協(xié)議棧復(fù)雜性的一部份，而且更重要的是，這么多年以來(lái)，為了高性能和擁賽控制，TCP協(xié)議棧已經(jīng)被仔細(xì)優(yōu)化。

    全部工作可以歸結(jié)為四點(diǎn)：第一，我們鑒別并描述了對(duì)TCP穿透NAT重要的全部NAT特點(diǎn)；第二，我們測(cè)定了多種建議解決途徑中P2P的TCP連接的成功率和各自的特點(diǎn)；第三，基于這些測(cè)定，我對(duì)這些建議途徑提出了改進(jìn)；第四，我們提供了通用的軟件工具，可以用來(lái)測(cè)定NAT的發(fā)展以及P2P應(yīng)用程序中TCP穿透NAT的基礎(chǔ)。總而言之，我們對(duì)穿透NAT的成功率與實(shí)現(xiàn)的復(fù)雜性之間的內(nèi)在均衡為應(yīng)用開(kāi)發(fā)者們提出了建議。最后，我們的結(jié)果可以為NAT和防火墻的標(biāo)準(zhǔn)化進(jìn)程提供指導(dǎo)，使NAT和防火墻具有更好的穿透性，但又不失原有的安全策略。

    本文后面的內(nèi)容安排如下：第二部分討論了建議的TCP穿透NAT的方法；第三部分和第四部分說(shuō)明了我們測(cè)試NAT的組織和觀察到的NAT行為；第五部分分析了端口預(yù)測(cè)；第六部分分析了P2P中TCP連接的建立；第七部分討論了相關(guān)的工作；第八部分對(duì)全文進(jìn)行了總結(jié)。

    2 TCP NAT-Traversal

    這部分我們討論TCP穿透NAT的方法，這些方法在最近的文章中被提出。所有這些方法中，兩個(gè)終端都發(fā)起一個(gè)TCP連接。從每個(gè)主機(jī)向外發(fā)出的SYN包在自己的NAT上創(chuàng)建必要的NAT狀態(tài)。然后，每種方法都通過(guò)本節(jié)描述的不同機(jī)制，把兩個(gè)TCP的嘗試連接轉(zhuǎn)換為一個(gè)單一的連接。這些原始SYN包被發(fā)送的目的地址和端口，通過(guò)端口預(yù)測(cè)決定。端口預(yù)測(cè)允許主機(jī)在發(fā)送外出的SYN之前猜測(cè)NAT為一個(gè)連接的映射，詳細(xì)方法稍后討論。這些方法也需要兩臺(tái)主機(jī)之間相互協(xié)調(diào)。比如通過(guò)第三方或UDP/STUN會(huì)話等這樣的連接代理作為輔助通道，就是一種技巧。一旦建立了直接的TCP連接，輔助通道就可以關(guān)閉了。協(xié)調(diào)機(jī)制在不同的NAT中觸發(fā)不同的行為，這也導(dǎo)致了在很多情況下，所建議的方法會(huì)失敗。而且，終端也可能處在連續(xù)的多個(gè)3NAT后面。這種情況下，所觀察到的行為是整個(gè)通路上所有NAT和防火墻行為的復(fù)合。簡(jiǎn)單的講，我們應(yīng)該明白，這里的NAT是指復(fù)合的NAT/防火墻。

    2.1 STUNT

    在參考文獻(xiàn)[9]中，作者提出了兩種穿透NAT的方法。第一種方法，如圖-1所示，終端雙方都主動(dòng)發(fā)送SYN，且SYN的TTL4要足夠大，大到SYN包能穿過(guò)他們各自的NAT，但TTL又要足夠小，小到穿過(guò)各自的NAT后就過(guò)期而被網(wǎng)絡(luò)丟棄。通過(guò)偵聽(tīng)經(jīng)過(guò)RAW-socket或PCAP向外發(fā)送的SYN，終端可以得知初始TCP的序號(hào)。終端雙方把各自的序號(hào)告訴都能抵達(dá)（連接）的STUN Server，緊接著，STUN Server通過(guò)設(shè)置匹配的序號(hào)構(gòu)造一個(gè)SYNACK來(lái)欺騙雙方（雙方都認(rèn)為該SYNACK是對(duì)方回應(yīng)的）。完成TCP握手任務(wù)的ACK按照正常方式穿過(guò)網(wǎng)絡(luò)。這種方法有四個(gè)潛在的問(wèn)題：第一，它需要終端確定一個(gè)TTL，該TTL足夠大，大到可以穿透自己的NAT，但又要足夠小，小到不能到達(dá)對(duì)方的NAT；第二，作為SYN包的回應(yīng)，比TTL優(yōu)先的ICMP錯(cuò)誤是可能產(chǎn)生的，而且，也可能被NAT認(rèn)為是致命的錯(cuò)誤；第三，NAT可能改變初始SYN的TCP序號(hào)，這樣就可能導(dǎo)致基于原始序號(hào)的欺騙SYNACK到達(dá)NAT時(shí)，被當(dāng)作窗口之外的包；第四，它需要一個(gè)第三方為一個(gè)任意地址產(chǎn)生一個(gè)欺騙包，而該欺騙包很可能被網(wǎng)絡(luò)中各種各樣的進(jìn)出過(guò)濾器丟棄。這些網(wǎng)絡(luò)和NAT實(shí)例在表-1中總結(jié)。

    參考文獻(xiàn)[9]中提出的第二種方法，與參考文獻(xiàn)[5]中提出的方法類似，只有一個(gè)終端發(fā)出一個(gè)低TTL的SYN包，接著該發(fā)送者取消該連接企圖，并在相同的地址和端口創(chuàng)建一個(gè)被動(dòng)的TCP套接字。然后，另一個(gè)終端初始化一個(gè)正常的TCP連接，如圖-1（b）所示。與第一種方法一樣，終端需要挑選一個(gè)恰當(dāng)?shù)腡TL，而且NAT也不能把ICMP錯(cuò)誤當(dāng)作致命錯(cuò)誤。它也需要NAT在一個(gè)向外發(fā)的SYN后，接收一個(gè)向內(nèi)發(fā)的SYN，但包的序號(hào)也不是普通的那種。

    2.2 NATBlaster

    參考文獻(xiàn)[3]中，作者提出了一種與第一種STUN方法類似但取消了IP欺騙需要的方法（如圖-1c所示）。每個(gè)終端發(fā)出一個(gè)低TTL的SYN，并記住協(xié)議棧所使用的TCP序號(hào)。與前面的類似，SYN包在網(wǎng)絡(luò)中被丟棄。兩臺(tái)主機(jī)之間交換各自的序號(hào)，并且每臺(tái)主機(jī)手工產(chǎn)生一個(gè)對(duì)方期望收到的SYNACK包。手工產(chǎn)生的包通過(guò)RAW socket注入網(wǎng)絡(luò)。然而，這并不等同于欺騙，因?yàn)樵摪械脑吹刂放c注入該包的終端地址匹配。一旦收到SYNACK，ACK就被交換了，從而完成了連接建立。與第一種STUNT方法一樣，該方法也需要終端準(zhǔn)確地選擇TTL值，也需要NAT忽略ICMP錯(cuò)誤和NAT改變SYN包序號(hào)的失敗。而且，（該方法）也需要NAT允許一個(gè)外發(fā)的SYN之后緊跟一個(gè)外發(fā)的SYNACK——非正常的另一個(gè)序號(hào)的包。

    2.3 Peer-to-Peer NAT

    參考文獻(xiàn)[6]中，作者利用了TCP規(guī)范[13]中定義的同時(shí)打開(kāi)方案。如圖-1d所示，兩個(gè)終端都通過(guò)發(fā)送SYN包來(lái)創(chuàng)建一個(gè)連接。如果SYN包在網(wǎng)絡(luò)中交叉（穿過(guò)），這兩個(gè)終端協(xié)議棧都用SYNACK包應(yīng)答從而建立連接。如果在對(duì)方的SYN包離開(kāi)它的NAT之前，一個(gè)終端的SYN包到達(dá)該終端的NAT而被丟棄，那么，第一個(gè)終端的協(xié)議棧會(huì)在TCP同時(shí)打開(kāi)之后而結(jié)束（關(guān)閉），而另一個(gè)終端則會(huì)按照正常流程打開(kāi)。接下來(lái)的情況，鏈路中的包看起來(lái)像第二種STUNT方法，沒(méi)有底TTL，也沒(méi)有相關(guān)的ICMP。然而，該方法并沒(méi)有用端口預(yù)測(cè)，如果使用的話，該方法可以從中獲益。與第二種STUNT方法一樣，該方法需要NAT允許在一個(gè)外發(fā)的SYN之后緊跟一個(gè)內(nèi)發(fā)的SYN，而且，該方法需要終端在一個(gè)循環(huán)中不停的嘗試重連，直到超時(shí)。如果不是SYN包被丟棄，而是NAT返回一個(gè)TCP RST，那這種方法將陷入包泛濫的境地，直到超時(shí)。

    2.4 實(shí)現(xiàn)

    我們?cè)贚inux和Windows上實(shí)現(xiàn)了上面所述的所有方法。我們還開(kāi)發(fā)了一個(gè)Windows設(shè)備驅(qū)動(dòng)，它實(shí)現(xiàn)了這些方法所需要的但Windows本身不支持的功能（函數(shù)）。第一種STUNT方法，無(wú)論是在Windows下還是在Linux下，都需要超級(jí)用戶特權(quán)來(lái)監(jiān)聽(tīng)鏈路中的TCP SYN包并獲取其序號(hào)。為了設(shè)置第一個(gè)SYN包的TTL，我們?cè)贚inux下使用了IP_TTL套接字選項(xiàng)，在Windows下使用了我們的驅(qū)動(dòng)。我們還實(shí)現(xiàn)了STUNT Server，并把它部署在ISP后面，為了欺騙任意地址，該ISP不進(jìn)行外出過(guò)濾。雖然該Server可以欺騙大部分SYNACK，但是，如果源和目標(biāo)在同一個(gè)管理域或者該域使用了準(zhǔn)入過(guò)濾，它的欺騙SYNACK就不成功了。等可能的時(shí)候，我們?cè)谶@種域中安裝一個(gè)另外的STUNT Server。第二種STUNT方法需要該驅(qū)動(dòng)來(lái)設(shè)置Windows下的TTL。NATBlaster方法需要超級(jí)用戶特權(quán)來(lái)獲取SYN的序號(hào)并通過(guò)RAW socket注入手工創(chuàng)建的SYNACK。由于Windows XP SP2中引入的限制，該方法需要我們的驅(qū)動(dòng)來(lái)注入（SYNACK）包。P2PNAT方法需要操作系統(tǒng)支持TCP同時(shí)打開(kāi)，Linux和Windows XP SP2支持TCP同時(shí)打開(kāi)，但SP2之前的Window XP都不支持。在Windows XP SP1以及之前的版本中，我們的驅(qū)動(dòng)增加了TCP同時(shí)打開(kāi)的支持。表-1總結(jié)了這些實(shí)現(xiàn)結(jié)果。

    我們發(fā)現(xiàn)，在Windows下設(shè)置TTL是有問(wèn)題的，因此，我們考慮了不使用它的后果。如果TTL不消減，一個(gè)主機(jī)發(fā)送的第一個(gè)SYN，在對(duì)方的SYN離開(kāi)其NAT之前到達(dá)對(duì)方的NAT，那對(duì)方的NAT可以悄無(wú)聲息地丟棄該入站的包，也可以返回一個(gè)ICMP不可達(dá)錯(cuò)誤或一個(gè)TCP RST/ACK。無(wú)論怎樣，回應(yīng)可能觸發(fā)該方法中未說(shuō)明的發(fā)送者NAT以及操作系統(tǒng)棧中的轉(zhuǎn)變。如果發(fā)送到對(duì)方的SYN的TTL不被消減，該SYN可能到達(dá)預(yù)期的目標(biāo)并觸發(fā)無(wú)法預(yù)料的轉(zhuǎn)換。這種行為對(duì)于最終目標(biāo)可能是有利的，例如，如果它觸發(fā)一個(gè)TCP同時(shí)打開(kāi)；如果它擾亂了協(xié)議棧或NAT，則它是有害的。我們實(shí)現(xiàn)了上述方法的修正版，它不使用低TTL。表-1列出了與修正方法對(duì)應(yīng)的網(wǎng)絡(luò)和實(shí)現(xiàn)結(jié)果。

    3 實(shí)驗(yàn)安裝

    我們定義了STUNT client-server協(xié)議，該協(xié)議既可以測(cè)試NAT/防火墻的行為，也可以幫助NAT后面peer之間建立TCP連接。完整的協(xié)議描述請(qǐng)參考文獻(xiàn)[7]。我們的測(cè)試程序?qū)崿F(xiàn)了該協(xié)議，測(cè)試程序包括一個(gè)client組件和一個(gè)server組件。如圖-2所示，client運(yùn)行在一臺(tái)一個(gè)或多個(gè)NAT后面的主機(jī)上，而server則在他們之外。該STUNT測(cè)試client偵測(cè)client和server之間的所有NAT和防火墻的合成行為。雖然測(cè)試client和server都需要超級(jí)特權(quán)來(lái)分析鏈路層的raw socket，但為了降低功能損失并保證client之間的交互，可以降低（取消）該需求（超級(jí)特權(quán)）。而且，該server至少需要兩個(gè)網(wǎng)絡(luò)接口來(lái)正確區(qū)分各種NAT所用的端口分配算法。該client的測(cè)試性能以及由此推演的NAT特點(diǎn)在后面的第四部分描述。

    我們用該client測(cè)試了實(shí)驗(yàn)（表-2）中16個(gè)NAT中多種集合。這些NAT包括了我們?cè)诿绹?guó)的網(wǎng)上商店所能找到的各種品牌NAT。這些測(cè)試NAT也包括了當(dāng)前流行操作系統(tǒng)所實(shí)現(xiàn)的軟件NAT。在每個(gè)實(shí)驗(yàn)測(cè)試中，client主機(jī)是該NAT內(nèi)的唯一主機(jī)，server與該NAT的外部接口在同一以太網(wǎng)段內(nèi)。Client主機(jī)被設(shè)置為只由測(cè)試程序產(chǎn)生網(wǎng)絡(luò)通信，而不產(chǎn)生任何其他的網(wǎng)絡(luò)通信。

    而且，為了這些實(shí)驗(yàn)測(cè)試，我們也測(cè)試了其他NAT設(shè)備。這樣做的主要原因是把我們的測(cè)試軟件暴露給更廣的情況范圍，而不僅僅是我們?cè)趯?shí)驗(yàn)室能夠重現(xiàn)的情況，從而提高它的魯棒性，也增強(qiáng)我們對(duì)它操作性的信心。而且，還提供了一個(gè)示例，雖然小，但可以用它測(cè)試出實(shí)際看到的NAT是什么類型。為此，我們請(qǐng)求家庭用戶運(yùn)行該測(cè)試client，共測(cè)試了計(jì)算機(jī)系、Cornell的學(xué)生以及其他大學(xué)所用的93個(gè)家用NAT，而且，測(cè)試通信是該client主機(jī)與NAT之后的其他主機(jī)之間的典型網(wǎng)絡(luò)活動(dòng)，包括web瀏覽、即時(shí)消息、p2p文件共享以及email等。測(cè)試數(shù)據(jù)告訴我們，NAT品牌與新舊模塊和固件是混合在一起的。當(dāng)然，必須承認(rèn)，在NAT和相關(guān)小用戶的選擇上是存在偏見(jiàn)的，他們大部分在美國(guó)的東北部。這種差異在表-3中很明顯，我們示例中觀察到的品牌普及率在“Sample”列中，Synergy Research Group調(diào)查的2005年第一季度的世界SOHO/家用廣域網(wǎng)市場(chǎng)品牌份額在“Market Survey”列中。特別要說(shuō)明的是，Buffalo科技和Netgear（的NAT）在我們的示例中表現(xiàn)一般，其他品牌的（NAT的市場(chǎng)份額）明顯更高。家用NAT測(cè)試的完整列表請(qǐng)參考文獻(xiàn)[8]。

    4 NAT TCP特點(diǎn)

    這一節(jié)，我們確定不同NAT怎樣影響TCP的NAT穿透方法。根據(jù)NAT的行為，我們劃分了五個(gè)類別，即NAT映射、終端包過(guò)濾、過(guò)濾應(yīng)答、TCP序號(hào)預(yù)留和TCP定時(shí)器。每個(gè)類別的分類和NAT能夠接收到的值之間的關(guān)系如表-4所示。我們使用STUNT的測(cè)試client和前面第三節(jié)中描述的server對(duì)實(shí)驗(yàn)室中的16個(gè)NAT和世界各地的93個(gè)NAT進(jìn)行了分類。完整的測(cè)試結(jié)果以及更廣范圍的分類集合在參考文獻(xiàn)[8]中有描述。

    4.1NAT映射

    NAT為每個(gè)基于源和目的IP和端口的TCP連接選擇一個(gè)對(duì)外映射。在某些條件下，有些NAT會(huì)重用已經(jīng)存在的映射，而有些則每次都分配新的映射。NAT映射類別就捕捉這些映射行為的不同。這對(duì)于那些企圖穿透NAT的終端來(lái)說(shuō)非常有用，因?yàn)檫@可以讓他們基于之前的連接來(lái)預(yù)測(cè)一個(gè)（新）連接的映射地址和端口。根據(jù)參考文獻(xiàn)[15]，對(duì)于UDP來(lái)說(shuō)，我們知道，有些NAT為那些從同一個(gè)源地址和端口產(chǎn)生的所有連接，總是分配一個(gè)固定的地址和端口。用STUNT的client，我們測(cè)試了TCP的類似行為。如圖-3和表-5所示，該（STUNT）client快速連續(xù)從固定的本地地址和端口a:p向不同server地址和端口建立了12個(gè)連接。每個(gè)連接在下一個(gè)連接產(chǎn)生之前關(guān)閉。Server把其感知到的映射地址和端口返回給該client。測(cè)試選擇了多個(gè)不同的本地端口重復(fù)了多次。

    從表-5中的NAT1——NAT6的端口映射中，我們注意到幾個(gè)截然不同的模式。假設(shè)每個(gè)NAT為第一個(gè)連接分配的映射叫做A:P，只要該client新連接的源地址和端口與第一次連接的相同，NAT1就一直重用該映射。我們把這種行為歸類為NB:Independent，因?yàn)橛成渲挥稍吹刂泛投丝跊Q定，而獨(dú)立于目的地址和端口。這與參考文獻(xiàn)[15]中擴(kuò)展到包括TCP的“cone behavior”相同。只要新連接的源和目標(biāo)的地址和端口與第一次連接的匹配，NAT2就重用該映射。這種NAT杯歸類為NB:Address and Port1，因?yàn)槟繕?biāo)地址和端口都影響映射。下標(biāo)“1” 表示兩個(gè)新映射之間的差，用δ表示，就是1。參考文獻(xiàn)[17]中表明，對(duì)UDP來(lái)說(shuō)，許多NAT的δ是固定的，通常是1或2。我們發(fā)現(xiàn)NAT對(duì)TCP也有同樣的特點(diǎn)，而且，我們所遇到的NAT，δ都為1。NAT3為每個(gè)新連接分配一個(gè)新的映射，盡管每個(gè)新映射的端口只比前一個(gè)（映射的）端口大1，即δ=1。我們把NAT3歸類為NB:Connection1。與NAT3類似，NAT4為每個(gè)TCP連接分配一個(gè)新的映射，但兩個(gè)并發(fā)映射之間卻沒(méi)有區(qū)分模式。我們把這類NAT歸類為NB:ConnectionR，下標(biāo)R表示δ是隨機(jī)的。NAT5是NAT2的一個(gè)變種，在NAT5中，只要目標(biāo)端口匹配就重用該映射，去除了源地址和端口（也匹配的條件）。NAT6也與此類似，只是用目標(biāo)地址代替了目標(biāo)端口的匹配。NAT5和NAT6各自被歸類為NB:Port1和NB:Address1。NAT2~6呈現(xiàn)的對(duì)稱行為參見(jiàn)[15]。

    表-6給出了每種NAT的相關(guān)比例。第二列是我們測(cè)試了的16個(gè)NAT中按照特定類型歸類的NAT個(gè)數(shù)。其中大部分是NB:Independent。唯一的一個(gè)NB:ConnectionR是OpenBSD中pf工具中實(shí)現(xiàn)的NAT。我們也發(fā)現(xiàn)我們的固件版本為5.13的Netgear RP614是NB:Connection1，而最近的NetgearNAT，如固件為5.3_05的MR814V2，則是NB:Independent。第三列則是估計(jì)的實(shí)驗(yàn)室之外的NAT行為。估計(jì)值是根據(jù)87個(gè)家用NAT樣本按照各自的類型和品牌的比例進(jìn)行計(jì)算的，并按照一個(gè)修正因子進(jìn)行了縮放，以此來(lái)避免我們所選樣本的偏見(jiàn)。每個(gè)品牌的修正因子都是表-3中的調(diào)查與觀察的市場(chǎng)份額的比率。該修正因子用來(lái)增加評(píng)估結(jié)果中表現(xiàn)不好的貢獻(xiàn)，降低表現(xiàn)太好的貢獻(xiàn)。雖然我們的評(píng)估很好的反映了我們所期望的趨勢(shì)，但我們也明白，在如今每年47%的工業(yè)變化率下，任何結(jié)果的正確性都不會(huì)持續(xù)太久。不過(guò)，我們?cè)u(píng)估出多數(shù)（70.1%）的NAT是NB:Independent類型的，幾乎沒(méi)有NB:ConnectionR類型的NAT。很大比例（29.9%）的NAT有對(duì)稱行為，因此，更多的情況下，從同一個(gè)端口發(fā)出的多個(gè)連接將不被分配到相同的映射，所以，應(yīng)用不得不使用后面描述的更成熟的端口預(yù)測(cè)技術(shù)。

    4.2 終點(diǎn)過(guò)濾

    NAT和防火墻都可能過(guò)濾尋址到某個(gè)端口的進(jìn)入包，除非（這些包）滿足一定的條件。如果那個(gè)端口上不存在NAT映射，NAT就會(huì)強(qiáng)制過(guò)濾掉包，所以，它就不能再前進(jìn)。然而，如果映射已經(jīng)存在，或者設(shè)備是防火墻的話，那就可能需要進(jìn)入包的源地址和（或）端口與之前的外出包的目的地匹配。這些觸發(fā)過(guò)濾條件的不同，是通過(guò)終點(diǎn)過(guò)濾分類捕捉的。STUNT的測(cè)試client通過(guò)連接（STUNT）server而首先設(shè)置NAT狀態(tài)來(lái)決定（是否過(guò)濾進(jìn)入包）的，然后再請(qǐng)求server從不同的地址和端口向已經(jīng)映射好的地址和端口發(fā)起連接（請(qǐng)求），如圖-4所示。

    根據(jù)該測(cè)試所觀察到的不同過(guò)濾行為如表-7所示。Nat1’接受所有三個(gè)SYN包。這種NAT允許進(jìn)入的TCP連接與源地址和端口無(wú)關(guān)，只要路由該請(qǐng)求的必要狀態(tài)存在即可。我們把這種NAT分類為有終點(diǎn)過(guò)濾行為，即EF:Independent。Nat2過(guò)濾所有進(jìn)入包，因此需要進(jìn)入的TCP報(bào)的源與創(chuàng)建映射的（TCP）連接的目的地址和端口都匹配。這種NAT的終點(diǎn)過(guò)濾被分類為EF:Address and Port。Nat3’和Nat4’允許與該連接目的地有相同地址或端口的包進(jìn)入，但各自會(huì)過(guò)濾從不同地址或不同端口來(lái)的包。我們把這種終點(diǎn)過(guò)濾分別分類為EF:Address和EF:Port。我們發(fā)現(xiàn)，通常情況下，一個(gè)NAT的終點(diǎn)過(guò)濾行為與NAT的映射行為無(wú)關(guān)。參考文獻(xiàn)[15]中定義的cone NAT的子類轉(zhuǎn)換為如下：full cone就等于NB:Independent和EF:Independent；restricted cone對(duì)應(yīng)于NB:Independent和EF:Address；port restricted cone與NB:Independent和EF:Port對(duì)應(yīng)。

    Table 7:NAT endpoint filtering behavior observed. Nat10–Nat40 show 4 different filtering behaviors that are observed or inbound SYN packets after an internal host establishes a connection from a:p to B:Q with allocated mapping A:P

    表-8列出了實(shí)驗(yàn)室中16個(gè)NAT的終點(diǎn)過(guò)濾分類和估計(jì)的實(shí)驗(yàn)室之外NAT的百分比。估計(jì)是基于前面所述的市場(chǎng)調(diào)查來(lái)計(jì)算的。81.9%的NAT估計(jì)是EF:Address和EF:Port，而只有5.8%的是EF:Independent。這表明，大多數(shù)情況下，若要兩臺(tái)NAT之后的主機(jī)要建立連接的話，外發(fā)的SYN必須在進(jìn)入包被接收前從每個(gè)終端發(fā)出。

    4.2.1 TCP狀態(tài)追蹤

    NAT實(shí)現(xiàn)一個(gè)狀態(tài)機(jī)來(lái)追蹤終端的TCP進(jìn)展，并決定連接狀態(tài)何時(shí)可以回收。雖然所有的NAT都能正確地處理TCP的三次握手，但并不是所有的NAT都正確地實(shí)現(xiàn)了TCP狀態(tài)機(jī)的特殊情況，因而導(dǎo)致提前終止連接狀態(tài)。通過(guò)為這些方法重復(fù)（發(fā)送）觀察到的包順序，STUNT的client和server測(cè)試了NAT/防火墻的實(shí)現(xiàn)如何影響TCP穿透NAT的方法。

    表-9列出了部分測(cè)試的包順序。我們估計(jì)，13.6%的NAT不支持TCP同時(shí)打開(kāi)，即通過(guò)一個(gè)進(jìn)入的SYN緊跟在一個(gè)外出的SYN之后。這就影響P2PNAT方法，因?yàn)樵摲椒ㄐ枰辽僖粋€(gè)終端要像第二種STUNT方法那樣支持同時(shí)打開(kāi)（TCP）。6.9%的（NAT）會(huì)在ICMP TTL短暫的超時(shí)錯(cuò)誤后就過(guò)濾掉進(jìn)入的SYNACK包。與此差不多數(shù)量的NAT會(huì)在ICMP之后丟棄進(jìn)入的SYN，但如果沒(méi)有錯(cuò)誤，則會(huì)接受該SYN。這種行為影響所有要設(shè)置SYN包低TTL的方法。大部分NAT（28.1%）接受進(jìn)入的SYN包，即使創(chuàng)建連接狀態(tài)的SYN包遇到了嚴(yán)重的TCP RST（錯(cuò)誤），這就減輕了欺騙RST的問(wèn)題，盡管有些方法可對(duì)付欺騙RST問(wèn)題。表中沒(méi)有提到的是NATBlaster方法中需要的SYN-out和SYNACK-out的順序。由于Windows XP SP2引入的限制，我們沒(méi)有全面的測(cè)試這種情況，然而，在實(shí)驗(yàn)室，我們發(fā)現(xiàn)D-Link NAT（DI-604）就不支持它（SYN-out和SYNACK-out順序）。

    4.2.2 過(guò)濾應(yīng)答

    當(dāng)一個(gè)進(jìn)入包被NAT過(guò)濾后，NAT可以選擇只是安靜的丟棄該包，或者通知發(fā)送者。據(jù)估計(jì)，約91.8%的NAT只是簡(jiǎn)單地丟棄這些包，而沒(méi)有任何通知。其余的NAT會(huì)為冒犯的包發(fā)送回一個(gè)TCP RST確認(rèn)的錯(cuò)誤信號(hào)。

    4.3 包破壞

    NAT改變外發(fā)包的源地址和端口以及進(jìn)入包的目標(biāo)地址和端口，而且，他們需要轉(zhuǎn)換出ICMP有效負(fù)載中封裝報(bào)的地址和端口，從而終端能夠使ICMP與他們各自的傳輸套接字匹配。我們的樣本集合中的所有NAT，要么正確地轉(zhuǎn)換ICMP，要么過(guò)濾ICMP包，這些被過(guò)濾的ICMP包并不總是首先產(chǎn)生。一些NAT通過(guò)給外發(fā)包的序號(hào)加一個(gè)恒定的偏移值、給進(jìn)入包的確認(rèn)序號(hào)減去相同的偏移值來(lái)改變TCP序號(hào)。我們估計(jì)，約8.4%的NAT改變TCP序號(hào)。因此，有些情況下，那些需要離開(kāi)NAT的包有初始序號(hào)的TCP穿透NAT的方法不能使用該終端SYN的序號(hào)來(lái)替代。

    4.4 TCP定時(shí)器

    NAT和防火墻不能隨便控制狀態(tài)，因?yàn)檫@樣使他們很容易受到DoS攻擊。相反，他們終止空閑連接，并刪除崩潰或行為不軌終點(diǎn)的連接狀態(tài)。而且，他們監(jiān)控TCP標(biāo)記，從由于FIN/FINACK交換或RST包而明確關(guān)閉的連接中恢復(fù)狀態(tài)。他們可能允許一些過(guò)渡時(shí)間來(lái)使那些已經(jīng)在傳輸中的包以及重傳被傳送。一旦連接狀態(tài)不能被分配，任何基于該連接的后續(xù)達(dá)到的包都會(huì)被過(guò)濾掉。通常，NATs為這些情況使用不同的定時(shí)器，如圖-5所示。在圖中位置1和位置3處，使用一個(gè)短的定時(shí)器，分別用來(lái)終止還沒(méi)有建立的連接或已經(jīng)被關(guān)閉的連接。RFC1122規(guī)定，為了傳遞那些已經(jīng)在傳輸中的包，終端機(jī)要等待4分鐘（即2倍的MSL5），然而，大部分操作系統(tǒng)都只等待約1分鐘。在圖-5的位置2處，為已經(jīng)建立的空閑連接，NAT使用一個(gè)常定時(shí)器，RFC1122中對(duì)應(yīng)的規(guī)定是，在空閑連接上（兩次）發(fā)送TCP-Keeplive包之間，TCP協(xié)議棧最少應(yīng)該等待2小時(shí)。

    STUNT測(cè)試client檢測(cè)了NAT定時(shí)器的實(shí)際情況與RFC規(guī)范的符合性。通過(guò)三個(gè)定時(shí)測(cè)試來(lái)分別檢測(cè)每種情況。在第一個(gè)測(cè)試中，由client發(fā)起連接，但從server發(fā)出的SYNACK被延遲幾分鐘；第二個(gè)測(cè)試中，連接被建立后，空閑2小時(shí)，這時(shí)再?gòu)膶?duì)面的server發(fā)送幾個(gè)字節(jié)；在第三個(gè)測(cè)試中，連接建立，然后被關(guān)閉，但最后從server發(fā)出的ACK被延遲約一分鐘。在各種情況下，如果引入延遲后，從server發(fā)出的包仍被傳遞到client，那對(duì)應(yīng)的定時(shí)器就被稱為保守派；相反就被稱為激進(jìn)派。我們估計(jì)，所有三種情況中，只有27.3%的NAT有保守定時(shí)器，而第二種情況則有35.8%的NAT有保守定時(shí)器。第二種情況，21.8%的NAT有非常激進(jìn)的定時(shí)器，不活動(dòng)時(shí)間不到15分鐘，他們就終止已經(jīng)建立的連接。這說(shuō)明，應(yīng)用不應(yīng)該依靠空閑連接到維持（連接）打開(kāi)太久（超過(guò)幾分鐘）。

    5 端口預(yù)測(cè)

    端口預(yù)測(cè)允許一臺(tái)主機(jī)在連接被創(chuàng)建之前預(yù)測(cè)該連接被映射的地址和端口。因此，它（端口預(yù)測(cè)）允許兩臺(tái)主機(jī)與彼此的映射地址和端口發(fā)起連接，即使映射是在連接發(fā)起之后分配的。圖-6顯示了使用端口預(yù)測(cè)信息實(shí)現(xiàn)的一個(gè)典型的TCP穿透NAT的嘗試。圖中，我們假設(shè)A已經(jīng)決定了它正使用的NAT類型。當(dāng)clientA希望與clientB建立一個(gè)連接的話，A首先與STUNT server建立一個(gè)TCP連接，并獲得映射（信息）。根據(jù)NAT M的NB類型，A預(yù)測(cè)出下一個(gè)連接的映射。B也作同樣的事（連接STUNT server并預(yù)測(cè)出下一連接的映射），且A和B通過(guò)這種非直接的通道交換他們的預(yù)測(cè)信息。每個(gè)終端通過(guò)發(fā)送一個(gè)SYN包發(fā)起一個(gè)與對(duì)方映射地址和端口的連接。其余被交換的包設(shè)計(jì)為使兩個(gè)TCP嘗試協(xié)調(diào)為一個(gè)連接，如第二節(jié)描述的那樣，不同的穿透方法，交換包的設(shè)計(jì)也各有不同。第一個(gè)SYN與目標(biāo)連接的SYN之間的空隙可能是一個(gè)攻擊點(diǎn)，這依賴于NAT M的類型。對(duì)于有些類型的NAT來(lái)說(shuō)，如果NAT M后面的另一個(gè)內(nèi)部主機(jī)A’在該空隙間發(fā)起另一個(gè)連接的話，M將會(huì)把A預(yù)測(cè)的映射分配給A’發(fā)起的連接。

    端口預(yù)測(cè)依賴于前面4.1節(jié)所探討NAT映射類型。如果NAT是NB:Independent類型，那之后從相同源地址和端口發(fā)起的任何連接將會(huì)重用連接STUNT server的映射。因此，映射重用完全在client的控制之下，這種情況下，攻擊點(diǎn)也就不存在了。然而，這種方法引入了一個(gè)潛在的問(wèn)題，那就是在映射能夠被預(yù)測(cè)之前，可能需要兩倍的到STUNT server的RTT6。可能的優(yōu)化是，我們注意到，大多數(shù)NAT通常分配一個(gè)與client所用的源端口相同的映射端口。我們稱這些NAT為端口保留（型NAT）。處在這種NAT之后的client，即使沒(méi)有首先與STUNT server建立連接，也能預(yù)測(cè)出被映射的端口，且有很高的概率。如果NAT不是NB:Independent類型，但有固定的δ，那么，與（STUNT）server連接之后立即發(fā)起的連接，將會(huì)有一個(gè)映射端口，該映射端口比server觀察到的映射端口大δ。由于從連接到連接映射的變化，攻擊點(diǎn)中的“流氓”連接的嘗試能夠竊取到該映射。而且，如果被預(yù)測(cè)的映射已經(jīng)被使用，這種方法會(huì)失敗，從而導(dǎo)致NAT的分配規(guī)則跳過(guò)它而直接到下一個(gè)有效的映射。

    在STUNT測(cè)試client中，我們實(shí)現(xiàn)了端口預(yù)測(cè)，且在一小時(shí)內(nèi)預(yù)測(cè)了83個(gè)家庭用戶的映射。每分鐘，測(cè)試client從一個(gè)源地址和端口發(fā)起一個(gè)到STUNT server的連接；然后，再用相同的源地址和端口向?yàn)樵搶?shí)驗(yàn)?zāi)康亩惭b的一臺(tái)遠(yuǎn)程主機(jī)發(fā)起一個(gè)連接。測(cè)試client檢查基于第一個(gè)連接映射所預(yù)測(cè)的映射與相對(duì)應(yīng)的第二個(gè)連接實(shí)際觀察到的映射（是否匹配）和NAT類型。如果，且只要他們匹配，端口預(yù)測(cè)就成功。當(dāng)用戶正常使用他們的主機(jī)和網(wǎng)絡(luò)過(guò)程中，端口預(yù)測(cè)才被執(zhí)行（才會(huì)激活（用的上）端口預(yù)測(cè)），這（正常使用主機(jī)和網(wǎng)絡(luò)）包括web瀏覽器、email閱讀器、即時(shí)消息以及在client主機(jī)和處在相同NAT后面的其他主機(jī)上運(yùn)行的文件共享應(yīng)用。88.9%的NB:Independent類型的NAT是端口保留的。這就說(shuō)明對(duì)實(shí)現(xiàn)上述優(yōu)化的交互應(yīng)用來(lái)說(shuō)是很有好處的。我們發(fā)現(xiàn)，81.9%的情況下，端口每次都被準(zhǔn)確的預(yù)測(cè)，這包括所有的NB:Independent類型的NAT和37.5%的非NB:Independent類型的NAT，只有一種NB:Independent類型的NAT除外。對(duì)于剩下的其余62.5%的各種NAT來(lái)說(shuō)，60個(gè)其他主機(jī)或應(yīng)用中最少就有一個(gè)“竊取”了測(cè)試client自身預(yù)測(cè)的映射。其中一個(gè)特例中，處在NB:Connection1類型NAT后面的client主機(jī)被感染了病毒，病毒每秒鐘產(chǎn)生多個(gè)隨機(jī)地址的SYN包，從而導(dǎo)致所有的預(yù)測(cè)失敗。另一個(gè)情況是，中途用戶通過(guò)該測(cè)試發(fā)起一個(gè)VPN連接，導(dǎo)致所有后續(xù)的請(qǐng)求都被經(jīng)過(guò)VPN發(fā)送，因而也就通過(guò)一個(gè)不同類型的NAT。這說(shuō)明，長(zhǎng)時(shí)間運(yùn)行的應(yīng)用可能會(huì)緩存一段時(shí)間的NAT映射類型，但必須及時(shí)更新使其有效。考慮所有情況的話，94.0%，也就是超過(guò)四分之三的端口預(yù)測(cè)是正確的。因此，一次嘗試失敗之后，如果應(yīng)用簡(jiǎn)單地再嘗試連接的話，很可能就成功了。

    5.1 問(wèn)題

    端口預(yù)測(cè)有幾個(gè)特殊例外的情況，在這些特殊情況下，端口預(yù)測(cè)可能失敗。圖-7中，當(dāng)A嘗試與C建立一個(gè)連接的時(shí)候，如果用STUNT server T來(lái)預(yù)測(cè)地址和端口的話，那A將會(huì)因獲得NAT M的外部地址而不是NAT O的外部地址而告終。端口預(yù)測(cè)要求，client與STUNT server之間的（連接）線路與client和他所希望連接主機(jī)的大部分外部NAT之間的（連接）線路相同。因此，由于某些原因，為了連接C，A需要找到S。然而，如果A希望與B通信的話，且A和B都使用STUNT server S，那他們的端口預(yù)測(cè)嘗試可能相互干擾，從而妨礙任何一方正確地預(yù)測(cè)端口。而且，即使端口預(yù)測(cè)正確，A和B也將由于使用O的外部地址而終止（連接）。這種情況被稱為hairpin translation，因?yàn)閺腁發(fā)向B的預(yù)測(cè)地址和端口（這里是O的地址）的SYN將被傳遞到O，而O則需要把它（A發(fā)出的SYN）通過(guò)一個(gè)內(nèi)部接口發(fā)送回去。不是所有的NAT都能正確處理hairpin translation，根據(jù)STUNT測(cè)試client所進(jìn)行的測(cè)試，我們估計(jì)，這種錯(cuò)誤行為高達(dá)72.8%。

    前面描述的端口預(yù)測(cè)技術(shù)不能處理NB:ConnectionR類型的NAT，這是由于連續(xù)的連接會(huì)被隨機(jī)分配。參考文獻(xiàn)[3]中提出了一種有趣的技術(shù)來(lái)處理這種情況，即在沖突發(fā)生前使用“生日悖論”來(lái)減少猜測(cè)的次數(shù)。該技術(shù)初始化439個(gè)連接，這樣，被猜測(cè)的端口將有95%的可能性與其中的一個(gè)匹配。不幸的是，我們發(fā)現(xiàn)，有些NAT，如Netgear，限制掛起連接嘗試的總數(shù)為1000，這就造成這種方法很快塞死NAT。幸運(yùn)的是，幾乎沒(méi)有NAT證明NB:ConnectionR行為減輕（緩解）這個(gè)問(wèn)題。

    6 TCP建立

    這一節(jié)，通過(guò)測(cè)試小范圍P2P的TCP建立，我們估計(jì)各種NAT穿透方法的成功（幾率），也給出我的經(jīng)過(guò)。TCP穿透NAT方法的成功，依賴于兩臺(tái)終端機(jī)之間所有NAT的行為，也依賴于這些NAT后面其他主機(jī)的活動(dòng)。第四節(jié)分析了相對(duì)獨(dú)立情況下的各種NAT，而第五節(jié)則分析了競(jìng)爭(zhēng)網(wǎng)絡(luò)活動(dòng)以及對(duì)端口預(yù)測(cè)的影響。結(jié)合這兩節(jié)的結(jié)果，我們可以從數(shù)量上估計(jì)出每種NAT穿透方法的成功（幾率）。關(guān)于TCP穿透方法的部署，我們作了如下的假設(shè)。我們假設(shè)STUNT server部署的足夠廣泛，可以確保每一對(duì)client都有一個(gè)STUNT server滿足端口預(yù)測(cè)的要求，也能都欺騙從每個(gè)client的映射地址和端口出現(xiàn)的包。我們假設(shè)終端機(jī)的堆棧固定，因此終端上所有軟件問(wèn)題可以解決。最后，由于我們?nèi)狈?shù)據(jù)來(lái)模擬5.1節(jié)所呈現(xiàn)的情況，我們假設(shè)這種情況的貢獻(xiàn)可以或略不計(jì)。作為這些假設(shè)的結(jié)果，我們的估計(jì)可能比較理想。

    P2P的TCP建立依賴與兩個(gè)終端的NAT。如果另一個(gè)（對(duì)方）終端的NAT可以預(yù)測(cè)，那一個(gè)不可預(yù)測(cè)NAT后面的終端仍能夠建立一個(gè)連接；但如果另一個(gè)終端的NAT也不可預(yù)測(cè)，那就不能建立起連接。通過(guò)考慮實(shí)際觀察到的所有NAT行為，我們?cè)u(píng)估了廣泛的TCP連通性。圖-8繪制出了各種TCP穿透NAT方法的成功率圖。我們繪制兩種STUNT方法（#1和#2），即參考文獻(xiàn)[9、3、6]中提出的NATBlaster和P2PNAT的圖示。而且，我們還繪制了STUNT#1和#2（方法）修改版的圖示以及未使用低TTL的NATBlaster方法的圖示。我們還繪制了使用端口預(yù)測(cè)的修改版P2PNAT方法的圖示。這些（穿透）方法中，有些方法中的SYN包之間存在競(jìng)爭(zhēng)條件，從而導(dǎo)致某些特定的NAT之間的欺騙包。淺灰色的柱表示當(dāng)每個(gè)終端都有均等的機(jī)會(huì)贏得競(jìng)爭(zhēng)情況下發(fā)送的成功率，這與終端雙方同時(shí)調(diào)用方法相對(duì)應(yīng)。深灰色的柱表示，當(dāng)為了有利于成功連接而打破這種競(jìng)爭(zhēng)時(shí)的成功率，這與雙方各自調(diào)用（先后，也就是不同時(shí)）方法的情況對(duì)應(yīng)，對(duì)于第一個(gè)調(diào)用，一個(gè)終端比對(duì)方稍微早一點(diǎn)點(diǎn)發(fā)起（連接），而對(duì)于第二個(gè)調(diào)用，則順序剛好與此相反。在建立TCP連接中，只要任何一方的調(diào)用成功，該嘗試（連接）就宣布成功。

    如圖所示，原來(lái)所提出的方法中，P2PNAT和STUNT#1的成功率分別是44.6%和73.4%。通過(guò)每個(gè)終端再多嘗試一次來(lái)打破競(jìng)爭(zhēng)條件后，原來(lái)的STUNT#2方法把其成功率提升到了86.0%。與此類似，給P2PNAT方法增加端口預(yù)測(cè)，允許他處理對(duì)稱NAT后，它的成功率增加到84.3%。令人驚訝的是，通過(guò)修改原來(lái)的方法，不使用低TTL，所有的方法都獲益超過(guò)5%！打破競(jìng)爭(zhēng)條件，因此獲得的收益就是兩種修改后的STUNT方法高達(dá)89.1%和88.7%的最好成功率，以及修改NATBlaster方法后85.2%的成功率。

    不使用低TTL的SYN所獲得的意外好處，可以這樣解釋。大部分NAT安靜的丟棄掉第一個(gè)SYN包（4.2.2節(jié)），只有一少部分NAT過(guò)濾外發(fā)SYN包后（緊跟）的進(jìn)入的SYN包（表-9）。因此，多數(shù)情況下，修改后的方法觸發(fā)TCP同時(shí)打開(kāi)，即使他們并不想這樣（同時(shí)打開(kāi)TCP）。相對(duì)于向產(chǎn)生TCP RST應(yīng)答NAT所付出的懲罰來(lái)說(shuō)，成功地TCP同時(shí)開(kāi)發(fā)的賠償更大。如果更多的NAT應(yīng)答TCP RST包或者終端主機(jī)的操作系統(tǒng)不支持TCP同時(shí)打開(kāi)的話，這種好處則被完全抹殺了。

    6.1 實(shí)現(xiàn)

    我們?cè)谝粋€(gè)P2P程序中用C實(shí)現(xiàn)了上述（穿透）方法。該程序運(yùn)行在圖-9所示的12個(gè)局域網(wǎng)連接的windows客戶端上以及廣域網(wǎng)連接的20個(gè)客戶端中的大部分上。每個(gè)客戶端隨機(jī)挑選另一個(gè)客戶端，并與其嘗試建立TCP連接。所有的方法按照宣稱工作（處理），只是不再討論不用低TTL的STUNT#2和使用端口預(yù)測(cè)的P2PNAT。這是因?yàn)椋覀儼l(fā)現(xiàn)STUNT#1和NATBlaster方法大范圍廣泛的部署是不切實(shí)際的，STUNT#1方法需要欺騙任意包的server廣泛部署，而NATBlaster方法所需要的RAW套接字功能由于安全關(guān)系而在WindowsXP中被移除。

    圖-10顯示了各種方法建立連接和在低延遲網(wǎng)絡(luò)情況下報(bào)告失敗所用時(shí)間的半對(duì)數(shù)圖。成功連接的時(shí)間分布（圖示中的x軸），P2PNAT方法中變化很大，而第二種STUNT方法則非常平和（一致）。這是因?yàn)镻2PNAT方法重復(fù)發(fā)起連接直到其中一次成功或者出現(xiàn)超時(shí)，而第二種STUNT方法只發(fā)起一個(gè)連接。從圖-10中的a圖來(lái)看，大部分的連接是不成功的，直到21秒進(jìn)入的連接嘗試（才成功），因而為了取得先前測(cè)定的評(píng)估的成功率，需要（花費(fèi)）大量超時(shí)時(shí)間。個(gè)別情況下，當(dāng)端口預(yù)測(cè)失敗且peer的NAT應(yīng)答TCP RST包時(shí)，這種大量超時(shí)的危險(xiǎn)副作用就顯現(xiàn)出來(lái)了。由于終端機(jī)重復(fù)地嘗試連接直到超時(shí)時(shí)間結(jié)束，這就導(dǎo)致P2PNAT方法產(chǎn)生SYN泛濫。誠(chéng)然，這個(gè)問(wèn)題在原本的P2PNAT方法中是不存在的，因?yàn)樗惶岢丝陬A(yù)測(cè)。

    總的來(lái)說(shuō)，我們發(fā)現(xiàn)，基于協(xié)議的TCP大部分情況下能夠穿透NAT。應(yīng)用程序必須通過(guò)端口預(yù)測(cè)來(lái)處理（解決）“delta”（“δ”）類型NAT，而且，當(dāng)NAT上有足夠的安全限制時(shí)，也必須使用帶外信號(hào)來(lái)建立連接。延遲不敏感的應(yīng)用程序，在放棄前，任何一方也都必須嘗試連接兩次（多次）。此外，應(yīng)用軟件不必依賴NAT保留空閑連接太久的時(shí)間，也不應(yīng)該期望端到端的TCP序號(hào)一成不變。盡管，某些特定情況下，所有的TCP穿透NAT方法都不十分完美，但在當(dāng)前的互聯(lián)網(wǎng)中用于建立P2P的TCP連接中，第二種STUNT方法是最好的（魯棒），它88%的情況都是成功的，而且不需要欺騙、RAW套接字或其它超級(jí)特權(quán)。它使用傳統(tǒng)的TCP協(xié)議棧，傳統(tǒng)的協(xié)議棧不支持TCP同時(shí)打開(kāi)，然而，利用現(xiàn)代操作系統(tǒng)中的這種好處，它在許多通常情況下提供了100%的成功。最后，我們發(fā)現(xiàn)，它也是所有方法中實(shí)現(xiàn)最簡(jiǎn)單的，而且在Linux下和Windows下都能工作。我們鼓勵(lì)應(yīng)用軟件開(kāi)發(fā)者們，在他們現(xiàn)在還不能在NAT后的peer之間建立TCP的P2P應(yīng)用軟件中采用這種方法來(lái)提供TCP穿透NAT（功能）。

    7 相關(guān)工作

    從Dan Kegel在上世紀(jì)90年代后期第一次提出用于P2P游戲的UDP穿透NAT以來(lái)，NAT穿透長(zhǎng)久以來(lái)一直是人們的夢(mèng)想。他的基本方法被當(dāng)作標(biāo)準(zhǔn)，并發(fā)表在參考文獻(xiàn)[15]中。UDP（穿透NAT）方法在幾個(gè)現(xiàn)行的文檔和互聯(lián)網(wǎng)草稿中已經(jīng)有結(jié)果（也就是成熟的方法），這些文檔和互聯(lián)網(wǎng)草稿把NAT對(duì)UDP的行為進(jìn)行了分類，并計(jì)劃把它標(biāo)準(zhǔn)化。不顯式控制NAT的TCP穿透NAT領(lǐng)域，才剛剛起步。本文已經(jīng)分析了一些方法，也證明了這些方法在當(dāng)前的互聯(lián)網(wǎng)中穿透NAT（的可行性）。參考文獻(xiàn)[6]中包括了類似的研究，作者測(cè)試了許多NAT對(duì)UDP和TCP穿透NAT特點(diǎn)的一小部分（子集）。我們提出了NAT行為和P2P的TCP建立（連接）的第一個(gè)全面研究，為在大范圍商業(yè)NAT產(chǎn)品上的TCP穿透NAT技術(shù)提供了全面的集合（整理/匯總）。

    像UPnP和MIDCOM這樣的協(xié)議，為了便于P2P連接，他們?cè)试S終端應(yīng)用軟件顯式的控制NAT。這種類型方法之所以呈下降趨勢(shì)，是因?yàn)樗鼈冃枰狽AT中存在并支持這些協(xié)議。應(yīng)用軟件開(kāi)發(fā)者們不能夠依賴這些，因此，暫時(shí)這些方法不是最好的選擇。

    另一個(gè)處理TCP連接的方法是TURN[14]，TURN方法中，TCP數(shù)據(jù)通過(guò)第三方代理（中轉(zhuǎn)），因而，第三方代理具有潛在的網(wǎng)絡(luò)瓶頸。通過(guò)在UDP上開(kāi)通IPV6通道的方式，Teredo[14]（方法）允許IPV6包穿透IPV4的NAT。這里，TCP原本就處在IPV6之上。Windows操作系統(tǒng)中已經(jīng)實(shí)現(xiàn)了Teredo。

    8 結(jié)論及將來(lái)的工作

    本文第一次對(duì)NAT關(guān)于TCP方面對(duì)特點(diǎn)進(jìn)行了全面的測(cè)評(píng)研究。盡管該研究表明TCP穿透當(dāng)前NAT還有很多問(wèn)題，不過(guò)它還是給了我很多值得高興的（樂(lè)觀的）。盡管存在NAT，而這些NAT當(dāng)初設(shè)計(jì)時(shí)并未考慮過(guò)TCP穿透NAT，但我們還是能夠看到，自然環(huán)境條件下TCP連接建立的成功率平均達(dá)88%，一些普通類型NAT的成功率高達(dá)100%。這些數(shù)字特別鼓勵(lì)一個(gè)假設(shè)：很多年前可以普遍地假設(shè)TCP穿透NAT是不可能的。盡管對(duì)許多應(yīng)用軟件來(lái)說(shuō)，11%的失敗率是不可接受的，但這些應(yīng)用軟件的用戶至少有選擇，可以選擇買(mǎi)一個(gè)支持TCP穿透的NAT設(shè)備，NAT提供商也有選擇，可以選擇把他們的NAT設(shè)備設(shè)計(jì)的對(duì)TCP更友好。

    該研究在某些方面還是有限的（不全面不完整）。第一，我們沒(méi)有測(cè)試所有現(xiàn)存的NAT設(shè)備。我們研究中大部分有效的NAT被限制在北美地區(qū)。第二，我測(cè)試的范圍太小，也因此在準(zhǔn)確預(yù)測(cè)廣泛的成功率方面是存在偏差的。盡管可以使用市場(chǎng)數(shù)據(jù)協(xié)助，但這些數(shù)據(jù)在范圍和詳細(xì)程度上也是有限的。第三，我們只測(cè)試了家用NAT。企業(yè)網(wǎng)絡(luò)中，“delta”（“δ”）型NAT的端口預(yù)測(cè)成功率通常更低一些，而這些對(duì)測(cè)評(píng)原本會(huì)更有幫助。第四，盡管TCP穿透NAT技術(shù)被廣泛地用于（穿透）防火墻，但我們并沒(méi)有測(cè)試NAT環(huán)境之外的防火墻。我們也沒(méi)有測(cè)試IPV4到IPV6的轉(zhuǎn)換網(wǎng)關(guān)。最后，與其他測(cè)評(píng)研究類似，這（研究）只是當(dāng)前的現(xiàn)狀。毫無(wú)疑問(wèn)，在本項(xiàng)目進(jìn)行過(guò)程中，同類NAT的新版本已經(jīng)展現(xiàn)出與之前版本不同的行為。展望未來(lái)，我們希望，我們的TCP穿透NAT測(cè)試套件能夠繼續(xù)被用來(lái)拓寬我們對(duì)NAT和防火墻特性的認(rèn)識(shí)，也能夠繼續(xù)跟得上NAT產(chǎn)品及其部署的趨勢(shì)。

    9 感謝

    作者非常感謝Bryan Ford、Andrew Biggadile以及那些匿名的IMC評(píng)論家，因?yàn)樗麄優(yōu)楸疚某醺宸答伒恼滟F的意見(jiàn)。我們也感謝Synergy Research Group,Inc.提供了及時(shí)的市場(chǎng)調(diào)查數(shù)據(jù)。最后，我們感謝許許多多的志愿者，他們?cè)谧约旱南到y(tǒng)上運(yùn)行了STUNT測(cè)試client和P2P的TCP測(cè)試，并反饋了結(jié)果。

    10 參考文獻(xiàn)

    [1] AUDET, F., AND JENNINGS, C. Internet draft: Nat behavioral requirements for unicast udp, July 2005. Work in progress.

    [2] BASET, S. A., AND SCHULZRINNE, H. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. Tech. Rep. CUCS-039-04, Columbia University, New York, NY, Sept. 2004.

    [3] BIGGADIKE, A., FERULLO, D., WILSON, G., AND PERRIG, A.NATBLASTER: Establishing TCP connections between hosts behind NATs. In Proceedings of ACM SIGCOMM ASIA Workshop

    (Beijing, China, Apr. 2005).

    [4] BRADEN, R. RFC 1122: Requirements for Internet Hosts – Communication Layers, Oct. 1989.

    [5] EPPINGER, J. L. TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem. Tech. Rep. CMU-ISRI-05-104, Carnegie Mellon University, Pittsburgh, PA, Jan. 2005.

    [6] FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer communication across network address translators. In Proceedings of the 2005 USENIX Annual Technical Conference (Anaheim, CA, Apr. 2005).

    [7] GUHA, S. STUNT - Simple Traversal of UDP Through NATs and TCP too. Work in progress. [online] http://nutss.gforge.cis.cornell.edu/pub/draft-guha-STUNT-00.txt.

    [8] GUHA, S. STUNT Test Results. [online] http://nutss.gforge.cis.cornell.edu/stunt-results.php.

    [9] GUHA, S., TAKEDA, Y., AND FRANCIS, P. NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity. In Proceedings of SIGCOMM’04 Workshops (Portland, OR, Aug. 2004), pp. 43–48.

    [10] HUITEMA, C. Internet draft: Teredo: Tunneling ipv6 over udp through nats, Apr. 2005. Work in progress.

    [11] JENNINGS, C. Internet draft: Nat classification test results, Feb.2005. Work in progress.

    [12] MICROSOFT CORPORATION. UPnP – Universal Plug and Play Internet Gateway Device v1.01, Nov. 2001.

    [13] POSTEL, J. RFC 761: DoD standard Transmission Control Protocol,Jan. 1980.

    [14] ROSENBERG, J., MAHY, R., AND HUITEMA, C. Internet draft:TURN – Traversal Using Relay NAT, Feb. 2004. Work in progress.

    [15] ROSENBERG, J., WEINBERGER, J., HUITEMA, C., AND MAHY, R. RFC 3489: STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), Mar. 2003.

    [16] STIEMERLING, M., QUITTEK, J., AND TAYLOR, T. MIDCOM Protocol Semantics, June 2004. Work in progress.

    [17] TAKEDA, Y. Internet draft: Symmetric NAT Traversal using STUN, June 2003. Work in progress.

    [18] VANCE, A., Ed. Q1 2005 Worldwide WLAN Market Shares. Synergy Research Group, Inc., Scottsdale, AZ, May 2005, p. 40.

    注釋：

    1處在NAT或防火墻后面的網(wǎng)絡(luò)（Network behind a NAT or firewall）

    2整篇文章中，NAT術(shù)語(yǔ)理解為包括防火墻（Throughout this paper, the term NAT is understood to include firewalls）

    3有時(shí)指雙層NAT（sometimes referred to as dual or double NAT）

    4IP中存活時(shí)間字段（IP time-to-live field）

    5最大段長(zhǎng)（Maximum Segment Length）

    6來(lái)回時(shí)間（Round-trip time）

    如何使tcp包和udp包穿透防火墻

    通過(guò)本文的httptunnel 技術(shù)同時(shí)逃過(guò)了防火墻的屏蔽以及系統(tǒng)的追蹤試驗(yàn)，我們可以看到網(wǎng)絡(luò)安全僅僅依靠某種或某幾種手段是不可靠的，同時(shí)對(duì)安全系統(tǒng)的盲目性依賴往往會(huì)造成巨大的安全隱患。希望通過(guò)本文能引起管理員對(duì)網(wǎng)絡(luò)安全防護(hù)系統(tǒng)的思考。

    什么是http暗藏通道

    什么是局域網(wǎng)安全，系統(tǒng)管理員怎樣才能保障局域網(wǎng)的安全？這是一個(gè)不斷變化的安全概念，很長(zhǎng)的一個(gè)時(shí)期以來(lái)，在局域網(wǎng)與外界互聯(lián)處放置一個(gè)防火墻，嚴(yán)格控制開(kāi)放的端口，就能在很大程度上掌握安全的主動(dòng)權(quán)，方便的控制網(wǎng)內(nèi)外用戶所能使用的服務(wù)。比如，在防火墻上僅僅開(kāi)放80，53兩個(gè)端口，那么無(wú)論是內(nèi)部還是外面的惡意人士都將無(wú)法使用一些已經(jīng)證明比較危險(xiǎn)的服務(wù)。

    但要注意一點(diǎn)，防火墻在某種意義上是很愚蠢的，管理員對(duì)防火墻的過(guò)分依賴以及從而產(chǎn)生的懈怠情緒將不可避免的形成安全上的重大隱患，作為一個(gè)證明，"通道"技術(shù)就是一個(gè)很好的例子，這也是本文要討論的。

    那么什么是通道呢？這里所謂的通道，是指一種繞過(guò)防火墻端口屏蔽的通訊方式。防火墻兩端的數(shù)據(jù)包封裝在防火墻所允許通過(guò)的數(shù)據(jù)包類型或是端口上，然后穿過(guò)防火墻與對(duì)端通訊，當(dāng)封裝的數(shù)據(jù)包到達(dá)目的地時(shí)，再將數(shù)據(jù)包還原，并將還原后的數(shù)據(jù)包交送到相應(yīng)的服務(wù)上。舉例如下：

    A主機(jī)系統(tǒng)在防火墻之后，受防火墻保護(hù)，防火墻配置的訪問(wèn)控制原則是只允許80端口的數(shù)據(jù)進(jìn)出，B主機(jī)系統(tǒng)在防火墻之外，是開(kāi)放的。現(xiàn)在假設(shè)需要從A系統(tǒng)Telnet到B系統(tǒng)上去，怎么辦？使用正常的telnet肯定是不可能了，但我們知道可用的只有80端口，那么這個(gè)時(shí)候使用Httptunnel通道，就是一個(gè)好的辦法，思路如下：

    在A機(jī)器上起一個(gè)tunnel的client端，讓它偵聽(tīng)本機(jī)的一個(gè)不被使用的任意指定端口，如1234，同時(shí)將來(lái)自1234端口上的數(shù)據(jù)指引到遠(yuǎn)端（B機(jī)）的80端口上（注意，是80端口，防火墻允許通過(guò)），然后在B機(jī)上起一個(gè)server，同樣掛接在80端口上，同時(shí)指引80端口的來(lái)自client的轉(zhuǎn)發(fā)到本機(jī)的telnet服務(wù)端口23，這樣就ok了。現(xiàn)在在A機(jī)上telnet本機(jī)端口1234，根據(jù)剛才的設(shè)置數(shù)據(jù)包會(huì)被轉(zhuǎn)發(fā)到目標(biāo)端口為80的B機(jī)，因?yàn)榉阑饓υ试S通過(guò)80端口的數(shù)據(jù)，因此數(shù)據(jù)包暢通的穿過(guò)防火墻，到達(dá)B機(jī)。此時(shí)B機(jī)在80端口偵聽(tīng)的進(jìn)程收到來(lái)自A的數(shù)據(jù)包，會(huì)將數(shù)據(jù)包還原，再交還給telnet進(jìn)程。當(dāng)數(shù)據(jù)包需要由B到A返回時(shí)，將由80端口再回送，同樣可以順利的通過(guò)防火墻。

    實(shí)際上tunnel概念已經(jīng)產(chǎn)生很久了，而且很有可能讀者使用過(guò)類似的技術(shù)，比如下面的網(wǎng)址http://www.http-tunnel.com。它是一個(gè)專業(yè)提供tunnel服務(wù)的公司，通過(guò)他們的在線tunnel server,局域網(wǎng)內(nèi)的用戶可以使用被防火墻所屏蔽的ICQ，E-MAIL，pcanywhere，AIM，MSN，Yahoo，Morpheus，Napster等等諸多軟件。我們看到，這里有ICQ,Napster等軟件，相信我們的讀者很多都使用過(guò)走proxy的ICQ,OICQ等等，其實(shí)他們的原理是差不多的。

    什么是Httptunnel

    作為一個(gè)實(shí)際的例子，我們下面來(lái)介紹一個(gè)在"非公開(kāi)領(lǐng)域"使用的的通道軟件，httptunnel。在httptunnel主頁(yè)（請(qǐng)參閱參考資料）上有這么一端話，

    httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests. The HTTP requests can be sent via an HTTP proxy if so desired.

    This can be useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use httptunnel and, say, telnet or PPP to connect to a computer outside the firewall.

    從這段說(shuō)明中我們可以看出來(lái)它就是我們今天說(shuō)要介紹的tunnel技術(shù)的一個(gè)證明，我們下面大致介紹一下它的使用。

    httptunnel目前比較穩(wěn)定的版本是3.0.5, 支持各種常見(jiàn)的unix系統(tǒng)，包括window平臺(tái)。可以從相關(guān)站點(diǎn)（請(qǐng)參閱參考資料）下載，它的安裝是比較簡(jiǎn)單的，照INSTALL文件做就可以了，這里不介紹。

    整個(gè)軟件安裝完畢后，我們會(huì)得到兩個(gè)關(guān)鍵文件，htc和hts,其中htc是客戶端（c），而hts是server(s)端，我們來(lái)看看具體怎么使用的。

    假設(shè)有A（域名client.yiming.com)機(jī)，B(域名server.yiming.com)機(jī)，兩機(jī)均為solaris環(huán)境，A機(jī)在防火墻保護(hù)中，B機(jī)在防火墻以外，防火墻的管理員控制了訪問(wèn)規(guī)則，僅ALLOW 80和53端口的進(jìn)出數(shù)據(jù)包。而我們的任務(wù)是要利用Httptunnel從A機(jī)telnet到B機(jī)上，穿過(guò)防火墻的限制。操作如下：

    首先我們?cè)贏上啟動(dòng)client端，命令很簡(jiǎn)單：

    client.yiming.com#htc -F 1234 server.yiming.com:80，

    系統(tǒng)回到提示符下，此刻我們用netstat -an 可以看到系統(tǒng)內(nèi)多出了1234端口的偵聽(tīng)*.1234                  *.*                 0       0      0       0 LISTEN

    然后我們?cè)贐機(jī)上啟動(dòng)server端，命令如下：

    server.yiming.com#hts -F localhost:23 80

    系統(tǒng)回到提示符下，此刻我們用netstat看*.80               *.*                 0       0      0       0 LISTEN

    80端口處于偵聽(tīng)狀態(tài)，需要注意的是，如果系統(tǒng)本身跑的有web服務(wù)（80端口本身處于偵聽(tīng)），并不會(huì)影響Httptunnel的工作。

    Ok,server以及client端都啟動(dòng)了，我們可以開(kāi)始我們的"通道"試驗(yàn)了，在client.yiming.com上執(zhí)行一下如下命令看看：

    Client.yiming.com#telnet localhost 1234

    Trying 0.0.0.0...

    Connected to 0.

    Escape character is '^]'.

    SunOS 5.7

    This is yiming's private box! Any question,contact me with yiming@security.zz.ha.cn

    login:

    看到B機(jī)的登錄提示符了,輸入賬號(hào)密碼看看是否工作正常？

    Login:yiming

    Password: (omit here;) )

    sever.yiming.com# ls

    bak          check        go           httpd        lost+found   mrtg         run          soft         wg

    OK! 工作正常，和正常的telnet沒(méi)有什么差別。

    仔細(xì)觀察整個(gè)過(guò)程，會(huì)發(fā)現(xiàn)在最開(kāi)始的地方顯示的是Trying 0.0.0.0...，Connected to 0.而不是Trying server.yiming.com…,Connect to server.yiming.com，這就很直觀的可以看出來(lái)client端是轉(zhuǎn)發(fā)1234數(shù)據(jù)包到本機(jī)80端口的。（然后再轉(zhuǎn)發(fā)到遠(yuǎn)端）而不是直接連接遠(yuǎn)端的B機(jī)。

    上面是比較直觀的測(cè)試，為了進(jìn)一步驗(yàn)證server和client之間不是通過(guò)23端口通訊，我們抓取數(shù)據(jù)包來(lái)看看。我們?cè)趕erver起個(gè)抓包工具tcpdump（請(qǐng)參閱參考資料）瞧瞧。

    server.yiming.com#tcpdump host client.yiming.com

    tcpdump: listening on hme0

    14:42:54.213699 client.yiming.com.51767 >   server.yiming.com.80: S 1237977857:1237977857(0) win 8760   (DF)

    14:42:54.213767server.yiming.com.80 >   client.yiming.com.51767: S 1607785698:1607785698(0) ack 1237977858 win 8760   (DF)

    14:42:54.216186 client.yiming.com.51768 >   server.yiming.com.80: . ack 1 win 8760 (DF)

    14:42:54.218661 client.yiming.com.51768 >   server.yiming.com.80: P 1:44(43) ack 1 win 8760 (DF)

    14:42:54.218728 client.yiming.com.51768 >   server.yiming.com.80: P 44:48(4) ack 1 win 8760 (DF)

    篇幅所限，上面只是截取了結(jié)果中的一點(diǎn)點(diǎn)數(shù)據(jù)包，但已經(jīng)可以說(shuō)明問(wèn)題了，我們看到server和client之間順利的完成了三次握手，然后開(kāi)始push數(shù)據(jù)，而且通訊確實(shí)走的是80端口。有點(diǎn)意思噢。

    看是看出來(lái)了，但太不直白，到底在搞什么呀，我們?cè)偕晕⒏膭?dòng)一下tcpdump的運(yùn)行方式，進(jìn)一步在來(lái)看看telnet的數(shù)據(jù)是否被封裝在80端口的數(shù)據(jù)包內(nèi)傳輸？

    server.yiming.com#tcpdump -X host client.yiming.com

    14:43:05.246911 server.yiming.com.80 >   client.yiming.com.51768: . 2997:4457(1460) ack 89 win 8760 (DF)

    0x0000    4500 05dc 3b23 4000 ff06 e2c2 yyyy yyyy         E...;#@......f.D

    0x0010    xxxx xxxx 0050 de42 5fd5 ac4f 39ac 016f         .f.#.P.B_..O9..o

    0x0020    5010 2238 98e4 0000 746f 7461 6c20 3636         P."8....total.66

    0x0030    370d 0a64 7277 7872 2d78 722d 7820 2032         7..drwxr-xr-x..2

    0x0040    3920 726f 6f74 2020 2020 2072 6f6f 7420         9.root.....root.

    呵呵，這次清楚多了，上面應(yīng)該是一次ls命令的輸出結(jié)果，可以清楚的看到telnet的結(jié)果！果然telnet的數(shù)據(jù)是在80端口的數(shù)據(jù)包內(nèi)！

    Httptunnel帶來(lái)的安全問(wèn)題

    寫(xiě)到這里，我們可以想象一下，如果管理員完全信賴防火墻，那么在一個(gè)有這樣隱患的的局域網(wǎng)中，會(huì)發(fā)生什么樣的后果？

    我們可以看到，多年以來(lái)，對(duì)防火墻的依賴也一直列在SANS的Top 10安全問(wèn)題中。

    既然如此，就很自然的會(huì)產(chǎn)生一個(gè)問(wèn)題是：這種httptunnel行為能被發(fā)現(xiàn)嗎？

    首先我們想到的是使用入侵檢測(cè)系統(tǒng)，在目前的網(wǎng)絡(luò)安全設(shè)計(jì)中，防火墻加入侵檢測(cè)系統(tǒng)是一種比較流行的安全聯(lián)動(dòng)配置，既然httptunnel繞過(guò)了防火墻，那么IDS系統(tǒng)呢？我們來(lái)測(cè)測(cè)看看。

    在下面的測(cè)試中，我們將使用IDS系統(tǒng)是Snort，版本1.8.2。（請(qǐng)參閱參考資料）這可是大名鼎鼎的開(kāi)放源代碼的IDS系統(tǒng)，在它的說(shuō)明中，被描述為一個(gè)輕量級(jí)的，可跨平臺(tái)工作的入侵檢測(cè)系統(tǒng)，在2001年12月英國(guó)的獨(dú)立測(cè)試實(shí)驗(yàn)室NSS的評(píng)測(cè)中（請(qǐng)參閱參考資料），擊敗了包括商用IDS系統(tǒng)的所有對(duì)手，這些商用軟件可是包括ISS，CISCO SECURE IDS，CA ETRUST，CYBERSAFE CENTRAX，NFR。有興趣的讀者還可以看這篇名為Open source mounts IDS challenge 的報(bào)道（請(qǐng)參閱參考資料）。

    好，對(duì)Snort的大致介紹完畢，我們來(lái)看看結(jié)果吧，Snort對(duì)整個(gè)試驗(yàn)過(guò)程抓獲的數(shù)據(jù)包產(chǎn)成了告警，如下：

    [**] WEB-MISC whisker splice attack [**]

    12/02-14:42:54.389175 client.yiming.com:51767->   server.yiming.com:80

    TCP TTL:251 TOS:0x0 ID:3327 IpLen:20 DgmLen:42 DF

    ***AP*** Seq: 0x49CA0BA7   Ack: 0x5FD4DCE3   Win: 0x2238   TcpLen: 20

    =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

    [**] WEB-MISC whisker splice attack [**]

    12/02-14:43:03.195006 client.yiming.com:51767 ->   server.yiming.com:80

    TCP TTL:251 TOS:0x0 ID:3439 IpLen:20 DgmLen:41 DF

    ***AP*** Seq: 0x49CA0C20   Ack: 0x5FD4DCE3   Win: 0x2238   TcpLen: 20

    =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

    [**] WEB-MISC whisker splice attack [**]

    12/02-14:43:04.630268 client.yiming.com:51768->   server.yiming.com:80

    TCP TTL:251 TOS:0x0 ID:3496 IpLen:20 DgmLen:41 DF

    ***AP*** Seq: 0x49CA0C4E   Ack: 0x5FD4DCE3   Win: 0x2238   TcpLen: 20

    =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

    我們看到snort對(duì)抓獲的數(shù)據(jù)包產(chǎn)生了WEB-MISC whisker splice attack的告警，然而這種攻擊并沒(méi)有發(fā)生，同時(shí)snort對(duì)tunnel數(shù)據(jù)包沒(méi)有察覺(jué)。這樣snort就同時(shí)出現(xiàn)了IDS系統(tǒng)的兩個(gè)問(wèn)題，false positive，false negative。

    這也很正常，因?yàn)檫@也是基于簽名的IDS系統(tǒng)的通病，目前決大數(shù)IDS系統(tǒng)包括著名的商用軟件ISS,NFR等都是基于簽名的，也就是說(shuō)系統(tǒng)維護(hù)著一套特定攻擊數(shù)據(jù)包的數(shù)據(jù)模式簽名。系統(tǒng)工作時(shí)，檢查經(jīng)過(guò)的數(shù)據(jù)包的內(nèi)容，和自己數(shù)據(jù)庫(kù)內(nèi)數(shù)據(jù)模式簽名對(duì)比，如果和某種攻擊模式簽名相同，那么就判斷發(fā)生了某種攻擊。

    由此我們可以看出很明顯的存在若干問(wèn)題：如對(duì)簽名的依賴不可避免的導(dǎo)致兩個(gè)結(jié)果，false negative ,false positive。也就是說(shuō)會(huì)產(chǎn)生漏報(bào)和誤報(bào)，這一點(diǎn)很容易理解，當(dāng)新出現(xiàn)一種攻擊模式時(shí)，由于IDS系統(tǒng)內(nèi)沒(méi)有相應(yīng)的數(shù)據(jù)簽名，那么就不可能捕獲相應(yīng)的攻擊數(shù)據(jù)包，false negative由此發(fā)生。同時(shí)，過(guò)于依賴簽名模式也很容易誤報(bào)，就象我們上面的例子。同時(shí)，對(duì)數(shù)據(jù)簽名的依賴會(huì)在一定程度上降低系統(tǒng)性能-經(jīng)過(guò)的數(shù)據(jù)包都需要和IDS系統(tǒng)的簽名對(duì)照。（請(qǐng)參閱參考資料）

    此外，基于簽名的IDS系統(tǒng)本身有可能由于依據(jù)簽名這一特性而被攻擊，一個(gè)例子是stick ，這個(gè)程序的作者利用IDS系統(tǒng)進(jìn)行簽名匹配工作原理，發(fā)送大量帶有攻擊特征的數(shù)據(jù)包給IDS系統(tǒng)，使IDS系統(tǒng)本身處理能力超過(guò)極限，從而導(dǎo)致IDS系統(tǒng)無(wú)法響應(yīng)。按照作者Coretez Giovanni的說(shuō)法