Firewall خوب فهرستی از چند port نیست؛ سیاستی است که جریان‌های مجاز میان کاربر، proxy، برنامه، دیتابیس، monitoring و مدیریت را مشخص می‌کند. خطر اصلی در production، اعمال rule بدون شناخت مسیر واقعی و قطع SSH، callback پرداخت، DNS یا backup است. طراحی باید قبل از فرمان و همراه rollback انجام شود.
پاسخ سریع: ابتدا listenerها و جریان ورودی/خروجی را inventory کنید، console اضطراری و session دوم داشته باشید و دسترسی مدیریت را صریحاً مجاز کنید. سپس default deny ورودی را مرحله‌ای برقرار، فقط سرویس‌های لازم را باز و IPv4/IPv6 و cloud firewall را هماهنگ کنید. نتیجه را از شبکه بیرونی واقعی آزمایش کنید.
از Flow Matrix شروع کنید
| مبدأ | مقصد | سرویس | دلیل |
|---|---|---|---|
| اینترنت | Reverse proxy | HTTP/HTTPS | وب عمومی |
| شبکه مدیریت | سرور | SSH | عملیات |
| برنامه | دیتابیس | پورت داخلی | داده |
| سرور | DNS/NTP/Update | خروجی لازم | زیرساخت |
اعداد port را از config و listener واقعی استخراج کنید؛ جدول بالا فقط شکل تصمیم است. هر rule باید owner، دلیل، تاریخ بازبینی و مسیر حذف داشته باشد.
Inventory خواندنی
ip -br addr
ss -lntup
ip route
sudo nft list ruleset
sudo ufw status verboseممکن است nftables یا UFW نصب/فعال نباشد؛ فرمان ناموجود خطاست و نباید ابزار دوم را صرفاً برای مشاهده نصب کنید. cloud security group و ruleهای provider بیرون host هستند و باید جدا ثبت شوند. خروجی IP داخلی و نام سرویس را عمومی نکنید.
قبل از اعمال: Console و Rollback
دسترسی out-of-band را واقعاً تست و config فعلی را backup کنید. session SSH موجود را باز نگه دارید و در session دوم ورود تازه را بیازمایید. rollback زمان‌دار می‌تواند مفید باشد، اما نباید تنها حفاظی باشد که با قطع session از کار می‌افتد. تغییر را در maintenance window اجرا کنید.
Default Policy
برای ورودی، deny by default همراه allowهای صریح سطح حمله را کم می‌کند. خروجی پیچیده‌تر است: update، DNS، NTP، ایمیل، API پرداخت، backup و monitoring ممکن است لازم باشند. deny خروجی بدون inventory می‌تواند خطاهای مبهم بسازد. سیاست stateful باید connectionهای برقرار و پاسخ ترافیک مجاز را درست مدیریت کند.
SSH را اول مجاز کنید
قبل از فعال‌سازی deny، مسیر SSH واقعی—port، interface، IPv4/IPv6 و subnet مدیریت—را allow کنید. اگر IP مدیر پویا است، VPN یا bastion را طراحی کنید. باز کردن SSH برای کل اینترنت فقط برای جلوگیری از lockout راه‌حل نهایی نیست. امن‌سازی SSH authentication و مسیر بازیابی را توضیح می‌دهد.
وب عمومی و Backend خصوصی
معمولاً 80/443 روی reverse proxy عمومی‌اند. PHP-FPM، app port، دیتابیس و Redis باید فقط از host یا شبکه لازم قابل دسترسی باشند. binding سرویس به interface خصوصی یک لایه مکمل است؛ firewall جای config listener را نمی‌گیرد و برعکس.
IPv4 و IPv6
rule IPv4 الزاماً IPv6 را پوشش نمی‌دهد. اگر AAAA یا listener v6 دارید، سیاست باید هر دو stack را شامل شود. غیرفعال‌کردن عجولانه IPv6 ممکن است dependency را خراب کند؛ exposure را اندازه بگیرید و آگاهانه مدیریت کنید. آزمون بیرونی هر دو مسیر لازم است.
Cloud Firewall و Host Firewall
دو لایه می‌توانند دفاع عمیق بسازند، اما اختلاف آن‌ها troubleshooting را دشوار می‌کند. source of truth و ترتیب تغییر مشخص باشد. cloud firewall ممکن است قبل از رسیدن packet به host آن را رد کند؛ log host در این حالت چیزی نشان نمی‌دهد. rule موقت باید expiration داشته باشد.
NAT و Port Forwarding
در شبکه NATشده، port خارجی و داخلی ممکن است متفاوت باشد. rule روی chain یا interface اشتباه بی‌اثر است. source IP پس از NAT نیز ممکن است تغییر کند. مسیر packet را از edge تا process رسم کنید و فقط به listener محلی یا scan یک شبکه تکیه نکنید.
Docker و Ruleهای خودکار
container runtime می‌تواند chain و NAT rule اضافه کند و published port را خارج از انتظار frontend فایروال در دسترس قرار دهد. خروجی UFW به‌تنهایی ممکن است exposure Docker را کامل نشان ندهد. published port، network و rule واقعی packet را بررسی کنید؛ directory یا rule runtime را دستی و کور تغییر ندهید.
Reverse Proxy و IP واقعی
اگر CDN یا load balancer مبدأ connection است، allowlist باید range معتبر و به‌روز آن را ببیند. header مانند X-Forwarded-For در firewall لایه شبکه قابل اتکا نیست و در برنامه نیز فقط از proxy مورد اعتماد پذیرفته شود. بستن origin به proxy باید مسیر healthcheck و مدیریت certificate را نیز حفظ کند.
ICMP را کور نبندید
ICMP فقط ping نیست؛ پیام‌های خطا و Path MTU برای کارکرد شبکه اهمیت دارند، به‌خصوص در IPv6. سیاست باید typeهای لازم را متناسب با شبکه مدیریت کند. بستن همه ICMP می‌تواند timeoutهای عجیب و عیب‌یابی دشوار ایجاد کند، بدون اینکه سرویس باز را مخفی کند.
Rate Limit و Connection Limit
محدودسازی می‌تواند burst مخرب را کنترل کند، اما threshold عمومی برای SSH، API و Checkout مناسب نیست. کاربران پشت NAT و crawler قانونی را در نظر بگیرید. rate limit در proxy گاهی context بیشتری از firewall دارد. metric drop و false positive باید وجود داشته باشد.
Outbound Filtering
محدودسازی خروجی می‌تواند اثر compromise را کاهش دهد، ولی نگهداری آن پرهزینه است. دامنه API ممکن است IP متغیر داشته باشد و DNS خودش نیازمند خروجی است. از deny ناگهانی شروع نکنید؛ ابتدا observe و flowهای ضروری را طبقه‌بندی کنید. secret exfiltration فقط با port filtering حل نمی‌شود.
Logging بدون پر کردن Disk
log همه packetهای ردشده در معرض اینترنت می‌تواند دیسک و CPU را مصرف کند. rate limit برای logging، retention و aggregation تعریف کنید. payload یا داده حساس را ثبت نکنید. log باید rule و جهت را مشخص کند تا troubleshooting ممکن باشد.
اعمال مرحله‌ای
- flow matrix، listener و rule فعلی را ثبت کنید.
- console، backup و session دوم را آماده کنید.
- allow مدیریت و سرویس‌های حیاتی را بسازید.
- config/ruleset را با ابزار همان سیستم validate کنید.
- deny ورودی را مرحله‌ای فعال کنید.
- از بیرون allow و deny را هر دو test کنید.
- reboot persistence و تعامل Docker را بررسی کنید.
- log، alert و مستندات را تکمیل کنید.
آزمون از کجا انجام شود؟
تست localhost مسیر firewall خارجی را طی نمی‌کند. از اینترنت، شبکه مدیریت، subnet برنامه و مسیر proxy نمونه مناسب داشته باشید. فقط باز بودن port کافی نیست؛ handshake و درخواست کاربردی کنترل‌شده را بررسی کنید. برای port ممنوع نیز timeout/refusal را طبق سیاست تأیید کنید.
تغییر Emergency
در قطعی، خاموش کردن کامل firewall دامنه exposure را بالا می‌برد و علت را مبهم می‌کند. rule موقت و محدود به مبدأ/سرویس با expiration بهتر است. هر تغییر emergency باید ثبت، بازبینی و پس از incident حذف یا دائمی‌سازی شود. credentialهای افشاشده را فقط با rule پنهان نکنید.
پایداری پس از Reboot
rule فعال در memory ممکن است پس از reboot بارگذاری نشود، یا برعکس rule قدیمی برگردد. روش persistence باید متعلق به ابزار اصلی باشد و با automation تضاد نداشته باشد. reboot کنترل‌شده در window و با console آماده، بخشی از آزمون تحویل است.
اشتباه‌های رایج
- فعال کردن default deny قبل از allow SSH
- نادیده گرفتن IPv6
- باز گذاشتن دیتابیس یا Redis
- اعتماد کامل به خروجی یک frontend در حضور Docker
- بستن همه ICMP
- deny خروجی بدون شناخت DNS و API
- logging بدون rate limit
- ویرایش هم‌زمان cloud و host firewall
بازبینی دوره‌ای
ruleهای بدون hit یا owner، دسترسی پیمانکار قبلی و portهای سرویس حذف‌شده باید پاک شوند. هر تغییر معماری flow matrix را به‌روز کند. drift میان config نسخه‌دار و ruleset فعال را مانیتور کنید. راهنمای امنیت اولیه لینوکس firewall را در کنار patch، account و backup قرار می‌دهد.
چه زمانی کمک تخصصی لازم است؟
اگر cloud firewall، Docker، CDN و VPN هم‌زمان در مسیرند، یک rule اشتباه می‌تواند origin یا مدیریت را قطع کند. نصب و کانفیگ سرور لینوکس می‌تواند flow matrix، ruleset، تست بیرونی و rollback را متناسب با معماری واقعی پیاده کند.
پرسش‌های متداول
UFW بهتر است یا nftables؟
به پیچیدگی ruleset و استاندارد تیم بستگی دارد. frontend ساده برای نیاز ساده مناسب است؛ مهم، یک source of truth و آزمون مسیر واقعی است.
آیا فقط باز کردن 80 و 443 کافی است؟
برای وب عمومی شاید ورودی اصلی باشد، اما مدیریت، monitoring، backup، DNS و dependencyها نیز باید طراحی شوند.
چرا port Docker با وجود Firewall باز است؟
runtime ممکن است NAT/chain مستقل اضافه کرده باشد. published port و مسیر واقعی packet را بررسی کنید.
آیا Firewall جلوی هک سایت را می‌گیرد؟
سطح شبکه را محدود می‌کند، اما آسیب‌پذیری برنامه روی port مجاز، credential سرقت‌شده و patch ناقص را حل نمی‌کند.