信息安全原理復習題

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

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