איך לבחור מדיניות חומת אש יעילה כדי לאבטח את השרתים שלך

הקדמה

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

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

החלטה על מדיניות ברירת מחדל

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

Default Drop vs Default Accept

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

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

Default Drop Policy vs Final Drop Rule

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

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

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

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

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

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

זריקת תעבורה בניגוד לדחיית תעבורה

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

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

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

אלטרנטיבה להורדת תעבורה היא לדחות במפורש חבילות שלא מותר להן. ICMP, או פרוטוקול הודעות בקרת רשת, הוא מטה-פרוטוקול המשמש ברחבי האינטרנט כדי לשלוח הודעות מעבר, דיאגנוזטיות, ושגיאה בין מארחים כערוץ מחוץ לפרוטוקולי תקשורת רגילים כמו TCP או UDP. כאשר אתה משתמש במטרת REJECT במקום מטרת DROP, התעבורה מתווך וחבילת ICMP מוחזרת לשולח כדי להודיע לו שהתעבורה שלו התקבלה אך לא תתקבל. הודעת מצב יכולה גם להיות מוכלת כדי לספק סיבה.

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

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

טבלת תגובת נפילה נגד דחיתה

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

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

מדיניות ICMP

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

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

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

סוגי חסימה תלויים בתצורת הרשת

סוגים מסוימים של ICMP שימושיים בהגדרות רשת מסוימות, אך עלולים להיות חסומים בתצורות אחרות.

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

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

סוגי ICMP אחרים שימושיים ברשתות מסוימות ומסוכנים פוטנציאלית באחרות הם הודעת ראוטר ICMP (סוג 9) ובקשת ראוטר ICMP (סוג 10). הודעות אלו משמשות כחלק מ-IRDP (פרוטוקול גילוי ראוטרי Internet Control Message Protocol), שמאפשר למחשבים, בעת הדלקה או הצטרפות לרשת, לגלות ראוטרים זמינים באופן דינמי.

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

סוגים שבדרך כלל בטוחים לאישור

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

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

הסוגים למטה ניתן להרשות לרוב בלי כללים מפורשים על ידי הגדרת הגנת הסוכן שלך לאפשר תגובות לבקשות שהוא יצר (על ידי שימוש במודול conntrack לאפשר תעבורה במצב ESTABLISHED ו-RELATED).

• סוג 0 — תגובות Echo: אלו הן תגובות לבקשות echo (ping).
• סוג 3 — יעד אינו נגיש: חבילות יעד לא נגישות הן תגובות לבקשות שנוצרו על ידי השרת שלך ומציינות כי החבילה לא יכולה להימסר.
• סוג 11 — זמן חולף: זו שגיאת אבחון שמוחזרת אם חבילה שנוצרה על ידי השרת שלך מתה לפני שהגיעה ליעד בגלל עברת TTL שלה.
• סוג 12 — בעיה בפרמטר: זה אומר שחבילה יוצאת מהשרת שלך הייתה מסורסת.
• סוג 14 — תגובות חותמת זמן: אלו הן התגובות לשאילתות חותמת זמן שנוצרו על ידי השרת שלך.

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

הגבלת חיבורים והגבלת קצב

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

הגבלת חיבורים

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

• האם להגביל על בסיס כתובת, רשת או גלובלי?
• האם להתאים ולהגביל תעבורה לשירות מסוים או לשרת כולו?

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

הגבלת קצב

הגבלת הקצב מאפשרת לך לבנות כללים שמנהלים את הקצב או תדירות התעבורה שתתקבל על ידי השרת שלך. קיימים מספר תוספות של חומת אש שיכולות לשמש להגבלת קצב כולל limit, hashlimit, ו־recent. בחירת התוסף שתשתמש בו תלויה בעיקר על הדרך שבה ברצונך להגביל את התעבורה.

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

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

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

ניהול מונוליתי נגד מבוסס רשימות

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

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

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

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

מסקנה

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

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

• איך עובד גדר האש Iptables
• A Deep Dive into Iptables and Netfilter Architecture

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

• איך להגדיר גדר באמצעות Nftables על Ubuntu 22.04
• איך להגדיר גדר עם UFW על Ubuntu 22.04
• איך להגדיר גדר באמצעות FirewallD על Rocky Linux 9