تنظیم فایروال UFW روی سرور اوبونتو؛ قاعده های ضروری

اگه یه سرور مجازی اوبونتو داری و می خوای فقط پورت های لازم به روی اینترنت باز باشه، UFW سریع ترین راهه. تنظیم فایروال UFW یعنی چند دستور کوتاه: همه ورودی ها رو ببند، SSH و وب (پورت 80 و 443) رو باز کن و بعد فایروال رو روشن کن. فقط ترتیبش مهمه: قاعده SSH رو باید قبل از روشن کردن فایروال اضافه کنی، وگرنه از سرور خودت بیرون می مونی.

این راهنما برای کسیه که یه سرور تازه یا نیمه تنظیم شده داره و به root یا sudo دسترسی داره. شاید فروشگاه وردپرسی یا یه اپلیکیشن کوچیک روش بالا آورده باشی و هنوز کسی بهت نگفته کدوم درها باز موندن.

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

اول ببین کدوم درها بازن، بعد نگهبان بذار

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

این دستور نشون می ده چه سرویسی روی چه پورتی گوش می ده:

sudo ss -tulpn

ستون Local Address:Port مهم ترین قسمت خروجیه. اگه کنار پورت 0.0.0.0 یا [::] دیدی، یعنی اون سرویس روی همه کارت های شبکه گوش می ده و بدون فایروال از بیرون در دسترسه. اگه 127.0.0.1 بود، فقط خود سرور بهش وصل می شه. مثلاً MySQL که روی 127.0.0.1:3306 گوش می ده، از اینترنت دیده نمی شه. ولی اگه 0.0.0.0:3306 بود، باید جدی بگیریش.

یه نکته رو یادت باشه: UFW فقط ترافیک رو فیلتر می کنه و تنظیم خود سرویس رو عوض نمی کنه. بهترین کار اینه که هم تنظیم خود سرویس رو درست کنی (مثلاً bind-address دیتابیس) و هم فایروال داشته باشی. دو لایه، نه یکی.

بعدش وضعیت UFW رو ببین. روی بیشتر نصب های اوبونتو نصبه ولی غیرفعاله:

sudo ufw status

اگه Status: inactive دیدی، یعنی هنوز هیچ فیلتری در کار نیست. اگه نصب نبود، با sudo apt install ufw نصبش کن.

قبل از ادامه: مطمئن شو از کنسول یا VNC پنل سرویس دهنده هم می تونی وارد سرور بشی. اگه قاعده اشتباه بزنی و SSH قطع بشه، تنها راه نجاتت همینه. همین الان تستش کن، نه وقتی که گیر کردی.

تنظیم فایروال UFW در سه قدم: پیش فرض، SSH، وب

اول سیاست پیش فرض رو مشخص کن

sudo ufw default deny incoming
sudo ufw default allow outgoing

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

خروجی رو آزاد بذار. سرور برای آپدیت، DNS و اتصال به سرویس های بیرونی بهش نیاز داره. مثلاً توی فروشگاه، وقتی مشتری از درگاه پرداخت برمی گرده، سایتت باید به درگاه بانکی وصل بشه و تراکنش رو تأیید کنه. اگه خروجی رو بی فکر ببندی، همین تأیید می شکنه و پرداخت ها ناقص می مونن.

SSH رو قبل از روشن کردن فایروال باز کن

sudo ufw allow OpenSSH

یا اگه پروفایل نداری:

sudo ufw allow 22/tcp

اگه پورت SSH رو عوض کردی، همون پورت رو باز کن، نه 22 رو. پروفایل OpenSSH پورت 22 رو فرض می کنه، پس اگه مثلاً روی 2222 کار می کنی، اینجوری بنویس:

sudo ufw allow 2222/tcp

اشتباه رایج: یکی ufw enable رو می زنه و تازه یادش میاد SSH رو باز نکرده. جلسه فعلی معمولاً زنده می مونه، ولی اتصال جدید رد می شه. به محض قطع شدن همون جلسه، دیگه نمی تونی وارد بشی.

وب رو باز کن و فایروال رو روشن کن

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

اگه Nginx یا Apache نصب کردی، پروفایل های Nginx Full و Apache Full هر دو پورت رو یکجا باز می کنن. پورت 80 رو نبند، حتی اگه سایتت کامل روی HTTPS باشه. اولاً کاربرها هنوز با http:// میان و باید ریدایرکت بشن. ثانیاً بعضی روش های صدور و تمدید گواهی به این پورت نیاز دارن. اگه مطمئن نیستی گواهی رایگان یا پولی چه فرقی داره، SSL رایگان یا پولی؛ برای امنیت سایت کدام بهتر است؟ رو بخون.

همه چیز یکجا، آماده کپی:

sudo ufw default deny incoming     # ورودی ها پیش فرض بسته
sudo ufw default allow outgoing    # خروجی آزاد
sudo ufw allow OpenSSH             # SSH، قبل از enable
sudo ufw allow 80/tcp              # HTTP
sudo ufw allow 443/tcp             # HTTPS
sudo ufw enable                    # روشن کردن؛ پیام هشدار رو بخون و y بزن
sudo ufw status verbose            # تأیید نهایی

وقتی enable رو می زنی، یه پیام هشدار می ده که ممکنه اتصال SSH قطع بشه. اگه قاعده SSH رو اضافه کرده باشی، با خیال راحت y بزن.

قاعده های دقیق تر: هر پورت فقط برای کسی که لازمش داره

پورت رو به یه IP یا یه بازه محدود کن

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

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow from 10.0.0.5 to any port 3306 proto tcp

خط اول SSH رو فقط برای یه IP مشخص باز می کنه. خط دوم پورت دیتابیس رو فقط برای سرور اپلیکیشن باز می کنه. نشانی ها نمونه هستن و باید با IP خودت عوض بشن. اگه قبلاً allow OpenSSH یا allow 22/tcp زدی، اون قاعده عمومی رو پاک کن، وگرنه محدودیت جدید اثری نداره.

یه موقعیت آشنا: فروشگاه وردپرسی و دیتابیس جدا

فرض کن مدیر یه فروشگاه اینترنتی هستی. سایت روی یه سرور مجازی ایران بالاست و دیتابیس روی سرور دومه. اگه پورت 3306 سرور دیتابیس برای همه باز باشه، هر رباتی می تونه رمزها رو امتحان کنه. با قاعده بالا فقط IP سرور وب رو راه می دی و بقیه پشت در می مونن.

الگوی درست همینه: فقط وب سرور پورت عمومی داره و دیتابیس و سرویس های داخلی توی شبکه داخلی هستن، بدون دسترسی بیرونی. اگه بخوای این معماری رو برای کسب و کارت بچینی، می تونی از مدیریت و امن سازی سرور کمک بگیری.

یه محدودیت واقعی هم هست: محدود کردن SSH به IP وقتی خوبه که IP ثابت داشته باشی. خیلی از اینترنت های خانگی و موبایل IP ثابت نمی دن و یه روز IP عوض می شه و خودت بیرون می مونی. اگه IP ثابت نداری، از کلید SSH استفاده کن و ورود با رمز رو ببند. محدودیت IP رو هم فقط وقتی اضافه کن که راه جایگزین (مثل کنسول سرویس دهنده) داری.

ترتیب قاعده ها مهمه

UFW قاعده ها رو از بالا به پایین می خونه و اولین قاعده منطبق اجرا می شه. پس اگه یه deny بذاری و بعدش allow اضافه کنی، ممکنه allow هیچ وقت اجرا نشه. برای گذاشتن قاعده توی جای مشخص:

sudo ufw insert 1 allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw status numbered
sudo ufw delete 3

دستور دوم قاعده ها رو شماره دار نشون می ده و سومی قاعده شماره 3 رو پاک می کنه. عدد 3 فقط مثاله. قبل از هر delete فهرست شماره دار رو دوباره بخون، چون بعد از هر حذف شماره ها جابه جا می شن.

جلوی تلاش های پشت سرهم رو بگیر

sudo ufw limit OpenSSH

این دستور اگه یه IP در مدت کوتاه بارها به SSH وصل بشه، اتصال های بعدیش رو موقتاً رد می کنه. نتیجه اش اینه که حدس زدن رمز با ربات کند می شه. limit جای allow رو می گیره، پس اگه قبلاً allow OpenSSH زدی، اون رو با delete پاک کن تا قاعده تکراری نمونه. این هم جای کلید SSH و رمز قوی رو نمی گیره و فقط یه لایه اضافه حساب می شه.

داکر قاعده های UFW رو دور می زنه

اگه با Docker کار نمی کنی، این بخش رو رد کن. ولی اگه کار می کنی، حتماً بخونش، چون سورپرایزیه که خیلی ها دیر می فهمن.

Docker برای پورت هایی که با -p منتشر می کنی، مستقیم قاعده iptables می نویسه و این قاعده ها قبل از قاعده های UFW اجرا می شن. نتیجه اینه که ممکنه ufw status همه چیز رو بسته نشون بده، ولی کانتینرت روی پورت 8080 برای کل اینترنت باز باشه. با دیدن همون خروجی هم فکر می کنی اوضاع امنه.

راه حل های ساده:

• پورت رو فقط روی لوکال منتشر کن: -p 127.0.0.1:8080:80. بعد Nginx روی میزبان درخواست ها رو به همون پورت لوکال پروکسی می کنه.
• برای کنترل واقعی، قاعده ها رو توی زنجیره DOCKER-USER بذار. این زنجیره قبل از قاعده های خود Docker اجرا می شه.

اگه بخوای فقط CDN به سرور برسه، می تونی قاعده ای شبیه این توی همون زنجیره بذاری:

sudo iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.0/24 -p tcp --dport 80 -j DROP

بازه نمونه رو با بازه های اعلام شده سرویس CDN خودت عوض کن و اسم کارت شبکه رو هم چک کن. دو نکته مهم هست. اول اینکه توی این زنجیره --dport پورت داخل کانتینره، نه پورتی که بیرون منتشر کردی. دوم اینکه قاعده های iptables با ری استارت از بین می رن، مگر اینکه با ابزاری مثل iptables-persistent یا فایل after.rules ثابتشون کنی. قبل از اجرا روی سرور واقعی، روی یه محیط تست امتحانش کن.

اگه می خوای بدونی CDN دقیقاً چه چیزی رو جایگزین می کنه و چه چیزی رو نه، CDN برای سایت؛ آیا جای هاست قوی را می گیرد؟ رو ببین.

کدوم پورت ها رو باز کنم و کدوم رو نه؟

یه جدول کوتاه برای تصمیم گیری سریع:

اگه روی همین سرور ایمیل هم راه انداخته باشی، فایروال تنها مسئله نیست. رکوردهای DNS و اعتبار فرستنده هم روی رسیدن ایمیل اثر دارن. اسپم شدن ایمیل؛ مشکل از هاست است یا فرستنده؟ کمکت می کنه ریشه مشکل رو پیدا کنی.

اشتباه های رایج بعد از روشن کردن

IPv6 رو فراموش کردن. توی فایل /etc/default/ufw چک کن IPV6=yes باشه. معمولاً پیش فرض همینه، ولی اگه no باشه، قاعده ها فقط برای IPv4 اعمال می شن و پورت ها از طریق IPv6 باز می مونن. بعد از تغییر این فایل، sudo ufw disable و بعدش sudo ufw enable رو بزن.

تست نکردن از بیرون. دیدن قاعده ها توی ufw status کافی نیست. از یه سیستم دیگه (نه خود سرور) با nmap یا ابزار مشابه پورت ها رو اسکن کن و ببین فقط همونایی که می خوای باز هستن.

بستن پورتی که یه سرویس لازم داره. مثلاً پنل مدیریتی یا API ای که روی پورت غیراستاندارد کار می کنه. قبل از enable، دوباره ss -tulpn رو بخون و با فهرست قاعده هات مقایسه کن.

لاگ رو روشن کن. اگه می خوای ببینی چی رد می شه، sudo ufw logging on رو بزن و لاگ رو توی /var/log/ufw.log بخون. چند روز نگاه کردن کافیه تا بفهمی کی در می زنه. سطح لاگ رو بالا نذار، چون فضا می خوره.

اگه کار خراب شد: با کنسول سرویس دهنده وارد شو و sudo ufw disable بزن. بعد قاعده ها رو مرور کن، درستشون کن و دوباره enable کن. فقط در بدترین حالت سراغ sudo ufw reset برو، چون همه قاعده ها رو پاک می کنه.

یه حد هم برای انتظارت بذار: UFW جلوی حمله های حجمی (DDoS) رو نمی گیره و اون موضوع به لایه شبکه و سرویس دهنده برمی گرده. UFW فقط درهای اضافه رو می بنده. اگه می خوای بعد از این مرحله سرور رو دائم زیر نظر داشته باشی، مانیتورینگ و پایداری می تونه کمک کنه.

سوالات متداول

اگه فایروال رو روشن کردم و از SSH بیرون افتادم، چی کار کنم؟

از کنسول یا VNC پنل سرویس دهنده وارد سرور شو و sudo ufw disable رو بزن. بعد قاعده SSH رو اضافه کن، با ufw status چک کن و دوباره فایروال رو روشن کن. اگه کنسول نداری، باید از پشتیبانی سرویس دهنده کمک بخوای.

UFW جای فایروال پنل سرویس دهنده رو می گیره؟

نه، این دو مکمل همدیگه هستن. فایروال پنل معمولاً قبل از رسیدن ترافیک به سرور عمل می کنه و UFW روی خود سرور. داشتن هر دو لایه بهتره، ولی اگه فقط یکی رو می تونی تنظیم کنی، UFW کنترل بیشتری بهت می ده.

UFW روی سرعت سایت اثر می ذاره؟

با چند قاعده ساده، معمولاً اثر قابل توجهی نمی بینی. هزینه فیلتر کردن چند ده قاعده برای یه سرور وب معمولی ناچیزه. اگه سایتت کند شده، اول سراغ منابع سرور و کدها برو. بهبود LCP سایت؛ چرا بزرگ ترین عنصر صفحه دیر نمایش داده می شود؟ می تونه نقطه شروع خوبی باشه.

عوض کردن پورت SSH لازمه؟

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

چطور یه قاعده رو پاک کنم؟

با sudo ufw status numbered فهرست شماره دار رو ببین و بعد sudo ufw delete شماره رو بزن. یا می تونی خود قاعده رو بنویسی: sudo ufw delete allow 80/tcp. بعد از حذف، دوباره status رو بخون تا مطمئن بشی.

قبل از بستن ترمینال

اگه فقط یه چیز یادت بمونه، این ترتیب باشه: پورت های باز رو با ss -tulpn ببین، سیاست پیش فرض رو بذار، SSH رو باز کن، وب رو باز کن و آخر از همه enable رو بزن. بعدش از بیرون با ابزار اسکن بررسی کن. اگه Docker داری، قاعده هاش رو هم جدا مرور کن. این کارها زیاد وقتت رو نمی گیره و بعدش به جای نگرانی بابت درهای باز، می تونی روی کسب و کارت تمرکز کنی. اگه خواستی یه نفر سرور رو برات مرور کنه، با پشتیبانی فنی ما در تماس باش.