SELinux, App Armor, PAM

במדריך קצר זה נסקור את עקרונות הפעולה של SELinux, AppArmor ו-PAM בלינוקס.
נרחיב על מבנה המדיניות, ההקשר (context) והתוויות (labels) ב-SELinux ונלמד כיצד לנהל משתני Boolean ולהשתמש בפקודות כמו sestatus ו-audit2allow.
בנוסף, נתרגל טעינת ועריכת פרופילים ב-AppArmor ונבחן מצבי enforce ו-complain.
נדון בתיעוד לוגים ובשחזור תוויות באמצעות restorecon, ובהגדרת פורטים וכללי מדיניות עם semanage.
בסיום נדון באפשרויות ההרחבה של אימות ב-PAM, כולל שילוב OTP, הגבלת ניסיונות כישלון וניהול משאבים עם pam_limits.
מבוא ל-‪SELinux‬, ‪AppArmor‬ ו-‪PAM‬ בלינוקס

מבוא ל-‪SELinux‬, ‪AppArmor‬ ו-‪PAM‬ בלינוקס

כדי להבין כיצד מערכות לינוקס המודרניות מנהלות אבטחת מידע ברמה גבוהה, יש להכיר שלושה רכיבים חשובים: ‪SELinux‬, ‪AppArmor‬ ו-‪PAM‬.
כל אחד מהרכיבים הללו מוסיף שכבת הגנה והגדרה המרחיקה אותנו ממודל הגישה המסורתי (‪DAC‬) אל עבר בקרת גישה קפדנית יותר (‪MAC‬).
במערכות מורכבות מומלץ מאוד לדעת כיצד לשלוט בהם, לנתח בעיות, ולבצע התאמות למדיניות הרצויה.

מהו ‪SELinux‬

‪Security-Enhanced Linux‬ (‪SELinux‬) הוא מנגנון בקרת גישה מחייב (‪MAC‬) המגיע עם רוב הפצת הלינוקס המודרניות, בפרט במשפחת ‪Red Hat‬.
‪SELinux‬ מכניסה מערכת של הקשרים (‪contexts‬) המגדירים משתמש (‪user‬), תפקיד (‪role‬) וסוג (‪type‬) לכל תהליך וקובץ.
במדיניות מורכבת, ניתן להגדיר כללי מעבר (‪transition‬) שמפקחים על האופן שבו תהליך אחד יוצר תהליך אחר, כך שלא יעביר הרשאות מופרזות או מסוכנות.

מצבים עיקריים של ‪SELinux‬ כוללים ‪enforcing‬, ‪permissive‬ ו-‪disabled‬.
המצב ‪enforcing‬ חוסם בפועל כל הפרה של מדיניות האבטחה, בעוד ‪permissive‬ מקליד את ההפרה ביומן אך אינו חוסם אותה.
אם צריך לבצע ניתוח בעיות ולקבל לוגים על הפרות, נשתמש בפקודה ‪setenforce‬ 0 כדי לעבור במהירות למצב ‪permissive‬, ובאותה צורה ‪setenforce‬ 1 מחזיר אותנו לאכיפה מלאה.
ההגדרה הקבועה של מצב ‪SELinux‬ נשמרת בקובץ ‪/etc/selinux/config‬ ומשפיעה על הפעלה מחדש של המערכת.

כדי לקבל מבט מהיר על מצב ‪SELinux‬ הנוכחי אפשר להשתמש בפקודת ‪sestatus‬.
פקודה זו מציגה אם המערכת פועלת במצב ‪enforcing‬, ‪permissive‬ או ‪disabled‬, וכן מספקת פרטים על המדיניות הטעונה.
אם רוצים לצפות בסוג (‪type‬) שמוקצה לקובץ מסוים, ניתן להשתמש בפקודה ‪ls -Z‬.
באופן דומה, פקודת ‪getsebool -a‬ מאפשרת לראות את כל משתני ה-‪Boolean‬ המוגדרים ולבדוק אם הם במצב פעיל או כבוי.

כאשר מעדכנים מדיניות ומתרחשות הפרות חדשות, אפשר להיעזר בכלי ‪audit2allow‬ כדי להמיר רשומות לוג שנוצרו מהפרות לכללי מדיניות (‪policy rules‬).
כך חוסכים זמן יקר באיתור הבעיה ויצירת הכללים ידנית.
בנוסף, כאשר קבצים חדלים להתאים לתוויות (‪labels‬) שקבעה המדיניות החדשה, משתמשים בפקודת ‪restorecon -R <directory>‬ כדי לשחזר את התוויות הנכונות על כל הקבצים בספרייה.

כלי חשוב נוסף הוא ‪semanage‬ שמציע דרך רשמית לניהול מדיניות ‪SELinux‬ בלי לערוך קבצי ‪policy‬ גולמיים.
באמצעות ‪semanage‬ ניתן להגדיר סוגי קבצים, פורטים, ‪Boolean‬ ומשתני ‪policy‬ אחרים, וכך להימנע מטעויות העשויות לשבור את המדיניות או לגרום לאי-תאימות.

יחידה 8200 עושה שימוש בשיטות אבטחה מתקדמות הכוללות לעיתים הטמעה של ‪SELinux‬ בתצורות מאובטחות במיוחד.

‪AppArmor‬

‪AppArmor‬ פועלת בדומה ל-‪SELinux‬, אך במקום להשתמש בשיטת ‪context‬ מפורטת, היא עובדת עם פרופילים (‪profiles‬) שמוגדרים לכל אפליקציה או תהליך.
הפרופיל מציין אילו תיקיות, קבצים ויכולות מותרות לאפליקציה, ובכך מצמצם משמעותית את יכולתה לפגוע במערכת במקרה של פריצה או התנהגות לא צפויה.

מצבי הפעולה העיקריים של ‪AppArmor‬ הם ‪enforce‬ ו-‪complain‬ (או ‪permissive‬).
במצב ‪complain‬ המערכת רושמת ביומן את ההפרות אך אינה חוסמת אותן, בדומה למצב ‪permissive‬ ב-‪SELinux‬.
לאחר שעורכים פרופיל חדש או מעדכנים קיים, ניתן לטעון אותו באמצעות הפקודה ‪apparmor_parser -r <profile_file>‬.

כדי לבדוק אילו פרופילים מופעלים כרגע, אפשר להיעזר בפקודת ‪aa-status‬.
בנוסף, אם רוצים לזהות פרופיל פעיל על תהליך מסוים, משתמשים בדגל -p וציון מספר תהליך (‪PID‬), לדוגמה ‪aa-status -p 1234‬.
כך מגלים אם התהליך נמצא תחת אחד הפרופילים ובאיזה מצב הפעלה הוא (‪enforce‬ או ‪complain‬).

הכנה למיונים גאמא סייבר כוללת לעיתים גם לימוד על ‪AppArmor‬ ויכולותיה בארגונים גדולים.

‪PAM‬

‪PAM‬ (‪Pluggable Authentication Modules‬) היא שכבת האימות הגמישה של לינוקס.
עבור כל שירות, למשל ‪SSH‬, ‪Login‬ או סיסמת ‪sudo‬, ישנו קובץ תצורה ב-‪/etc/pam.d‬ שמכיל רשימה של מודולי ‪PAM‬ הפועלים בשלבים שונים של תהליך ההתחברות.
כאשר מעוניינים לבדוק את מודולי האימות לשירות ‪ssh‬, למשל, בודקים את הקובץ ‪/etc/pam.d/sshd‬.

באמצעות ‪PAM‬ אפשר להוסיף אימות דו-שלבי באמצעות מודולים ייעודיים כמו ‪pam_google_authenticator‬.
הגדרת מנגנון זה נעשית על ידי עריכת הקובץ המתאים ב-‪/etc/pam.d‬ (בדרך כלל ‪sshd‬), והוספת שורת דרישה למודול ה-‪OTP‬ לאחר אימות בסיסי.
כך, משתמשים יתבקשו להקליד קוד חד-פעמי נוסף בנוסף לסיסמה הרגילה.

מודולים אחרים כגון ‪pam_tally2‬ או ‪pam_faillock‬ מאפשרים להגביל מספר ניסיונות התחברות כושלים ולנעול חשבון או לעכב את ההתחברות לאחר כישלונות חוזרים.
דרך זו מחזקת משמעותית את אבטחת הגישה למערכת, במיוחד בסביבות בהן קיימות התקפות מבוססות ניחוש סיסמאות.

לבסוף, כדאי להכיר את ‪pam_limits‬, אשר מחיל הגבלות משאבים בעת תהליך ההתחברות על בסיס ההגדרות בקובץ ‪/etc/security/limits.conf‬ או בקבצים נוספים בספרייה ‪limits.d‬.
כך שומרים על יציבות המערכת ומונעים שימוש יתר במשאבים, באמצעות הגדרת מקסימום תהליכים לכל משתמש, מקסימום קבצים פתוחים ועוד.

סיכום

‪SELinux‬, ‪AppArmor‬ ו-‪PAM‬ הם שלושה מרכיבים קריטיים בניהול אבטחת לינוקס ברמה גבוהה.
בעוד ‪SELinux‬ ו-‪AppArmor‬ מטפלים בנקודות שונות של בקרת גישה מחייבת (‪MAC‬) ומאפשרים שליטה מדויקת בהרשאות תהליכים וקבצים, ‪PAM‬ ממוקד בשכבת האימות וההרשאות הנלוות לה.
יחד הם מספקים מעטפת הגנה חכמה ויעילה מפני מגוון איומים.
השילוב הנכון בין שלושתם מעניק גמישות, שליטה ואפשרות לגדול בהתאם לצורכי הארגון או המערכת.

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

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

תודה! בזכותכם נוכל להשתפר