
/etc/pam.d. הקובץ הבסיסי הוא system-auth, ושירותים רבים מפנים אליו. לשירות SSH יש קובץ נפרד עם הגדרות מעט שונות.pam_unix בודק את השם והסיסמה מול הקבצים המקומיים, אפשר להפנות גם ל-LDAP או ל-Active Directory. pam_fprintd בודק טביעת אצבע, ו-pam_cracklib בודק את חוזק הסיסמה.מבנה ושמות דיסקים ומחיצות בלינוקס:

הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על PAM - חלק 1» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום וברוכים הבאים לסרטון בנושא פעם מנגנון האותנטיקציה המודולרי של לינוקס בסרטון הזה אנחנו הולכים ללמוד על המנגנון האותנטיקציה של לינוקס אנחנו הולכים לנתח את הקונפיגורציה שלו אנחנו הולכים לדבר על איך בעצם שירותים שונים מבצעים אותנטיקציה בתוך הלינוקס ואיך אנחנו יכולים להתאים את המנגנון לצרכים שלנו
ולכתוב בפנים קונפיגורציה שהיא מיוחדת אלינו. ראשית, בואו נבין בעצם מה זה הפעם. קודם כל, נתחיל מהבסיס, נתחיל מהצרכים. יש לנו בתוך הלינוקס מגוון אפליקציות שדורשות זיהוי על ידי שם משתמש וסיסמה.
למשל, יש לנו כניסה באמצעות SSH, יש לנו רגיל, בעצם לוגין רגיל ישירות לתוך הקונסול, יש לנו FTP ויש לנו עוד מגוון שירותים אשר אנחנו צריכים בעצם בכל אותם השירותים האלה לבדוק האם המשתמש שבעצם נכנס הוא המשתמש הנכון להיכנס לאותו השירות, כלומר, האם הוא משתמש מורשה, האם המשתמש הזה הוא בכלל מי שהוא טוען את
זה, למשל, מוודאים על ידי סיסמה. לאחר מכן אנחנו צריכים לבדוק האם המשתמש הוא בעצם מורשה להיכנס למערכת חוץ מזה שאנחנו וידאנו שזה אכן המשתמש, קיבלנו את שם המשתמש, קיבלנו את הסיסמה, אנחנו רוצים לבדוק האם האקאונט שלו מאופשר להיכנס כרגע.
למשל, אני לא רוצה שבזמנים מסוימים משתמש ייכנס לשרת. למשל, אני רוצה להגביל את המשתמש שיוכל להיכנס למערכת רק בשעות העבודה.
אז אחרי שאני וידאתי שהשם משתמש הוא נכון והסיסמה היא נכונה, אני רוצה לוודא גם פרמטרים נוספים שיקבעו לי האם בעצם המשתמש יקבל גישה למערכת או לא. עכשיו, יש לי גם, אחרי שהמשתמש נכנס, למשל בחלק מהמקרים אני ארצה ליצור לו תיקיית בית מסוימת, או שאני רוצה להציג הודעה מסוימת למשתמשים האלה, כלומר, מה יקרה בתוך אותו סשן שהמשתמש יקבל
על עצמו, וגם כן, אני רוצה לקבוע למשתמש הזה מה מותר לו לעשות בתוך המנגנון אונטנטיקציה. למשל, האם למשתמש מותר להחליף לעצמו סיסמה? האם המשתמש יכול לשים לעצמו סיסמה שהיא ריקה?
או האם המשתמש יכול לשים לעצמו סיסמה קצרה מאוד של כמה תווים וכדומה? כל זה בעצם נעשה בצורה סטנדרטית ומדולרית עבור כל אחת ואחת מהאפליקציות על ידי מנגנון אחיד, כמו שבעצם בלינוקס דואגים לפתור דברים בצורה יסודית ומרוכזת, ככה גם את הנושא של האותנטיקציה פתרו בצורה יסודית ומרוכזת בעזרת מנגנון הפעם.
אז מה זה בעצם מנגנון הפעם בקצרה? יש לנו מספר אפליקציות שפונות למערכת דרך הספרייה, הדרך הלייברי של הפעם בצורה סטנדרטית כדי לקבל אישור עבור משתמש מסוים.
הספרייה הזאת של הפעם יש לה תיקייה עם קבצים עבור כל אחד מהשירותים שנקראת פעם.די אשר ממוקמת איפה שההגדרות הסטנדרטיות של המערכת ממוקמות בתיקיית ה-ETC ובתוך אותה תיקיה יש בעצם קובץ לכל שירות, ובקובץ הזה יש לנו בעצם ארבעה מדורים, ארבעה סעיפים.
יש לנו את הסעיף של האותנטיקציה, של האאוסט, ששם יש לנו מודולים מסוימים, שתכף אנחנו נדבר מה זה אותם המודולים, שכאן אנחנו מוודאים שהמשתמש אכן מישהו איכשהו הזדהה, שם אנחנו בודקים את השם משתמש ואת הסיסמה.
כמו שאנחנו יכולים לבחון אותם מול הקבצים המקומיים, הסטנדרטים שנמצאים על השרת, אנחנו יכולים לבחון אותם מול איזשהו יוניק, למעשה אלדאפ או איזשהו אקטיב דירקטורי או איזשהו שירות חיצוני.
לאחר מכן אנחנו בודקים את האקאונט של המשתמש והמודור של האקאונט, כלומר, האם המשתמש מורשה להיכנס למערכת הזאת, מורשה להיכנס לשירות הזה ולאחר מכן אנחנו בודקים את דרישות הסשן עבור אותו הסרוויס האם אנחנו צריכים להציג למשתמש איזושהי הודעה או ליצור לו תיק יד בית או לעשות איזשהו שירות
נוסף עבור המשתמש הזה בתוך אותו הסשן כמו כן קיים גם מדור הפסוורד שבו בעצם נבחן את העניין מבחן העניין של מה המשתמש יכול או לא יכול לעשות בזמן החלפת סיסמה, כמו למשל האם הוא יכול או לא יכול לתת לעצמו סיסמה ריקה, או האם בכלל הוא יכול להחליף לעצמו סיסמה.
אז בואו תכלס נראה איך זה מתבצע בתוך המערכת. אוקיי, עכשיו אנחנו מחוברים בפוטי לשרת בעצם סטנדרטי לחלוטין, שלא התבצע עליו שום הגדרה מיוחדת.
וכמו שאמרתי, אנחנו בעצם נבחן את מנגנון הפאם. אנחנו נעשה cd לתיקייה etc.pam.d. כאן, אם אנחנו נעשה ls, אנחנו נראה כאן בעצם מגוון קבצים שהם קבצי הגדרות של פאם, אשר מכילים הודעות שונות עבור אפליקציות שונות הגדרות של פאם.
למשל, ניקח את הקובץ הבסיסי ביותר, את ה-System Auth, שבו בעצם נמצאים ההגדרות של הכניסה מהקונסול.
נעשה Vi על System Auth. כאן אנחנו בעצם רואים את קובץ הגדרות הבסיסי של הפעם. כמו שדיברנו מקודם במצגת, אנחנו רואים כאן ארבעה מדורים, את מדור האאוס, מדור האותנטיקציה, את מדור האקאונט, את מדור הפסוורד ואת מדור הסשן.
אז כמו שאמרתי, מדור האאוס ישמש אותנו כדי לבדוק האם המשתמש מזדהה נכון, לבדוק את ההזדהות של המשתמש. לכל שירות קיים קובץ כזה בתיקיית etc.pam.d.
למשל, אם אני אסתכל, אני אראה שלכובד של ה-SSH קיימות הגדרות שהן מעט שונות מההגדרות הראשיות של המערכת.
כמו כן, אני אמצא כאן קבצים של Vsftpd במידה והוא מותקן, ועוד מספר שירותים במערכת. בעזרת השוני בין הקבצים האלה, אני יכול להגדיר שלמשל כאשר משתמש עושה לוגין למערכת, מהקונסול אז הוא יידרש לדברים מסוימים, כאשר משתמש עושה לוגין דרך ה-SSH אז בעצם חלות
עליו הגדרות אחרות. למשל, אחת מההגדרות השימושיות שהרבה חברות מיישמות זה שה-ROOT יוכל להיכנס באופן ישיר רק דרך הקונסול הפיזי, ולמשל כאשר ב-SSH נכנס המשתמש, הוא יוכל לעשות SCU ולעבור לאקאונט של רוט, אוקיי?
אז בעצם הרוט לא יכול להיכנס ב-SSH, וכן יכול למשל להיכנס דרך הקונסול הפיזי. דוגמה נוספת שראינו לכך היא למשל בסרטון ה-FTP, שהיה שם קובץ אשר בעצם ביטל את האפשרות של חלק מהמשתמשים כמו רוט וכדומה להיכנס דרך ה-FTP.
העניין הזה נעשה בעזרת מנגנון הפאם. למה בעצם קוראים לזה פאם? Plugable Authentication Modules. אם אנחנו נסתכל על הקובץ הגדול, אנחנו נראה בעצם שבתוך ארבעת הסקשנים יש לנו In-Houth Account Session, יש לנו למעשה הפניות לקבצים מסוימים.
נעשה רגע וי איי לסיסטם האוס ונראה שיש לנו הפניות לקבצים מסוימים שאלה הם בעצם מודולים של פאם מה שאיך שנקראים פאם מודולס כל מודול של פאם יש לו תפקיד מסוים יש לו בדיקה מסוימת שהוא יודע לעשות למשל המודול פאם יוניקס הוא בודק את הרשאות המשתמש בעצם את השם משתמש ואת הסיסמה מול הקבצים הסטנדרטיים של יוניקס ETC PassWD ו-ETC Shadow.
למשל כאן בסקשן הפאסוורד שבעצם בודק את תקינות הסיסמה אני רואה שכאן מופעל מודול פעם קראקליב אשר התפקיד שלו הוא בעצם לבדוק האם הסיסמה שהמשתמש הזין היא סיסמה שהיא חזקה מספיק לצורך הבדיקה של האם אפשר לפרוץ אותה את אותה הסיסמה של הקראקליפ, בודק את הסיסמה מול
הדיקשנרי, לבדוק אם זה קובץ מתוך המילון, בודק אם היא מכילה מספיק תווים נכונים וכדומה. וגם כאן יש את מספר ה-retraise, כלומר כמה פעמים המשתמש יוכל לנסות שוב ושוב במידה והסיסמה איננה נכונה.
למשל, בתוך שורת הפאם יוניקס, שזהו בעצם המודול הראשי שעובד מול קבצה ETC פס WD, נבחן כאן בעצם סוג ההצפנה, זה שבעצם הקובץ נשמר בתוך קובץ Shadow וכדומה.
למשל בחלק של הסשן אנחנו נראה שכאן מופעל המודול פעם לימיץ אשר בעצם הולך ומיישם את ההגבלות על אותו משתמש שקובעות כמה פרוססים הוא יכול להריץ במקביל, כמה קבצים הוא יכול לפתוח וכדומה.
האפשרות של לקחת את המודולים האלה ובעצם לבנות מהם בצורה מודולרית את מנגנון האותנטיקציה שאנחנו צריכים עבור שירות מסוים, זה בעצם מה שנותן לפעם את השם שלו, את השם של ה-Plugable Authentication Modules.
בהמשך הסרטון אנחנו למשל נראה איך בעזרת החלק של ה-Session, איך אנחנו יכולים לשתול למשתמש הודעה מיוחדת שמופיעה אחרי שהוא עושה לוגין.
אנחנו נראה איך אנחנו יכולים בעזרת מודול אחר, על ידי הוספה שלו לתוך מנגנון האודנטיקציה, איך אנחנו יכולים לנעול משתמש אם הוא מבצע מספר כניסות לא נכונות למערכת.
כלומר, אם המשתמש נכנס למערכת עם פרטים לא נכונים, נגיד שלוש, ארבע, חמש פעמים, אז לאחר הניסיונות הכושלים האלה, משתמש ינהל את זה אנחנו נעשה בעזרת מודול פעם פייל לוק.
ובהמשך אנחנו גם נעשה בסרטון הזה הדגמה של איך אנחנו יכולים לתת למשתמש אפשרות להיכנס למערכת רק בשעות מסוימות. כלומר אם יש לי משתמשים שעובדים על המערכת במשרד אז אני רוצה למעשה שלתת להם אפשרות להיכנס למערכות רק בשעות העבודה למשל.
אנחנו נראה איך עושים את זה בעזרת המודול פעם טיים. כלומר, אנחנו ניקח מודולים שונים ונחבר אותם, נוסיף אותם לתוך הקובץ קונפיגורציה במקום הנכון, בסקשן הנכון, אם זה בסקשן של האותנטיקציה או בסקשן של האקאונט או בסקשן של הסשן,
או במקום הפסוורד. אנחנו נוסיף אותם במקום הנכון, ועל ידי כך אנחנו נקבל את הפונקציונליות שאנחנו רוצים, בין אם זה הצגת תודעה, בין אם זה נעילת המשתמש, בין אם זה קביעת מדיניות הסיסמאות, בין אם זה התאמה לשירות מסוים, ואנחנו נעשה את זה גם בצורה שונה עבור שירותים
שונים. למשל, נוכל לראות שאנחנו נאפשר כניסה למשתמשים ב-FTP בשעות מסוימות, ובשעות אחרות אנחנו ניתן למשתמשים אפשרות להיכנס למערכת.
כלומר, אנחנו גם ניצור בעצם צורת אותנטיקציה