فایروال UFW در اوبونتو
تنظیم امن و قابل‌آزمون

۱) قبل از تغییر، سرویس‌ها و مسیر مدیریت را موجودی‌برداری کنید

از کنسول یا یک نشست SSH پایدار، listenerهای شبکه و وضعیت فعلی UFW را ببینید. هر پورتی که گوش می‌دهد الزاماً نباید از اینترنت عمومی باز باشد؛ این فهرست فقط برای تصمیم‌گیری است.

sudo ss -lntup
sudo ufw status verbose
sudo ufw status numbered
sudo ufw app list
sudo sshd -T | grep '^port '

پورت مدیریت واقعی، وب‌سرور، VPN و هر سرویس ضروری را همراه با مبدا موردنیاز بنویسید. دیتابیس، Redis و پنل داخلی معمولاً نباید برای همه‌ی اینترنت مجاز شوند. اگر پنل ابری یا روتر نیز firewall دارد، policy آن لایه را جدا ثبت کنید؛ UFW فقط ترافیکی را کنترل می‌کند که به سیستم‌عامل رسیده است.

برای هر فرمان rule می‌توانید ابتدا نسخه‌ی --dry-run را ببینید؛ برای نمونه sudo ufw --dry-run allow 80/tcp تغییر تولیدشده را چاپ می‌کند ولی آن را اعمال نمی‌کند.

۲) پیش از enable، راه SSH را دقیقاً مجاز کنید

اگر sshd روی پورت 22 گوش می‌دهد، ابتدا TCP همان پورت را مجاز کنید. برای پورت سفارشی عدد واقعی را جایگزین کنید:

sudo ufw allow 22/tcp comment 'SSH administration'
sudo ufw status numbered

اگر IP ثابت مدیریتی دارید، rule محدودتر بهتر است؛ اما پیش از محدودسازی مطمئن شوید IP خروجی شما واقعاً ثابت است. نمونه زیر فقط الگوی نحوی است و ADMIN_PUBLIC_IP باید با آدرس معتبر جایگزین شود:

sudo ufw allow proto tcp from ADMIN_PUBLIC_IP to any port 22 comment 'SSH from admin IP'

داشتن هم‌زمان یک allow عمومی و یک allow محدود، محدودسازی واقعی ایجاد نمی‌کند؛ rule عمومی همچنان دسترسی را باز می‌گذارد. ابتدا rule محدود را اضافه و از یک پنجره‌ی دوم تست کنید، سپس فقط پس از تأیید، درباره حذف rule وسیع تصمیم بگیرید. نشست فعلی و کنسول را تا پایان باز نگه دارید.

۳) policy پایه را تعیین و UFW را مرحله‌ای فعال کنید

برای یک VPS که gateway یا router نیست، الگوی رایج ردکردن ورودی ناخواسته و اجازه‌ی خروجی است. این فرمان‌ها state فایروال را تغییر می‌دهند؛ فقط پس از ثبت rule SSH و داشتن کنسول اجرا کنید:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

UFW اتصال‌های established را دنبال می‌کند، اما تضمین نکنید نشست فعلی برای همیشه شما را نجات می‌دهد. بلافاصله یک اتصال SSH تازه باز کنید. اگر آزمون دوم موفق نیست، نشست اول را نبندید و rule، پورت و IP مبدا را اصلاح کنید.

برای ماشین‌هایی که packet forwarding، VPN gateway، Kubernetes یا bridge شبکه انجام می‌دهند، policy routed جداگانه اهمیت دارد و این الگوی ساده کافی نیست. قبل از تغییر forwarding، طراحی مسیر و NAT را مستند کنید.

۴) فقط سرویس لازم را عمومی و سرویس حساس را محدود کنید

برای وب‌سرور عمومی معمولاً HTTP و HTTPS لازم‌اند. می‌توانید عدد پورت یا profile برنامه را پس از مشاهده‌ی جزئیات آن استفاده کنید:

sudo ufw app info 'Nginx Full'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw status numbered

برای یک سرویس داخلی، مبدا را محدود کنید. مثال زیر فقط اتصال MySQL از IP خصوصی برنامه را می‌پذیرد؛ علاوه بر UFW، خود دیتابیس نیز باید روی آدرس مناسب bind و حسابش حداقل مجوز را داشته باشد:

sudo ufw allow proto tcp from 10.0.0.10 to any port 3306 comment 'MySQL from app host'

پورت برنامه‌ی Node.js که پشت Nginx روی 127.0.0.1:3000 گوش می‌دهد نباید در UFW عمومی شود. bind کردن سرویس به loopback و استفاده از reverse proxy سطح مواجهه را از بازکردن مستقیم پورت برنامه کمتر می‌کند.

۵) ruleها را بخوانید، تغییر دهید و قابل بازگشت نگه دارید

sudo ufw status numbered ترتیب و شماره ruleها را نشان می‌دهد. حذف با شماره ممکن است پس از هر حذف شماره‌های بعدی را جابه‌جا کند؛ بنابراین پیش از هر حذف دوباره فهرست بگیرید و متن rule هدف را ثبت کنید. از ufw reset به‌عنوان میانبر استفاده نکنید، چون همه‌ی ruleها را پاک و دسترسی را در معرض خطا قرار می‌دهد.

برای تغییر یک rule مدیریتی این ترتیب امن‌تر است: rule جدید را اضافه کنید، از مسیر واقعی تست کنید، rule قبلی را شناسایی کنید، حذف هدفمند را در پنجره‌ی نگهداری انجام دهید و دوباره تست بگیرید. برای دیدن log محدود فایروال:

sudo ufw logging low
sudo journalctl -k --grep='UFW' -n 100 --no-pager

logging زیاد روی سرور پرترافیک می‌تواند فضای دیسک و I/O را مصرف کند. از سطح پایین شروع، مصرف journal را پایش و پس از تشخیص سطح را متناسب کنید. محتوای log ممکن است IP کاربران را داشته باشد و باید با سیاست نگهداری داده هماهنگ باشد.

۶) IPv6، Docker و خطاهای رایج را فراموش نکنید

وضعیت IPv6 را در /etc/default/ufw و خروجی ip -6 address بررسی کنید. اگر دامنه رکورد AAAA دارد، policy ناقص IPv6 می‌تواند باعث شود اتصال برخی کاربران با IPv4 کار کند و برای برخی شکست بخورد. غیرفعال‌کردن IPv6 بدون شناخت وابستگی‌ها راه‌حل عمومی نیست؛ ruleهای هر دو خانواده را هماهنگ کنید.

Docker برای پورت‌های publishشده ruleهای netfilter خود را می‌سازد. مستند رسمی Docker هشدار می‌دهد که ترافیک publishشده ممکن است پیش از زنجیره‌های معمول UFW پردازش شود؛ بنابراین ufw deny به‌تنهایی تضمین نمی‌کند پورت کانتینر بیرونی بسته باشد. فقط پورت ضروری را publish کنید و در صورت امکان آن را به 127.0.0.1 یا reverse proxy bind کنید.

اگر سرویس بعد از enable شدن در دسترس نیست، سه چیز را کنار هم بگذارید: ss برای listener، ufw status numbered برای policy میزبان و ruleهای پنل/روتر برای لایه‌ی بالادستی. تغییر تصادفی هر سه لایه به‌طور هم‌زمان علت واقعی را پنهان می‌کند.