PracticU

הסבר על Constrained Delegation
עם Kerberos

בלי כתוביותעם כתוביות
PracticU › קורס פריצה ומבדקי חדירה לתשתית ארגונית - בדיקות חוסן מתקדמות ל-Active Directory - קורס זה נדרש למבחן ההסמכה היוקרתי OSCP › הסבר על Constrained Delegation עם Kerberos
מילון מושגים:
Kerberos - פרוטוקול אימות המבוסס על כרטיסים (tickets), המשמש ברשתות Active Directory לאימות מאובטח של משתמשים ושירותים.
TGT - כרטיס שמנפיק שרת האימות ב-Kerberos, שבעזרתו המשתמש מבקש גישה לשירותים בלי להזדהות שוב בכל פעם.
SQL Server - מערכת ניהול מסדי נתונים יחסיים של מיקרוסופט, הנשלטת בשפת T-SQL.
HTTP - פרוטוקול להעברת דפי אינטרנט ונתונים בין דפדפן לשרת. הגרסה המאובטחת שלו היא HTTPS.
דומיין קונטרולר - שרת בדומיין של Active Directory שמאמת משתמשים ואוכף מדיניות והרשאות ברשת הארגונית.
VPN - רשת פרטית וירטואלית שיוצרת חיבור מוצפן דרך האינטרנט, כאילו המכשיר מחובר ישירות לרשת מרוחקת.
פרוטוקול - מערכת כללים מוסכמת שקובעת כיצד מכשירים או תוכנות מתקשרים ומחליפים מידע, למשל HTTP או TCP.
VLAN - רשת מקומית וירטואלית שמחלקת מתג פיזי לרשתות לוגיות נפרדות, לשם ארגון ואבטחה.

הסבר על Constrained Delegation עם Kerberos
ב-Constrained Delegation אפשר להגביל מול אילו שרתים ושירותים מותר לשרת, למשל שרת Web, להזדהות בשם משתמשים. זה פותר את הבעיה של Unconstrained Delegation, שבו השרת קיבל TGT והיה יכול להזדהות מול כל שרת.
מה מגדירים
1. רשימת יעדים: מוסיפים (add) שרתים ספציפיים, למשל SQL Server 1 ולא SQL Server 2, ובוחרים לכל שרת אילו שירותים מותרים, כמו HTTP או CIFS (שיתופי קבצים). אפשר לתת כמה שירותים מול אותו שרת.
2. בדיקה בדומיין קונטרולר: לפני שהוא מנפיק Service Ticket הוא בודק את הרשימה, ובודק שהמשתמש לא מסומן כרגיש.
3. שתי אפשרויות: Kerberos only מחייבת שהמשתמש יזדהה ב-Kerberos, ולכן יצטרך גישה ל-DC דרך הרשת או VPN. האפשרות לכל פרוטוקול מאפשרת למשתמש להזדהות ל-Web1 בכל דרך, למשל HTTP, ו-Web1 מנפיק בעצמו את הטיקטים.
מה קורה מאחורי הקלעים ב-Kerberos only
1. ההזדהות הרגילה: המשתמש מקבל TGT ומבקש Service Ticket ל-SPN של שרת A.
2. בקשה בשם המשתמש: שרת A לא מקבל את ה-TGT של המשתמש. הוא פונה לדומיין קונטרולר באמצעות פונקציית הפרוקסי, שנוספה ב-2003, ומבקש Service Ticket ליעד B בשם המשתמש.
3. הוכחה: שרת A מצרף את ה-Service Ticket שהמשתמש הביא, כהוכחה שהמשתמש אכן פנה אליו.
4. הגישה ליעד: הדומיין קונטרולר מנפיק טיקט, ושרת B רואה משתמש רגיל.
למה זה טוב יותר
1. אין TGT: ה-TGT לא עובר לשרת A, ולכן פריצה אליו חושפת רק את היעדים שהוגדרו ולא את כל הרשת.
2. סגמנטציה: המרצה מסביר שבארגון עם חלוקה לרשתות משנה (VLAN) משתמש לא יכול לגשת ישירות לשרת רגיש B, ורק שרת A מתווך ובודק הכול.
התסריט הזה דורש הזדהות מול הדומיין קונטרולר מתוך אותה רשת.
השיעור הבא בקורס: הסבר על Constrained Delegation עם כל פרוטוקול

פרקי ההרצאה: הסבר על Constrained Delegation עם Kerberos

  1. 00:00

    מהו Constrained Delegation

  2. 00:42

    הגבלת שרת ושירות ליעד

  3. 01:57

    Kerberos Only מול כל פרוטוקול

  4. 02:36

    הנפקת טיקטים ללא VPN

  5. 03:17

    מה קורה מאחורי הקלעים

  6. 04:12

    תהליך הבקשה מול Domain Controller

  7. 04:50

    תוספת ה-Proxy בשרת 2003

תמלול ההרצאה: הסבר על Constrained Delegation עם Kerberos

הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על Constrained Delegation עם Kerberos» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

  1. 00:02

    שלום לכולם, בהרצאה הזו אנחנו נדבר על Constraint Delegation, על הצלת סמכות על שרת, נניח, Web, להזדהות בשמם של כל היוזרים בארגון שלי מול שרתים פנימיים, אבל כאן ב-Constraint Delegation אני יכול להגביל מול מי הוא רשאי להזדהות.

  2. 00:19

    בניגוד לאופציה הראשונה של Un-Constraint Delegation, שהיה ללא הגבלה מול כל סרוויס, שזה היה מאוד מאוד מסוכן, כי השרת קיבל את ה-TGT של היוזר ויכל להזדהות בשמו של כל יוזר מול כל שרת.

  3. 00:35

    כאן באופציה השנייה שיצא בשנת 2003 אם אני לא טועה יש כבר הגבלה ואני יכול פה להגביל מול איזה סרוויס מול איזה שרת מותר לו להזדהות. אני יכול לעשות פה add ולבחור שלשרת Web1 מותר להזדהות רק מול נניח SQL Server 1 ולא מול SQL Server 2 נניח.

  4. 00:57

    וגם אני בוחר מול איזה סרוויס בתוך SQL האם זה יהיה סיפס של שיתופים, האם זה יהיה HTTP ואם אני בוחר HTTP אז רק לצורך HTTP הוא יוכל לקבל סרוויס טיקט רק לשירות הזה, לא לשירות אחר אני יכול גם לתת לו כמה שירותים מול אותו שרת אחד

  5. 01:17

    אני יכול גם לתת לו כמה שירותים מול SQL נניח גם HTTP וגם סיפס, שזה שיתוף אני אומר לו בדיוק מול מי אני מרשה לו ואיזה שירות אני מרשה לו. נניח בחרתי סיפס ועכשיו מותר לו גם שיתופים וגם HTTP רק מול שרת הזה.

  6. 01:37

    זה אומר ששרת וב אחד מותר לו להזדהות בשמם של כל היוזרים שהם לא סנסיטיב מול שרת SQL Server רק לצורך HTTP או סיפס. דרך אגב אם נשים פה v אנחנו נראה שמותר גם לקבל פניות עם שם מלא או עם שם מקוצר.

  7. 01:54

    זה אומר ש Active Directory לפני שהוא ינפיק Service Ticket הוא יבדוק את ההגדרות כאן ושימו לב לעוד משהו חשוב שיש פה או קרברוס only או בכל פרוטוקול זה אומר שמול שרת Web אחד אני כיוזר פשוט מהבית חייב להזדהות קרברוסית זה אומר עם כל הטיקטים ובשביל זה אני צריך מהבית גישה ל-DC כדי להזדהות בקרברוס בשביל שתהיה לי גישה ל-DC מהבית אני חייב VPN כי DC בחיים לא פתוח לאינטרנט בצורה גלויה,

  8. 02:27

    חייבים VPN או חייבים להיות באותה רשת. או לחלופין, אפשר להעביר את האופציה לכאן, ואז אני יכול להזדהות בכל פרוטוקול שבא לי מול Web1, נניח HTTP או כל פרוטוקול שבא לי, ואז Web1 לבד ינפיק את הטיקטים של קרברוס בשמי, ויזדהה בשמי מול שרתים אחרים, במקרה הזה SQL Server 1 בסיפס או ב-HTTP.

  9. 02:53

    אז כאן אני יכול בלי VPN דרך HTTP להזדהות מול Web אחד והתוכנה שיושבת בתוך Web אחד אחרי שהיא תבדוק את השם והסיסמה שלי שזה עניין שלה איך היא בודקת שם וסיסמה ואיך בנויה שם האבטחה בכל מקרה התוכנה הזאת שבדקה את השם והסיסמה שלי דרך Web נניח תוכל להנפיק לעצמה טיקט וללכת להזדהות בשמי מול השרתים האחרים אלו שמוגדרים כאן עכשיו אנחנו נראה מה קורה מאחורי הקלעים באופציה של קרברוס אונלי

  10. 03:22

    ובאופציה של any authentication מה שקורה מאחורי הקלעים ואנחנו מדברים פה כרגע על אופציה עם קרברוס מה שקורה שאני כיוזר מהבית דרך VPN או שאני נמצא ברשת ופשוט לא יכול להגיע לשרת B כי הוא ברשת מאובטחת כאילו הרשת הארגונית מחולקת לתתי רשתות ויוזר שיושב ברשת פנים ארגונית לא יכול לגשת לשרת סופר מאובטח שנקרא

  11. 03:48

    Service B ולשרת סרוויס B יכול לגשת רק שרת A אחרי שהוא בדק כל מיני דברים. זה נקרא סגמנטציה, חלוקה לתתי רשתות בתוך הארגון, וזה נהוג, חלוקה לווילנים.

  12. 04:00

    המטרה זה למנוע מאקר שפרץ לאיזשהו יוזר לגשת ישירות לשרת רגיש ולנסות לפרוץ אותו. אני שם פה מתווך שבודק הכל. בגלל שאנחנו באותה רשת פנימית, או שאני מהבית עם VPN, אני עובר הזדהות רגילה, שולח בקשת הזדהות עם טיימסטמפ, מסתמת זמן שמוצפנת עם הסיסמה שלי, מקבל חזרה TGT מהשר"ט, ושולח אחרי זה בקשת Service Ticket,

  13. 04:26

    בקשת שירות ליעד מסוים, ליעד A. את היעד שלי אני כותב ב-spn בתוך הבקשה, אז אני שולח בקשה לדומיין קונטרולר להנפיק לי טיקט עבור שירות A. דומיין קונטרולר מנפיק לי Service Ticket עבור יעד A, ואני פונה ליעד A ומבקש ממנו להזדהות בשמי מול יעד B.

  14. 04:48

    אתם זוכרים מה היה ב-unconstrained delegation? בשלב הזה ב-unconstrained delegation הייתי מעביר לו גם את ה-TGT וזה היה סופר מסוכן. כאן אני כבר לא מעביר לו את ה-TGT שלי, אני רק מבקש ממנו שירות רגיל.

  15. 05:02

    והאופציה הזאת שהוסיפו בשרת 2003, שרת A הולך חזרה לדומיין קונטרולר, מפעיל שם הפרוקסי, זאת התוספת דרך אגב שהכניסו בשרת 2003 האופציה של הפרוקסי בתוך הקרברוס, ואומר לו, תביא לי סרוויס טיקט יעד B בשמו של יוזר.

  16. 05:22

    עכשיו, הדומיין קונטרולר אומר, רגע, אתה מבקש בשמו של יוזר סרוויס טיקט מול יעד B? תוכיח לי שלא פרצו אותך, שאתה

לקורס המלא: מבדקי חדירה ל‑Active Directory

ההרצאה הקודמת: הסבר על Kerberos - Unconstrained Delegation

ההרצאה הבאה: הסבר על Constrained Delegation - עם כל פרוטוקול

הרצאות קשורות מקורסים אחרים

  • הסבר על Kerberos ועל NTLM
  • הגדרת לוגין ל-vCenter - עם AD Kerberos - חלק 1

קורסים נוספים במסלול

  • קורס SOC - מיישם הגנת סייבר
  • קורס סייבר למתחילים - Hacking - בדיקות חוסן תשתיתי ופריצה ל-Windows 10/11 - קורס זה נדרש למבחן ההסמכה היוקרתי OSCP
  • קורס פריצה ומבדקי חדירה לאתרי אינטרנט - בדיקות חוסן לאתרים - Web Pentesting - קורס זה נדרש למבחן ההסמכה היוקרתי OSCP
  • קורס סייבר והאקינג ל-Android - פריצה לטלפונים ואפליקציות אנדרואיד - בודק חוסן - Mobile App Pentesting