קמיעות נגד פרצות באבטחת המידע

קמיעות נגד פרצות באבטחת המידע

Print Friendly, PDF & Email

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

1. Firewall – המטרה של ה-Firewal היא לסנן את התעבורה על בסיס מספר Port (במקרה של Packet filter), סדר כרונולוגי הגיוני של מנות (במקרה של Stateful firewall) או על בסיס תוכן (במקרה של Application layer firewall), על מנת להקל על מנהל הרשת, מערכות Firewall רבות מגיעות כאשר הן בברירת המחדל חוסמות הכל ורק במקרה ונמצא כלל המאפשר את התעבורה הן מאפשרות אותה. עם זאת, מנהלי רשת רבים יוצאים מנקודת הנחה בעייתית ביותר שהמצב כרגע אצלם הוא מצב תקין ומגדירים כללים על מנת לאפשר לתעבורה הזורמת כיום לעבור באופן תקין ולמעשה חוסמים רק אנומליות ביחס למצב הנוכחי. בדרך כלל מנהלי רשת מסוג זה נוטים לפתוח כל שירות שנחוץ למשתמשיהם כל אימת שעולה דרישה כזו. מובן שבאופן כזה לא משיגים כל אבטחת מידע כלשהי.

2. DMZ – המשמעות של ראשי התיבות היא "DeMeliterized Zone" או בעברית "שטח מפורז", הרעיון הבסיסי הוא בעצם להקים רשת נפרדת שלא ניתן להתחבר ממנה אל הרשת של הארגון ולא ניתן להתחבר ממנה אל האינטרנט. בתוך הנחת היסוד הזו מגולמת הנחת יסוד שאם הגדרנו ב-Firewall שלנו חוק האוסר גישה באופן מסויים היא אכן תיאסר ולא יהיה ניתן לגשת למשאב האסור באופן שהגדרנו בחוק. השימוש ב-DMZ נעשה בדרך כלל כאשר הארגון מספק שירות כלשהו (אתר אינטרנט למשל) לרשת רחבה יותר (למשל רשת האינטרנט) והוא לא מעוניין שיהיה ניתן, עקב הגדרה שגויה ב-Firewall, להעלות קבצים אל שרת האתר ובאופן כזה להשיג גישה כלשהי לרשת הפנימית. בפועל, מנהלי רשת רבים משתמשים במונח זה על מנת לתאר כל רשת המופרדת ע"י Firewall גם אם באופנים מסויימים ניתן לגשת ממנה אל הרשת הפנימית. הדוגמא השכיחה ביותר היא כנראה DMZ המשמש את שרת ה-Mail Relay אשר בד"כ חשופה לאינטרנט לשירות SMTP וניתן להתחבר ממנה אל הרשת הפנימית (אל שרת הדואר הפנימי, ליתר דיוק) באותו שירות. לעצם העובדה ששתי רשתות מופרדות ביניהן ע"י נתב (או Firewall המתפקד כנתב עבור שירותים מסויימים) אין למעשה שום תפקיד מבחינת אבטחת המידע.

3. WAF – או Web Application Firewall הוא סוג של Firewall שמודע לסוג התוכן המועבר דרכו ולפיכך מאפשר סינון לפי סוג התוכן (HTTP, FTP, TELNET וכו') ולאו דוקא לפי אופן העברתו (Port 80, Port 443, Port 21 וכו'), יתירה מזאת, הוא מסוגל גם לזהות אנומליות ברמת הפרוטוקול המועבר, למשל מבנה תקין של XML, אורך של נתון בתג מסוים ב-XML המועבר, נסיון לשליחת פקודות SQL אסורות וכו'. הבעיה הגדולה של ציודים כאלו נובעת למעשה מהבעיה לזהות הקשר (Context) שהיא בעיה אמיתית במחשוב כיום ודומה במהותה לבעיית דואר הזבל (Spam) ואני אנסה להסביר בעזרת הדוגמא הבאה: נניח כי באתר מסוים במקרים מסוימים למשתמשים מסוימים מותר לבצע שאילתות מסוימות אשר בעצם נשלחות מהאתר אל מסד הנתונים כאשר השאילתה מורכבת באתר על בסיס הנתונים שהמשתמש הזין, ייתכן אף שבאתר הזה מותר למשתמשים מסוימים על בסיס מידור מוצלח במיוחד ועל בסיס הזדהות באמצעות זיהוי הרשתית של המשתמש, לבצע גם שאילתות המוחקות טבלאות שלמות (DROP). כעת, כיצד היינו משיגים רמה סבירה של אבטחת מידע בעזרת WAF? האם תוכל לקבוע כי שאילתות SQL מסוימות אסורות להרצה? אם תעשה זאת תאסור בעצם על אותם משתמשים מורשים לבצע פעולות הנחוצות להם ואשר אותן הם מורשים לבצע. על מנת לחדד את הבעיה נצא מנקודת הנחה שהאתר הזה נבנה ע"י תוכניתן שאינו זמין יותר (יצא לפנסיה) ולא קיים בידינו תיעוד או קוד מקור של האתר כך שלמעשה איננו יכולים לבצע בו שינויים, זאת ועוד, התקנתו והטמעתו של מוצר WAF היא באחריות של מנהלי הרשת, כעת – לו אתה מנהל הרשת במקרה כזה כיצד היית מגדיר את ה-WAF? אני משער שהיית עושה מה שכולם עושים – משמרים את המצב הנוכחי.

4. הצפנה – מנהלי רשת רבים סבורים כי HTTPS הוא פרוטוקול מאובטח שאין לחשוש מפניו ולכן מאפשרים למשתמשיהם לגלוש באינטרנט תוך שימוש בפרוטוקול זה ובכך למעשה חושפים את הרשת שלהם למתקפות מסוגים שונים. אכן, נכון הדבר שהפרוטוקול הזה מוצפן באופן שנחשב כיום לבלתי פציח, אבל זו גם הבעייתיות שבו. נחשוב על דוגמא שפורץ פוטנציאלי המעוניין להשיג נתונים כלשהם לגבי פעילות הארגון ישלח מייל לאנשים בארגון עם קישורית לאתר ב-HTTPS כאשר בכניסה לאתר הזה מבוצע קוד זדוני כלשהו על מחשבו של הגולש, במקרה כזה שום ציוד אשר קיים בדרך (כגון Firewalls, WAFs וכו') לא יוכלו לאתר את הקוד הזדוני ולחסום אותו – זאת משום שכל התעבורה מוצפנת.

5. מנגנוני הגנה נגד מתקפות Brute Force – במערכות רבות (כדוגמת Active Directory) ניתן לחסום משתמש שהקליד סיסמא שגויה יותר ממספר פעמים מסויים, זאת על מנת לחסום נסיונות לנחש את הסיסמה האמיתית. מנהלי רשת רבים המודעים לעובדה שסיסמא כבר מזמן נחשבת למזהה חלש למדי מנסים, בפאניקה מסויימת לשפר את המצב ברשת שלהם ע"י הגדרת מספר הסיסמאות השגויות המותר טרם נעילת המשתמש למספר קטן יחסית (פחות מ-15) ואת זמן נעילת המשתמש במקרה שכזה למשך זמן ארוך מאד (יותר מ-5 שעות). ובכן, זה בהחלט חוסם מתקפות Brute Force אבל גם מייצר פוטנציאל טוב מאד למתקפות DoS שהרי מתקפה שתנסה לעבור על כל רשימת המשתמשים ולנחש סיסמאות בקצב גבוה תנעל בסופו של דבר את כל המשתמשים ברשת… גם אם לא תבוצע מתקפה מסוג כזה, זו עדיין לא מעט עבודה לצוות התמיכה, בעוד שהיה ניתן להשיג את אותה רמה של אבטחת מידע גם ע"י חסימת המשתמש לאחר 15 נסיונות כושלים למשך שעה בלבד, בכ"ז צריך לזכור שמתקפות מסוג זה ינסו כמות גדולה מאד של סיסמאות שגויות במשך זמן רב, אחרת מתקפה מסוג זה פשוט לא תהיה אפקטיבית.

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

השאר תגובה