פיירוול Palo Alto למתחילים: מדריך מלא בעברית — Interfaces, Zones, NAT, Security Policy, App-ID ו-Commit

אם אתם מגיעים מעולם הרשתות — CCNA ביד, סוויצ׳ים ונתבים בדם — הפעם הראשונה שאתם מתחברים ל-Palo Alto יכולה להיות מבלבלת. הכל נראה מוכר: ממשקים, ראוטינג, כללים. ואז אתם מגדירים IP על ממשק, שומרים, ושום דבר לא עובר. אחר כך מגלים שיש דבר שנקרא Zone, שיש שני עותקי קונפיגורציה, ושבמקום לפתוח פורט 443 אתם אמורים לבחור אפליקציה בשם ssl. במדריך הזה נעשה סדר בכל זה — בדיוק בסדר שבו אנחנו מלמדים את זה במעבדה בקורס Palo Alto של מכללת נטמי.

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

רגע, למה בכלל צריך פיירוול?

נתב מעביר חבילות בין סאבנטים. זה התפקיד שלו. נכון, אפשר לסנן איתו תעבורה עם ACL, אבל ACL בודק כתובת ופורט ותו לא. ניקח ארגון לדוגמה — נקרא לו "מאפיית שחר" — עם משרד ראשי, כמה מאות עובדים, מחלקת כספים, מחלקת HR, מחסן ושרתים פנימיים. אנחנו לא רוצים שאיש מכירות יקרא תלושי שכר, לא רוצים שתחנה נגועה תדבר עם שרת ה-DC בפורט 445, ואנחנו כן רוצים שהעובדים יעבדו מהבית דרך VPN מוצפן. ACL לא יודע לעשות את זה. פיירוול דור חדש (NGFW) — כן.

• ▸בקרת גישה ברמת מחלקה: מי מדבר עם מי, לאיזה שרת, ובאיזו אפליקציה — ולא רק לאיזה פורט.
• ▸בדיקת תוכן: זיהוי חתימות של נוזקות, חסימת קטגוריות URL וסינון קבצים מסוכנים.
• ▸זיהוי אפליקציות אמיתי (App-ID): גם אם התוקף מבריח תעבורה על UDP/53, הפיירוול יראה שזה לא באמת DNS.
• ▸גישה מרחוק מאובטחת: Site-to-Site VPN בין סניפים ו-GlobalProtect למשתמשים מהבית.
• ▸נראות: לוגים, דוחות וציר זמן שמאפשרים לחקור אירוע במקום לנחש.

מה יש במסך? סיור מהיר ב-GUI של PAN-OS

בניגוד להרבה ציוד תקשורת, את רוב העבודה על Palo Alto עושים דרך ה-GUI, וה-CLI נשמר בעיקר לפתרון תקלות ולפקודות show. אחרי התחברות תראו שורת טאבים בחלק העליון. שניים מהם (Dashboard ו-ACC) הם תצוגה, וחמישה הם מקום העבודה האמיתי שלכם.

• ▸Monitor — כאן חיים הלוגים: Traffic, Threat, URL Filtering, System. גם Packet Capture ו-Configuration Audit נמצאים כאן.
• ▸Policies — כללי Security, כללי NAT, Decryption ו-Policy Based Forwarding.
• ▸Objects — אובייקטים של כתובות, קבוצות, Services, קטגוריות URL ו-Security Profiles. בונים כאן, ומשתמשים בזה בכללים.
• ▸Network — ממשקים, Zones, Virtual Router, DHCP, ו-VPN. כל מה שקשור לתשתית.
• ▸Device — ניהול המכשיר עצמו: משתמשי ניהול, HA, פרופילי שרתים (RADIUS/TACACS), עדכוני תוכנה ו-Content.

הרעיון שמבלבל את כולם: Security Zones

זו הנקודה שבה מהנדסי רשת מתחילים לגרד בראש. ב-Palo Alto אתם לא כותבים כללים מול ממשקים — אתם משייכים ממשק אחד או יותר ל-Zone, וכותבים את הכללים מול ה-Zone. יש לזה שתי השלכות שחשוב להפנים.

• ▸ממשק בלי Zone הוא ממשק מת. אפשר להגדיר עליו IP, הוא יעלה, אבל שום תעבורה לא תעבור דרכו עד שתשייכו אותו ל-Zone.
• ▸תעבורה בתוך אותו Zone (Intra-Zone) מותרת כברירת מחדל, ותעבורה בין Zones שונים (Inter-Zone) חסומה כברירת מחדל. שני הכללים האלה יושבים בתחתית טבלת הכללים ולא ניתן למחוק אותם.
• ▸המשמעות המעשית: אם תשימו את משתמשי ה-Windows ואת משתמשי ה-Mac באותו Zone, הם ידברו ביניהם בלי שום כלל. רוצים להפריד? Zone נפרד לכל אחד.
• ▸שם ה-Zone הוא לוגי בלבד. TRUST, UNTRUST, DMZ, USERS, SERVERS — הפיירוול לא נותן לשם משמעות מיוחדת, רק אתם.

טעות מספר אחת של מתחילים ב-Palo Alto: להגדיר IP על ממשק, לשכוח Zone ו-Virtual Router, ואז לבזבז שעה על ping שלא עובר. תמיד שלושה שלבים: IP, Zone, Virtual Router.

התרחיש שנבנה: משרד קטן עם יציאה לאינטרנט

נבנה תרחיש שמייצג משרד אמיתי: רשת משתמשים פנימית 10.1.1.0/24, וממשק חיצוני שמקבל כתובת מה-ISP. ממשק ethernet1/2 יהיה הפנימי וישויך ל-Zone בשם TRUST, וממשק ethernet1/1 יהיה החיצוני וישויך ל-Zone בשם UNTRUST. זו בדיוק הטופולוגיה שאנחנו מרימים בשיעור הראשון של המעבדה בקורס.

שלב 1 — הממשק הפנימי וה-Zone

נכנסים ל-Network > Interfaces > Ethernet, בוחרים את ethernet1/2 ומגדירים אותו כ-Layer3. בטאב Config בוחרים Virtual Router (ברירת מחדל: default) ויוצרים Security Zone חדש בשם TRUST. בטאב IPv4 מזינים 10.1.1.1/24. אם המשתמשים אמורים לקבל כתובת אוטומטית, אפשר להרים DHCP Server על אותו ממשק תחת Network > DHCP.

נקודה שנופלים עליה הרבה: כדי שתוכלו לעשות ping לממשק הפנימי או לנהל את הפיירוול דרכו, צריך Interface Management Profile (תחת Network > Network Profiles > Interface Mgmt) עם Ping ו-HTTPS מסומנים, ולשייך אותו לממשק בטאב Advanced. בלי זה הממשק לא יענה — וזה לא תקלה, זו התנהגות מכוונת.

שלב 2 — הממשק החיצוני והראוט הדיפולטיבי

ethernet1/1 מוגדר גם הוא כ-Layer3, משויך ל-Zone בשם UNTRUST ולאותו Virtual Router. בסביבת מעבדה נוח להגדיר אותו כ-DHCP Client ולסמן Automatically create default route pointing to default gateway — כך הפיירוול מקבל כתובת וגם ראוט דיפולטיבי מה-ISP. בסביבת ייצור לרוב תגדירו כתובת סטטית, ואז תצטרכו להוסיף ידנית תחת Network > Virtual Routers > default > Static Routes ראוט 0.0.0.0/0 שמצביע ל-Next Hop של הספק.

# בדיקת מצב הממשקים
show interface all

# האם קיבלנו כתובת מה-ISP?
show dhcp client state ethernet1/1

# האם יש ראוט דיפולטיבי בטבלה?
show routing route

# בדיקת קישוריות מהפיירוול עצמו (חשוב: source נכון)
ping source 10.1.1.1 host 1.1.1.1

שלב 3 — NAT: בלעדיו לא יוצאים לאינטרנט

הכתובות הפנימיות שלנו פרטיות, ולכן חייבים לתרגם אותן לכתובת החיצונית של הפיירוול. תחת Policies > NAT יוצרים כלל Source NAT: ה-Original Packet מגיע מ-Zone TRUST ליעד ב-Zone UNTRUST דרך ממשק ethernet1/1, וב-Translated Packet בוחרים Dynamic IP and Port עם Interface Address של ethernet1/1. זהו — כל המשרד יוצא מאחורי כתובת אחת.

• ▸Source NAT (רבים ליציאה אחת) — Dynamic IP and Port, הצורה הנפוצה ביותר.
• ▸Destination NAT (פרסום שרת פנימי החוצה) — כאן מגיע הבלבול הגדול: ב-NAT מציינים את ה-Zone היעד המקורי (UNTRUST), אבל ב-Security Policy מציינים את ה-Zone שאליו התעבורה באמת מגיעה אחרי התרגום (למשל DMZ), עם כתובת היעד המקורית הציבורית.
• ▸כלל אצבע: NAT ו-Security הם שתי טבלאות נפרדות. NAT מתרגם, Security מחליט. תעבורה שעברה NAT עדיין חייבת כלל Security שמתיר אותה.

שלב 4 — Security Policy ו-App-ID: לשכוח מפורטים

כאן Palo Alto באמת שונה. בכלל Security אתם מגדירים Zone מקור ויעד, כתובות, משתמש — ובמקום פורט, אפליקציה. App-ID מזהה את האפליקציה לפי התנהגות התעבורה ולא לפי מספר הפורט. נתחיל בשלושה כללים בסיסיים שמספיקים כדי לגלוש: DNS לשרת 1.1.1.1, ping החוצה, ו-web-browsing יחד עם ssl.

שימו לב לעמודת Service: הערך application-default אומר לפיירוול להתיר את האפליקציה רק על הפורטים הסטנדרטיים שלה. כלומר DNS יעבור על UDP/53 — ואם מישהו ינסה להבריח SSH או ערוץ C2 בתוך UDP/53, App-ID יזהה שזה לא DNS והכלל לא יתפוס. זה בדיוק ההבדל בין פיירוול דור שלישי לפיירוול דור חדש.

עוד נקודה שמפתיעה מתחילים: הכלל שמתיר web-browsing ו-ssl לא פותח את כל האינטרנט. אתרי חדשות, בלוגים ואתרי מסחר יעבדו — אבל YouTube, Gmail ו-Google לא, כי להם יש App-ID ייעודי משלהם. אפשר להתיר אפליקציות ספציפיות, ואפשר (וכדאי) לעבוד עם Application Filters לפי קטגוריה, למשל כל אפליקציות ה-video conferencing. מי שרוצה בכל זאת לעבוד לפי פורטים — צריך להגדיר Application ל-any ולבחור Service מתאים כמו service-http או service-https, אבל אז ויתרתם בדיוק על מה ששילמתם עליו.

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

שלב 5 — Commit: candidate מול running

ב-Cisco ASA וב-FortiGate כל שינוי נכנס לתוקף מיידית. ב-Palo Alto זה לא כך, ולדעתנו זו אחת התכונות הטובות של המערכת. קיימים שני עותקי קונפיגורציה: running-config, זה שרץ בפועל, ו-candidate-config, שאליו נכנסים כל השינויים שלכם. כלומר אתם יכולים לשבת שעה, לבנות עשרה כללים, לשנות אובייקטים — ושום דבר לא משפיע על הרשת עד שתלחצו Commit.

• ▸Preview Changes — לפני Commit אפשר לראות diff מדויק של מה עומד להשתנות. הרגל מציל קריירות.
• ▸Commit Changes Made By — כשכמה אנשים עובדים על אותו פיירוול, אפשר לשחרר רק את השינויים שלכם.
• ▸Config Audit (תחת Device > Config Audit) — השוואה בין גרסאות קונפיגורציה, מצוין לחקירת "מי שבר את זה אתמול".
• ▸Revert — טעיתם ועוד לא עשיתם Commit? Revert to running configuration מחזיר את המצב לאחור בשנייה.

שלב 6 — Traffic Logs: איך באמת מאבחנים תקלה

הלוגים נמצאים ב-Monitor > Logs > Traffic, אבל יש מלכוד: לוגים לא נרשמים אלא אם הכלל אומר להם. בכל כלל Security, בטאב Actions, תחת Log Setting, יש שתי אפשרויות — Log at Session Start ו-Log at Session End. ברוב המקרים נשתמש ב-Session End: זה מדויק יותר, כולל את כמות הבתים ואת האפליקציה הסופית, ולא מציף את האחסון. את Session Start מפעילים נקודתית בזמן פתרון תקלה, כשרוצים לראות סשנים שנתקעים ולא נסגרים.

( addr.src in 10.1.1.15 ) and ( action eq deny )
( app eq ssl ) and ( addr.dst in 142.250.0.0/16 )
( zone.src eq TRUST ) and ( zone.dst eq UNTRUST ) and ( port.dst eq 22 )
( receive_time geq '2026/08/20 09:00:00' )

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

אין תחליף לידיים. אפשר להריץ PA-VM על VMware Workstation או ESXi, ואפשר לעבוד ב-EVE-NG או GNS3 ולבנות טופולוגיה שלמה עם סוויצ׳ים ותחנות. מומלץ להקצות לפחות 4 vCPU ו-6.5GB זיכרון ל-VM, ולזכור שהממשק הראשון הוא תמיד ממשק הניהול (MGT) ולא ממשק תעבורה.

• ▸בנו חברה דמיונית: סאבנט למשתמשים, סאבנט לשרתים ו-DMZ לשרת אינטרנטי.
• ▸תנו למשתמשים אינטרנט, אבל חסמו רשתות חברתיות בעזרת App-ID או URL Filtering.
• ▸פרסמו שרת Web מה-DMZ החוצה עם Destination NAT — וראו איך זה משפיע על כללי ה-Security.
• ▸שברו בכוונה: מחקו Zone מממשק, הסירו ראוט, כבו Logging — ותתאמנו לאבחן לבד מהלוגים.
• ▸רק אחרי שהבסיס יושב, עברו ל-Site-to-Site VPN, GlobalProtect, User-ID ו-SSL Decryption.

חמש טעויות שאנחנו רואים כמעט אצל כל תלמיד חדש

• ▸ממשק בלי Zone או בלי Virtual Router — הכל נראה תקין, שום דבר לא עובר.
• ▸בניית כללים לפי פורטים במקום App-ID — עובד, אבל מוותר על כל הערך של ה-NGFW.
• ▸שכחת Commit — "עשיתי בדיוק מה שאמרת ולא עובד". תסתכלו על סימן השינויים בפינה.
• ▸Security Policy ל-Destination NAT עם ה-Zone הלא נכון — זוכרים: Zone אחרי תרגום, כתובת לפני תרגום.
• ▸כללים בלי Logging — ואז אבחון תקלה הופך לניחוש. תמיד Log at Session End.

מה הלאה

אם הגעתם עד כאן והבנתם את הזרימה — ממשק, Zone, ראוט, NAT, Policy, Commit, Log — יש לכם את הבסיס שעליו נשען כל השאר. משם הדרך ל-App-ID מתקדם, User-ID, Threat Prevention, WildFire, URL Filtering, VPN אתר-לאתר ו-GlobalProtect היא הרבה יותר קצרה ממה שנדמה. בקורס Palo Alto של מכללת נטמי עוברים על כל זה בכ-61 שיעורים עם מעבדות Hands-On, בעברית, בקצב של מי שעובד בשטח.