חומת אש רשתית מול חומת אש לאפליקציות ווב: מה בעצם ההבדל?

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

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

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

מה חומת אש רשתית עושה בפועל

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

היא בודקת דברים כמו:

  • איזה כתובות IP מנסות להתחבר
  • לאיזה פורטים הן מנסות להגיע (כמו פורט 22 עבור SSH או פורט 3306 עבור MySQL)
  • איזה פרוטוקול הן משתמשות בו (TCP, UDP, ICMP)
  • האם דפוס החיבור נראה כמו סקירה (scan) או כמו הצפה

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

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

איפה חומת האש הרשתית נכשלת

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

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

מה חומת אש לאפליקציות ווב עושה אחרת

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

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

  • ניסיונות SQL injection שמוסתרים בטופס התחברות
  • קוד XSS זדוני שמוחבא בשדה תגובה
  • ניסיונות העלאת קבצים חשודים שמנסים להטמיע סקריפטים זדוניים
  • בקשות שלא תואמות לדפוסים המצופים באפליקציה הספציפית שלכם

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

למה אתם צריכים את שתיהן, לא רק את אחת מהן

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

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

אתר שיש לו רק חומת אש רשתית חשוף לכל קטגוריית ההתקפות של OWASP Top 10 שנוגעות לאפליקציה, דברים כמו פגמי injection ו-XSS, כי אף אחת מהתעבורות האלה לא מסומנת כחשודה בשכבת הרשת. אנחנו מפרטים על האיומים הספציפיים הללו במאמר איומי OWASP Top 10 וכיצד חומת אש לאפליקציות ווב מתמודדת עם כל אחד מהם.

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

איך זה מתבטא בסביבות אחסון אמיתיות

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

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

דרך מהירה לבדוק מה יש לכם

שאלו את עצמכם את שתי השאלות האלה:

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

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

לסיכום

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