外文翻譯-回顧-tcpip協(xié)議套件安全問題-

學院：信息科學與工程學院專業(yè)：計算機科學與技術專業(yè)姓名：xxx、學號：xxx外文出處：ALookBackat“SecurityProblemsintheTCP/IPProtocolSuite”附件：1.外文資料翻譯譯文；2.外文原文。指導教師評語：簽名：2021

附件1：外文資料翻譯譯文回顧“TCP/IP協(xié)議套件安全問題”摘要大約十五年前，我寫了一篇關于TCP/IP協(xié)議安全問題的論文，我特別側重于協(xié)議層面的問題，而不是實施的缺陷?；仡櫮瞧撐拇_實具有指導意義。它可以指導我去看看哪里的重點和預測是準確的，哪里是錯的，還有哪里的危險尚未發(fā)生。這是一個在原來論文基礎上加了評注的重印稿。1.引言該論文中的“TCP/IP協(xié)議套件的安全問題”最初是在1989年4月《計算機通信研究》第19卷第2號出版。這是一個協(xié)議層面的分析，我故意不考慮實施或業(yè)務問題。我覺得而且仍然覺得，那是正確的做法。錯誤來來去去，大家的經營環(huán)境是不同的。但解決協(xié)議層面的問題很難，特別是如果你想保持與安裝基礎的兼容性。

本文是我的原創(chuàng)作品的回顧。新的評注以無襯線字體，縮進方式顯示。除了推出時從troff到LATEX轉換時可能出現(xiàn)的錯誤之外，其他原文字保持不變。我已經離開了完整的參考，即使現(xiàn)在有更好的版本。當然，參考號碼和分頁是不同的；節(jié)數(shù)保持不變，除了一個新的“結論“部分。作為一般規(guī)則，評注跟隨其所討論的章節(jié)。它有助于理解本文來自哪里。當我1982年開始在美利山貝爾實驗室工作，我承擔了前三個以太網(wǎng)電纜的AT＆T公司的所有公司巨頭壟斷的所有權。我的實驗室有一個電線，另一個實驗室有第二個，有一個“骨干“聯(lián)系將這兩個實驗室聯(lián)系在一起。隨著骨干的增長，其他實驗室也相繼連接到它。最后，我們獲得資金，可以與其他貝爾實驗室的位置連接起來；我們稱此網(wǎng)絡為“貝爾實驗室互聯(lián)網(wǎng)”或“研發(fā)網(wǎng)絡”。新詞“內聯(lián)網(wǎng)”當時還沒有被發(fā)明。專用路由器當時是非常罕見的，我們一般伸進一秒鐘以太網(wǎng)板的VAX或太陽，用它做路由。這意味著該路由軟件（我們使用Berkeley的路由）是可以訪問系統(tǒng)管理員的。當事情發(fā)生，我們常常發(fā)現(xiàn)，這是一個路由問題：有人錯誤配置了他們的機器。有一次，我們發(fā)現(xiàn)有人插入一個新的美利山工作站的骨干，而不是進入它的部門網(wǎng)絡。更糟糕的是（專有）地址分配給他的機器上的軟件沒有看到該網(wǎng)絡的任何（專有）地址分配服務器，因此它分配0.1-網(wǎng)關路由器給它本身。這兩種情況使我擔心，很明顯，任何可能發(fā)生的事故都有可能是故意而為之，而且可能會造成嚴重后果。幾個其他事情使我更注重于安全問題。一個是羅伯特.莫里斯關于序列號猜測攻擊的發(fā)現(xiàn)，這些都是廣泛的討論如下。另一個是“影子”號事件，一個十幾歲的孩子攻擊AT＆T公司的很多電腦[2]。當他試圖用統(tǒng)一慣例盜取從各研究機密碼文件時他被發(fā)現(xiàn)了。我們已經安裝了一些這種精確的活動排序探測器，而得以注意到不尋常的行為。當時，我們很幸運，在AT＆T的連接內大部分是通過專有的Datakit網(wǎng)絡，他不知道如何利用。到了1988年的網(wǎng)絡蠕蟲時代，這個文件已經在實質上是它目前的形式。（盡我最大的能力，當時對于安全問題比較新穎）其結果是對TCP/IP協(xié)議層次問題的分析。原稿獲得很多評論。[54]在我看來，有些批評是有效的。而有些批評是沒有用的。當時，我選擇不公布詳細的反駁，在這里我也不會這樣做。在適當情況下，我會指出我哪里的分析是錯誤的。我覺得我做的結論大致是正確的。在今天廣泛使用的TCP/IP協(xié)議套件[41，21]，是根據(jù)美國國防部的贊助而發(fā)展起來的。盡管如此，有一些嚴重的安全漏洞還存在于協(xié)議中。這些缺陷的存在，一個明顯的例子是因為一些主機上的IP源地址依靠認證;伯克利的“R-事業(yè)“[22]。其他存在的原因是因為網(wǎng)絡控制機制，并在特定的路由協(xié)議中有很少或根本不存在的認證。當描述這種攻擊，我們的基本假設是，攻擊者已經或多或少完成了連接到互聯(lián)網(wǎng)的一些機器的控制權。這可能是由于

該機器的自身保護機制的缺陷，也可能是因為該機器是微電腦，和固有的不安全。事實上，攻擊者甚至可能是惡意的系統(tǒng)管理員。1.1獨占我們并不關心特別是實現(xiàn)了協(xié)議的缺陷，如通過互聯(lián)網(wǎng)的“蠕蟲”[95，90，38]。相反，我們討論了通用協(xié)議本身的問題。正如將要看到的那樣，認真執(zhí)行技術可以減輕或避免這些問題。一些我們討論的是從Berkeley的UNIX系統(tǒng)版本派生協(xié)議，其他都是通用的互聯(lián)網(wǎng)協(xié)議。我們也并不關心經典網(wǎng)絡攻擊，如物理竊聽，涂改或帶有病毒的信息。我們只討論這樣的問題，只要他們可能是協(xié)助或協(xié)議問題。

在大多數(shù)情況下，也沒有在這里討論供應商特定的協(xié)議。我們討論大學伯克利分校的協(xié)議的一些問題，因為這些已經成為事實上的標準，許多廠商，而不是只為

UNIX系統(tǒng)。文獻[54]的批評之一是，我已經集中在RFC中描述的標準化協(xié)議中把伯克利特定協(xié)議添加到一起。它不同于前一段，我理解的差異明顯。但是，基于地址的認證，使用的主要缺陷，我批評整個紙張是特有的伯克利的軟件，我沒有嚴格的區(qū)分清楚。這確實是一個糟糕的做身份驗證的方法，但它不受任何官方標準的保護。2.TCP序列號預測

更有趣的安全漏洞之一是莫里斯首次描述[70]。簡單地說，他使用TCP序列號預測興建而沒有從服務器收到任何回應一個TCP包序列。這使他欺騙在本地網(wǎng)絡上可信主機。

建立正常的TCP連接的序列涉及三路握手?？蛻舳诉x擇并發(fā)送一個初始序列號ISNC，服務器確認并發(fā)送自己的序列號iSNS和客戶確認。繼上述三個消息，數(shù)據(jù)傳輸可能發(fā)生。該交易所可示意如下：C→S:SYN(ISNC)S→C:SYN(ISNS),ACK(ISNC)C→S:ACK(ISNS)C→S:數(shù)據(jù)和/或S→C:數(shù)據(jù)也就是說，對于一個對話得以進行，C必須先聽ISNS的，或多或少的隨機數(shù)。不過，假設有一種方式是入侵者X來預測ISNS的。在這種情況下，它可以發(fā)送下面的序列來模擬信任的主機：X→S:SYN(ISNX),SRC=TS→T:SYN(ISNS),ACK(ISNX)X→S:ACK(ISNS),SRC=TX→S:ACK(ISNS),SRC=T,盡管信號S→T沒有去到X中，x

能夠知道它的內容，因此可以發(fā)送數(shù)據(jù)。如果X是一個連接上執(zhí)行命令，允許執(zhí)行（即伯克利的rsh服務器）這種攻擊，惡意命令可以被執(zhí)行。那么，如何來預測隨機的ISN？在Berkeley系統(tǒng)中，初始序列號變量遞增一次每秒不斷金額，該金額減半每次連接啟動。因此，如果一開始一個合法連接，并觀察使用的ISNS，就可以高度精密地計算該ISNS的使用在下次連接嘗試。莫里斯指出，回復消息S-T中SYN（ISNS）,ACK（ISNX）其實不是一個黑洞消失了，而是真正的主機T將接受它，并試圖重新連接。這不是一個嚴重的障礙。莫里斯發(fā)現(xiàn)，通過模擬對T服務器端口，并具有明顯的水浸，連接請求的端口，他可能會產生隊列溢出，將使它有可能的ST消息將會消失。另外，我們可以等待，直到T是日常保養(yǎng)或重新啟動了。本人在這一點上認同莫里斯的文章。盡管水浸能夠起作用沒有明確說明它，我預料到拒絕服務攻擊始于1996年，莫里斯實際上利用了Berkeley內核，用更少的錯誤數(shù)據(jù)包，實現(xiàn)了他的目標。該缺陷（如[10]所描述以及在莫里斯的文章）當時受到很少關注，直到許多年以后才被關注。對于序列號攻擊這個問題，除了我的論文之外很少受到關注。直到凱文米特尼克重新實現(xiàn)莫里斯的理念，并用它來攻擊下村勉[93]。下村接著追查米特尼克。不是由莫里斯描述，關于此TCP序列號攻擊的變種利用了netstat[86]服務。在這種攻擊中，入侵者模擬一個主機已關閉。如果可以用netstat的目標主機，可以提供必要的另一個端口上的序列號信息，這消除了所有需要猜測。netstat的伯克利的實施是危險的，但不是我這里給的原因。它沒有列出本機的開放端口，以及目前所有的連接;這兩個項目都是非常有價值的想成為攻擊者。事實上，發(fā)現(xiàn)前者是許多攻擊工具的主要功能塊。幸運的是，即使在1989年netstat命令不是由任何4.2bsd系統(tǒng)或4.3BSD系統(tǒng)默認提供的。仍然有在Tops-20系統(tǒng)對當時的網(wǎng);這些系統(tǒng)有一個脆弱的netstat命令。事實上,所以我沒有提到,因為怕指向的襲擊者指向它。實際產量見圖1。更重要的一點（這是一個[54]提出），是將R-公用事業(yè)隱含依賴于TCP序列號，并因此對TCP會話的正確性，為安全屬性。但是，TCP從來沒有設計成一個安全協(xié)議，也沒有出現(xiàn)過有關的序列號的任何屬性的保證。根本的問題是：怎樣的一個層的屬性是“出口“到一個更高的層？假設在任何較高太多以后是一個錯誤，它可以導致功能失靈的正確性以及安全性故障。對于這個問題，有必要更加緊密地詢問，甚至在一個序列號安全協(xié)議：他們是什么性質保證呢？僅僅因為他們的數(shù)據(jù)包序列號，或者可以被理解為，例如，對計數(shù)器模式加密初始化向量[35]？

是否有一個安全問題？是的，當然是有，如圖形顯示，幾年后，在主場迎戰(zhàn)下村米尼克事件。但是，建筑缺陷是假定TCP序列號了安全性能，他們沒有。（諷刺的是，我聽說的序列號的安全屬性分析，事實上，在世界上所做的分類，他們得出結論，這種攻擊并不可行…）序列號攻擊的故事還沒有結束。2021年，沃森指出，TCP復位數(shù)據(jù)包應該很榮幸，如果RST位是在一包的初始序列號是接收窗口內的任何地方（見US-CERT的電腦安全警報技術TA04-111A章）為基礎。在現(xiàn)代系統(tǒng)中，接收窗口是奧芬32K字節(jié)以上，這意味著它只需不到217試驗，通過這種盲目的攻擊產生這樣的數(shù)據(jù)包。這聽起來像一個很大的數(shù)據(jù)包，它僅僅是一個拒絕服務攻擊，但對于長期生活會話（尤其是在BGP的[84]路由器之間的特別會議），這是相當可行的攻擊。此外，拆除一個BGP會話對全球路由表互聯(lián)網(wǎng)廣泛的影響。

圖1。輸出在Tops-20netstat命令。請注意“發(fā)送”和“'收到“序列號。在狀態(tài)顯示的第一行是會議上是我用于檢索的數(shù)據(jù)。防御

顯然，這種攻擊的關鍵是在上大學伯克利分校系統(tǒng)的初始序列號變量的變化率相對粗糙。TCP的規(guī)范要求，這個變量遞增約每秒25萬次;伯克利使用速度卻慢得多。不過，關鍵的因素是粒度，而不是平均水平。從一個每秒128增量4.2bsd系統(tǒng)改變每秒125,0004.3BSD是沒有意義的，即使后者在一個指定的兩個因素是利率。讓我們看看是否有一個真正的柜臺，在250,000Hz的頻率操作會有所幫助。為了簡便起見，我們將忽略其他連接發(fā)生的問題，只考慮改變此計數(shù)器的固定利率。

要了解當前的序列號，必須發(fā)送一個SYN包，并接收響應，如下：X→S:SYN(ISNX)S→X:SYN(ISNS),ACK(ISNX) (1)第一個偽造包能夠緊跟在服務器的響應對探測包起作用，這將觸發(fā)下一個序列號生成：X→S:SYN(ISNX),SRC=T (2)在反應中的ISNS序列號該序列號唯一由信息源（1）與消息服務器（2）收到的時間決定。但這個數(shù)字恰恰是與X和S往返時間。因此，如果能精確測量欺騙程序（和預測）那個時候，即使4μ-第二個時鐘不會擊敗這種攻擊。S→T:SYN(ISNS),ACK(ISNX)行程時間的衡量能準確到什么程度呢？如果我們假設穩(wěn)定性好，我們或許可以在10毫秒或約束所以它。顯然，互聯(lián)網(wǎng)不會出現(xiàn)在長期[64]這種穩(wěn)定的，但它往往是在短期term.2足夠好，因此有2500中為iSNS的可能值的不確定性。如果每次試驗需要5秒鐘，假設有時間重新測量往返時間，入侵者將有一個合理的七千五百秒成功的可能性，以及近一天之內肯定。更多的可預測性（即，更高的質量）的網(wǎng)絡，或者更準確測量，將進一步提高的可能性在入侵者的青睞。顯然，只要按照規(guī)范的TCP信是不夠的。我們迄今沒有處理默認假定發(fā)生在目標主機的地方。事實上，一個新的請求出現(xiàn)時我們確實進行了一些處理，而可變性量在此處理中是至關重要的。在6MIPS的機器，一剔-4μ-秒，約25指令。因此，對于精確指示路徑有相當?shù)拿舾卸?。高?yōu)先級中斷，或略有不同的TCB分配順序，將對下一個序列號的實際價值較大的影響。這種隨機效應是相當大的優(yōu)勢的目標。應當指出，雖然，更快的機器更容易受到這種攻擊，因為該指令路徑變異將需要更少的實時性，并因而影響增量較少。當然，CPU的速度迅速增加。這表明另一個序列號攻擊的解決方案：隨機的增量。必須小心使用足夠的位，如果說只有低8位隨機挑選的，而增量粒度較粗，入侵者的工作因素，只是乘以256。一個精細粒度遞增和一個小的隨機數(shù)生成器，或者只是一個32位發(fā)生器，組合為好。請注意，雖然，許多偽隨機數(shù)生成器很容易可逆[13]。事實上，由于大多數(shù)這類發(fā)電機的輸出通過反饋工作，敵人可以簡單地計算出下一個選出的“隨機“數(shù)目。一些混合技術已經許諾使用32位發(fā)生器，例如，但它只能發(fā)出16位，但是蠻力攻擊可能會取得成功確定種子。人們會每個增量需要至少16位的隨機數(shù)據(jù)，也許更多，打敗從網(wǎng)絡探測器，但也可能給數(shù)位提防的種子搜索。為確定正確的參數(shù)需要更多的研究和模擬。與其這么精密，更簡單的方法是使用加密算法的iSNS代（或設備）。數(shù)據(jù)加密標準[73]的電子密碼本模式[74]是為iSNS的來源有吸引力的選擇作為輸入簡單的計數(shù)器。另外，可用于DES的輸出反饋模式，無需額外的計數(shù)器。無論哪種方式，必須采取非常謹慎選擇。開機時間是不足夠的;充分了解良好的信息重新啟動時間往往是提供給入侵者，從而使強力攻擊。但是，如果重新啟動時間是加密并生成每個主機密鑰，任何合理的努力都不能破解。初始序列號生成器性能是沒有問題的。新的序列號是在每個連接只需要一次，甚至一對DES軟件實現(xiàn)就足夠了。2.3毫秒加密1倍MIPS處理器已有報道[12]。另外防御涉及好的日志和報警機制。在往返測量的時間為攻擊RFC兼容的主機必要將最有可能進行使用ICMPping消息，一個“轉發(fā)“功能，可以登錄過度ping請求。另一方面，也許更適用，定時測量技術包括TCP連接嘗試，這些連接都明顯短命的，甚至可能不會完全和SYN的處理。同樣，欺騙活動主機最終會產生不尋常的RST報文類型，這些不應該經常發(fā)生，并且應該被記錄。經過多年思考它，我終于想出了序列號攻擊的解決方案。該計劃如RFC所描述1948[10]，采用了加密散列函數(shù)來創(chuàng)建一個單獨的序列號空間，為每一個“連接“，每一個連接被RFC791[81]定義為唯一4tuple<本地主機，本機連接埠，遠程主機，遠程連接埠>。這個計劃沒有被廣泛采納如我所想地那樣，我在這里認為，在TCP連接建立額外的CPU負載無關呈現(xiàn)的是非常大的Web服務器出現(xiàn)過時。朗讀GāijìhuàrúRFCsuǒmiáoshù1948[10],cǎiyònglejiāmìsànlièhánshǔláichuàngjiànyīgèdāndúdexùlièhàokōngjiān,wèiměiyīgè“l(fā)iánjiē“,měiyīgèliánjiēbèiRFC791[81]dìngyìwèiwéiyī4tuple<běndìzhǔjī,běnjīliánjiēbù,yuǎnchéngzhǔjī,yuǎnchéngliánjiēbù>.Zhègejìhuàméiyǒubèiguǎngfàncǎinàrúwǒsuǒxiǎngdenàyàng,wǒdeyāoqiúzhèlǐ,zàiTCPliánjiējiànlìéwàideCPUfùzǎiwúguānchéngxiàndeshìfēichángdàdeWebfúwùqìchūxiànguòshí.Shìshíshàng,zuìdàdeTCPliánjiēsùlǜshìyīgèzhòngyàodezhǐbiāoláipínggūxiàndàixìtǒng.字典-查看字典詳細內容事實上，最大的TCP連接速率是評估現(xiàn)代系統(tǒng)一個重要的指標。相反，許多實現(xiàn)使用隨機的iSNS或（特別是）隨機增量。這對TCP在重復的數(shù)據(jù)包，一個是保證更高層次的正確性財產存在明顯的負面影響。（也看到了[52]附錄。）更糟的是，紐沙姆指出，中心極限定理，隨機遞增序列的總和將有一個正常的分布，這意味著，該iSNS的實際范圍是相當小。（見CERT建議的CA-2021-09）。有些混合計劃不屬于這些攻擊，但潛在的信息與在1989年是相同的：不依賴于安全的TCP序列號。另外值得一提的是建議，入侵檢測系統(tǒng)可以發(fā)揮的作用：他們可以提醒你由于某些原因你無法招架的攻擊。附件2：外文原文ALookBackat“SecurityProblemsintheTCP/IPProtocolSuite”StevenM.BellovinAT&TLabs—Researchbellovin@AbstractAboutfifteenyearsago,IwroteapaperonsecurityproblemsintheTCP/IPprotocolsuite,Inparticular,Ifocusedonprotocol-levelissues,ratherthanimplementationflaws.Itisinstructivetolookbackatthatpaper,toseewheremyfocusandmypredictionswereaccurate,whereIwaswrong,andwheredangershaveyettohappen.Thisisareprintoftheoriginalpaper,withaddedcommentary.1.IntroductionThepaper“SecurityProblemsintheTCP/IPProtocolSuite”wasoriginallypublishedinComputerCommunicationReview,Vol.19,No.2,inApril,1989.Itwasaprotocol-levelanalysis;Iintentionallydidnotconsiderimplementationoroperationalissues.Ifelt—andstillfeel—thatthatwastherightapproach.Bugscomeandgo,andeveryone’soperationalenvironmentisdifferent.Butit’sveryhardtofixprotocol-levelproblems,especiallyifyouwanttomaintaincompatibilitywiththeinstalledbase.Thispaperisaretrospectiveonmyoriginalwork.Newcommentaryisshownindented,inasansseriffont.Theoriginaltextisotherwiseunchanged,exceptforpossibleerrorsintroducedwhenconvertingitfromtrofftoLATEX.I’veleftthereferencesintact,too,eveniftherearebetterversionstoday.Thereferencenumbersandpaginationare,ofcourse,different;thesectionnumbersremainthesame,exceptforanew“Conclusions”section.Asagen-Thispaperwaspresentedat20thAnnualComputerSecurityApplicationsConference(ACSAC),December2021,inaspartofthe“classicpapers”track.eralrule,thecommentaryfollowsthesectionit’sdiscussing.Ithelpstounderstandwherethispapercamefrom.WhenIstartedworkatBellLabsMurrayHillin1982,Iassumedownershipof112ofthefirstthreepiecesofEthernetcableinallofAT&T,thenagiantmonopolytelephonecompany.Mylabhadonecable,anotherlabhadasecond,anda“backbone”linkedthetwolabs.Thatbackbonegrew,asotherlabsconnectedtoit.Eventually,wescroungedfundstosetuplinkstootherBellLabslocations;wecalledtheresulingnetworkthe“BellLabsInternet”orthe“R&DInternet”,theneologism“Intranet”nothavingbeeninvented.Dedicatedrouterswererarethen;wegenerallystuckasecondEthernetboardintoaVAXoraSunandusedittodotherouting.Thismeanthattheroutingsoftware(weusedBerkeley’srouted)wasaccessibletosystemadministrators.Andwhenthingsbroke,weoftendiscoveredthatitwasaroutingproblem:someonehadmisconfiguredtheirmachine.Once,wefoundthatsomeonehadpluggedanewworkstationintotheMurrayHillbackbone,ratherthanintohisdepartment’snetwork;worseyet,the(proprietary)addressassignmentsoftwareonhismachinedidn’tseeany(proprietary)addressassignmentserversonthatnetwork,soitallocated.1—thegatewayyrouter—toitself.Thesetwosituationsworriedme;itwasclearthatanythingthatcouldhappenbyaccidentcouldbedonedeliberately,possiblywithseriousconsequences.Severalotherthingsfocusedmyattentiononsecurityevenmore.OnewasRobertMorris’discoveryofsequencenumberguessingattacks;thesearediscussedextensivelybelow.Anotherwasthe“ShadowHawk”incident—ateenagerbrokeintovariousAT&Tcomputers[2].HewasdetectedwhenhetriedtouseuucptograbpasswordfilesfromvariousResearchmachines;anumberofushadinstalleddetectorsforexactlythatsortofactivity,andnoticedtheunusualbehavior.Atthat,wewerelucky—mostoftheconnectivitywithinAT&TwasviatheproprietaryDatakitnetwork,whichhedidn’tknowhowtoexploit.BythetimeoftheInternetwormof1988,thispaperwasalreadyinsubstantiallyitscurrentform.Theresultwasananalysis(tothebestofmyability;Iwasrelativelynewtosecurityatthetime)ofprotocol-levelproblemsinTCP/IP.Theoriginalpaperwascriticizedin[54].Someofthecriticismswerevalid;some,inmyopinion,werenot.Atthetime,Ichosenottopublishadetailedrebuttal;Iwillnotdosohere.Ihave,whereappropriate,notedwheremyanalysiswasespeciallyincorrect.Ididanddofeelthatmyconclusionsweresubstantiallycorrect.TheTCP/IPprotocolsuite[41,21]whichisverywidelyusedtoday,wasdevelopedunderthesponsorshipoftheDepartmentofDefense.Despitethat,thereareanumberofserioussecurityflawsinherentintheprotocols.SomeoftheseflawsexistbecausehostsrelyonIPsourceaddressforauthentication;theBerkeley“r-utilities”[22]areanotableexample.Othersexistbecausenetworkcontrolmechanisms,andinparticularroutingprotocols,haveminimalornonexistentauthentication.Whendescribingsuchattacks,ourbasicassumptionisthattheattackerhasmoreorlesscompletecontroloversomemachineconnectedtotheInternet.Thismaybeduetoflawsinthatmachine’sownprotectionmechanisms,oritmaybebecausethatmachineisamicrocomputer,andinherentlyunprotected.Indeed,theattackermayevenbearoguesystemadministrator.1.1.ExclusionsWearenotconcernedwithflawsinparticularimplementationsoftheprotocols,suchasthoseusedbytheInternet“worm”[95,90,38]Rather,wediscussgenericproblemswiththeprotocolsthemselves.Aswillbeseen,carefulimplementationtechniquescanalleviateorpreventsomeoftheseproblems.SomeoftheprotocolswediscussarederivedfromBerkeley’sversionoftheUNIXsystem;othersaregenericInternetprotocols.Wearealsonotconcernedwithclassicnetworkattacks,suchasphysicaleavesdropping,oralteredorinjectedmessages.Wediscusssuchproblemsonlyinsofarastheyarefacilitatedorpossiblebecauseofprotocolproblems.Forthemostpart,thereisnodiscussionhereofvendor-specificprotocols.WedodiscusssomeproblemswithBerkeley’sprotocols,sincethesehavebecomedefactostandardsformanyvendors,andnotjustforUNIXsystems.Oneofthecriticismsin[54])wasthatIhadlumpedBerkeley-specificprotocolstogetherwithstandardizedprotocolsdescribedinRFCs.It’squiteclearfromthepreceedingparagraphthatIunderstoodthedifference.However,theuseofaddress-basedauthentication—amajorflawthatIcriticizethroughoutthepaper—waspeculiartoBerkeley’ssoftware;Ididnotmakethatdistinctionclear.Itisindeedabadwaytodoauthentication,butitwasnotblessedbyanyofficialstandard.2.TCPSequenceNumberPredictionOneofthemorefascinatingsecurityholeswasfirstdescribedbyMorris[70].Briefly,heusedTCPsequencenumberpredictiontoconstructaTCPpacketsequencewithouteverreceivinganyresponsesfromtheserver.Thisallowedhimtospoofatrustedhostonalocalnetwork.ThenormalTCPconnectionestablishmentsequenceinvolvesa3-wayhandshake.TheclientselectsandtransmitsaninitialsequencenumberISNC,theserveracknowledgesitandsendsitsownsequencenumberISNS,andtheclientacknowledgesthat.Followingthosethreemessages,datatransmissionmaytakeplace.Theexchangemaybeshownschematicallyasfollows:C!S:SYN(ISNC)S!C:SYN(ISNS),ACK(ISNC)C!S:ACK(ISNS)C!S:dataand/orS!C:dataThatis,foraconversationtotakeplace,CmustfirsthearISNS,amoreorlessrandomnumber.Suppose,though,thattherewasawayforanintruderXtopredictISNS.Inthatcase,itcouldsendthefollowingsequencetoimpersonatetrustedhostT:X!S:SYN(ISNX),SRC=TS!T:SYN(ISNS),ACK(ISNX)X!S:ACK(ISNS),SRC=TX!S:ACK(ISNS),SRC=T,nasty?dataEventhoughthemessageS!TdoesnotgotoX,Xwasabletoknowitscontents,andhencecouldsenddata.IfXweretoperformthisattackonaconnectionthatallowscommandexecution(i.e.,theBerkeleyrshserver),maliciouscommandscouldbeexecuted.How,then,topredicttherandomISN?InBerkeleysystems,theinitialsequencenumbervariableisincrementedbyaconstantamountoncepersecond,andbyhalfthatamounteachtimeaconnectionisinitiated.Thus,ifoneinitiatesalegitimateconnectionandobservestheISNSused,onecancalculate,withahighdegreeofconfidence,ISN′Susedonthenextconnectionattempt.MorrispointsoutthatthereplymessageS!T:SYN(ISNS),ACK(ISNX)doesnotinfactvanishdownablackhole;rather,therealhostTwillreceiveitandattempttoresettheconnection.Thisisnotaseriousobstacle.MorrisfoundthatbyimpersonatingaserverportonT,andbyfloodingthatportwithapparentconnectionrequests,hecouldgeneratequeueoverflowsthatwouldmakeitlikelythattheS!Tmessagewouldbelost.Alternatively,onecouldwaituntilTwasdownforroutinemaintenanceorareboot.ImischaracterizedMorris’paperonthispoint.Whilefloodingcanwork—withoutexplicitlystatingit,Ianticipatedthedenialofserviceattacksthatstartedoccurringin1996—MorrisinfactexploitedanimplementationerrorintheBerkeleykerneltoaccomplishhisgoalwithmanyfewerpackets.Thatflaw(describedin[10]aswellasinMorris’paper)receivedverylittleattentionatthetime,andwasnotfixeduntilmanyyearslater.Forthatmatter,sequencenumberattacksreceivedlittleattentionoutsideofmypaper,untilKevinMitnickreimplementedMorris’ideaandusedittoattackTsutomuShimomura[93].ShimomurathenproceededtotrackdownMitnick.AvariantonthisTCPsequencenumberattack,notdescribedbyMorris,exploitsthenetstat[86]service.Inthisattack,theintruderimpersonatesahostthatisdown.Ifnetstatisavailableonthetargethost,itmaysupplythenecessarysequencenumberinformationonanotherport;thiseliminatesallneedtoguess.1TheBerkeleyimplementationofnetstatwasdangerous,butnotforthereasonsthatIgavehere.Itdidlisttheopenportsonthemachine,1Thenetstatprotocolisobsolete,butisstillpresentonsomeInternethosts.Securityconcernswerenotbehinditselimination.aswellasallcurrentconnections;bothitemsareveryvaluabletowould-beattackers.Indeed,discoveringtheformerisamajorpieceoffunctionalityofmanyattacktools.Fortunately,evenin1989netstatwasnotavailablebydefaultonany4.2BSDor4.3BSDsystems.TherewerestillTOPS-20systemsonthenetatthattime;thosesystemshadavulnerablenetstat,afactIrefrainedfrommentioningforfearofpointingattackersattargets.ActualoutputisshowninFigure1.Thereareseveralsalientpointshere.Thefirst,ofcourse,whichIstressedatthetime,isthataddress-basedauthenticationisveryvulnerabletoattack.Iwillreturntothispointlater.AsecondpointisathreatImentionlater,butnotinthiscontext:ifyouknowthesequencenumbersofanactivesession,youcanhijackit.ThisattackwasimplementedafewyearslaterbyJoncheray[53].Amoreimportantpoint(andthisisonemadein[54])isthatther-utilitiesareimplicitlyrelyingonTCPsequencenumbers—andhenceonTCPsessioncorrectness—forsecurityproperties.However,TCPwasneverdesignedtobeasecureprotocol,norwerethereeveranyguaranteesaboutthepropertiesofthesequencenumber.Theunderlyingissueisthis:whatpropertiesofalayerare“exported”toahigherlayer?Assumingtoomuchatanyhigherlaterisamistake;itcanleadtocorrectnessfailursaswellastosecurityfailures.Forthatmatter,itisnecessarytoinquireevenmoreclosely,evenofsequencenumbersinasecurityprotocol:whatpropertiesaretheyguaranteedtohave?Aretheysimplypacketsequencenumbers,orcantheybeusedas,say,theinitializationvectorforcountermodeencryption[35]?Wasthereasecurityproblem?Yes,therecertainlywas,asdemonstratedgraphicallyafewyearslaterintheMitnickvs.Shimomuraincident.ButthearchitecturalflawwastheassumptionthatTCPsequencenumbershadsecuritypropertieswhichtheydidnot.(Ironically,IhaveHeardthatanalysesofthesecuritypropertiesofsequencenumberswere,infact,doneintheclassifiedworld—andtheyconcludedthatsuchattackswerenotfeasible...)Thesequencenumberattackstoryisn’tover.In2021,WatsonobservedthatTCPresetpacketswerehonorediftheRSTbitJCNSTATELPORTFPORTFGN-HOSTR-SEQUENCES-SEQUENCESENDW0,-1-3-.EST.OOPA---152934ATT.ARPA33388800176080742540966,6FIN.FIN.--P----1500,0,0,00006,5FIN.FIN.--P----7900,0,0,00000,21-3-.EST.O-PAV--23411926,1,0,1629289421757012358453190,2-3-.EST.O-PAV--231792192,33,33,1157396133426605429234096Figure1.OutputfromaTOPS-20netstatcommand.Notethe“send”and”‘receive”sequencenumbers.ThefirstlineinthestatusdisplayisthesessionIusedtoretrievethedata.wassetonapacketwhoseinitialsequencenumberwasanywherewithinthereceivewindow(seeUS-CERTTechnicalCyberSecurityAlertTA04-111A).Onmodernsystems,thereceivewindowisofen32Kbytesormore,whichmeansthatittakeslessthan217trialstogeneratesuchapacketviaablindattack.Thatsoundslikealotofpackets,andit’sonlyadenialofserviceattack,butforlonglivedsessions(andinparticularforBGP[84]sessionsbetweenrouters),it’squiteafeasibleattack.Furthermore,tearingdownasingleBGPsessionhaswide-spreadeffectsontheglobalInternetroutingtables.DefensesObviously,thekeytothisattackistherelativelycoarserateofchangeoftheinitialsequencenumbervariableonBerkeleysystems.TheTCPspecificationrequiresthatthisvariablebeincrementedapproximately250,000timespersecond;Berkeleyisusingamuchslowerrate.However,thecriticalfactoristhegranularity,nottheaveragerate.Thechangefromanincrementof128persecondin4.2BSDto125,000persecondin4.3BSDismeaningless,eventhoughthelatteriswithinafactoroftwoofthespecifiedrate.Letusconsiderwhetheracounterthatoperatedatatrue250,000hzratewouldhelp.Forsimplicity’ssake,wewillignoretheproblemofotherconnectionsoccurring,andonlyconsiderthefixedrateofchangeofthiscounter.Tolearnacurrentsequencenumber,onemustsendaSYNpacket,andreceivearesponse,asfollows:X!S:SYN(ISNX)S!X:SYN(ISNS),ACK(ISNX)(1)Thefirstspoofpacket,whichtriggersgenerationofthenextsequencenumber,canimmediatelyfollowtheserver’sresponsetotheprobepacket:X!S:SYN(ISNX),SRC=T(2)ThesequencenumberISNSusedintheresponseS!T:SYN(ISNS),ACK(ISNX)isuniquelydeterminedbythetimebetweentheoriginationofmessage(1)andthereceiptattheserverofmessage(2).Butthisnumberispreciselytheround-triptimebetweenXandS.Thus,ifthespoofercanaccuratelymeasure(andpredict)thattime,evena4μ-secondclockwillnotdefeatthisattack.Howaccuratelycanthetriptimebemeasured?Ifweassumethatstabilityisgood,wecanprobablybounditwithin10millisecondsorso.Clearly,theInternetdoesnotexhibitsuchstabilityoverthelong-term[64],butitisoftengoodenoughovertheshortterm.2Thereisthusanuncertaintyof2500inthepossiblevalueforISNS.Ifeachtrialtakes5seconds,toallowtimetore-measuretheround-triptime,anintruderwouldhaveareasonablelikelihoodofsucceedingin7500seconds,andanear-certaintywithinaday.Morepredictable(i.e.,higherquality)networks,ormoreaccuratemeasurements,wouldimprovetheoddsevenfurtherintheintruder’sfavor.Clearly,simplyfollowingtheletteroftheTCPspecificationisnotgoodenough.Wehavethusfartacitlyassumedthatnoprocessingtakesplacesonthetargethost.Infact,someprocessingdoestakeplacewhenanewrequestcomesin;theamountofvariabilityinthisprocessingiscritical.Ona6MIPSmachine,onetick—4μ-seconds—isabout25instructions.Thereisthusconsiderablesensitivitytotheexactinstructionpathfollowed.High-priorityinterrupts,oraslightlydifferentTCBallocationsequence,willhaveacomparativelylargeeffectontheactualvalueofthenextsequencenumber.Thisrandomizingeffectisofconsiderableadvantagetothetarget.Itshouldbenoted,though,thatfastermachinesaremorevulnerabletothisattack,sincethevariabilityoftheinstructionpathwilltakelessrealtime,andhenceaffecttheincrementless.Andofcourse,CPUspeedsareincreasingrapidly.Thissuggestsanothersolutiontosequencenumberattacks:randomizingtheincrement.Caremustbetakentousesufficientbits;if,say,onlythelow-order8bitswerepickedrandomly,andthegranularityoftheincrementwascoarse,theintruder’sworkfactorisonlymultipliedby256.Acom-2Atthemoment,theInternetmaynothavesuchstabilityevenovertheshort-term,especiallyonlong-haulconnections.Itisnotcomfortingtoknowthatthesecurityofanetworkr