Firewall, Reverse Proxy ו-WAF יכולים להופיע באותה ארכיטקטורה, אבל הם אינם שמות שונים לאותו מוצר. כל אחד מהם רואה שכבה אחרת של התעבורה ומקבל החלטות מסוג שונה. בלבול ביניהם עלול ליצור נתיב עקיפה, להשאיר את שרת המקור חשוף או לתת תחושת הגנה שאינה קיימת.
ההבדל בקצרה
| רכיב | תפקיד עיקרי | מה הוא בוחן | מה הוא לא מחליף |
|---|---|---|---|
| Firewall | בקרת תעבורה בין רשתות | כתובות, פורטים, פרוטוקולים ומצב חיבור; במוצרי NGFW גם יישומים ותוכן | הגנה ייעודית על לוגיקת יישום Web |
| Reverse Proxy | קבלת בקשות בשם שרתי היישום וניתובן | שם מארח, נתיב, יעד, זמינות ולעיתים TLS ומטמון | Firewall או WAF, אלא אם נוספו לו יכולות כאלה במפורש |
| WAF | הגנת HTTP/HTTPS על יישום Web | Headers, Query String, גוף הבקשה ודפוסי תקיפה בשכבת היישום | סינון רשת מלא והפרדת סגמנטים |
מה עושה Firewall?
Firewall מגדיר אילו חיבורים מורשים לעבור בין אזורי רשת. חומת אש בסיסית יכולה להחליט לפי כתובת מקור ויעד, פורט ופרוטוקול; Stateful Firewall עוקב גם אחר מצב החיבור. מוצרי NGFW מוסיפים יכולות כמו זיהוי יישומים, IPS וסינון מתקדם. לפי ההסבר של Cisco, התפקיד המרכזי נשאר קבלת החלטת Allow או Block בהתאם למדיניות.
לדוגמה, אפשר לאפשר מהאינטרנט רק HTTPS אל אזור DMZ, לחסום גישה ישירה למסד הנתונים, ולאפשר ל-Reverse Proxy לדבר עם שרתי היישום רק בפורטים מוגדרים.
מה עושה Reverse Proxy?
Reverse Proxy יושב לפני שרת אחד או יותר ומקבל את החיבור מהלקוח. לאחר מכן הוא פותח חיבור נפרד אל שרת המקור. כך ניתן לבצע ניתוב לפי דומיין או נתיב, איזון עומסים, בדיקות Health, סיום TLS, מטמון והסתרת כתובות שרתי המקור. בתיעוד הרשמי של NGINX ל-Reverse Proxy מודגם כיצד בקשות מועברות לשירותי Backend וכיצד Headers נכתבים מחדש.
עצם העובדה שהלקוח אינו מתחבר ישירות לשרת המקור היא יתרון ארכיטקטוני, אבל Reverse Proxy רגיל אינו בודק בהכרח אם בקשת HTTP מכילה SQL Injection, ניסיון Path Traversal או Payload זדוני. יכולות אבטחה תלויות במוצר, ברישוי ובתצורה.
מה עושה WAF?
WAF מיועד לשכבת היישום ומבין את מבנה בקשות ה-Web. הוא יכול לנתח Headers, פרמטרים, Cookies וגוף בקשה, ולהחיל כללים על דפוסי תקיפה, Bots, קצב בקשות והתנהגות חריגה. Check Point מסבירה כי WAF עוטף יישום מסוים ובוחן את בקשות ה-HTTP הנשלחות אליו.
WAF אינו יודע בהכרח מי רשאי לפתוח חיבור RDP או SSH בין רשתות, ואינו תחליף ל-Segmentation. הוא גם אינו מתקן קוד פגיע. כלל חסימה יכול לצמצם סיכון, אבל נדרשים עדכון היישום, בדיקות וקונפיגורציה נכונה.
איך שלוש השכבות משתלבות?
מבנה נפוץ נראה כך: האינטרנט מגיע ל-Firewall, שמאפשר רק תעבורה מוגדרת אל כתובת הפרסום. משם הבקשה עוברת ל-Reverse Proxy או Load Balancer. יכולת WAF עשויה לפעול כרכיב נפרד, כשירות ענן או כחלק מאותו מוצר. לבסוף הבקשה מועברת לשרת היישום ברשת פנימית.
- Firewall: מצמצם את שטח החשיפה ברמת הרשת.
- Reverse Proxy: מנהל את פרסום השירות והניתוב ל-Backend.
- WAF: מוסיף מדיניות ובדיקה מותאמות ל-HTTP/HTTPS.
- היישום: עדיין חייב אימות, הרשאות, טיפול בקלט ועדכוני אבטחה.
שש טעויות תצורה נפוצות
- שרת המקור נגיש ישירות: תוקף עוקף את ה-WAF וה-Reverse Proxy באמצעות כתובת ה-IP של ה-Backend. הפתרון הוא Allowlist מהפרוקסי בלבד, בכפוף לצורכי ניהול ו-Health Checks.
- אמון עיוור ב-X-Forwarded-For: אם כל לקוח יכול לקבוע את הכותרת, הלוגים ובקרות הקצב עלולים לזהות כתובת מזויפת. יש לסמוך רק על Proxies מוכרים ולדרוס Headers נכנסים.
- TLS מסתיים ללא הצפנה פנימית: לעיתים זה תקין ברשת מבודדת, אך בסביבות רגישות כדאי לשקול Re-encryption ואימות תעודה גם אל המקור.
- ממשקי ניהול מפורסמים: נתיב Admin אינו אמור להיות נגיש רק מפני שהוא חולק אותו שרת Web. הפרידו גישה ניהולית והפעילו MFA היכן שנתמך.
- WAF במצב ניטור בלבד: מצב Log הוא שלב טוב לכיול, אך אינו חוסם. הגדירו תכנית מעבר הדרגתית ל-Enforcement ובדקו False Positives.
- כללים ללא בעלים: תעדו מי אישר חריגה, למה היא קיימת ומתי היא נבדקת מחדש.
מתי Reverse Proxy לבדו מספיק?
בסביבת פיתוח סגורה או בפרסום שירות פשוט, Reverse Proxy עשוי להספיק לצורכי ניתוב, תעודות ואיזון עומסים. בסביבה ציבורית או רגישה הוא בדרך כלל חלק ממערך רחב יותר. ההחלטה צריכה להתבסס על מודל האיומים, סוג המידע, חשיפה לאינטרנט, דרישות זמינות ויכולת התפעול של הצוות.
אם אתם בונים ארכיטקטורה חדשה, התחילו ממפת זרימה: מי מתחבר, לאיזה שם DNS, היכן מסתיים TLS, איזה רכיב מוסיף כתובות Forwarded, מי יכול להגיע ל-Origin ואיפה נשמרים הלוגים. לאחר מכן הגדירו בדיקות עקיפה וניטור. למדריכים משלימים ראו מדריך סגמנטציה ו-Firewall ואת ההסבר על ZTNA וגישה לפי עקרון אפס אמון.
קרדיט תמונה: נוצרה באמצעות AI עבור מערכת ITPortal.
