הגדרת Fail2Ban מקצועית: הגנה מפני התקפות כוח גס

הגדרת Fail2Ban: מדוע ניחוש סיסמאות מגיע אל השירות

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

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

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

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

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

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

להלן נפרט איך סוגרים זאת בלי הפעלות שווא.

מה משתנה אחרי ההטמעה: סוגי תקיפות וזמן תגובה

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

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

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

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

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

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

הגדרת Fail2Ban: אפשרויות מיקום ומצבי חסימה

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

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

מצבי חסימה ומשכי החזקה

חומרת המצב נבחרת לפי אופי התעבורה: רך — השהיה והגבלת קצב הפניות, בינוני — חסימה זמנית של הכתובת לפרק קצר, קשה — חסימה מלאה של המקור עם משך עולה בחזרות.

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

שלבי הטמעה: מביקורת יומנים ועד העברה לתמיכה

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

1. ביקורת יומנים. לוקחים חתך לתקופה: אילו שירותים כותבים על כניסות כושלות, באיזה פורמט, באיזו תדירות, האם יש התפרצויות ליליות וכתובות מקור שחוזרות מיום ליום.
2. מיפוי נקודות כניסה. מאחדים לרשימה אחת שירותים, פורטים וחשבונות שנגישים מבחוץ — אחרת ההגנה תסגור חלק מהכניסה והשאר יישאר פתוח.
3. תוכנית הטמעה וסכמה. קובעים מה נחסם, לכמה זמן, איך מוגדרים חריגים לניטור, גיבוי וכתובות שירות.
4. הגדרת מסננים. כותבים תבניות פענוח לפורמטי היומנים שלכם ומתאימים ספי הפעלה כך שהכלל לא יחתוך משתמשים חיים.
5. בדיקה בקונטור בדיקה. משחזרים תרחיש ניחוש: הכלל מופעל, כניסה לגיטימית עוברת, החסימה מוסרת בתום המשך.
6. מעבר למצב עבודה. בהתחלה עוקבים, מנתחים הפעלות שנויות במחלוקת ומתקנים ספים — ורק אחר כך מוסרים את המערכת לתחזוקה.
7. העברת נוהל. מוסרים מסמך: אילו כללים פועלים, מדוע קורות הפעלות שווא ומה לעשות בזמן תקיפה.

הרכב המסירה: קונפיגורציות מסננים, כללים ונוהלים

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

• קונפיגורציות מסננים — מערכי כללים נפרדים לשירותים ספציפיים: גישה ב-SSH, שרת אינטרנט, דואר, לוח בקרה. כל מסנן נבדק על שורות לוג אמיתיות, לא על דוגמאות הדגמה.
• ספי חסימה — ערכי maxretry, findtime ו-bantime לכל שירות עם נימוק: עבור SSH וטופס כניסה הם שונים, כי מחיר ההפעלה השווא שונה.
• רשימות מהימנות — כתובות המשרד, צמתי יציאה של גישה מאובטחת, מערכות ניטור וגיבוי. בסעיף נפרד — כיצד לתחזק את הרשימה בעת החלפת כתובות, כדי לא לחסום בדיקות משלכם.
• כללי החרגה — מסננים נגד חסימת רובוטים לגיטימיים של מנועי חיפוש וסורקים פנימיים, שאחרת נופלים באופן קבוע לחסימה ויוצרים התראות שווא.
• סכמת אינטראקציה עם חומת האש — אילו שרשראות משמשות, איך מסירים חסימה לפני הזמן ואיך מתנהגת הקונפיגורציה בעת הפעלה מחדש של הצומת.
• נוהל תגובה — מי מקבל התראה, תוך כמה זמן מנתח, מה עושה בתקיפה המונית ממאות כתובות ומתי מסלים את הנושא.
• תיעוד — מפת קונפיגורציות, מיקום היומנים, סדר שחזור ההגדרה בצומת חדש וצ'ק-ליסט בדיקה לאחר עדכון.

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

מקרה בוחן: ההגנה חתכה ניחוש בלי לאבד כניסות לגיטימיות

מה היה לפני

שירות האימות החזיק החוצה שתי כניסות — גישה מרחוק למנהלים ולוח בקרה. ביומנים יומיים שקעו 40–60 אלף ניסיונות כניסה כושלים, וכמעט כולם הגיעו לבדיקת סיסמה: המחסום היחיד היה אורכה.

כללי Fail2Ban הסטנדרטיים הופעלו פורמלית — מערך תנאים אחד וסף שבו החסימה הופעלה במקרה הטוב פעם ביום. הניחוש מילא את היומנים, אירועים אמיתיים בהם אבדו, ולניתוח אירוע נדרשו שעות.

מה שינו

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

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

מה יצא

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

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

במה שונה חסימה בפרימטר מהגנה על השרת עצמו?

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

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

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

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

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

ספקות נפוצים: הפעלות שווא, הרשאות ותאימות

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

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

הגישה עוברת דרך פרוקסי או מאזן עומסים — מה אז?

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

האם זה תואם שירותים שכותבים יומנים אחרת?

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

מה לעשות עם כללים מיושנים?

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

נדון במשימה: מה נדרש מכם להתחלה מהירה

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

• מה מגינים עליו: רשימת שרתים ושירותים שבהם fail2ban כבר עובד או רק צריך לעלות, ואיזו ענף משמש כעת.
• נקודות כניסה: באילו פורטים מגיעים חיבורים ל-SSH, לוחות ניהול ושירותי אינטרנט, והאם יש לא סטנדרטיים או חשופים החוצה.
• הרשאות להתחלה: חשבון עם הרשאות לקרוא קונפיגורציות ולהפעיל מחדש את השירות, או חיבור דרך ערוץ מאובטח עם תיעוד יומן של הסשן.
• מה כבר מוגדר: כללי חסימה נוכחיים, רשימות לבנות, חיבור לחומת אש, אופן מסירת הקונפיגורציה לצמתים.
• איך בנויה הכניסה כעת: במפתחות או בסיסמה, היכן נשמרים היומנים, איך אתם מבדילים בין שלכם לזרים.
• סדרי עדיפויות ולוחות זמנים: מה קריטי לסגור ראשון, האם יש חלון תחזוקה ומגבלות על הפעלה מחדש של שירותים.
• מגבלות: דרישות אבטחה, איסור התקנת חבילות נוספות, דרישות לאחסון נתוני חסימות.

תארו את המשימה — נחזור עם הערכה, תוכנית וגבולות עבודה.