שאלת ראיון: מה זה SP3 של Palo Alto ובמה הוא שונה מפיירוול מסורתי?

אתם בראיון לתפקיד מהנדס אבטחת רשתות או אינטגרטור Firewall. סיפרתם על NAT, על Security Policy, אולי אפילו על VPN. ואז המראיין נשען אחורה ושואל: ״תסביר לי מה זה SP3 של Palo Alto. ובמה זה שונה מפיירוול Stateful רגיל או מ־UTM, מבחינת ה־Packet Flow?״

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

רגע לפני SP3: Stateless מול Stateful

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

• ▸Stateless Firewall (Packet Filter): בודק כל חבילה לבד, בלי זיכרון. Source IP, Destination IP, פרוטוקול ופורט. הוא לא יודע אם החבילה הזו היא תשובה לבקשה שיצאה מבפנים או ניסיון חדירה. לכן צריך לפתוח חוקים לשני הכיוונים, ולפעמים לפתוח טווחי פורטים שלמים. מהיר וזול, אבל עיוור. ACL על Cisco הוא הדוגמה הקלאסית.
• ▸Stateful Firewall: מחזיק Session Table. כשחבילת SYN יוצאת מבפנים, הוא רושם את ה־Session, וחבילות התשובה מתקבלות אוטומטית כי הן שייכות ל־Session קיים. הוא מכיר את מצבי TCP, מזהה חבילה שלא מתאימה ל־Session ומפיל אותה. זו הייתה המהפכה של שנות התשעים, ו־Check Point עם Stateful Inspection היו מהחלוצים בה.
• ▸המגבלה של Stateful: הוא עדיין חושב בפורטים. בשבילו פורט 443 זה HTTPS וזהו. אם מישהו מריץ BitTorrent, Tunnel או תוכנת שליטה מרחוק על פורט 443, הפיירוול הקלאסי לא מבחין בהבדל.

UTM: כשהוסיפו עוד ועוד מנועים

בשנות האלפיים האיומים זזו לשכבת האפליקציה, והיצרנים הגיבו בדרך הכי טבעית: הוסיפו לפיירוול עוד מנועים. IPS, Antivirus, URL Filtering, Anti-Spam. ככה נולד ה־UTM, Unified Threat Management. קופסה אחת שעושה הכול.

הבעיה הייתה באיך זה נבנה. ברוב ה־UTM המסורתיים כל מנוע הוא מודול נפרד, לפעמים ממש תוכנה של ספק אחר. החבילה נכנסת, הפיירוול בודק Policy, אחר כך היא נשלחת למנוע ה־IPS שמפרק אותה ובודק, אחר כך ל־Antivirus שמרכיב את הקובץ מחדש ובודק שוב, אחר כך ל־URL Filtering. כל שלב משלם מחדש על אותה עבודה: פענוח, Reassembly, ניתוח פרוטוקול.

Packet In
  -> Firewall (Stateful, ports)
  -> IPS engine        (parse again)
  -> Antivirus engine  (reassemble again)
  -> URL Filtering     (parse again)
  -> Anti-Spyware      (scan again)
Packet Out

# כל מנוע = עוד מעבר, עוד Latency, עוד CPU

מי שעבד עם UTM ישן מכיר את התופעה: בדף המוצר כתוב 10Gbps, אבל ברגע שמדליקים IPS ו־Antivirus המספר יורד לחלק קטן מזה. זו לא אגדה, זו תוצאה ישירה של עיבוד טורי.

אז מה עושה SP3? שני חצאים של אותו רעיון

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

Single-Pass: התוכנה מסתכלת על החבילה פעם אחת

• ▸פעולות הרשת נעשות פעם אחת לכל חבילה: Session Lookup, ניתוח פרוטוקול, Decoding ו־NAT. אין חזרה על אותה עבודה בכל מנוע.
• ▸App-ID מזהה מה האפליקציה באמת, בלי קשר לפורט: חתימות, Decoders של פרוטוקולים, ניתוח התנהגות. Facebook על 443, SSH על 443, או סתם HTTPS.
• ▸User-ID מקשר את התעבורה למשתמש ולקבוצה ב־Active Directory, כך שה־Policy נכתב לפי ״מחלקת כספים״ ולא לפי טווח כתובות IP.
• ▸Content-ID סורק את התוכן עם מנוע חתימות אחיד אחד לווירוסים, Spyware, פרצות (Vulnerabilities) ו־URL Filtering. לא ארבעה מנועים נפרדים, אלא פורמט חתימות אחד שנבדק בסריקה אחת.
• ▸הסריקה היא Stream-Based ולא File-Based. לא מחכים שכל הקובץ יגיע לזיכרון כדי לסרוק אותו, אלא סורקים תוך כדי שהזרם עובר. זה חוסך זיכרון ומוריד Latency.

Parallel Processing: החומרה עובדת במקביל

• ▸Control Plane: מעבד, זיכרון ודיסק נפרדים לניהול: ממשק Web, CLI, Logging, Routing Protocols, עדכוני חתימות ו־User-ID. גם אם מישהו מעמיס על הניהול, התעבורה לא נפגעת.
• ▸Data Plane: החומרה שמטפלת בתעבורה עצמה. בדגמים הפיזיים יש בה רכיבים ייעודיים: מעבד רשת שמטפל ב־Routing, NAT ו־Session Setup, מעבדי אבטחה ל־Decryption ולמשימות כבדות, ומנוע ייעודי להתאמת חתימות.
• ▸הרכיבים האלה רצים במקביל, כל אחד במה שהוא טוב בו, במקום שמעבד כללי אחד יעשה הכול לבד.
• ▸בפיירוולים וירטואליים מסדרת VM-Series אין את רכיבי החומרה האלה. ה־Single-Pass בתוכנה עדיין קיים, אבל ה־Parallel Processing מבוסס על ליבות CPU. שווה להזכיר את זה בראיון, זה מראה דיוק.

Packet In
  -> Ingress + Session Lookup (Fast Path / Slow Path)
  -> Single-Pass:
       App-ID  | User-ID  | Content-ID
       (one parse, one unified signature scan)
  -> Security Policy + NAT + Forwarding
Packet Out

# Control Plane נפרד: ניהול, לוגים, עדכונים

רגע, ואיך נראה ה־Packet Flow בפועל?

אם המראיין טכני במיוחד, הוא עלול להמשיך: ״ספר לי מה קורה לחבילה הראשונה של Session לעומת חבילה שלישית.״ כאן נכנסים Slow Path ו־Fast Path.

• ▸חבילה ראשונה (Slow Path): אין Session בטבלה. הפיירוול מזהה Zones לפי Routing, בודק NAT Policy לצורך זיהוי ה־Destination Zone, בודק Security Policy ראשונית ויוצר Session חדש בטבלה.
• ▸חבילות המשך (Fast Path): ה־Session כבר קיים. החבילה מזוהה מיד ועוברת לבדיקת App-ID ו־Content-ID בלי לחזור על כל תהליך ההקמה.
• ▸שינוי אפליקציה תוך כדי: ב־Session אחד App-ID יכול להתחיל כ־SSL, להתעדכן ל־web-browsing ובסוף ל־facebook-base. בכל שינוי ה־Security Policy נבדקת מחדש על האפליקציה המדויקת.
• ▸תוצאה: אותה חבילה עוברת זיהוי אפליקציה, משתמש ואיומים בלי לקפוץ בין מנועים נפרדים.

show session all filter application ssl
show session id <session-id>
show counter global filter delta yes packet-filter yes
show running resource-monitor

# Packet Capture לפי שלבים: receive / firewall / transmit / drop
debug dataplane packet-diag set filter on

טבלת השוואה מהירה

• ▸Stateless: בודק כל חבילה לבד לפי IP ופורט. אין Session Table, אין הבנה של אפליקציה. מהיר מאוד ועיוור לחלוטין.
• ▸Stateful: Session Table ומצבי TCP. מבין ״מי פתח את השיחה״, אבל עדיין מזהה אפליקציה לפי פורט.
• ▸UTM מסורתי: Stateful ועוד מנועים נפרדים, IPS, AV, URL. עיבוד טורי, כל מנוע בודק מחדש, ירידה חדה בביצועים כשמדליקים הגנות.
• ▸Palo Alto SP3: App-ID, User-ID ו־Content-ID במעבר תוכנה אחד, עם חומרה ייעודית שעובדת במקביל והפרדה מלאה בין Control Plane ל־Data Plane.

שאלות המשך שכדאי להיות מוכנים אליהן

• ▸מה ההבדל בין Control Plane ל־Data Plane? Control Plane מנהל: GUI, לוגים, Routing ועדכונים. Data Plane מעביר ובודק תעבורה. ההפרדה מבטיחה שעומס ניהולי לא יפיל תעבורה.
• ▸מה זה App-ID ולמה זה עדיף על פורטים? App-ID מזהה את האפליקציה עצמה גם על פורט לא סטנדרטי, כך שה־Policy נכתב על ״ssh״ ולא על ״tcp/22״.
• ▸מה זה Application Default ב־Service? מאפשר לאפליקציה לעבוד רק על הפורטים הסטנדרטיים שלה, וחוסם ניסיון להריץ אותה על פורט אחר.
• ▸האם SP3 בודק תעבורה מוצפנת? רק אם מגדירים SSL Decryption. בלי פענוח, App-ID מזהה חלקית לפי ה־Handshake וה־SNI, ו־Content-ID לא רואה את התוכן.
• ▸מה ההבדל בין Stateful Inspection ל־Deep Packet Inspection? Stateful בודק Headers ומצב Session. DPI פותח את ה־Payload ומבין את התוכן והאפליקציה.