امنیت فایروال‌ها

امنیت فایروال‌ها در معماری‌های مدرن شبکه و امنیت اطلاعات
بررسی معماری، فناوری‌های نوین، تهدیدها، روش‌های امن‌سازی و نمونه‌های عملی در فایروال‌های نسل جدید

چکیده
فایروال یکی از بنیادی‌ترین مؤلفه‌های معماری امنیت شبکه است، اما در معماری‌های مدرن، مفهوم فایروال دیگر به یک سامانه ساده برای فیلترکردن بسته‌ها بر اساس آدرس IP و شماره پورت محدود نمی‌شود. ظهور رایانش ابری، سرویس‌های توزیع‌شده، APIها، کاربران راه‌دور، SaaS(Software As a Service)، رمزنگاری گسترده ترافیک، HTTP/3، (Quick UDP Internet Connections)QUIC، معماری Zero Trust و حملات زنجیره‌ای باعث شده است که فایروال از یک کنترل امنیتی در مرز شبکه به یک موتور اعمال سیاست، تحلیل ترافیک، کنترل هویت و اجرای بخشی از معماری دفاعی سازمان تبدیل شود.
فایروال‌های نسل جدید (Next-Generation Firewalls یا NGFW) با ترکیب Stateful Inspection، کنترل برنامه‌ها، تشخیص هویت کاربر، IPS(Intrusion Prevention System)، فیلتر URL(Uniform Resource Locator)، تحلیل بدافزار، DNS(Domain Name System)، (Transport Layer Security)TLS، کنترل فایل و در برخی محصولات قابلیت‌های مرتبط با (Data Loss Prevention)DLP ، (Cloud Access Security Broker)CASB تلاش می‌کنند تصمیم امنیتی را بر اساس مجموعه‌ای از ویژگی‌های چندلایه اتخاذ کنند.
با این حال، افزایش قابلیت‌های فایروال به معنای حذف ریسک نیست. خود فایروال یک نرم‌افزار، سیستم‌عامل، صفحه مدیریت، API، موتور تحلیل پروتکل و گاهی یک نقطه تمرکز بسیار حساس در معماری سازمان است و بنابراین می‌تواند هدف حمله قرار گیرد. نمونه‌های منتشرشده در سال‌های ۲۰۲۵ و ۲۰۲۶ علیه محصولات امنیتی نشان می‌دهد که آسیب‌پذیری در رابط مدیریت، VPN، Web Proxy یا موتور پردازش بسته‌ها می‌تواند مستقیماً بر دسترس‌پذیری یا محرمانگی زیرساخت امنیتی اثر بگذارد.

این مقاله مفهوم امنیت فایروال را از دو زاویه بررسی می‌کند:

نخست؛ فایروال چگونه از سازمان محافظت می‌کند؟
و دوم، چگونه باید خود فایروال را در برابر حمله محافظت کرد؟

۱. مقدمه
در معماری سنتی شبکه، فایروال معمولاً در مرز میان شبکه داخلی و اینترنت قرار می‌گرفت:

Internet → Firewall → Internal Network

فرض اساسی این مدل آن بود که شبکه داخلی قابل اعتماد و شبکه خارجی غیرقابل اعتماد است. این مدل در معماری‌های امروزی دیگر کافی نیست.
یک سازمان متوسط ممکن است هم‌زمان دارای موارد زیر باشد:
* کاربران داخل سازمان
* کاربران دورکار
* لپ‌تاپ‌ها و تجهیزات شخصی
* سرویس‌های On-Premises
* ماشین‌های مجازی
* Kubernetes و Containerها
* سرویس‌های SaaS
* چند Cloud Provider
* APIهای عمومی
* سرویس‌های اینترنتی
* تجهیزات IoT
* شعب متعدد
* ارتباطات VPN
* سرویس‌های Third-Party
در چنین محیطی، دیگر یک «مرز شبکه‌ای» واحد وجود ندارد.

NIST در معماری Zero Trust صراحتاً بر همین تغییر پارادایم تأکید می‌کند: محل قرارگیری یک کاربر یا تجهیزات در شبکه نباید به‌تنهایی مبنای اعتماد باشد و تمرکز امنیت باید از «شبکه» به سمت «کاربر، دستگاه، سرویس و منبع» حرکت کند.

بنابراین اکنون سؤال این نیست که: «آیا این Packet از داخل شبکه آمده است؟»
بلکه سؤال امنیتی باید چیزی شبیه این باشد:
«چه کسی، با چه دستگاهی، برای دسترسی به کدام سرویس، با چه سطحی از ریسک، در چه شرایطی و با چه پروتکلی در حال برقراری ارتباط است؟»
این تغییر، اساس تحول فایروال‌های مدرن را تشکیل می‌دهد.

۲. فایروال دقیقاً چیست؟
فایروال را می‌توان یک Security Enforcement Point دانست که جریان ارتباطی میان دو یا چند ناحیه امنیتی را بر اساس مجموعه‌ای از سیاست‌ها کنترل می‌کند.
یک مدل ساده برای تصمیم‌گیری فایروال را می‌توان چنین نمایش داد:

Decision = f(Src, Dst, Protocol, Port, State, Application, User, Identity, Content, Risk)

در فایروال‌های سنتی، تابع تصمیم ممکن است عمدتاً به موارد زیر وابسته باشد:

* Source IP
* Destination IP
* Source Port
* Destination Port
* Protocol

اما در NGFWها متغیرهای بسیار بیشتری وارد تصمیم‌گیری می‌شوند:

* Application
* User
* Device
* URL
* Threat Intelligence
* File Type
* TLS Characteristics
* Security Zone
* Reputation
* IPS Signature
* Malware Detection
* Authentication Context

در نتیجه، یک Policy مدرن می‌تواند به جای «IP A اجازه دسترسی به TCP/443 را دارد»؛ به چیزی مانند این تبدیل شود:
«گروه Finance فقط از دستگاه‌های مدیریت‌شده، در ساعات کاری، به Application مشخص‌شده روی Server خاص دسترسی داشته باشد؛ ترافیک نیز تحت IPS و کنترل فایل قرار گیرد.»
این تفاوت از نظر امنیتی بسیار مهم است.

۳. تکامل فناوری فایروال
Stateless Packet Filtering
نسل ابتدایی فایروال‌ها بر اساس Headerهای بسته تصمیم می‌گرفتند.

برای مثال:

Source: 10.10.10.0/24
Destination: 172.16.20.10
Protocol: TCP
Destination Port: 443
Action: ALLOW

مزیت:
* سریع
* ساده
* قابل پیش‌بینی

ضعف:
* درک محدودی از ارتباط
* عدم درک مناسب از وضعیت Session
* عدم شناخت Application
* امکان سوءاستفاده از پروتکل‌ها و Portها

۴. Stateful Firewall
فایروال Stateful مفهوم Session را وارد تصمیم‌گیری کرد. فرض کنید کلاینت داخلی ارتباط زیر را آغاز کند:

10.10.10.25:53000
↓
Internet Server:443

فایروال State مربوط به Connection را ثبت می‌کند. برای نمونه:

TCP
SRC = 10.10.10.25:53000
DST = 203.0.113.20:443
STATE = ESTABLISHED

در نتیجه پاسخ برگشتی می‌تواند بر اساس State موجود مجاز شود، بدون اینکه لازم باشد یک Rule مستقل برای Reverse Traffic ایجاد شود. Stateful Inspection یکی از پایه‌های اصلی فایروال‌های مدرن باقی مانده است.

۵. Application-Aware Firewall و NGFW(Next-Generation Firewall)
مشکل مهم Port-based Firewall این است که Port الزاماً بیانگر Application واقعی نیست. مثلاً:

TCP/443 = HTTPS

اما این مورد به‌تنهایی نمی‌گوید چه Application یا چه فعالیتی داخل این Connection انجام می‌شود.

یک Application می‌تواند:
* روی Port غیرمعمول اجرا شود؛
* از HTTPS استفاده کند؛
* از TLS استفاده کند؛
* ترافیک را در CDN عبور دهد؛
* یا از تکنیک‌های مختلف برای مخفی‌سازی ارتباط استفاده کند.

به همین دلیل NGFWها به سمت Application Identification حرکت کرده‌اند.
برای مثال، مستندات FortiGate توضیح می‌دهد که Application Control می‌تواند Applicationها را حتی در شرایطی که از Portهای غیر استاندارد استفاده می‌کنند شناسایی کند و این قابلیت از طریق موتورهای تحلیل پروتکل/IPS پیاده‌سازی می‌شود.
در محصولات Palo Alto نیز Security Policy می‌تواند بر اساس عواملی مانند Zone، IP، Application، User و Service تصمیم‌گیری کند.

بنابراین:

ALLOW TCP/443

این امر از لحاظ امنیتی بسیار متفاوت است با:

ALLOW Application = Approved-Business-App
USER = Finance
SOURCE = Managed-Device
DESTINATION = Approved-Service

۶. Deep Packet Inspection
یکی از قابلیت‌های مهم NGFW، تحلیل عمیق ترافیک است. در DPI، فایروال فقط Header را بررسی نمی‌کند؛ بلکه در صورت امکان بخش‌هایی از Payload و ساختار پروتکل را نیز تحلیل می‌کند.

این قابلیت می‌تواند برای شناسایی مواردی مانند:

* Exploit
* Malware
* Command & Control
* Protocol Anomaly
* فایل مخرب
* رفتار غیرعادی
* حملات Application Layer

استفاده شود.

اما یک مشکل بنیادین وجود دارد آن هم Encryption است. اگر Payload رمز شده باشد، فایروال نمی‌تواند محتوای آن را بدون سازوکار مناسب مشاهده کند. اینجاست که TLS Inspection اهمیت پیدا می‌کند.

۷. TLS Inspection؛ یکی از مهم‌ترین چالش‌های امنیت فایروال
امروزه بخش بزرگی از ترافیک اینترنت رمزنگاری شده است. این موضوع برای امنیت ارتباطات بسیار مثبت است، اما برای تجهیزات امنیت شبکه یک چالش ایجاد می‌کند:

Client
|
| TLS Encrypted Traffic
|
Firewall
|
| ؟
|
Internet

اگر Firewall یک Payload را نبیند، بسیاری از قابلیت‌های زیر محدود می‌شوند:

* Malware Inspection
* File Inspection
* IPS
* DLP
* Application Visibility
* Content Filtering

راهکار کلاسیک TLS Decryption / SSL Inspection است. فایروال در مسیر ارتباط قرار می‌گیرد، ترافیک را رمزگشایی و بررسی می‌کند و سپس آن را دوباره رمزگذاری می‌کند.

مدل مفهومی:

Client
|
| TLS
↓
Firewall
|
| Decrypt
↓
Security Inspection
|
| Re-encrypt
↓
Internet Server

FortiGate در نسخه‌های جدید FortiOS قابلیت‌هایی مانند Certificate Inspection و Deep Inspection را ارائه می‌کند. Deep Inspection امکان بازرسی محتوای رمزنگاری‌شده را برای قابلیت‌هایی مانند Antivirus، Web Filtering و Email Filtering فراهم می‌کند.

Cisco Secure Firewall نیز برای ترافیک رمزنگاری‌شده از Decryption Policy استفاده می‌کند تا قابلیت‌هایی مانند IPS و تشخیص فایل و Malware بتوانند روی ترافیک رمزگشایی‌شده اعمال شوند.

اما TLS Inspection بدون هزینه نیست.

۸. هزینه امنیتی TLS Decryption
فعال‌کردن Decryption می‌تواند:
* مصرف CPU را افزایش دهد؛
* Throughput را کاهش دهد؛
* Latency ایجاد کند؛
* مشکلات Certificate ایجاد کند؛
* با Certificate Pinning تداخل داشته باشد؛
* مشکلات Privacy و Compliance ایجاد کند.
Cisco در مستندات خود تصریح می‌کند که Decryption از نظر منابع پرهزینه است و Certificate Pinning می‌تواند برخی Applicationها را از Decryption خارج کند.

بنابراین معماری حرفه‌ای نباید چنین رویکردی داشته باشد که «همه TLSها را بدون استثناء Decrypt کن». بلکه باید Selective Decryption انجام شود. برای مثال:

Financial Services → BYPASS
Healthcare Services → BYPASS
Government Sensitive → BYPASS
Known Sensitive Apps → BYPASS

Unknown Web Traffic → DECRYPT
Untrusted Downloads → DECRYPT
High-Risk Categories → DECRYPT

نکته ی امنیتی مهم: این تصمیم باید براساس قوانین سازمان، حریم خصوصی، قوانین محلی و مدل تهدید اتخاذ شود.

۹. TLS 1.3 و افزایش دشواری Visibility
TLS 1.3 سطح دید بسیاری از تجهیزات سنتی را کاهش داده است. در TLS 1.3، بخش‌های بیشتری از Handshake نسبت به TLSهای قدیمی محافظت می‌شوند. به همین دلیل Firewallهای جدید به روش‌هایی برای ایجاد Visibility بدون الزام به Decryption کامل نیاز دارند.
برای نمونه، Cisco Secure Firewall از قابلیت‌هایی مانند TLS Server Identity و Encrypted Visibility Engine (EVE) استفاده می‌کند تا بخشی از Application Visibility را حتی در شرایطی که Full MITM Decryption انجام نمی‌شود، حفظ کند.

این موضوع یکی از مهم‌ترین جهت‌گیری‌های معماری فایروال‌های مدرن است. Security Visibility نباید کاملاً وابسته به Decryption همه ترافیک باشد.

۱۰. QUIC و HTTP/3؛ چالش جدید برای فایروال
یکی از تحولات مهم شبکه مدرن، استفاده از QUIC و HTTP/3 است. QUIC بر بستر UDP اجرا می‌شود و ویژگی‌های مختلفی برای کاهش Latency و بهبود عملکرد ارتباطات دارد. از دید امنیتی، QUIC چالش‌هایی ایجاد می‌کند، زیرا بسیاری از فرضیات قدیمی فایروال‌ها بر اساس TCP و TLS روی TCP شکل گرفته بودند.
Cisco Secure Firewall در نسخه‌های جدید قابلیت‌های مرتبط با تشخیص و Visibility ترافیک QUIC را توسعه داده و در نسخه 7.6 قابلیت آزمایشی Decryption ترافیک QUIC را نیز معرفی کرده است. بنابراین در سال ۲۰۲۶، یک طراحی فایروال جدی نمی‌تواند فقط با این منطق کار کند:

TCP/80
TCP/443
TCP/22

بلکه باید پروتکل‌های جدید، به‌خصوص HTTP/3 و QUIC، را نیز در مدل Threat و Visibility در نظر بگیرد.

۱۱. امنیت خود فایروال؛ موضوعی که گاهی نادیده گرفته می‌شود
یکی از مهم‌ترین اصول امنیتی این است:

Firewall itself is an attack surface

فایروال یک دستگاه جادویی نیست. در واقع فایروال معمولاً شامل موارد زیر است:

* Operating System
* Management Interface
* Web Server
* SSH/CLI
* API
* VPN Components
* Routing Engine
* Packet Processing Engine
* IPS Engine
* Proxy Components
* Authentication Components
* Logging System

بنابراین هر کدام می‌تواند دارای Vulnerability باشد. اگر مهاجم خود Firewall را Compromise کند، ممکن است بتواند:
* Ruleها را تغییر دهد؛
* ترافیک را مشاهده کند؛
* VPN ایجاد کند؛
* Logging را دستکاری کند؛
* ترافیک را Redirect کند؛
* Credentialها را سرقت کند؛
* یا حتی Firewall را از کار بیندازد.

۱۲. نمونه واقعی: آسیب‌پذیری‌های PAN-OS
این موضوع کاملاً تئوریک نیست. برای مثال، در سال ۲۰۲۵ آسیب‌پذیری CVE-2025-0108 در رابط مدیریت PAN-OS گزارش شد که امکان Authentication Bypass را برای مهاجمی که به Management Web Interface دسترسی شبکه‌ای داشت فراهم می‌کرد. این آسیب‌پذیری با CVSS 8.8 و وضعیت Exploitation به‌عنوان Attacked گزارش شده بود.

این مثال یک اصل بسیار مهم را نشان می‌دهد:
اگر Management Plane امن نباشد، Data Plane امن بودن فایروال کافی نیست.
در سال ۲۰۲۵ آسیب‌پذیری‌هایی برای DoS در PAN-OS گزارش شدند؛ برای نمونه CVE-2025-0116 می‌توانست با پردازش یک LLDP Frame دستکاری‌شده باعث Reboot شدن Firewall شود.

در نمونه دیگری، CVE-2025-0130 در قابلیت Web Proxy می‌توانست با Packetهای مخرب باعث از کارافتادن و Reboot شدن Firewall شود.

این موارد نشان می‌دهند که «در اختیار داشتن فایروال» به معنای «امن بودن فایروال» نیست.

۱۳. Management Plane باید جدا از Data Plane محافظت شود
یکی از مهم‌ترین اصول Hardening این است که Management Interface فایروال نباید به‌طور عمومی در اینترنت قابل دسترسی باشد.
معماری ضعیف:

Internet
|
+—— HTTPS —–> Firewall Management

معماری بهتر:

Admin Workstation
|
Management VLAN
|
Bastion / Jump Host
|
Management Interface
|
Firewall

و بهتر از آن:

Admin
↓
MFA
↓
Privileged Access
↓
Jump Host
↓
Management Network
↓
Firewall

این اصل حتی در توصیه‌های امنیتی مربوط به آسیب‌پذیری‌های واقعی PAN-OS نیز دیده می‌شود؛ Palo Alto Networks برای برخی آسیب‌پذیری‌های Management Interface توصیه کرده است دسترسی به رابط مدیریت فقط از IPهای داخلی و مورد اعتماد امکان‌پذیر باشد.

۱۴. Policy Design؛ قلب امنیت فایروال
یکی از بزرگ‌ترین اشتباهات سازمان‌ها این است که تصور کنند «هرچه Rule بیشتر باشد، امنیت بیشتر است.»
در واقع Policyهای پیچیده، قدیمی و متناقض می‌توانند امنیت را کاهش دهند.

یک Rulebase ضعیف ممکن است دارای:
* Ruleهای Shadowed
* Ruleهای Duplicate
* Any/Any
* Objectهای بدون مالک
* Ruleهای بدون Expiration
* دسترسی‌های موقت که دائمی شده‌اند
* Serviceهای غیرضروری
* Sourceهای بیش از حد گسترده
باشد.

۱۵. اصل Least Privilege در Firewall Policy
Policy مناسب باید تا حد امکان بر اساس Least Privilege طراحی شود. به جای:

Source: Any
Destination: Any
Service: Any
Action: Allow

باید به چیزی شبیه این نزدیک شد:

Source: Finance-Users
Destination: ERP-Server
Application: ERP(Enterprise Resource Planning)
Service: HTTPS
Schedule: Business-Hours
Inspection: IPS + AV + Logging
Action: Allow

و در پایان Default Deny قرار گیرد. البته Default Deny باید با دقت و بر اساس Dependencyهای واقعی سازمان پیاده‌سازی شود تا موجب اختلال عملیاتی نشود.

۱۶. Policy Lifecycle Management
امنیت فایروال فقط ایجاد Rule نیست. هر Rule باید چرخه عمر داشته باشد:

Request
↓
Risk Analysis
↓
Approval
↓
Implementation
↓
Validation
↓
Monitoring
↓
Periodic Review
↓
Expiration / Removal

در نسخه‌های جدید FortiOS حتی قابلیت‌هایی برای Policy Change Summary و Policy Expiration ارائه شده است که می‌تواند به Auditability و کاهش Ruleهای فراموش‌شده کمک کند.
این موضوع نشان می‌دهد مدیریت Policy در فایروال مدرن یک مسئله صرفاً فنی نیست؛ بلکه بخشی از Governance امنیت است.

۱۷. Segmentation و Micro-Segmentation
یکی از کاربردهای بسیار مهم فایروال‌های امروزی، جلوگیری از Lateral Movement است. فرض کنید مهاجم یک Workstation را آلوده کند.

در معماری سنتی:

Internet
↓
Firewall
↓
Internal Network
 User PCs
 Database
Domain Controller
File Server
 Admin Systems

اگر مهاجم به شبکه داخلی برسد، ممکن است بتواند به سیستم‌های دیگر حرکت کند.

معماری بهتر:

Firewall
|
+———–+———–+
| | |
Users Servers Admin
| | |
| DB/ERP DC
| |
+—– Controlled ——+
Communication

در این مدل ارتباطات East-West نیز تحت Policy قرار می‌گیرند.

۱۸. ارتباط Firewall با Zero Trust
Zero Trust به این معنا نیست که «فایروال دیگر لازم نیست.» بلکه نقش فایروال تغییر می‌کند. در Zero Trust، شبکه به‌تنهایی منبع اعتماد نیست. NIST SP 800-207 بر این اصل تأکید دارد که دسترسی نباید صرفاً بر اساس محل قرارگیری کاربر یا تجهیزات در شبکه اعطا شود.

بنابراین Firewall می‌تواند بخشی از Enforcement Architecture باشد، در کنار:

* Identity Provider
* MFA(Multi-factor authentication)
* Endpoint Security
* Device Posture
* Micro-Segmentation
* API Gateway
* Service Identity
* Policy Engine

در محیط Cloud-Native نیز NIST بر اهمیت هویت Application و Service در کنار هویت کاربر و پارامترهای شبکه تأکید می کند.

۱۹. فایروال در برابر حرکت جانبی مهاجم
فرض کنیم مهاجم با Phishing به Credential یک کاربر دست پیدا کند. سپس:

Attacker
↓
User Account
↓
Workstation
↓
Internal Network
↓
File Server
↓
Domain Controller

اگر Firewall فقط در مرز Internet قرار گرفته باشد، ممکن است بعد از ورود مهاجم دیگر نقش زیادی در جلوگیری از حرکت جانبی نداشته باشد. اما اگر Segmentation مناسب وجود داشته باشد:

User VLAN
↓
Firewall
↓
Server VLAN
↓
Firewall
↓
Critical Server

می‌توان Ruleهایی مانند زیر ایجاد کرد:

Users → DB
ALLOW فقط TCP/1433

Users → Domain Controller
ALLOW فقط سرویس‌های مورد نیاز

Users → Admin Network
DENY

Servers → User VLAN
DENY

این همان جایی است که Firewall از یک Perimeter Device به یک Segmentation Control تبدیل می‌شود.

۲۰. IDS/IPS و Firewall
Firewall به‌تنهایی برای تشخیص تمام حملات کافی نیست. به همین دلیل NGFWها معمولاً با IPS ترکیب می‌شوند. مدل ساده:

Packet
↓
Session Inspection
↓
Policy Match
↓
Application Identification
↓
IPS
↓
Malware / File Inspection
↓
Logging
↓
ALLOW / BLOCK

برای مثال FortiGate در معماری‌های NGFW خود Application Control، Web Filtering، IPS، Antivirus، File Filtering و سایر Security Profileها را در Policy قرار می‌دهد.

۲۱. تفاوت Firewall با IPS
این دو مفهوم نباید یکی تلقی شوند.
تمرکز اصلی Firewall این است که آیا این ارتباط بر اساس Policy مجاز است؟ اما در IPS تمرکز اصلی روی آن است که آیا محتوای این ارتباط دارای الگوی حمله یا رفتار مخرب است؟ مثلاً:

Source = Internal Web Server
Destination = Database
Port = 1433

Firewall می‌گوید: این ارتباط از نظر Policy مجاز است. اما IPS ممکن است تشخیص دهد Payload شامل الگوی Exploitation شناخته‌شده است. پس:

Firewall Policy = ALLOW
IPS Verdict = BLOCK

این دو کنترل مکمل یکدیگرند.

۲۲. Logging؛ فایروال بدون Log یک کنترل کور است
امنیت واقعی بدون Visibility امکان‌پذیر نیست. حداقل رویدادهای مهم فایروال باید ثبت شوند:

* Allowed Connections
* Denied Connections
* Administrative Login
* Policy Changes
* VPN Events
* IPS Events
* Malware Events
* Configuration Changes
* System Events
* Authentication Events

اما نگهداری Log روی خود فایروال کافی نیست بلکه بهتر است:

Firewall
↓
Central Logging
↓
SIEM(Security Information and Event Management)
↓
Correlation
↓
Detection
↓
SOC(Security Operations Center)

انجام شود.

۲۳. چرا SIEM برای امنیت فایروال اهمیت دارد؟
یک Event به تنهایی ممکن است بی‌اهمیت به نظر برسد.
مثلاً:

Firewall Deny
Source = 10.10.10.20
Destination = 10.10.20.15
Port = 445

اما اگر SIEM در چند دقیقه صدها مورد مشابه از چندین سیستم مشاهده کند:

SMB Scanning
+
Multiple Hosts
+
Authentication Failures
+
Unusual DNS
+
Outbound C2

ممکن است یک حمله Lateral Movement یا Malware Campaign شناسایی شود.

بنابراین Firewall Log به‌تنهایی Event است؛ SIEM می‌تواند آن را به Security Intelligence تبدیل کند.

۲۴. High Availability و امنیت فایروال
فایروال معمولاً یک نقطه بسیار حیاتی در شبکه است. اگر فایروال از کار بیفتد، ممکن است:
* Internet قطع شود؛
* ارتباط شعب قطع شود؛
* VPNها قطع شوند؛
* سرویس‌های Cloud مختل شوند؛
* ارتباطات داخلی از بین بروند.
بنابراین در محیط‌های حساس باید از High Availability استفاده شود:

Internet
|
+——-+——-+
| |
Firewall A Firewall B
| |
+——-+——-+
|
LAN/DC

اما HA فقط برای Availability نیست. باید موارد زیر نیز بررسی شوند:

* State Synchronization
* Session Synchronization
* Configuration Synchronization
* Certificate Synchronization
* Logging
* Failover Security
* Split-Brain Protection

۲۵. خطر Fail-Open و Fail-Closed
در طراحی HA و Failure Handling باید تصمیم گرفت هنگام خرابی چه اتفاقی رخ دهد.
Fail-Open : ترافیک در صورت خرابی کنترل امنیتی ممکن است عبور کند.
مزیت:
* Availability بالاتر
عیب:
* احتمال کاهش Security

Fail-Closed : در صورت خرابی، ترافیک متوقف می‌شود.
مزیت:
* Security بالاتر
عیب:
* Availability پایین‌تر
انتخاب صحیح به نوع سیستم بستگی دارد. برای مثال Critical Safety System ممکن است الزامات متفاوتی از Office Internet Access داشته باشد.

۲۶. DoS علیه خود Firewall
فایروال علاوه بر اینکه باید DoS را برای سازمان کاهش دهد، ممکن است خودش هدف DoS قرار گیرد. حمله می‌تواند علیه موارد زیر باشد:

* Control Plane
* Data Plane
* VPN
* Proxy
* IPS Engine
* Management Interface
* Session Table

نمونه‌های PAN-OS در سال ۲۰۲۵ نشان داده‌اند که Packetهای خاص می‌توانند در شرایطی باعث Reboot یا از کارافتادن Firewall شوند.
بنابراین Rate Limiting، DoS Protection، ظرفیت Session، طراحی HA و Patch Management اهمیت بسیار زیادی دارند.

۲۷. Patch Management؛ یکی از مهم‌ترین اجزای امنیت فایروال
یکی از خطرناک‌ترین اشتباهات این است: «چون فایروال دستگاه امنیتی است، پس خودش امن است.»
برعکس، فایروال یکی از جذاب‌ترین اهداف مهاجم است. چرا؟
چون در موقعیت بسیار مناسبی قرار دارد:

Internet
↓
[ FIREWALL ]
↓
Internal Network

اگر مهاجم بتواند Firewall را Compromise کند، ممکن است در بهترین موقعیت برای مشاهده یا تغییر ترافیک قرار گیرد. بنابراین باید:

* Firmware
* Operating System
* Security Signatures
* IPS Database
* Malware Database
* Application Database

به‌صورت منظم به‌روزرسانی شوند. اما Patch کردن نباید بدون فرآیند انجام شود. فرآیند حرفه‌ای:

Vendor Advisory
↓
Asset Identification
↓
Exposure Analysis
↓
Risk Assessment
↓
Test
↓
Backup
↓
Upgrade
↓
Validation
↓
Monitoring

۲۸. مدیریت آسیب‌پذیری باید بر اساس Exposure باشد
صرف وجود CVE به معنی Risk یکسان برای همه سازمان‌ها نیست.

مثلاً: CVE = High

اگر Management Interface = Internet Exposed باشد ریسک بسیار بالاتر است. اما اگر:

Management Interface = Isolated
MFA = Enabled
Access = Restricted
Version = Patched

Exposure ممکن است به‌شدت کاهش یابد. بنابراین مدل صحیح حالت زیر است: 

Risk = Vulnerability \times Exposure \times Impact

۲۹. نمونه دیگر از اهمیت Management Security
در سال ۲۰۲۵ آسیب‌پذیری‌های متعددی در اکوسیستم محصولات Firewall منتشر شد.
برای مثال، Palo Alto Networks در مورد ابزار Expedition هشدار داد که آسیب‌پذیری‌های آن می‌توانند به افشای اطلاعاتی مانند Passwordها، Configurationها و API Keyهای مربوط به فایروال‌ها منجر شوند.
این مثال یک نکته بسیار مهم را نشان می‌دهد. امنیت فایروال فقط امنیت Appliance نیست؛ ابزارهای Management، Migration، Orchestration و APIهای اطراف آن نیز بخشی از Attack Surface هستند.

۳۰. نمونه عملی: Palo Alto Networks
در فایروال‌های Palo Alto، Security Policy می‌تواند بر اساس موارد زیر تصمیم بگیرد:

Source Zone
Destination Zone
Source IP
Destination IP
Application
User
Service

یک سناریوی فرضی:

Source Zone:
Corporate

Source User:
Finance-Group

Destination:
ERP-Server

Application:
ERP-App

Service:
HTTPS

Security Profiles:
IPS
Anti-Malware
URL Filtering
File Inspection

Action:
Allow

در این مدل، فایروال دیگر صرفاً نمی‌گوید: «TCP/443 مجاز است.» بلکه تلاش می‌کند بفهمد: «چه Applicationای، توسط چه Userی، از کجا و به کجا در حال ارتباط است؟»

۳۱. نمونه عملی: FortiGate
FortiGate در معماری NGFW خود می‌تواند Security Policy را با قابلیت‌هایی مانند زیر ترکیب کند:

* Application Control
* IPS
* Antivirus
* Web Filter
* File Filter
* SSL Inspection
* DLP
* Authentication

برای مثال:

Source:
Employee VLAN

Destination:
Internet

Application:
Web Browsing

SSL Inspection:
Deep Inspection

Security Profiles:
IPS
Antivirus
Web Filter
Application Control

Logging:
Enabled

در این حالت Policy از یک ACL ساده به یک Security Control چندلایه تبدیل می‌شود.

۳۲. نمونه عملی: Cisco Secure Firewall
Cisco Secure Firewall نیز برای مقابله با مشکل Visibility در ترافیک رمزنگاری‌شده از قابلیت‌هایی مانند زیر استفاده می کند:

* TLS Decryption
* TLS Server Identity
* Encrypted Visibility Engine
* Application Identification

اهمیت این مسئله در محیط مدرن بسیار زیاد است؛ زیرا اگر سازمان همه ترافیک را رمزنگاری کند ولی هیچ Visibility روی آن نداشته باشد، ممکن است Malware نیز از همان کانال رمزنگاری‌شده عبور کند.

۳۳. آیا Decryption همه ترافیک راهکار مناسبی است؟
خیر.
یک معماری حرفه‌ای باید بر اساس Risk تصمیم بگیرد. برای مثال:

TLS Traffic
|
+——-+——-+
| |
Low Risk High Risk
| |
Bypass Decrypt
|
+———+———+
| | |
IPS AV DLP

همچنین باید Applicationهای حساس از نظر موارد زیر در نظر گرفته شوند:

* Privacy
* Certificate Pinning
* Legal Requirements
* Business Criticality

۳۴. فایروال و معماری Cloud
در Cloud، مفهوم Firewall تغییر می‌کند. به جای یک Appliance فیزیکی ممکن است داشته باشیم:

* Virtual Firewall
* Cloud Firewall
* Security Group
* Network Firewall
* Cloud-Native Policy
* Service Mesh
* API Gateway

در این محیط، یک سازمان ممکن است دارای چندین لایه Enforcement باشد:

Internet
↓
CDN / WAF
↓
Cloud Firewall
↓
Load Balancer
↓
Application
↓
Service Mesh
↓
Database

بنابراین نباید Firewall را به یک Box فیزیکی محدود کرد.

۳۵. Firewall و Kubernetes
در معماری Container، ارتباطات بسیار Dynamic هستند. ممکن است IPها دائماً تغییر کنند. بنابراین Policy مبتنی بر:

IP = 10.20.10.15

ممکن است در یک معماری Kubernetes مناسب نباشد. به سمت مفاهیمی زیر حرکت می کنیم:

Namespace
Service Identity
Pod Identity
Application Identity
Service Account

NIST نیز در معماری Zero Trust برای Cloud-Native بر اهمیت Application و Service Identity در کنار پارامترهای سنتی شبکه تأکید کرده است.

۳۶. Firewall و SASE(Secure Access Service Edge)
با افزایش کاربران راه‌دور و Cloud، معماری‌هایی مانند SASE نیز اهمیت پیدا کرده‌اند. در چنین معماری‌هایی Security Enforcement ممکن است از Data Center خارج شود. 
مدل سنتی:

User
↓
Corporate Network
↓
Firewall
↓
Internet

مدل مدرن:

User
↓
Identity
↓
Security Edge
↓
Cloud Security
↓
Application

در نتیجه، مفهوم «فایروال» بیش از پیش از یک Appliance به یک مجموعه Capability امنیتی تبدیل می‌شود.

۳۷. اشتباهات رایج در امن‌سازی فایروال
اشتباه اول: Any/Any

Source = Any
Destination = Any
Service = Any
Action = Allow

این Rule باید فقط در شرایط کاملاً خاص و کنترل‌شده وجود داشته باشد.

اشتباه دوم: مدیریت فایروال از اینترنت

Internet
↓
HTTPS
↓
Firewall Management

این معماری Attack Surface بسیار خطرناکی ایجاد می‌کند.

اشتباه سوم: استفاده از Ruleهای قدیمی
Ruleهایی که سال‌ها قبل ایجاد شده‌اند ممکن است دیگر مورد نیاز نباشند.

اشتباه چهارم: عدم Logging
اگر Rule مهمی ایجاد شود اما Log مناسب نداشته باشد، تشخیص سوءاستفاده دشوار می‌شود.

اشتباه پنجم: اعتماد بیش از حد به IPS
IPS بسیار مهم است اما جایگزین Policy صحیح نیست.

اشتباه ششم: اعتماد به Port
TCP/443 = Safe
این فرض اشتباه است.

اشتباه هفتم: Decrypt همه چیز
این کار می‌تواند هم Performance و هم Privacy را تحت تأثیر قرار دهد.

اشتباه هشتم: عدم Patch فایروال
این یکی از خطرناک‌ترین اشتباهات است.

۳۸. معماری پیشنهادی برای یک سازمان متوسط
یک معماری نسبتاً مدرن می‌تواند چنین ساختاری داشته باشد:

INTERNET
|
[ Edge / DDoS ]
|
[ NGFW ]
/ | \
/ | \
DMZ Users VPN
| | |
Servers Endpoint MFA
| |
+—-[Internal Segmentation]
|
Critical Servers
|
Database

در کنار آن:

NGFW
|
+—- IPS
|
+—- TLS Inspection
|
+—- Application Control
|
+—- URL Filtering
|
+—- Malware Inspection
|
+—- Logging
|
+—- Threat Intelligence
|
+—- SIEM
|
+—- SOC

و برای Management:

Admin
↓
MFA
↓
Privileged Access
↓
Jump Host
↓
Management Network
↓
Firewall

۳۹. چک‌لیست امنیت فایروال
برای ارزیابی یک Firewall می‌توان چک‌لیست زیر را در نظر گرفت:
معماری
* آیا Firewall در محل صحیح معماری قرار گرفته است؟
* آیا Single Point of Failure وجود دارد؟
* آیا HA فعال است؟
* آیا Internal Segmentation انجام شده است؟
* آیا East-West Traffic کنترل می‌شود؟

Management
* آیا Management Interface از Internet قابل دسترسی است؟
* آیا MFA فعال است؟
* آیا RBAC استفاده می‌شود؟
* آیا Management Network جداست؟
* آیا Admin Activity Logging فعال است؟

Policy
* آیا Default Deny وجود دارد؟
* آیا Any/Any Ruleها بررسی شده‌اند؟
* آیا Ruleهای Shadowed شناسایی شده‌اند؟
* آیا Ruleها مالک دارند؟
* آیا Ruleهای موقت Expiration دارند؟
* آیا Rulebase به‌صورت دوره‌ای Review می‌شود؟

Inspection
* آیا IPS فعال است؟
* آیا Application Control فعال است؟
* آیا Malware Inspection فعال است؟
* آیا TLS Inspection بر اساس Risk طراحی شده است؟
* آیا HTTP/3 و QUIC در معماری در نظر گرفته شده‌اند؟

Logging
* آیا Firewall Log به SIEM ارسال می‌شود؟
* آیا Policy Change Log وجود دارد؟
* آیا Admin Login ثبت می‌شود؟
* آیا IPS Eventها مانیتور می‌شوند؟
* آیا Alertهای مهم به SOC ارسال می‌شوند؟

Vulnerability Management
* آیا Firmware به‌روز است؟
* آیا Security Advisoryهای Vendor پایش می‌شوند؟
* آیا CVEهای مرتبط بررسی می‌شوند؟
* آیا Management Plane در معرض اینترنت نیست؟
* آیا Backup امن از Configuration وجود دارد؟

۴۰. مدل بلوغ امنیت فایروال
می‌توان سازمان‌ها را به‌صورت مفهومی در پنج سطح دسته‌بندی کرد:

سطح ۱ — Basic
IP + Port Filtering

سطح ۲ — Stateful
Stateful Firewall
+
Basic Logging

سطح ۳ — NGFW
Application Control
+
IPS
+
User Awareness
+
URL Filtering

سطح ۴ — Integrated Security
NGFW
+
SIEM
+
Threat Intelligence
+
TLS Inspection
+
EDR
+
Identity

سطح ۵ — Adaptive / Zero Trust
Identity
+
Device Posture
+
Micro-Segmentation
+
Continuous Verification
+
Risk-Based Policy
+
Cloud Security
+
Automation

در سطح پنجم، Firewall دیگر یک تجهیز مستقل نیست؛ بلکه یکی از اجزای یک Security Control Plane گسترده‌تر است.

۴۱. آینده امنیت فایروال‌ها
جهت حرکت فناوری فایروال را می‌توان در چند روند اصلی خلاصه کرد:
۱. Identity-Aware Security
تصمیم‌گیری بر اساس User و Service Identity به‌جای IP تنها.
۲. Encrypted Traffic Visibility
توانایی تحلیل ترافیک رمزنگاری‌شده بدون وابستگی کامل به MITM Decryption.
۳. Cloud-Native Enforcement
Policyهایی که با Workload و Service Identity کار می‌کنند.
۴. Micro-Segmentation
کنترل ارتباطات East-West.
۵. AI-Assisted Security Operations
استفاده از مدل‌های هوشمند برای:
* تحلیل Log
* تشخیص Anomaly
* Policy Optimization
* Threat Hunting
* Incident Correlation
البته AI نباید بدون کنترل انسانی اجازه تغییر مستقیم Policyهای حیاتی را داشته باشد.
۶. Policy as Code
مدیریت Policy با روش‌های:

Git
+
CI/CD
+
Validation
+
Automated Testing
+
Change Control

این مدل می‌تواند خطاهای انسانی را کاهش دهد و قابلیت Audit را افزایش دهد.

۴۲. رابطه Firewall و NIST CSF 2.0
امنیت فایروال را می‌توان با چارچوب Cybersecurity Framework 2.0 نیز همسو کرد. NIST CSF 2.0 در سال ۲۰۲۴ منتشر شد و رویکردی مبتنی بر مدیریت ریسک ارائه می‌کند. در این چارچوب، فایروال می‌تواند در چند حوزه نقش داشته باشد:
Govern
* تعیین مسئولیت Firewall
* تعریف Policy
* مدیریت Risk

Identify
* شناسایی Assetها
* شناسایی جریان‌های داده
* شناسایی Exposure

Protect
* Network Segmentation
* Access Control
* Policy Enforcement

Detect
* IDS/IPS
* Logging
* Anomaly Detection

Respond
* Block
* Quarantine
* Policy Modification

Recover
* HA
* Backup
* Configuration Restore
* Disaster Recovery
بنابراین Firewall باید بخشی از یک برنامه Cybersecurity Risk Management باشد، نه یک محصول منفرد.

۴۳. یک سناریوی جامع حمله
فرض کنیم مهاجم یک ایمیل Phishing ارسال می‌کند.

Attacker
↓
Phishing Email
↓
Employee
↓
Malicious Attachment
↓
Endpoint Compromise

اگر فقط Firewall مرزی وجود داشته باشد، بخش زیادی از حمله ممکن است از داخل سازمان انجام شود.

اما در معماری دفاعی چندلایه:

Email Security
↓
Endpoint Security
↓
Identity Security
↓
Internal Firewall
↓
IPS
↓
DNS Security
↓
SIEM
↓
SOC

ممکن است مراحل بعدی حمله شناسایی شوند. مثلاً Endpoint تلاش می‌کند:

Workstation
↓
DNS Query
↓
Malicious Domain

Firewall/DNS Security آن را Block می‌کند. اگر مهاجم تلاش کند:

Workstation
↓
TCP/445
↓
Multiple Servers

Segmentation Firewall می‌تواند ارتباط را Block کند و SIEM نیز:

Multiple Failed Auth
+
SMB Scanning
+
Malicious DNS
+
Unusual Outbound Traffic

را Correlate می‌کند. 

این یعنی امنیت واقعی نتیجه Defense in Depth است، نه یک Firewall منفرد.

۴۴. نتیجه‌گیری
فایروال همچنان یکی از مهم‌ترین کنترل‌های امنیت شبکه است، اما تعریف آن در سال ۲۰۲۶ با تعریف فایروال‌های سنتی تفاوت بنیادی دارد.
فایروال مدرن باید بتواند تا حد امکان:
* Session را درک کند؛
* Application را شناسایی کند؛
* User و Identity را در Policy وارد کند؛
* حملات را با IPS شناسایی کند؛
* فایل‌ها و Malware را بررسی کند؛
* ترافیک رمزنگاری‌شده را با رویکردی کنترل‌شده تحلیل کند؛
* پروتکل‌های جدید مانند QUIC/HTTP/3 را در نظر بگیرد؛
* Segmentهای شبکه را کنترل کند؛
* Logهای قابل استفاده برای SIEM تولید کند؛
* با معماری Cloud و Zero Trust سازگار باشد؛
* و در عین حال خود در برابر حمله Harden شود.

مهم‌تر از همه، باید پذیرفت که فایروال بخشی از سطح حمله سازمان است.

آسیب‌پذیری‌های واقعی منتشرشده در محصولات Firewall در سال‌های اخیر، از جمله آسیب‌پذیری‌های مرتبط با Management Interface و نقص‌هایی که می‌توانند موجب DoS یا Reboot شدن Firewall شوند، این مسئله را به‌وضوح نشان می‌دهند.
از سوی دیگر، Zero Trust نشان داده است که دیگر نمی‌توان امنیت را صرفاً با ساختن یک «دیوار» در مرز اینترنت تعریف کرد. NIST نیز در معماری Zero Trust بر حرکت از مدل اعتماد مبتنی بر محل شبکه به سمت حفاظت از منابع، هویت‌ها و سرویس‌ها تأکید می‌کند.
بنابراین، تعریف دقیق‌تر Firewall Security در معماری مدرن را می‌توان چنین بیان کرد:

Firewall\ Security =
Secure\ Enforcement
+
Secure\ Configuration
+
Secure\ Management
+
Continuous\ Monitoring
+
Vulnerability\ Management
+
Identity
+
Segmentation
+
Threat\ Intelligence

در نهایت، یک Firewall زمانی واقعاً «امن» است که نه‌تنها بتواند حملات ورودی و خروجی را کنترل کند، بلکه خودش نیز در برابر Compromise، Misconfiguration، Abuse، DoS و آسیب‌پذیری‌های نرم‌افزاری مقاوم باشد و در معماری گسترده‌تر امنیت سازمان نقش مشخص و قابل اندازه‌گیری داشته باشد.