網(wǎng)絡(luò)安全概述(ppt79頁)(編輯修改稿)
2025-02-26 11:15 本頁面
【文章內(nèi)容簡介】 獲取服務(wù)類型的辦法是根據(jù) RFC1700直接推斷 。 但是下面幾種 情況可能會使這項工作變得稍微有些麻煩： 252。該主機將某服務(wù)故意開設(shè)了非標(biāo)準(zhǔn)端口； 252。該主機開設(shè)了一個 RFC1700中未定義的服務(wù)； 252。該主機被安臵了后門程序 。 所以有時候僅憑端口號來判斷服務(wù)類型是不夠的 ， 可能 需要更多的信息 。 3. 操作系統(tǒng)探測 利用 TCP/IP堆棧指紋識別操作系統(tǒng)是近年來發(fā)展迅 速的一類技術(shù)。這類技術(shù)的出現(xiàn)主要基于以下幾個原因： ?? 每個操作系統(tǒng)通常都使用自己的 IP棧實現(xiàn)； ?? TCP/IP規(guī)范并不是被嚴(yán)格地執(zhí)行，每個不同的實現(xiàn)將會擁有自己的特點； ?? 規(guī)范中一些選擇性的特性可能在某些系統(tǒng)中使用，而在其他的一些系統(tǒng)中則沒有使用； ?? 某些系統(tǒng)私自對 IP協(xié)議做了改進(jìn)。目前主要的網(wǎng)絡(luò)堆棧特征探測技術(shù)有如下幾種： ICMP響應(yīng)分析、 TCP報文響應(yīng)分析、 TCP報文延時 分析、被動特征探測。 （ 1） ICMP響應(yīng)分析 這種方法向目標(biāo)發(fā)送 UDP或者 ICMP報文，然后分 析目標(biāo)響應(yīng)的 ICMP報文的內(nèi)容，根據(jù)不同的響應(yīng)特征 來判斷操作系統(tǒng)。 前面已經(jīng)介紹過， ICMP數(shù)據(jù)報是封裝在 IP數(shù)據(jù)報 之內(nèi)的，而且這種判斷操作系統(tǒng)的方法也利用了 IP頭 部的字段內(nèi)容，所以在具體說明這種方法使用的技術(shù) 之前，有必要先熟悉一下 IP數(shù)據(jù)報的頭部。 其中需要注意的是服務(wù)級別 TOS、總長度、標(biāo)識、 DF位、生存期 TTL和校驗和字段。 下面分別說明 ICMP響應(yīng)分析方法使用的具體技術(shù)。 ① ICMP差錯報文引用大小。 ICMP的規(guī)則之一是 ICMP差錯報文必須包括生成該差錯報文的數(shù)據(jù)報 IP頭部（包含任何選項），還必須至少包括跟在該 IP頭部后面的前 8個字節(jié)。 圖顯示了由 UDP數(shù)據(jù)報引起的 ICMP端口不可到達(dá)差錯 報文。 圖 “ UDP端口不可到達(dá)”差錯報文 3. 操作系統(tǒng)探測 導(dǎo)致差錯的數(shù)據(jù)報中的 IP頭部要被送回的原因是 IP頭部中包含了協(xié)議字段，使得 ICMP可以知道如何解 釋后面的 8個字節(jié)（在圖 UDP頭部）。 大多數(shù)操作系統(tǒng)都只返回產(chǎn)生差錯的數(shù)據(jù)報的 IP 頭部后的前 8個字節(jié)，然而有一些操作系統(tǒng)在這 8個字 節(jié)之后還返回更多的字節(jié)（這些字節(jié)通常是沒有任何 意義的）。 這樣的系統(tǒng)包括 Linux（內(nèi)核 ）、 SUN Solaris、 HPUX 、 MacOS 、 Nokia系統(tǒng)、 Foundry交換機和其他一些操作系統(tǒng)或者 網(wǎng)絡(luò)設(shè)備。 ② ICMP差錯報文回顯完整性。 一般而言，在發(fā)送 ICMP差錯報文時，差錯報文的數(shù)據(jù)部 分，只有產(chǎn)生差錯的數(shù)據(jù)報 IP頭部的 TTL字段和 IP頭部校驗 和字段會與初始報文不同，因為初始報文到達(dá)目標(biāo)之前會經(jīng)過一系列的路由設(shè)備，而每經(jīng)過一個設(shè)備 TTL都會減一，相應(yīng)的校驗和也要重新計算。 然而實際情況是，有些操作系統(tǒng)會改變產(chǎn)生差錯的數(shù)據(jù)報 IP頭部的其他字段的內(nèi)容和 /或后面數(shù)據(jù)的內(nèi)容。 如果用 UDP數(shù)據(jù)報產(chǎn)生的端口不可到達(dá)差錯報文來進(jìn)行分 析，可以利用的特點包括下面一些內(nèi)容： IP數(shù)據(jù)報總長度 AIX BSDI IP棧會將 產(chǎn)生差錯的數(shù)據(jù)報 IP頭部的總長度字段加上 20，而另一些系統(tǒng)會將這個字段的數(shù)值減少 20，更多的系統(tǒng)會保持這個字段的內(nèi)容不變。 IP數(shù)據(jù)報標(biāo)識（ IPID） FreeBSD 、 OpenVMSs和 ULTRIX等系統(tǒng)的 IP棧不能正確回顯產(chǎn)生差錯數(shù)據(jù)報的 IPID，它們回顯的 IPID的位順序和初始順序不同。其他 更多的系統(tǒng)則能夠正確回顯 IPID字段。 分段標(biāo)志（ 3位）和片偏移有一些系統(tǒng)會改變產(chǎn)生差 錯的數(shù)據(jù)報頭部中 3位分段標(biāo)志和片偏移字段的位順序， 而另一些系統(tǒng)只能正確回顯。 IP頭部校驗和 FreeBSD 、 OpenVMSs和 ULTRIX等 系統(tǒng)會將產(chǎn)生差錯的數(shù)據(jù)報 IP頭部的校驗和字段臵為 0， 而大多數(shù)的系統(tǒng)只是將重新計算的校驗和回顯。 UDP頭部校驗和 FreeBSD 、 Compaq Tru6 DG UX 、 AIX 、 ULTRIX和 OpenVMS等系統(tǒng) 會將差錯報文中的 UDP頭部的校驗和字段臵為 0。另外的 一些系統(tǒng)則會保持 UDP校驗和不變。 ③ ICMP差錯報文的“優(yōu)先權(quán)”字段。 IP頭部中有一個 8位的 TOS字段， TOS字段包括一個 3位的優(yōu) 先權(quán)字段、 4位的 TOS子字段和一位必須臵 0的未用位，如圖 Ipuuee頭部的 TOS字段。 ④ ICMP差錯報文 IP頭部的不分片 （ DF） 位 。 有一些操作系統(tǒng)在發(fā)送 ICMP差錯報文時 ， 會根據(jù)引起差錯的數(shù)據(jù)報的 IP頭部的 DF位來設(shè)臵差錯報文本身 IP頭部的 DF位 。 Linux 、 ULTRIX 、 Novell Netware 、 HPUX 、Windows98/98SE/ME、 Windows NT4 Server SP Windows 2023 Family等系統(tǒng)則不會這么做 。 ⑤ ICMP報文 IP頭部的 TTL字段 。 不同的操作系統(tǒng)在設(shè)臵 ICMP報文 IP頭部的 TTL字段時有不同的默認(rèn)值 。 而且一般來講 ， ICMP應(yīng)答報文和 ICMP查詢報文的 TTL還不一樣 。 例如 ， Windows 95應(yīng)答報文和查詢報文的 TTL都是32Windows 98/98SE/ME/NT4應(yīng)答報文的 TTL是 12 查詢報文的 TTL是 32； Windows 2023應(yīng)答報文和查詢報文的 TTL都是 128。 ⑥ 使用代碼字段不為 0的 ICMP回顯請求 。 ICMP報文的種類由第一個字節(jié) （ 類型字段 ） 和第二個字節(jié) （ 代碼字段 ） 決定 。 回顯請求的類型字段為 8， 默認(rèn)的代碼字段為 0。 如果把回顯請求的代碼字段設(shè)臵為非 0值 ， 這樣的回顯請求就不是標(biāo)準(zhǔn)的 ICMP報文了 。 對于這樣的回顯請求報文 ，Windows操作系統(tǒng)做出的回顯應(yīng)答 （ 類型為 0） 的代碼字段值為 0， 而其他系統(tǒng)和網(wǎng)絡(luò)設(shè)備做出的回顯應(yīng)答的代碼字段值和它收到的回顯請求中的代碼字段值相同 。 ⑦ TOS子字段回顯 。 RFC1349定義了 ICMP報文使用 TOS子字段的方法 。 其中 區(qū)分了差錯報文 、 查詢報文和應(yīng)答報文的不同使用方法 ，規(guī) 則是： ?差錯報文總是使用默認(rèn)值 0； ?查詢報文可以在 TOS子字段中使用任何值； ?應(yīng)答報文應(yīng)該在 TOS子字段中使用造成應(yīng)答的查詢報文中使用的 TOS值 。 ?? 然而有些操作系統(tǒng) （ 例如 Linux） 在發(fā)送回顯應(yīng)答報文時忽視了這項規(guī)定 ， 無論查詢報文使用何種 TOS值 ， 它的應(yīng)答報文的 TOS值都是一樣的 。
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1