信息安全原理復(fù)習(xí)題

PAGE11/11如何理解Ipsec平安聯(lián)盟SA的本地化和單向性？在同一個節(jié)點設(shè)備上AH和ESP能共享同一個SA嗎？為什么？〔15〕平安關(guān)聯(lián)是兩個應(yīng)用IPsec實體〔主機(jī)、路由器〕間的一個單工連接，決定保護(hù)什么、如何保護(hù)以及誰來保護(hù)通信數(shù)據(jù)。它規(guī)定了用來保護(hù)數(shù)據(jù)報平安的平安協(xié)議、密碼算法、密鑰以及密鑰的生存期。SA是單向的，要么對數(shù)據(jù)報進(jìn)行“進(jìn)入〞保護(hù)，要么對數(shù)據(jù)報進(jìn)行“外出〞保護(hù)。·思考題.為什么IPSec要對進(jìn)入和外出兩個方向的SA進(jìn)行單獨的控制?進(jìn)入和外出的數(shù)據(jù)的平安需求不同，一般對進(jìn)入的數(shù)據(jù)平安要求更高，因此它們的平安處理未必相同，需要用不同SA處理一個SA對IP數(shù)據(jù)報只能提供AH或ESP保護(hù)。補(bǔ)充：假設(shè)應(yīng)用IPsec，策略要包含使用的平安協(xié)議〔AH、ESP〕、模式、算法等參數(shù)以平安關(guān)聯(lián)的形式存儲在SAD(securityAssociationdatabase)中。平安關(guān)聯(lián)的字段包括：目的IP地址(SA的目的地址，可為終端防火墻、路由器、系統(tǒng)等網(wǎng)絡(luò)設(shè)備)、IPsec協(xié)議〔標(biāo)識用的AH還是ESP〕、序號計數(shù)器〔用于產(chǎn)生AH或ESP頭的序號〕、序號計數(shù)器溢出標(biāo)志〔假設(shè)溢出，那么產(chǎn)生一個審計事件，并禁止用SA繼續(xù)發(fā)送數(shù)據(jù)報〕、抗重放窗口〔32bit計數(shù)器及位圖，決定進(jìn)入的AH或ESP數(shù)據(jù)報是否為重放的〕、密碼算法和密鑰、平安關(guān)聯(lián)的生存期.AH對應(yīng)IPsec數(shù)據(jù)交互階段，AH只提供認(rèn)證功能〔數(shù)據(jù)源發(fā)認(rèn)證和完整性校驗〕，ESP同時提供機(jī)密性和完整性保護(hù)〔機(jī)密性和認(rèn)證效勞〕，因為加解密操作是耗時的，所以在僅需要認(rèn)證的場合就可以使用AH。從部署方面看，IPsec有傳輸和隧道兩種模式，在網(wǎng)關(guān)上使用IPsec時，通常使用隧道模式，當(dāng)在兩臺主機(jī)上使用時，通常使用傳輸模式。分析SSL防重放攻擊的平安機(jī)制，并比擬分析其與ipsec反重放機(jī)制的主要異同點〔20〕SSL防重放是通過客戶端〔效勞器〕向效勞器〔客戶端〕發(fā)送隨機(jī)數(shù)來實現(xiàn)，期待這個隨機(jī)數(shù)兩次是不同的，如果有兩次隨機(jī)數(shù)相同，那么說明發(fā)生了重放攻擊。Ipsec防重放是使用AH或ESP中的序號，假設(shè)兩次序號相同，那么發(fā)生了重放攻擊。補(bǔ)充：IPsec防重放攻擊：使用AH〔ESP〕保護(hù)數(shù)據(jù)發(fā)送接收數(shù)據(jù)的處理過程：發(fā)送數(shù)據(jù)查詢SA以獲取平安參數(shù)(報文加密)生成序號計算認(rèn)證數(shù)據(jù)構(gòu)造IPsec報文并發(fā)送接收數(shù)據(jù)：根據(jù)<SPI，目的IP地址，平安協(xié)議>在SAD中查找相應(yīng)的SA，如果找不到就丟棄這個報文使用滑動窗口機(jī)制驗證序號，防止重放攻擊驗證認(rèn)證數(shù)據(jù)，假設(shè)通過驗證，那么復(fù)原數(shù)據(jù)并遞交給相應(yīng)的協(xié)議模塊或轉(zhuǎn)發(fā)，否那么丟棄報文〔驗證認(rèn)證數(shù)據(jù)，驗證失敗那么丟棄報文〕(解密，并將復(fù)原后的數(shù)據(jù)遞交給相應(yīng)的協(xié)議模塊或轉(zhuǎn)發(fā)，解密失敗那么丟棄報文)SSL〔平安套接層〕標(biāo)準(zhǔn)規(guī)定了4個協(xié)議：握手協(xié)議〔與SSL協(xié)商有關(guān)〕、更改密碼標(biāo)準(zhǔn)協(xié)議〔與ssl協(xié)商有關(guān)〕、警告協(xié)議〔同時包含SSL平安通道關(guān)閉及錯誤通告功能〕、記錄協(xié)議〔數(shù)據(jù)封裝和處理〕。SSL提供的平安效勞：機(jī)密性、完整性、效勞器認(rèn)證以及可選的客戶端認(rèn)證。客戶端想效勞器發(fā)送ClientHello消息，其中包含了客戶端所支持的各種算法和一個隨機(jī)數(shù)，這個隨機(jī)數(shù)將用于各種密鑰的推導(dǎo)，并可以防止重放攻擊。效勞器端返回ServerHello消息，隨機(jī)數(shù)的功能與上述相同。警告協(xié)議包括兩種功能：一是提供了報錯機(jī)制，即通信雙方假設(shè)某一方法發(fā)現(xiàn)了問題便會利用該協(xié)議通告對等段；二是提供了平安斷連機(jī)制，即以一種可認(rèn)證的方式關(guān)閉連接。從適用場景、平安機(jī)制、能對抗的平安威脅等方面〔至少包括、但不限于〕，具體比擬分析L2tp用戶認(rèn)證與PGP認(rèn)證的實現(xiàn)原理和平安性。〔15〕LAC：L2TP接入集中器；LNS：L2TP網(wǎng)絡(luò)效勞器遠(yuǎn)程系統(tǒng)的PPP幀首先發(fā)送給LAC，LAC將它作為L2TP協(xié)議報文的數(shù)據(jù)區(qū)封裝并發(fā)送給LNS，LNS那么對報文進(jìn)行解封處理后發(fā)送給家鄉(xiāng)網(wǎng)絡(luò)中的主機(jī)。某些情況下，主機(jī)可以不依賴LAC，而是獨立運行L2TP，并于LNS建立隧道。數(shù)據(jù)消息：通過數(shù)據(jù)通道傳輸，不保證數(shù)據(jù)的可靠傳輸，承載PPP幀?？刂葡ⅲ和ㄟ^控制通道傳輸，保證控制消息的可靠傳輸，用于L2TP隧道和會話的協(xié)商及維護(hù)。L2TP基于UDP。L2TP包括兩種消息，數(shù)據(jù)消息和控制消息，分別通過數(shù)據(jù)通道和控制通道傳輸，L2TP不保證數(shù)據(jù)消息的可靠傳輸，但保證控制消息的可靠傳輸。L2TP不提供對PPP數(shù)據(jù)的機(jī)密性和完整性保護(hù)，假設(shè)使用CHAP，那么可表達(dá)端點身份認(rèn)證的功能。L2TP規(guī)定了以下確?？刂葡⒌目煽客哆f的機(jī)制：每個L2TP報文都包含序列號，從而為監(jiān)測報文丟棄和亂序提供了根底L2TP使用肯定確認(rèn)防止報文丟棄，即接收方收到報文后發(fā)回確認(rèn)。發(fā)送發(fā)假設(shè)在一段時間之內(nèi)沒有手動啊確認(rèn)那么重發(fā)L2TP使用滑動窗口技術(shù)提高通信效率并進(jìn)行流量控制L2TP使用慢啟動策略防止擁塞PGP的平安業(yè)務(wù)數(shù)字簽名:DSS/SHA或RSA/SHA完整性：RSA、MD5消息加密:CAST-128或IDEA或3DES+Diffie-Hellman或RSA數(shù)據(jù)壓縮:ZIP郵件兼容:Radix64(將任意二進(jìn)制輸入，轉(zhuǎn)換成可打印的字符輸出的編碼技術(shù))數(shù)據(jù)分段：大郵件自動分段并在接收時自動恢復(fù)?！ど矸蓁b別·保密性發(fā)生在簽名后、加密前。壓縮壓縮發(fā)生在簽名后，加密前以下各題考慮如下列圖所示的原始應(yīng)用環(huán)境，A是遠(yuǎn)程工作前端網(wǎng)絡(luò)的接入網(wǎng)關(guān)，C是后臺業(yè)務(wù)資源網(wǎng)的接入網(wǎng)關(guān)。前述兩個網(wǎng)內(nèi)部IP分配均是獨立的私網(wǎng)地址，A與C之間為第三方IP網(wǎng)絡(luò)，其間可能存在NAT、或代理、或端口控制等環(huán)節(jié)。4.上圖所示網(wǎng)絡(luò)環(huán)境中，請注意B所在網(wǎng)段有網(wǎng)關(guān)A和無線網(wǎng)關(guān)W兩個出口。需要從B-C建立端-gate的IPSEC通道、并屏蔽W帶來的不確定性，如何建立B-C的ipsecSA平安聯(lián)盟？〔1〕請給出各種可能的sa組合；〔2〕并從中挑選出符合要求的ipsecsa隧道配置方案，并給出理由；〔3〕比擬分析各種可能的組合各自存在的主要平安風(fēng)險、以及對抗平安威脅能力的區(qū)別。〔25〕

考慮如下列圖所示的原始應(yīng)用環(huán)境，A是遠(yuǎn)程工作前端網(wǎng)絡(luò)的接入網(wǎng)關(guān)，C是后臺業(yè)務(wù)資源網(wǎng)的接入網(wǎng)關(guān)。前述兩個網(wǎng)內(nèi)部IP分配均是獨立的私網(wǎng)地址，A與C之間為第三方IP網(wǎng)絡(luò)，其間可能存在NAT、或代理、或端口控制等環(huán)節(jié)。5.考慮基于PGP和pop3/SMTP根本郵件效勞以附件形態(tài)從B到D傳輸大數(shù)據(jù)文件，基于PGP保證其間數(shù)據(jù)的機(jī)密性和完整性，考慮把B端CPU序列號和操作系統(tǒng)及用戶注冊信息等本地軟硬件環(huán)境參數(shù)的md5值作為端端識別參量，如何與大數(shù)據(jù)文件一起打包后〔請具體畫出封包形式〕經(jīng)pgp處理后傳到D端以認(rèn)證B設(shè)備？畫出從B端原始文件、到發(fā)送端處理、郵件發(fā)送、D端接收、接收端認(rèn)證和數(shù)據(jù)復(fù)原處理等主要操作流程，以及發(fā)送端和接收端對應(yīng)的端認(rèn)證過程?！?5〕PGP的實際操作由五種效勞組成：鑒別、機(jī)密性、電子郵件的兼容性、壓縮、分段和重裝PGP〔PrettyGoodPrivacy〕：是一個可提供機(jī)密性和認(rèn)證的軟件。通常用來加密和解密電子郵件。Md5用作單向hash函數(shù)，通過使用RSA算法加密，用郵件發(fā)送者的秘密鑰對md5消息摘要進(jìn)行加密(2)Ks:sessionkeyKRa:用戶A的私鑰KUa:用戶A的公鑰EP:公鑰加密DP:公鑰解密EC:常規(guī)加密DC:常規(guī)解密H:散列函數(shù)||:連接Z:用ZIP算法數(shù)據(jù)壓縮R64:用radix64轉(zhuǎn)換到ASCII格式PGP消息產(chǎn)生過程PGP消息接收過程：平安協(xié)議在TCP/IP協(xié)議棧的分布應(yīng)用層：L2TP、SSH〔基于TCP〕、PGP、IKE傳輸層：SSL、SocksIP層：IPSecL2TP：不提供機(jī)密性〔沒有對數(shù)據(jù)的加密功能〕，IPsec：身份認(rèn)證、機(jī)密性、完整性和防止重放攻擊IKE的功能包括SA協(xié)商、密鑰生成和身份認(rèn)證，它是一個應(yīng)用層協(xié)議基于UDP。身份認(rèn)證(IKE，通信雙方互相認(rèn)證)數(shù)據(jù)源發(fā)認(rèn)證(AH、ESP)完整性〔AH、ESP〕防止重放攻擊〔AH、ESP〕機(jī)密性(ESP+傳輸模式、ESP+隧道模式)對通信流提供有限的機(jī)密性保護(hù)(ESP+隧道模式)SA提供的平安效勞取決于所選的平安協(xié)議〔AH或ESP〕、SA模式(傳輸或隧道)、SA作用的兩端點SSL〔TLS〕：為兩個通訊個體之間提供機(jī)密性、完整性，效勞器認(rèn)證以及可選的客戶端認(rèn)證。效勞器身份認(rèn)證：典型流程客戶端身份認(rèn)證：客戶端認(rèn)證流程，可選完整性：Finished消息〔防止降級攻擊〕機(jī)密性：記錄協(xié)議中定義平安斷連：Closenotisfy消息SSH：機(jī)密性、完整性保護(hù)、身份認(rèn)證〔必選的效勞器認(rèn)證，可選的客戶端認(rèn)證〕效勞器身份認(rèn)證：傳輸層協(xié)議，必選的客戶端身份認(rèn)證：用戶認(rèn)證協(xié)議，可選的完整性：傳輸層協(xié)議定義機(jī)密性：傳輸層協(xié)議定義防止重放攻擊：SG_MSG_KEXINIT消息中包含的cookieSSH傳輸協(xié)議(協(xié)商和數(shù)據(jù)處理，包含效勞器身份認(rèn)證)：SSH通信總是由客戶端發(fā)起。當(dāng)期望使用SSH時，客戶端首先通過三次握手與效勞器的22號端口建立TCP連接。版本協(xié)商密鑰交換：(1)算法協(xié)商(2)D-H交換：實現(xiàn)了密鑰交換、效勞器身份認(rèn)證、握手消息完整性驗證防重放攻擊：SSH_MSG_KEXINIT消息中包含的cookie是一個隨機(jī)數(shù)，在計算密鑰和生成會話ID時它是輸入之一。每次平安協(xié)商時應(yīng)選取不同的cookie值，所以如果兩次協(xié)商所獲取得會話ID相同，那么有可能發(fā)生了重放攻擊。(3)計算密鑰③效勞請求/響應(yīng)·SSH傳輸層協(xié)議與用戶認(rèn)證協(xié)議的關(guān)系如何?傳輸層協(xié)議只提供效勞器認(rèn)證功能，沒有用戶認(rèn)證功能，如果需要認(rèn)證用戶身份，那么客戶需要利用傳輸層協(xié)議向效勞器提出用戶身份認(rèn)證效勞請求，假設(shè)效勞器接受請求，那么雙方開始執(zhí)行SSH身份認(rèn)證協(xié)議。身份認(rèn)證協(xié)議在傳輸層協(xié)議提供的平安通道上運行。·SSH連接協(xié)議當(dāng)客戶端通過SSH傳輸層協(xié)議發(fā)出連接協(xié)議效勞請求后，即可開始連接協(xié)議相關(guān)的流程。該協(xié)議規(guī)定了利用SSH傳輸層協(xié)議已建立的平安通道進(jìn)行交互式登錄會話、遠(yuǎn)程執(zhí)行命令、轉(zhuǎn)發(fā)TCP/IP連接記憶X11連接的相關(guān)內(nèi)容。傳輸層協(xié)議構(gòu)建的平安通道成為隧道，而所有的終端繪畫和被轉(zhuǎn)發(fā)的連接都被陳偉通道。一條隧道可以包含多條通道，這意味著SSH平安協(xié)議可以同時為多個不同的應(yīng)用提供平安效勞。代理平安Socks〔防火墻平安會話轉(zhuǎn)換協(xié)議〕·使用端口1080，工作于應(yīng)用層?！た赊D(zhuǎn)發(fā)所有高層應(yīng)用，對操作系統(tǒng)無限制?！ｉT設(shè)計用于防火墻·在應(yīng)用層和傳輸層之間墊了一層·Socks庫和sockd守護(hù)程序·不支持ICMP轉(zhuǎn)發(fā)Socks本身未定義機(jī)密性、完整性保護(hù)方法，但由于所有通信量都要經(jīng)過代理效勞器轉(zhuǎn)發(fā)，為統(tǒng)一制定平安策略并部署平安防護(hù)措施提供了便利。Socks5支持多種客戶端身份認(rèn)證方案，如果某些認(rèn)證方案能夠支持機(jī)密性和完整性保護(hù)，這些功能在應(yīng)用Socks后仍然能夠得到保存?！ocks客戶端命令：CONNECT：通告代理效勞器與遠(yuǎn)程主機(jī)建立連接，調(diào)用函數(shù)：RconnectBIND：通告效勞器接收來自某個遠(yuǎn)程主機(jī)的連接請求，調(diào)用函數(shù)：Rbind，Rlisten和Raccept.·Socks5沿襲了Socks4的體系結(jié)構(gòu)以及命令，并作了以下擴(kuò)展1.擴(kuò)展了客戶端身份認(rèn)證功能，支持多種身份驗證方法：用戶名/口令認(rèn)證方法〔用戶名和口令以明文方式發(fā)送，如被截獲面臨身份被假冒的風(fēng)險〕、GSSAPI認(rèn)證〔GSSAPI為定義所使用的認(rèn)證方法和密鑰交換方法，其平安風(fēng)險取決于所使用的認(rèn)證方法和密鑰交換方法的平安性〕。2.擴(kuò)展了尋址方法：除了IPv4地址外，還支持域名及IPv6地址〔基于Socks的IPV4/IPv6網(wǎng)關(guān)〕3.增加了對UDP的支持課后習(xí)題：1.比擬SSLv3與IPSec，請從功能的角度分析這兩個協(xié)議套件所包含的平安協(xié)議之間的對應(yīng)關(guān)系?！っ艽a算法和密鑰協(xié)商：SSLv3的握手協(xié)議，IPSec的IKE協(xié)議·過失通知、狀態(tài)通知：SSLv3的警告協(xié)議，IPSec的IKE協(xié)議的通知交換模式·消息完整性：SSLv3記錄格式中的MAC，IPSec的AH和ESP報文中的認(rèn)證數(shù)據(jù)?！ぜ用埽篠SLv3的記錄協(xié)議，IPSec的ESP·身份認(rèn)證：SSLv3握手協(xié)議，IPSec的IKE2.利用SSL也可以構(gòu)建VPN，但I(xiàn)PSecVPN仍然是企業(yè)解決方案主流，為什么？·SSLVPN只能進(jìn)行認(rèn)證和加密，不能實施訪問控制，建立隧道后，管理員對用戶不能進(jìn)行所有的控制，而集成防火墻的IPSecVPN那么可以根據(jù)用戶的身份和角色進(jìn)行平安控制和審計?！SLVPN局限了用戶只能訪問web效勞器的應(yīng)用，而IPSecVPN幾乎能為所有應(yīng)用提供訪問。·SSLVPN只提供了單一的證書認(rèn)證方式，企業(yè)需要購置或者部署一個小型證書系統(tǒng)，IPSec可以提供多種認(rèn)證方式?！SLVPN位于傳輸層，IPSecVPN位于網(wǎng)絡(luò)層，SSLVPN的效率比IPSecVPN差。·要實現(xiàn)網(wǎng)絡(luò)-網(wǎng)絡(luò)的平安互聯(lián)，只能考慮使用IPSecVPN。3.從配置方法、管理簡易性、可擴(kuò)展性和平安性等方面對SSLVPN與SSHVPN進(jìn)行比擬?！ば剩篠SH位于TCP/IP協(xié)議棧的應(yīng)用層，SSL位于傳輸層，利用SSH構(gòu)建VPN比SSL消耗更多帶寬?！づ渲梅椒ǎ篠SHVPN使用TCP/IP端口轉(zhuǎn)發(fā)，SSLVPN使用分設(shè)端口。·管理簡易性：使用上，SSLVPN對用戶完全透明，SSHVPN需要用戶登錄到用戶賬戶上。管理上，SSHVPN可配置成僅允許目標(biāo)端口為