【正文】 cket 后，即可將 Ticket 核發(fā)給經(jīng)過(guò)認(rèn)證的客戶端，客戶端稍后即可利用此 Ticket 向服務(wù)器要求服務(wù)或是進(jìn)行認(rèn)證。 假設(shè)現(xiàn)在網(wǎng)絡(luò)上有客戶端與服務(wù)器兩臺(tái)計(jì)算機(jī)，以及負(fù)責(zé)密鑰中心工作的計(jì)算機(jī) KDC。客戶端與 KDC 各自擁有一把相同的密鑰 Kclt，且服務(wù)器與 KDC 各自擁有一把相同的密鑰 Ksrv。在上述條件下，若客戶端與服務(wù)器要相互認(rèn)證，其步驟如下： 1. 客戶端首先必須與 KDC 進(jìn)行相互認(rèn)證的工作，此一工作即是使用一對(duì)一認(rèn)證。 KDC 在確認(rèn)彼此的身份之后，客戶端即送出 Msg1 消息給 KDC： Msg1：“客戶端要與服務(wù)器進(jìn)行認(rèn)證” 3. KDC 收到 Msg1 后，首先建立兩把相同的 Kcltsrv ，這兩把 Kcltsrv 稍后將會(huì)交由客戶端與服務(wù)器，用來(lái)進(jìn)行兩者之間的相互認(rèn)證。 4. KDC 從本身的安全數(shù)據(jù)庫(kù)中找出與服務(wù)器共享的秘鑰Ksrv，再利用 Ksrv 將一把 Kcltsrv 連同客戶端的相關(guān)信息一起加密，即產(chǎn)生服務(wù)器的 Ticket。Ticket 的內(nèi)容如下： Ticket：{客戶端相關(guān)信息, Kcltsrv}Ksrv KDC 建好服務(wù)器的 Ticket 后，以 Kclt 將剩下的一把 Kcltsrv 加密，連同建好的 Ticket 一并放入 Msg2 消息，再傳送給客戶端： Msg2：{Kcltsrv}Kclt, Ticket 5. 客戶端收到 Msg2 消息后，利用本身所擁有的 Kclt 來(lái)解密 Msg2，取得 Msg2 中的 Kcltsrv 與 Ticket，由于 Ticket 是以 Ksrv 加密，因此客戶端無(wú)法對(duì) Ticket 進(jìn)行解密?？蛻舳嗽倮?Kcltsrv 來(lái)建立 Authenticator： Authenticator：{客戶端相關(guān)信息, 時(shí)間戳} Kcltsrv 然后將 Authenticator 與 Ticket 一起傳送給服務(wù)器： Msg3：Authenticator, Ticket 6. 服務(wù)器收到 Msg3 后，首先利用本身所擁有的 Ksrv 來(lái)解密 Ticket，取得 Kcltsrv 以及客戶端相關(guān)信息。接著再以 Kcltsrv 解開(kāi) Authenticator，再核對(duì) Authenticator 中的時(shí)間戳與客戶端的相關(guān)信息。若核對(duì)無(wú)誤，服務(wù)器則可確認(rèn) Msg3 來(lái)自客戶端，因?yàn)橹挥锌蛻舳伺c服務(wù)器才會(huì)有 Kcltsrv，且此客戶端已經(jīng)通過(guò) KDC 的認(rèn)證。至此，服務(wù)器即可確認(rèn)客戶端的身份。 接下來(lái)，服務(wù)器將 Authenticator 中的時(shí)間戳以 Kcltsrv 加密后傳送給客戶端： Msg4：{時(shí)間戳} Kcltsrv 7. 客戶端收到 Msg4 消息后，利用 Kcltsrv 解密取得其中的時(shí)間戳，并用來(lái)比對(duì)在建立 Msg3 的時(shí)間。若兩者相符，則客戶端即可確認(rèn)服務(wù)器的身份。 以上即為密鑰中心的認(rèn)證方式。整個(gè)架構(gòu)看起來(lái)似乎有點(diǎn)復(fù)雜，但其主要的用意只有兩點(diǎn)： 原先客戶端與服務(wù)器之間并無(wú)共享任何秘鑰：透過(guò)上述步驟，KDC 將兩把相同的 Kcltsrv 分送給客戶端與服務(wù)器，使兩者之間共享 Kcltsrv，以便進(jìn)行相互認(rèn)證。在后續(xù)的作業(yè)中，客戶端與服務(wù)器也可利用 Kcltsrv 來(lái)加密雙方之間所傳送的數(shù)據(jù)。 Kcltsrv 的管理完全由客戶端所負(fù)責(zé)：透過(guò) Ticket 的機(jī)制，服務(wù)器端只須管理一把 Ksrv，毋須保留與客戶端共享的 Kcltsrv，Kcltsrv 的管理完全由客戶端所負(fù)責(zé)。客戶端會(huì)視情況需要，將 Ticket 傳送給服務(wù)器，以便服務(wù)器取得 Kcltsrv。 此外，由于客戶端可反復(fù)使用 Ticket (在實(shí)作上，為了安全顧慮，會(huì)設(shè)定 Ticket 的使用期限)，如此當(dāng)客戶端重復(fù)存取服務(wù)器時(shí)，即可免去重復(fù)向 KDC 要求認(rèn)證，因而大量減輕 KDC 的工作負(fù)荷。 不過(guò)，密鑰中心的認(rèn)證方式還是有如下列所述的小缺點(diǎn)： 1. 客戶端每次與不同的服務(wù)器進(jìn)行認(rèn)證時(shí)，用戶必須重復(fù)輸入密碼的動(dòng)作。 2. 客戶端每次向密鑰中心要求某一服務(wù)器的 Ticket 時(shí)，密鑰中心必須重復(fù)從數(shù)據(jù)庫(kù)中找出客戶端的密碼，再以哈希函數(shù)求出 Kclt。 TicketGranting TicketKerberos 利用 TGT(Ticket~Granting Ticket)，也就是用來(lái)申請(qǐng)其他票證的票證，來(lái)解決上述的問(wèn)題。TGT 可視為一種特殊的 Ticket，由密鑰中心核發(fā)給經(jīng)過(guò)認(rèn)證的客戶端?？蛻舳嗽诤罄m(xù)的作業(yè)中，即可重復(fù)利用 TGT 向密鑰中心申請(qǐng)其他服務(wù)器的 Ticket?？蛻舳死?TGT 向 KDC 申請(qǐng) Ticket，就好比是客戶端利用 Ticket 向某一臺(tái)服務(wù)器要求服務(wù)。兩者不管在意義或?qū)嵸|(zhì)的程序上，都沒(méi)有差別。使用 TGT 的認(rèn)證程序如下： 1. 客戶端首先與 KDC 進(jìn)行相互認(rèn)證的工作 (Msg1)。 2. 認(rèn)證完畢后，KDC 建立兩把相同的 Kclt~kdc，也就是客戶端與 KDC 之間的 Session Key。KDC 利用一把 KDC 專(zhuān)屬的秘鑰 Kkdc，將一把 Kclt~kdc 連同客戶端的相關(guān)信息一起加密，即產(chǎn)生 TGT： TGT：{客戶端相關(guān)信息, Kclt~kdc}Kkdc 3. KDC 建好 TGT 后，再以 Kclt 加密 Kcltkdc，連同 TGT 一并放入 Msg2 消息，并傳送給客戶端。之后，KDC 即可摧毀步驟 1 在 KDC 端利用密碼與哈希函數(shù)所建立的 Kclt。 Msg2：{Kcltkdc}Kclt, TGT 4. 客戶端收到 Msg2 消息后，利用本身所擁有的 Kclt 來(lái)解密 Msg2，取得 Msg2 中的 Kcltkdc 與 TGT，由于 TGT 是以 Kkdc 加密，因此客戶端無(wú)法對(duì) TGT 進(jìn)行解密。 客戶端會(huì)小心保管 Kcltkdc 與 TGT，供后續(xù)作業(yè)使用，并摧毀步驟1在客戶端端利用密碼與哈希函數(shù)所建立的 Kclt。 5. 當(dāng)客戶端需要與服務(wù)器進(jìn)行認(rèn)證時(shí)，客戶端利用 Kcltkdc 來(lái)建立 Authenticator，連同 TGT 一起傳送給 KDC： Msg3：Authenticator, TGT 6. KDC 利用其專(zhuān)屬的 Kkdc 將 TGT 解密，取得 Kcltkdc。然后再用 Kcltkdc 來(lái)解密 Authenticator，并確認(rèn)客戶端的身份。KDC 接下來(lái)便建立兩把相同的 Kcltsrv，也就是客戶端與服務(wù)器之間的 Session Key，將一把 Kcltsrv 以 Kcltkdc 加密，另一把 Kcltsrv 以 Ksrv 加密 (服務(wù)器的 Ticket)，再一起送回給客戶端。 7. 后續(xù)的步驟與密鑰中心的認(rèn)證方式相同。 使用 TGT 的好處在于客戶端可反復(fù)使用 TGT (當(dāng)然，TGT 實(shí)際上也會(huì)設(shè)定使用期限)，因此使用者便不需要頻頻輸入密碼，而 KDC 端也不用經(jīng)常執(zhí)行 Kclt 的建立動(dòng)作。在實(shí)作上，一般是在客戶端每次作業(yè)開(kāi)始時(shí)(例如，每天早上開(kāi)機(jī)登入)，KDC 即核發(fā) TGT 給客戶端?？蛻舳嗽谠摯巫鳂I(yè)中，皆可使用同一張 TGT 向 KDC 要求其他服務(wù)器的 Ticket?？巛爡^(qū)的認(rèn)證方式由先前的定義可知，每個(gè)密鑰中心有其管轄的轄區(qū) (Realm)，密鑰中心保有轄區(qū)內(nèi)所有主體(包括全部的客戶端與服務(wù)器)的秘鑰。假設(shè)現(xiàn)在有兩臺(tái) KDC，KDC~x 管轄 Realmx，KDCy 管轄 Realmy，且 KDCx 與 KDCy 相互信任，也就是說(shuō) KDCx 與 KDCy 各自擁有一把相同的密鑰 Kxy。當(dāng) Realmx 中的客戶端欲存取 Realmy 的服務(wù)器時(shí)，則必須進(jìn)行跨轄區(qū)的認(rèn)證程序。以下為認(rèn)證的步驟： 1。.客戶端首先與 KDCx 進(jìn)行相互認(rèn)證的工作，并取得 KDCx 所核發(fā)的 TGTx 以及 Kcltx。 2. 客戶端以 TGTx 向 KDCx 要求服務(wù)器的 Ticket(Msg1)。KDCx 檢視本身的安全數(shù)據(jù)庫(kù)，得知服務(wù)器位于 KDCy 所管轄的 Realmy 轄區(qū)內(nèi)，因此 KDCx 準(zhǔn)備建立 Referral Ticket (轉(zhuǎn)介票證)。Referral Ticket 的功能就好比是推薦函或介紹信。 例如，A 與 B 互相認(rèn)識(shí)，B 與 C 互相認(rèn)識(shí)，但 A 與 C 互不相識(shí)。當(dāng) A 要與 C 建立關(guān)系時(shí)，A 會(huì)先向 B 取得介紹信，然后再拿著介紹信去見(jiàn) C，以便取得 C 的信任。Referral Ticket 的功能也是如此，讓素未謀面的客戶端與 KDCy 得以進(jìn)行認(rèn)證的工作。 3. KDCx 首先建立兩把相同的 Kclty。KDCx 再利用與 KDCy 共享的秘鑰 Kxy 將一把 Kclty 連同客戶端的相關(guān)信息一起加密，產(chǎn)生 Ticketref： Ticketref：{客戶端相關(guān)信息, Kclty}Kxy KDCx 建好 Ticketref 后，再以 Kcltx 加密剩下的一把 Kclty，連同 Tikcetref 一并傳送給客戶端： Msg2：{Kclty}Kcltx, Ticketref 4. 客戶端解開(kāi)上列消息，取得 Kclty 與 Ticketref，然后利用這兩者直接向 KDCy 要求服務(wù)器的 Ticket。后續(xù)的步驟與使用 TGT 向 KDC 申請(qǐng) Ticket 的步驟相同。 使用跨轄區(qū)的認(rèn)證機(jī)制有幾個(gè)優(yōu)點(diǎn)： 1. 整個(gè)網(wǎng)絡(luò)可分割成較易管理的小單位(Realm)，各單位自行管理所轄的秘鑰，單位之間再以信任關(guān)系(也就是兩臺(tái) KDC 共享秘鑰)串連起來(lái)。 2. 客戶端可透過(guò)多臺(tái) KDC，與位于其他 Realm 的服務(wù)器進(jìn)行證認(rèn)。 5．2．3 Kerberos 的基本協(xié)定在 RFC 1510 中，詳細(xì)定義了 Kerberos 的數(shù)個(gè)基本協(xié)議。接下來(lái)便要介紹 Kerberos 的三個(gè)最重要的協(xié)議。透過(guò)這些協(xié)議，以及協(xié)議中所定義的消息，即可執(zhí)行之前所提及的 Kerberos 認(rèn)證功能。 AS ExchangeAS (Authentication Service，認(rèn)證服務(wù)) 主要負(fù)責(zé)讓 KDC 核發(fā) TGT 與 Session Key 給客戶端。AS 主要有兩個(gè)消息： KRB_AS_REQ：這是客戶端在一開(kāi)始登入時(shí)向 KDC 發(fā)出的認(rèn)證要求，消息內(nèi)容包括了一些明文信息與 Authenticator (以客戶端秘鑰來(lái)加密)。 KRB_AS_REP：KDC 確認(rèn)客戶端的身份后，將 Kcltkdc 與 TGT 傳送給客戶端。 TGS ExchangeTGS (TicketGranting Service，取票服務(wù)) 主要負(fù)責(zé)讓 KDC 核發(fā)服務(wù)器的 Ticket 與 Kcltsrc。TGS 主要有兩個(gè)消息： KRB_TGS_REQ：客戶端利用 Kcltkdc 與 TGT 向 KDC 要求服務(wù)器的 Ticket。 KRB_TGS_REP：KDC 確認(rèn)客戶端的身份后，將 Kcltsrv 與服務(wù)器的 Ticket 傳送給客戶端。 CS ExchangeCS (客戶端/服務(wù)器) 主要負(fù)責(zé)讓客戶端與服務(wù)器進(jìn)行相互認(rèn)證。 KRB_AP_REQ：客戶端利用 Kcltsrv 來(lái)建立 Authenticator。然后再利用 Authenticator 與 Ticket 向服務(wù)器要求認(rèn)證。 KRB_AP_REP：服務(wù)器確認(rèn)客戶端的身份后，以 Kcltsrv 加密 Authenticator 中的時(shí)間戳信息，然后送回給客戶端，供客戶端確認(rèn)服務(wù)器的身份。 從這三項(xiàng)協(xié)議中，我們可以知道 KDC 負(fù)責(zé) AS 與 TGS 這兩項(xiàng)工作。其實(shí)，在原先 Kerberos 的架構(gòu)中，AS 與 TGS 各自獨(dú)立，可由不同的計(jì)算機(jī)來(lái)提供 AS 與 TGS 的服務(wù)。不過(guò)，在實(shí)作上 AS 與 TGS 通常會(huì)放在一起，而構(gòu)成所謂的密鑰中心(KDC)。 5．2．4 Kerberos缺陷：它需要中心服務(wù)器的持續(xù)響應(yīng)。當(dāng)Kerberos服務(wù)結(jié)束前，沒(méi)有人可以連接到服務(wù)器。這個(gè)缺陷可以通過(guò)使用復(fù)合Kerberos服務(wù)器和缺陷認(rèn)證機(jī)制彌補(bǔ)。票據(jù)具有一定有效期，因此，如果主機(jī)的時(shí)鐘與Kerberos服務(wù)器的時(shí)鐘不同步，認(rèn)證會(huì)失敗。默認(rèn)設(shè)置要求時(shí)鐘的時(shí)間相差不超過(guò)10分鐘。在實(shí)踐中，通常用網(wǎng)絡(luò)時(shí)間協(xié)議后臺(tái)程序來(lái)保持主機(jī)時(shí)鐘同步。，在服務(wù)器實(shí)現(xiàn)工具中有一些差別。，危及服務(wù)器的安全的行為將危及所有用戶的密鑰。[10]。5．3 IPC IPC(InterProcess Communication)是共享命名管道的資源，它是為了讓進(jìn)程間通信而開(kāi)放的命名管道，通過(guò)提供可信任的用戶名和口令，連接雙方可以建立安全的通道并以此通道進(jìn)行加密數(shù)據(jù)的交換，從而實(shí)現(xiàn)對(duì)遠(yuǎn)程計(jì)算機(jī)的訪問(wèn)。IPC是NT/2000的一項(xiàng)新功能，它有一個(gè)特點(diǎn)，即在同一時(shí)間內(nèi)，兩個(gè)IP之間只允許建立一個(gè)連接。NT/2000在提供了ipc功能的同時(shí)，在初次安裝系統(tǒng)時(shí)還打開(kāi)了默認(rèn)共享，即所有的邏輯共享(c,d,e……)和系統(tǒng)目錄winnt或windows(admin)共享。所有的這些，微軟的初衷都是為了方便管理員的管理，但在有意無(wú)意中，導(dǎo)致了系統(tǒng)安全性的降低。平時(shí)我們總能聽(tīng)到有人在說(shuō)ipc漏洞，ipc漏洞，其實(shí)ipc并不是一個(gè)真正意義上的漏洞,我想之所以有人這么說(shuō)，一定是指微軟自己安置的那個(gè)‘后門(mén)’：空會(huì)話（Null session）。5．3．1 IPC建立的過(guò)程1）會(huì)話請(qǐng)求者（客戶）向會(huì)話接收者（服務(wù)器）傳送一個(gè)數(shù)據(jù)包，請(qǐng)求安全隧道的建立；2）服務(wù)器產(chǎn)生一個(gè)隨機(jī)的64位數(shù)（實(shí)現(xiàn)挑戰(zhàn)）傳送回客戶；3）客戶取得這個(gè)由服務(wù)器產(chǎn)生的64位數(shù)，用試圖建立會(huì)話的帳號(hào)的口令打亂它，將結(jié)果返回到服務(wù)器（實(shí)現(xiàn)響應(yīng)）；4）服務(wù)器接受響應(yīng)后發(fā)送給本地安全驗(yàn)證（LSA），LSA通過(guò)使用該用戶正確的口令來(lái)核實(shí)響應(yīng)以便確認(rèn)請(qǐng)求者身份。如果請(qǐng)求者的帳號(hào)是服務(wù)器的本地帳號(hào)，核實(shí)本地發(fā)生；如果請(qǐng)求的帳號(hào)是一