נעילת חשבון מול חסימת כתובת: היכן OpenVPN באמת סופר

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

ב-VPN שמאציל אימות ל-PAM, המונה הוא מה שמגיעה אליו מחסנית ה-PAM, ולא מה שהמאזין תיעד.

שני מונים, שני קורבנות שונים

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

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

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

מצאו את המאגר שכבר מחזיק את הספירה

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

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

קראו את קובץ השירות שה-VPN באמת מזכיר ועקבו אחרי שורות ההכללה שלו. בהפצות רבות שירות ה-VPN כולל קובץ משותף, כלומר הספירה שאתם מכווננים חלה גם על SSH ועל התחברויות מקומיות.

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

ל-pam_faillock יש שלושה מקומות קריאה, לא אחד

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

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

faillock --user alice
faillock --user alice --reset

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

שם שירות ייעודי אינו בידוד

מתן קובץ שירות PAM נפרד ל-VPN הופך את המדיניות המכוונת לגלויה, אך אינו מגביל את ההשפעה. כל הכללה של קובץ משותף מביאה את מה שהקובץ עושה, כולל ספירות ברמת המערכת.

החליטו במפורש אם הנעילה אמורה לכסות רק גישת VPN או כל שירות שמאמת את אותו חשבון. שתי התשובות סבירות; הכשל הוא להאמין שבחרתם באחת בזמן שהמחסנית מיישמת את האחרת.

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

קבלו את הרצף, לא דחייה אחת

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

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

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

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