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