Qual é a diferença entre firewall stateful e stateless?

Um firewall stateless avalia cada pacote de forma isolada, sem memória de conexões anteriores, aplicando regras com base exclusivamente em cabeçalhos (IP, porta, protocolo). Já o firewall stateful mantém uma tabela de estados de conexão (connection tracking table) e permite ou bloqueia pacotes com base no contexto da sessão estabelecida, o que reduz drasticamente falsos positivos e dificulta ataques de spoofing e session hijacking. Para a maioria dos ambientes corporativos, o stateful é o mínimo recomendado (NIST SP 800-41r1).

O que é a política default-deny e por que ela é obrigatória?

A política default-deny (ou 'implicit deny all') significa que qualquer tráfego não explicitamente permitido por uma regra é bloqueado. É o oposto do default-permit, onde tudo que não é proibido passa. O CIS Benchmark para firewalls exige default-deny como requisito fundamental: ela minimiza a superfície de ataque, força a revisão consciente de cada fluxo liberado e garante que novas portas ou serviços não fiquem expostos acidentalmente quando um servidor é provisionado. Sempre inclua a regra 'deny all / log' como última entrada no ruleset.

Como definir a ordem correta das regras de firewall?

Firewalls processam regras na ordem sequencial e param na primeira que corresponder ao pacote (first-match). A ordem recomendada é: (1) permitir tráfego de gerenciamento (SSH/HTTPS restrito a IPs administrativos), (2) permitir tráfego de retorno de conexões estabelecidas (estado ESTABLISHED/RELATED), (3) regras específicas de serviços permitidos (menor escopo possível), (4) regras de bloqueio explícito de fontes conhecidamente maliciosas, (5) regra final deny-all com log. Regras muito genéricas no topo mascaram regras específicas abaixo — use 'shadowing analysis' para detectar isso.

O que é um NGFW e quando ele é necessário?

Next-Generation Firewall (NGFW) é um firewall que, além de filtragem de pacotes e inspeção stateful, inclui DPI (Deep Packet Inspection), identificação de aplicação independente de porta (App-ID), prevenção de intrusão (IPS) embutida, inspeção de TLS/SSL, filtro de URL por categoria e integração com feeds de threat intelligence. É necessário em ambientes que precisam controlar aplicações SaaS (ex.: bloquear upload no Dropbox mas permitir download), inspecionar tráfego criptografado ou aplicar políticas baseadas em usuário/grupo (LDAP/AD). Exemplos de soluções NGFW: Palo Alto, Fortinet, Check Point, Cisco Firepower.

Como configurar firewall em ambientes de nuvem (AWS, Azure, GCP)?

Em nuvem pública, o controle de rede é feito em múltiplas camadas: (1) Security Groups (AWS/GCP) ou Network Security Groups (Azure) — stateful, operam no nível de interface de rede da instância; (2) Network ACLs (AWS) ou regras de firewall de VPC (GCP) — stateless, operam no nível de sub-rede; (3) Web Application Firewall (WAF) para tráfego HTTP/S; (4) firewall virtual de terceiros para inspeção centralizada de tráfego leste-oeste (inter-VPC). A regra de ouro: security groups com menor privilégio (0.0.0.0/0 apenas para portas 80/443 voltadas ao público), NACL como segunda camada de defesa, e logs de VPC Flow habilitados obrigatoriamente.

Quais são os erros mais comuns na configuração de firewall?

Os erros mais frequentes documentados em auditorias incluem: (1) regras 'any/any' sem justificativa — liberam todo tráfego entre zonas; (2) ausência de egress filtering — permite que malware estabeleça canais de comando e controle; (3) regras fantasma (shadow rules) — nunca matchadas porque sobrepostas por regras anteriores; (4) bases de regras com centenas de entradas sem revisão periódica (firewall rule bloat); (5) portas administrativas (22, 3389, 8443) acessíveis da internet sem MFA; (6) logging desabilitado ou sem retenção adequada; (7) zonas DMZ e produção na mesma sub-rede lógica. O CIS Benchmark recomenda revisão semestral do ruleset.

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

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

תצורת חומת אש

תצורה אפקטיבית של חומת אש היא יסוד קריטי בהגנה ההיקפית ברשתות ארגוניות, ומשמשת כשומר סף השולט בכל התעבורה הנכנסת והיוצאת מהתשתית בהתבסס על מדיניות אבטחה מוגדרת מראש - יישום לקוי, בין אם באמצעות כללים מתירניים מדי החושפים שירותים פנימיים שלא לצורך, ובין אם באמצעות רישום לוגים בלתי מספק המונע זיהוי תקיפות, יוצר פגיעויות משמעותיות שתוקפים יכולים לנצל לסיור ברשת, לתנועה רוחבית לאחר פריצה ראשונית, לחילוץ נתונים דרך פורטים בלתי צפויים, ולעקיפת בקרות אבטחה באמצעות שימוש זדוני בפרוטוקולים מותרים. חומות אש מודרניות התפתחו ממסנני מנות פשוטים מבוססי IP/פורט (stateless, שבדקו כל מנה בנפרד ללא הקשר של session) לחומות אש מסוג stateful העוקבות אחר חיבורי TCP מלאים ומבינות handshakes ומצבים, וכיום ל-Next-Generation Firewalls (NGFWs) המשלבות IPS (Intrusion Prevention System) לזיהוי חתימות של תקיפות, application awareness המזהה יישומים ללא תלות בפורט שבו נעשה שימוש (מזהה Skype הרץ על פורט 443 בתחפושת של HTTPS), בדיקת SSL/TLS המפענחת תעבורה מוצפנת לבדיקת ה-payload, ו-threat intelligence feeds החוסמים אוטומטית כתובות IP/דומיינים זדוניים מוכרים. תצורה איתנה פועלת לפי עקרון deny-by-default (default deny) שבו כל התעבורה נחסמת למעט זו המותרת במפורש, מיישמת defense-in-depth עם שכבות מרובות (חומת אש היקפית + חומות אש לסגמנטציה פנימית + חומות אש מבוססות host), משתמשת באזורי אבטחה עם רמות אמון שונות (אינטרנט בלתי מהימן, DMZ עם שרתים ציבוריים, רשת פנימית, רשת ניהול), מאפשרת רישום לוגים מפורט של חיבורים שאושרו ונדחו לצורך ביקורת ו-threat hunting, ומקיימת סקירות תקופתיות של כללים להסרת הרשאות מיושנות המצטברות לאורך זמן ויוצרות משטח תקיפה מיותר.

עקרון Deny-by-Default והרשאות מינימליות

Deny-by-default היא פילוסופיה יסודית בתצורת חומת אש שבה מדיניות ברירת המחדל היא לדחות את כל התעבורה, ועל המנהל ליצור כללים מפורשים המתירים רק את הזרימות הנחוצות לפעילות העסקית - הדבר הופך את המודל הלא מאובטח של "להתיר הכול ולחסום את הרע" (בלתי אפשרי לתחזוקה משום שתקיפות מתפתחות כל הזמן) ל"לחסום הכול ולהתיר את הנחוץ" (בר-קיימא משום שדרישות העסק משתנות בתדירות נמוכה יותר). בפועל, הכלל האחרון ב-ruleset של חומת האש צריך להיות implicit deny המסלק כל תעבורה שלא הותאמה לכללים קודמים, ולכלל דחייה זה צריך להיות מופעל רישום לוגים לצורך נראות של ניסיונות חסומים העשויים להעיד על סריקה, תצורה שגויה או תקיפות ממוקדות. הרשאות מינימליות ביישום על חומת אש פירושן להתיר רק את הפרוטוקול והפורטים הספציפיים הנחוצים במקום טווחים רחבים - אם יישום אינטרנט זקוק רק ל-HTTPS, התירו TCP 443 במקום פרוטוקול "any"; אם נדרשת גישת ניהול ב-SSH, התירו רק מ-subnet ניהול ספציפי במקום 0.0.0.0/0. הימנעו מכללי "any any permit", המהווים נורות אדומות בביקורות - לכל הרשאה צריכה להיות הצדקה עסקית מתועדת עם owner אחראי ותאריך סקירה. יישמו תהליך change management שבו הוספת כללים מחייבת אישור, היא זמנית כברירת מחדל עם תאריכי תפוגה, ונסקרת אחת לרבעון לאישור הצורך המתמשך - כללים ללא hits במשך 90 ימים הם מועמדים להסרה.

סגמנטציה של רשת ואזורי אבטחה

סגמנטציה של רשת מחלקת את התשתית לאזורים מבודדים עם רמות אמון שונות ובקרות אבטחה מתאימות, תוך שימוש בחומות אש (פיזיות או וירטואליות) לאכיפת מדיניות בין אזורים - הדבר מגביל את ה-blast radius של פריצה משום שתוקף המשיג גישה לאזור אחד אינו ניגש אוטומטית לאחרים, מאלץ את התנועה הרוחבית לעבור דרך chokepoints מנוטרים, ומאפשר יישום הגנות מחמירות יותר באזורים הקריטיים יותר. ארכיטקטורה טיפוסית כוללת: Untrusted Zone (Internet) מחוץ לשליטת הארגון עם zero trust, DMZ (Demilitarized Zone) המכילה שרתים ציבוריים (web servers, mail relays, DNS אוטוריטטיבי) הנגישים מהאינטרנט אך מבודדים מהרשת הפנימית, Internal Zone הרשת הארגונית עם workstations ויישומים business-critical, Management Zone לתשתית ניהול (jump hosts, configuration management, backup servers) עם גישה מוגבלת מאוד, Data Zone ל-database servers ו-file servers עם נתונים רגישים, ו-Guest WiFi Zone מבודדת לחלוטין ללא גישה למשאבים פנימיים. חומות אש בין אזורים מיישמות מדיניות ספציפית: תעבורה מהאינטרנט אל ה-DMZ מתירה רק פורטים ציבוריים ספציפיים (80, 443) המיועדים ל-load balancers/proxies, תעבורה מה-DMZ אל Internal צריכה להיות ממוזערת (באופן אידיאלי אפס, או רק חיבורי בסיס נתונים מ-app servers אל DB servers ב-Data Zone), תעבורה מ-Internal אל האינטרנט עוברת דרך proxy עם content filtering ובדיקת SSL, וגישה ל-Management Zone מחייבת MFA ומקורה רק מ-workstations ניהול ספציפיים. השתמשו ב-VLANs לסגמנטציה לוגית ובחומות אש וירטואליות (VM-series, virtual appliances) למיקרו-סגמנטציה בתוך אזורים.

רישום לוגים, ניטור וניתוח תעבורה

רישום לוגים איתן של פעילות חומת האש חיוני לזיהוי תקיפות, לפתרון תקלות קישוריות, לעמידה בתקנות (PCI-DSS, LGPD מחייבים audit trails) ולחקירה פורנזית לאחר אירוע - חומות אש צריכות לרשום בלוג לא רק תעבורה חסומה (denied connections חושפים סריקה וניסיונות exploit) אלא גם תעבורה מותרת (accepted connections נחוצים ליצירת baseline של התנהגות נורמלית ולזיהוי חריגות, כגון עלייה פתאומית בחיבורים יוצאים אל כתובות IP חיצוניות חשודות המעידה על חילוץ נתונים). מידע קריטי בלוגים: source IP/פורט, destination IP/פורט, פרוטוקול, פעולה (allow/deny), מספר הכלל שהותאם, timestamp מדויק, בתים שהועברו (נפח חריג עשוי להעיד על גניבת נתונים) ומשך ה-session. שלחו לוגים של חומת האש ל-SIEM מרכזי (Splunk, QRadar, ELK stack) לצורך correlation עם אירועים ממקורות אחרים (EDR, web proxy, authentication logs) ושמירה לטווח ארוך החורגת מקיבולת האחסון המקומית של חומת האש. הגדירו alerting לדפוסים חשודים: ריבוי denied connections מאותו source (port scanning), חיבורים מותרים אל כתובות IP ב-threat intelligence blacklists (command and control callbacks), תעבורה המשתמשת בפרוטוקולים בלתי צפויים (תעבורת בסיס נתונים היוצאת אל האינטרנט), והפרות של מדיניות geo-IP (חיבורים ממדינות שבהן אין לנו פעילות). dashboards צריכים להציג: top talkers (כתובות IP המייצרות הכי הרבה תעבורה), מגמות של denied connections, ניצול רוחב פס לפי יישום, ו-rule hit counts (כללים שמעולם לא הותאמו ניתנים להסרה). שקלו flow analysis (NetFlow, sFlow) לנראות של דפוסי תעבורה ללא full packet capture - הוא מזהה חריגות בהתבסס על נפח, כיוון ו-timing של ה-flows.

Next-Generation Firewalls (NGFW) ויכולות מתקדמות

Next-Generation Firewalls חורגות מ-traditional stateful firewalls בכך שהן מוסיפות יכולות בדיקה מעמיקה של יישומים ושילוב עם threat intelligence - מבדל מרכזי הוא application awareness המזהה יישומים ללא תלות בפורט או בפרוטוקול שבו נעשה שימוש (מזהה BitTorrent הרץ על פורט 443, Tor hidden services, שימוש ב-VPNs לעקיפת מדיניות, ו-tunneling של פרוטוקולים אסורים בתוך HTTP/HTTPS), ומאפשר מדיניות מפורטת כגון "להתיר Slack אך לחסום העברת קבצים ב-Slack" או "להתיר YouTube אך להגביל ל-720p לחיסכון ברוחב פס". Intrusion Prevention System (IPS) משולב בודק את ה-payload של מנות בחיפוש אחר חתימות של exploits מוכרים (buffer overflows, דפוסי SQL injection, command injection) וחוסם אותם אוטומטית - עדכון מתמיד של ה-signature database הוא קריטי משום שפגיעויות חדשות מתגלות מדי יום. SSL/TLS Inspection (הנקראת גם SSL decryption או בדיקת man-in-the-middle) מיירטת חיבורי HTTPS, מפענחת אותם באמצעות dynamic certificate generation, בודקת את ה-payload לאיתור malware ולצורך data loss prevention, ומצפינה מחדש לפני השליחה אל היעד - נחוצה משום שרוב ה-malware delivery ותקשורת ה-C2 כיום משתמשים בהצפנה כדי להתחמק מזיהוי, אך היא מחייבת deployment של enterprise root CA במכשירי הקצה והחרגה זהירה של אתרים רגישים (בריאות, בנקאות) לשם פרטיות. Sandboxing שולח קבצים חשודים (executables, PDFs, מסמכי Office) שהתקבלו דרך אינטרנט או דוא"ל לניתוח בסביבה וירטואלית מבודדת, תוך התבוננות בהתנהגות (registry modifications, network connections, file creation) לזיהוי malware מסוג zero-day שאין לו חתימה מוכרת. URL Filtering חוסם גישה לקטגוריות של אתרים (gambling, תוכן למבוגרים, אתרי malware/phishing באמצעות reputation databases) ו-DNS Security מונע שאילתות לדומיינים זדוניים מוכרים ומזהה DGA (Domain Generation Algorithms) שבהם משתמשות botnets לאיתור שרתי C2.

סקירה ותחזוקה של כללים

rulesets של חומת אש מתדרדרים לאורך זמן אם אינם מתוחזקים באופן פעיל - כללים מתווספים לפרויקטים זמניים ואינם מוסרים לעולם, הרשאות רחבות מדי נוצרות מתוך דחיפות ואינן מעודנות בהמשך, ושינויים בתשתית (שרתים שהוצאו משירות, מעברים לענן) מותירים כללים מיושנים היוצרים בלבול ו-security gaps פוטנציאליים. יישמו תהליך פורמלי של firewall rule lifecycle management: כל כלל חדש צריך לכלול owner (האדם האחראי), business justification (כרטיס או אישור), expiration date (90 ימים כברירת מחדל לכללים זמניים) ו-review date (שנתי לכל הפחות). השתמשו ב-rule hit counters לזיהוי כללים שאינם בשימוש - כללים ללא hits במשך 6 חודשים הם מועמדים להסרה לאחר אימות מול ה-owner. מעת לעת (אחת לרבעון), ייצאו את ה-ruleset המלא ובצעו סקירה שורה-אחר-שורה תוך שאלה: האם כלל זה עדיין נחוץ? האם ה-source/destination נכונים ומינימליים? האם הפרוטוקול/פורט יכולים להיות ספציפיים יותר? האם קיימת חפיפה עם כללים אחרים היוצרת shadow rules? האם סדר הכללים מיטבי (הכללים המותאמים בתדירות הגבוהה ביותר בראש, לצורך ביצועים)? תעדו את הנימוק של כל כלל בהערות בתוך התצורה - שנים לאחר מכן, כשהתצורה המקורית נשכחת, ההערות מסבירות את הכוונה ומקלות על שינוי בטוח. עבור חומות אש מורכבות עם מאות או אלפי כללים, השתמשו ב-firewall management tools (Tufin, AlgoSec, Firemon) המבצעים אוטומציה לסקירת כללים, מזהים התנגשויות, ומדמים את השפעת השינויים לפני ה-deployment. שמרו backups של התצורה עם בקרת גרסאות (Git) המאפשרת rollback אם שינוי גורם להשפעה בלתי מכוונת, ובדקו שינויים בסביבת מעבדה המשכפלת את טופולוגיית הייצור לפני יישומם בייצור.