ההתקנה הרחוקה של PowerShell (PSRemoting) היא אחת מהתכונות הנפוצות ביותר בכל הפקודות של PowerShell. למה? כי זה כל כך שימושי! באמצעות פקודה יחידה, תוכל להתחבר בצורה שוטפת לכמה שהם מחשבים רחוקים ולבצע פקודות.
במדריך האולטימטיבי הזה, תעמיק ב-PSRemoting. תלמד מה זה, איך זה עובד, ואת כל הטכנולוגיות השונות שהופכות את PSRemoting לתפקוד. מדריך זה לא יכסה איך להשתמש ב-PSRemoting. תראה המון הפניות למדריכים שלנו לאורך הדרך.
כיצד PSRemoting פועל
בגיליון, PSRemoting מאפשר לך להריץ פקודות על מחשבים רחוקים בדיוק כמו שתהיה יושב מולם. PSRemoting מספק סט של תכונות שמתחברות ומאמתות משתמש, מריצות פקודות רחוקות ומחזירות כל פלט מהפקודה ההיא למחשב המקומי.
תחשוב על PSRemoting כמו על telnet או SSH או אפילו psexec. זו פשוט דרך להריץ פקודות על מחשבים בתוך PowerShell.
PSRemoting תלוי הרבה במושג הנקרא ישיבה. ישיבה הוא מונח המשמש לתאר קופסה רחוקה שמריצה פקודות בתוכה. התהליך ליצירת אחת מהישיבות האלה עובר דרך מספר צעדים ברקע.
כאשר אתה מתחיל ישיבת PSRemoting, השלבים הגסים הבאים מתבצעים:
- הלקוח מנסה להתחבר לשרת היעד על ידי נצב WinRM (מידע נוסף על נצבי WinRM למטה). נצב WinRM הוא שירות אינטרנט קטן הפועל על השרת היעד. WinRM הוא יישום של Microsoft לתקן בשם WSMan. WSMan הוא תקן פתוח שנוצר יחד עם חברות טכנולוגיה גדולות נוספות בעת ההקמה כמו Dell, Intel ו-Sun Microsystems.
- כאשר הלקוח מתחבר לנצב דרך הפרוטוקולים HTTP או HTTPS, מתחיל תהליך האימות. כל פרטי של כל אמצעי אימות ייכסו מאוחר יותר, אך לעכשיו ידוע שהלקוח צריך להעביר פרטיות לשרת באמצעי אחר.
- לאחר שהלקוח מתחבר ומאמת את עצמו לשרת, PSRemoting יוצר ישיבה.
- ברגע זה, השיחה נפתחת לעסקים. בנקודה זו, הלקוח יכול להתחיל לשלוח מידע לשרת והשרת יחזיר כל פלט נדרש הידוע כ- serialization. התקשורת הזו בדרך כלל מוצפנת.
נצבי WinRM: זמינים לחיבור
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
ניתן לגלות את כל נצבי WinRm הפועלים על כל מחשב Windows באמצעות פקודת winrm למטה.
נצבי WinRm כוללים מספר רכיבים חשובים. יש להם:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- הסוג של תחבורה – כל מאזין WinRM צריך דרך לתקשר עם הלקוח; הם עושים זאת דרך תחבורה באמצעות HTTP או HTTPS.
- טביעת אצבע אופציונלית – כאשר מאזין WinRM משתמש ב-HTTPS לתחבורה, יש לו לדעת איזה מפתח פרטי לאימות הלקוח; מפתח זה נמצא באמצעות טביעת אצבע של תעודת זהות.
השתמש במאזין HTTPS כשאפשר. הגדרת תחבורת HTTPS מגבירה את האבטחה על ידי הבטיחות של תקינות השרת והצפנת שני התנועה של האימות והתחבורה. בעת הנפקת תעודה, השתמש בתעודה מהותחת מרשם הרשיונות, כאשר זה אפשרי במקום תעודה מחותמת עצמית.
מארחים מהותחים: אימות שרת
איך אימות PSRemoting דרך WinRM עובד
כפי שצוין לעיל, אחד השלבים הראשונים שבהם מתקיימת PSRemoting הוא האימות. האימות הוא אחד החלקים הכי מורכבים ובוודאי הכי חיוניים של PSRemoting.
כאשר PSRemoting נוצר לראשונה, יש לו רק מנגנון אימות אחד, Windows Remote Management (WinRM) אך בימינו, ניתן גם לאמת באמצעות SSH שתראו מאוחר יותר.
WinRM תומך בשני סוגים שונים של אימות; שם משתמש וסיסמה או תעודה עם מספר סוגים שונים של אימות עבור שם משתמש/סיסמה.
אימות בסיסי
התחלה בסוג האימות הקל ביותר, אך הפוגע ביותר, הוא אימות בסיסי. סוג זה של אימות הוא סטנדרטי שמובנה בפרוטוקול HTTP. אימות בסיסי שולח עותק מקודד ב־base64 של שם המשתמש והסיסמה בכותרת HTTP מהלקוח למאזין.
מכיוון שאימות בסיסי מקודד רק את שם המשתמש והסיסמה ולא מצפין אותם, זה קל להתפס במתקפת הרשת.
אל תשתמשו באימות בסיסי אלא אם כן יש לכם צורך חד וחלק. ישנם דרכים רבות יותר מאובטחות שבאפשרות WinRM להאמת משתמשים!
אימות Kerberos
האם גם הלקוח והשרת שלך נמצאים בסביבת Active Directory? אם כן, כבר משתמשים באימות Kerberos ברוב שירותי הרשת שלך.
כאשר הלקוח של WinRM מנסה להתחבר למאזין WinRM דרך Kerberos:
- השרת ראשית מנסה לאחזר מפתח סשן או כרטיס קבלת כרטיס עבור הלקוח משרת בקרת הדומיין.
- שרת בקרת הדומיין מחפש את הלקוח והשרת ואם שניהם תקפים ומהימנים, היא מנפיקה את האסימון.
- השרת מאמת את חיבור הלקוח באמצעות האסימון המהימן במקום שם המשתמש והסיסמה.
במהלך האימות של Kerberos, בקר הדומיין מאמת גם את הלקוח וגם את השרת במהלך קבלת הכרטיסית, מונע מאדם רע להתחזות כשרת.
Kerberos הוא שיטת אימות בוגרת ובטוחה והיא שיטת האימות הברירת מחדל כאשר לקוח ושרת הם שניהם חברים בתחום של פעילות פעילה משותפת. אך, זה מחייב גם את הלקוח והשרת להצטרף לאותו יער של פעילות פעילה משותפת או עם הקמת אמון בין היערות.
אימות לפי הסכם
WinRm יכול גם לנסות להשתמש ב-Kerberos ואם אינו זמין, יכול להשתמש בפרוטוקול אימות הנקרא מנהל הרשת NT (NTLM).
כאשר משתמשים ב-NTLM:
- השרת שולח ללקוח מחרוזת.
- הלקוח מצפין לאחר מכן את המחרוזת באמצעות גיבוי של סיסמת המשתמש.
- המחרוזת המצופנת מועברת לשרת ששולח את שם המשתמש, המחרוזת המקורית והמחרוזת המוצפנת לבקר דומיין.
- הבקר דומיין מחפש אז השם הגיבוי של הסיסמה למשתמש ומחזיר את אותו תהליך ההצפנה על המחרוזת כדי לוודא שהיא תואמת.
NTLM טוב לאימות הלקוח, אך לא דומה ל-Kerberos ביכולתו לאמת את השרת. זה פותח פתח להתקפות מרובות שבהן השרת יכול להיות מעוות על ידי התוקף.
ניתן לשפר את אבטחת NTLM על ידי אימות השרת גם עם תעודת אימות שרת והקצאתה למאזין WinRM מאובטח ב-HTTPS. בהגדרה זו, הלקוח מאומת עם NTLM נגד בקר מרשת, והשרת מאומת עם תעודה מהימנה. למרות שהגדרה זו מספקת אימות גם ללקוח וגם לשרת, פרוטוקול ה-NTLM משתמש באלגוריתם הצפין הישן עם גודל מפתח מיושן.
מסיבות אלה, NTLM ניתן לשימוש רק אם מוסיפים את השרת לרשימת המארחים המהימנים או משתמשים במאזין HTTPS.
אימות עם קיבוץ
אחת משיטות האימות הפחות נפוצות לשימוש ב-WinRM היא אימות עם קיבוץ. NTLM וקיבוץ הם שיטות אימות דומות. דומה ל-NTLM, קיבוץ יוצר מחרוזת ייחודית שמוצפנת עם האש של סיסמת המשתמש. הסיסמה אינה נשלחת אז לשרת.
קיבוץ משתמש באלגוריתם הצפין MD5 להצפנת הסיסמה. עקב בחירה זו של אלגוריתם, קיבוץ כללית נראה כמיושן ולא צריך להשתמש בו. MD5 יש בעיות אבטחה ידועות שמבטלות את השימוש הקריפטוגרפי בו.
ספק התמיכה באבטחת כרטיס אשראי (CredSSP)
אם נרצה, נוכל להעמיק בנושא CredSSP, אך זה אינו נחוץ. למה? מכיוון שכאשר מדובר ב- PSRemoting ו- WinRM, CredSSP מיושם בדרך כלל מטעם אחד, בעיה ה"קפיצה השנייה" שתלמד עליה למטה.
כאשר מוגדרת אימות CredSSP, הלקוח והשרת של WinRM משתמשים באימות של הפרטים באמצעות ניהול סכסוך כדי לאמת את המשתמש והלקוח. אך לאחר הושלמותו, הסיסמה של המשתמש נשלחת לשרת.
מכיוון שהסיסמה נשלחת לאחר שהתהליך של האימות הושלם, היא מוצפנת כעת. CredSSP גם מצפין את הסיסמה באמצעות מפתחות סשן של כמו כן כי סדרת המפתחות המוצפנת תהיה ייחודית בין הסשנים.
CredSSP מועיל מכיוון שלאחר האימות, השרת יכול להתחבר לכל דבר אחר בשמך. אך, כאשר זה קורה, אתה מאמין לשרת שאליו התחברת באופן מלא עם סיסמת המשתמש.
אימות על בסיס תעודות
אחת השיטות הבטוחות ביותר לאימות להשתמש בו עם PSRemoting הוא אימות על בסיס תעודות. בשיטת האימות הזו, התקיום הרגיל של המפתח קורה עם מפתח פרטי וציבורי על הלקוח, ושרת התעודות מאמת את התעודה.
**WinRM מאמת את המשתמש על ידי מיפוי של משתמש בשרת בתוך WinRM. הדבר היחיד שעובר במהלך האימות הוא המפתח הציבורי, לכן זו דרך מאוד מאובטחת לאימות
עם זאת, למרות שהאימות המבוסס על תעודות הוא האימות המאובטח ביותר, זה לא נפוץ יותר מדי. למה? פשוט בגלל המאמץ שנדרש להגדיר אותו. עליך ל:
- לבנות סמכות אישור
- ליצור תעודת אימות משתמש
- לשתף את המפתח הציבורי
- להשתמש בחשבון משתמש מקומי עם הרשאות מתאימות (כנראה בקבוצת המנהלים)
- להגדיר חשבון האזרחי HTTPS
- …וצעדים נוספים.
אי אפשר להשתמש במשתמש דומיין לאימות עם תעודות, גם אם הלקוח והשרת חלק מ-Active Directory.
ברירות המחדל לאימות במערכת ההפעלה Windows OS
עכשיו שראית שיש הרבה אפשרויות אימות שונות זמינות, איך תדע אילו זמינות כבר כחלק מהתיק הבסיסי? למטה תראה טבלה עם שתי עמודות המציינות האם הלקוח WinRM, כבר כחלק מהברירה, מופעל והאם סוג האימות הספציפי הזה מופעל כבר כחלק מהברירה.
כל סוגי האימות שלמעלה ניתנים להגדרה, אך בשימוש בטבלה למטה תקבל רעיון טוב על מה עליך להגדיר בעצמך.**
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
הבעיה שנייה או בעיה של קפיצה כפולה
אחת מהבעיות הגדולות ביותר של PSRemoting ידועה בשם "הבעיה שנייה" או "קפיצה כפולה". מצב זה מתרחש כאשר אתה מתחבר למערכת מרוחקת דרך PSRemoting ואז עליך להתחבר למחשב מרוחק נוסף.
מצב זה אינו פשוט מכיוון שכאשר לקוח WinRm מאמת את עצמו למחשב הרחוק הראשון, השרת מאמת רק את זהות הלקוח המקורי בלעדי, בלעדי שלא שולח את הסיסמה לשרת. כאשר אתה מנסה להתחבר למחשב השני מהשרת של החיבור הראשון, השרת הסופי אין לו דרך לאמת את זהות המשתמש.
ניתן לפתור את בעיה הקפיצה הכפולה בכמה דרכים שונות דרך שימוש ב-CredSSP או בהשקמה של Kerberos.
שימוש ב-CredSSP
הדרך הנפוצה ביותר לעבור על בעיה זו היא על ידי שימוש ב-CredSSP. אימות CredSSP עובר על המצב הזה על ידי אחסון של כרטיס אשראי של משתמש בשרת הרחוק הראשון, אשר יכול להיעבר לשרת השני על ידי הלקוח הפוך לשרת.
יש לזה דרך אחת לפחות לשימוש ב-CredSSP. כרטיס האשראי שמאוחסן בשרת הרחוק הראשון יכול להישמר בטקסט פשוט, מה שיוצר חשש אבטחה ניכר. במערכות הפעלה החדשות יותר, יש גם אפשרות לשמור גרסה מקוצרתת של הסיסמה ותעוזת כרטיס Kerberos (TGT). ניתן להשתמש ביחד כדי לאמת זהות כמו סיסמה בטקסט פשוט, אך זה מוריד קצת מהסיכון.
עם ניהול, הלקוח והשרת מעבירים מידע הלוך ושוב כדי לאמת את זהותם, אך הסיסמה של המשתמש אינה נגישה לעולם. עקב לתכלית האבטחה הזו, אין דרך שהשרת הראשון יכול לאמת אותך כאשר אתה מתחבר לשרת השני.
בשימוש בהעברת Kerberos
ה-Kerberos, כפי שאומרנו למעלה, הוא דרך נפוצה להגדיר את PSRemoting. כחלק ממאגר המידע הפעיל האולטימטיבי וכבר מוגדר כברירת מחדל, זה די נפוץ. אף שבפני עצמו, Kerberos הוא דרך טובה לאימות של WinRM, הוא אינו פותר את בעיה ההתחברות הכפולה.
כדי להתמודד עם סצנריו ההתחברות הכפולה, ניתן להשתמש בסוג שני של אימות הידוע כ-Kerberos Delegation. אף שישנם כמה סוגים של העברת Kerberos, היחיד שמסוגל (וחסין מספיק) לשמש כאלטרנטיבה ל-CredSSP הוא נקרא Kerberos Constrained Delegation, יותר מסוים – ההעברה המוגבלת למשאבים של Kerberos.
ההעברה המוגבלת למשאבים של Kerberos היא צורת העברת טוקנים של Kerberos המבוססת על משאבי דומיין, כמו מחשבים, במקרה זה, המוגבלת לרשימה ספציפית של אובייקטים של Kerberos (Active Directory).
להגדיר את העברת הקרברוס הזו, יש לערוך את אובייקט ה-ADComputer של המחשב השלישי בשרשרת. לדוג, אם אתה מתכוון להתחבר מ-ClientA ל-ServerB ול-ServeC, עליך לערוך את אובייקט ה-ADComputer של ServerC, אך יש גם לדעת איזה ServerB יהיה. לדוג, להפעיל את הפקודה הבאה ב-PowerShell:
שימוש בהעברת קרברוס המבוססת על משאבים עובדת לחיבורים מרוחקים כמו … או … אך אינה עובדת עם PSRemoting. לא תוכל להתחבר למחשב שלישי כאשר מחובר למחשב מעל יד WinRM באמצעות PSRemoting.
הגדרת העברת הקרברוס המוגבלת למשאבים היא פקודת PowerShell בשורה אחת באמצעות הפקודה Set-ADComputer. אם, לדוג, אתה מחובר אל ServerB מתוך ClientA באמצעות PSRemoting ורוצה להתחבר ל-ServerC עם …, תוכל לעשות זאת על ידי הפעלת הפקודה הבאה ב-PowerShell.
WinRm מאחסן במטמון חיבורים נכשלים למשך 15 דקות. עקוב לכך, ייתכן שלא תוכל להתחבר למחשב השלישי גם לאחר הגדרת העברת הקרברוס המוגבלת למשאבים. לטפל בזה, יש להמתין או להפעיל את הפקודה
klist purge -LI 0x3e7על המחשב השלישי כדי לנקות את אסימוני הקרברוס הנכשלים.
איך פירמוטינג PSRemoting דרך אימות SSH עובד
אף על פי שאימות WinRm הוא השיטה הנפוצה ביותר לאימות עבור PSRemoting, מאז PowerShell v6 יש לך דרך נוספת; SSH. שימוש ב־SSH כשיטת אימות מאפשר לך להשתמש ב־PSRemoting עם Linux.
SSH, להפריד מ־WinRm, מחייב תצורה נוספת בשני הצדדים, הלקוח והשרת, כמו הגדרת לקוח SSH על הלקוח של Windows ו־…
שימוש ב־SSH לטיפול באימות משמעה הגבלה לסוגי האימות ש־SSH תומך בהם. זה מקטין את הרשימה עם שני העיקריים הראשונים היותר, מבוססי סיסמה ומבוססי מפתח ציבורי.
קיימים סוגים נוספים של אימות שנתמכים על ידי SSH, אך כל הסימנים מצביעים על פחות בטיחותיות מהאפשרויות המבוססות סיסמה ומפתח ציבורי ולכן נתמקד רק בשני אלו.
אימות באמצעות סיסמה
הדרך הקלה ביותר להגדיר אימות SSH עם PSRemoting היא עם אימות מבוסס סיסמה. אימות מבוסס סיסמה מאפשר לך לספק סיסמה כדי לאמת את עצמך.
בתהליך אימות SSH, הסיסמה נחלפת לאחר שהחיבור ל-SSH נוצר והסיסמה מוצפנת במהלך ההעברה. להבחנה ממספר שיטות אימות המשמשות ב-WinRM, כמו קרברוס, שיטת האימות הזו אינה שולחת את כל הסיסמה לשרת.
ניתן להשוות בין אימות סיסמת SSH לשיטת האימות הבסיסית של WinRM באמצעות האזנת HTTPS. הסיסמה עצמה אינה מוגנת בכל דרך משמעותית, אך החיבור כולו, כולל הסיסמה, מוצפן והשרת מאומת על פי תעודה.
אימות על פי תעודה במבנה מתקדם
בעוד שאימות על פי סיסמה קל להגדרה ופשוט לשימוש, יש בעיה בשתי השלבים.
- הבעיה הראשונה היא שאין אפשרות לאמת בצורה בטוחה בפורמט לא מורץ.
- אימות על פי סיסמה עדיין שולח סיסמה לאורך הרשת. גם אם הסיסמה מוצפנת בתוך החיבור ל-SSH, השרת מקבל את כל הסיסמה. אם השרת נפגע בכל דרך שהיא, יתכן שזה יהפוך לבעיה בטחונית.
אימות על פי תעודה, מצד שני, אינו שולח נתונים רגישים דרך הרשת כמו הסיסמה. במקום זאת, השרת מכיל עותק של מפתח ציבור, הלקוח מכיל עותק של מפתח פרטי והמגעים מתרחשים על השרת.
A rough workflow goes as follows:
- כאשר הלקוח מנסה לאמת, הוא שולח את המזהה או הטמפלייט של המפתח הציבורי לשרת.
- אם לשרת יש את המפתח הציבורי ברשימת המורשים, הוא מגיב במחרוזת מוצפנת בעזרת המפתח הציבורי.
- אז הלקוח מפענח את המחרוזת בעזרת המפתח הפרטי.
- המפתח הפרטי מתבצע הפיצוץ עם מספר זיהוי ישיבה.
- מספר הזיהוי ישיבה נשלח בחזרה לשרת, שבתורו משווה אותו נגד הפיצוץ שנוצר באמצעות המחרוזת המקורית ומספר הזיהוי ישיבה.
- אם פיצוץ הזיהוי של הלקוח תואם לפיצוץ הזיהוי בשרת, הלקוח מאמת ונתון לחיבור.
כל דבר המוצפן עם המפתח הציבורי יכול להיות פרוק רק עם המפתח הפרטי המשוייך. כל דבר המוצפן עם המפתח הפרטי יכול להיות פרוק רק עם המפתח הציבורי. מספר הזיהוי ישיבה גם נכנס לתמיכה במה שנקרא הסודיות הקדימה המושלמת (PFS).
ה-PFS מספק אבטחה אם המפתח הפרטי נפגע, התוקף לא יוכל לפענח את כל ההודעות שעברו מהלקוח לשרת והפוך. מספר זיהוי ישיבה ייחודי מבטיח שהסוד המשותף המשמש להצפנת התקשורת הוא שונה לכל ישיבה.
אימות בהתבסס על תעוזת אישור עם SSH, כמו WinRm, מחייב מאמץ נוסף להגדיר דברים כמו יצירת המפתח הפרטי/ציבורי והאישור של המפתח הציבורי בשרת המרוחק.
רשויות המשתמש הנדרשות לחיבור
כברירת מחדל, שני קבוצות מקומיות של משתמשים יכולים להתחבר לשרת מרחוק באמצעות PSRemoting; מנהלים ו-משתמשי ניהול מרחוק.
בעוד שתוכלו פשוט להוסיף חשבונות משתמש לקבוצת המנהלים המקומית בשרת רחוק, תמיד כדאי לספק את הכמות הקטנה ביותר של גישה. אם יש פשוט צורך של המשתמש להתחבר באמצעות PSRemoting למחשב רחוק, אפשר להוסיף את חשבון המשתמש לקבוצת משתמשי ניהול רחוק; ולא מנהלים.
כדי לשלוט נוסף בגישת PSRemoting, אפשר גם להשתמש בתכונה הנקראת ניהול מספיק (JEA). JEA מאפשרת למשתמשים שאינם מנהלים להריץ רק פקודות מסוימות כמנהלים ב מצב שפת התכנות המוגבל של PowerShell.
סמכות משולבת ביחס ל- "רמות" רימוטיות
אם כבר השתמשת ב- PSRemoting לפני כן, כנראה תהיה לך מוכר עם פקודות כמו Invoke-Command, New-PSSession, Enter-PSSession, וכו '. כאשר אתה מפעיל את הפקודות האלה, זה ברור שאתה מתחבר למחשב רחוק בדרך מסוימת. אתה באופן פושט משתמש ב- PSRemoting.
כאשר אתה מפעיל פקודות ספציפיות ל- PSRemoting, אתה באופן פושט מריץ את הפקודות האלה אך הידעת שיש דרך נוספת? במקום לקרוא לפקודת Invoke-Command ולcmdlets אחרים ישירות, אפשר להשתמש ב- PSRemoting על ידי שימוש מרומז ב- PSRemoting.
הַרְמָת פקודות PSRemoting עשויה להיראות כאילו אתה מפעיל את הפקודות מקומית בתוך הסשן של PowerShell שלך, אך הן מתבצעות בעצם על מכונה מרוחקת. משל הסבר טוב לכך הוא שימוש במודול שאינו מותקן על המערכת שלך. במקום להתקין אותו מקומית, אפשר לייצא פקודות מתוך הסשן (PSSession) שיאפשרו לך להריץ אותן כאילו הן מותקנות מקומית.
בתמונת המסך למטה אפשר לראות שאין לי את הפקודה Test-PendingReboot. לאחר מכן התחברתי למכונה מרוחקת וייצאתי את הפקודה הזו.
לאחר מכן, כאשר המודול הזה מיובא, אני יכול להריץ את הפקודה Test-PendingReboot. זה מוצג למטה, אך תשימו לב שהמכונה שמופיעה בפלט היא לא שם המכשיר ממנו PowerShell מופעל, אלא שם המכשיר ממנו ייבאו את הפקודה.
