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