امن‌سازی اولیه سرور اوبونتو در ۳۰ دقیقه

لحظه‌ای که یک سرور اوبونتو روی اینترنت عمومی بالا می‌آید، پورت ۲۲ آن هدف اسکن و تلاش‌های خودکار ورود قرار می‌گیرد؛ نه چون کسی شما را می‌شناسد، بلکه چون ربات‌ها کل فضای آدرس اینترنت را جارو می‌کنند. این راهنما یک چک‌لیست عملی به شما می‌دهد که پنج کنترل امنیتی پایه را در کمتر از ۳۰ دقیقه پیاده می‌کند: کاربر sudo و کلید SSH، سخت‌سازی sshd، فایروال ufw، fail2ban و به‌روزرسانی خودکار امنیتی. همه‌ی دستورها روی نسخه‌های LTS پرکاربرد (۲۲.۰۴ و ۲۴.۰۴) یکسان است و روی نسخه‌های جدیدتر نیز به همین شکل کار می‌کند.

پیش از شروع: چه چیزی لازم دارید

قبل از هر تغییری، مطمئن شوید به یکی از این دو راه دسترسی جایگزین دارید تا اگر خودتان را از SSH بیرون انداختید، قفل نشوید:

1. دسترسی به کنسول یا VNC از پنل ارائه‌دهنده (اکثر سرویس‌های ابری و VPS این را می‌دهند).
2. یک نشست SSH باز و فعال که تا پایان کار آن را نبندید.

این نکته مهم‌ترین بخش کل فرایند است: امن‌سازی SSH یعنی بستن درها، و اگر کلید یا مسیر جایگزین نداشته باشید ممکن است خودتان پشت در بمانید.

چک‌لیست ۳۰ دقیقه‌ای امن‌سازی سرور اوبونتو

گام ۱: کاربر sudo و کلید SSH

هیچ‌گاه روزمره با کاربر root کار نکنید. یک کاربر معمولی بسازید و او را عضو گروه sudo کنید تا هر اقدام مدیریتی قابل‌ردیابی به یک حساب مشخص باشد:

1. adduser deploy
2. usermod -aG sudo deploy

سپس روی دستگاه محلی خودتان (نه روی سرور) یک جفت‌کلید بسازید و کلید عمومی را روی سرور قرار دهید:

1. ساخت کلید: ssh-keygen -t ed25519
2. کپی به سرور: ssh-copy-id deploy@SERVER_IP

پیش از رفتن به گام بعد، از یک ترمینال جداگانه با کلید وارد شوید و مطمئن شوید ~/.ssh/authorized_keys کاربر شامل کلید عمومی شماست. مستندات Red Hat هم صراحتاً تأکید می‌کنند که قبل از غیرفعال‌کردن احراز هویت با رمز، باید تأیید کنید حداقل یک کاربر کلید عمومی فعال دارد و می‌توانید با آن وارد شوید.

گام ۲: سخت‌سازی SSH

مؤثرترین دو تغییر امنیتی روی SSH، غیرفعال‌کردن احراز هویت با رمز عبور و بستن ورود مستقیم root است؛ این دو، حمله‌ی brute-force روی گذرواژه را عملاً بی‌اثر می‌کنند. فایل /etc/ssh/sshd_config (یا یک فایل در /etc/ssh/sshd_config.d/) را ویرایش کنید و مقادیر زیر را تنظیم کنید:

یک نکته‌ی دقیق درباره‌ی PermitRootLogin: مستندات Red Hat اشاره می‌کند که در RHEL 10 مقدار پیش‌فرض این گزینه prohibit-password است، یعنی ورود root فقط با کلید ممکن است. اما همان مستندات توضیح می‌دهد که حتی حالت «فقط با کلید» به این معناست که یک کلید root دزدیده‌شده، شل مستقیم root به مهاجم می‌دهد؛ به همین دلیل توصیه‌ی سخت‌گیرانه‌تر، مقدار no و ارتقای دسترسی از یک کاربر نام‌دار با sudo است.

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

1. تست پیکربندی: sudo sshd -t
2. اعمال: sudo systemctl restart ssh

سرویس را در همان نشست فعلی ری‌استارت کنید و بدون بستن آن، از یک ترمینال جدید ورود با کلید را امتحان کنید. اگر جواب داد، حالا امن است که نشست قدیمی را ببندید.

گام ۳: فایروال ufw

اوبونتو ابزار ufw را به‌همراه دارد اما به‌صورت پیش‌فرض آن را غیرفعال می‌گذارد. طبق مستندات رسمی سرور اوبونتو، فعال‌سازی با sudo ufw enable و اجازه‌ی دسترسی SSH با sudo ufw allow ssh (یا sudo ufw allow 22) انجام می‌شود. توالی امن به این شکل است:

1. sudo ufw default deny incoming
2. sudo ufw default allow outgoing
3. sudo ufw allow ssh (قبل از enable تا قفل نشوید)
4. در صورت وب‌سرور: sudo ufw allow 80,443/tcp
5. sudo ufw enable

ufw یک قابلیت محدودسازی نرخ اتصال هم دارد: sudo ufw limit ssh به‌جای allow، اتصال‌های پرتکرار از یک IP را کند می‌کند. در خروجی نمونه‌ی مستندات اوبونتو دیده می‌شود که قاعده‌ی زیربنایی این محدودسازی، اتصال را تا حدود ۳ بار در دقیقه محدود می‌کند؛ همین قبل از آنکه fail2ban حتی بیدار شود، بخشی از حملات brute-force را خفه می‌کند. اگر آدرس ثابت دارید، سخت‌گیرانه‌تر این است که SSH را فقط از IP خودتان باز کنید: sudo ufw allow from YOUR_IP to any port 22.

گام ۴: fail2ban

fail2ban لاگ‌ها را می‌خواند و IPهایی را که چند بار ناموفق تلاش کرده‌اند موقتاً بلاک می‌کند. نصب: sudo apt install fail2ban. طبق پیکربندی رسمی پروژه (jail.conf)، هرگز فایل jail.conf را مستقیم ویرایش نکنید؛ تنظیمات خود را در jail.local یا jail.d/*.local بگذارید تا با هر به‌روزرسانی بازنویسی نشود. مقادیر پیش‌فرض همان فایل عبارت‌اند از bantime = 10m، findtime = 10m و maxretry = 5.

یک /etc/fail2ban/jail.local ساده و کاربردی:

1. [DEFAULT]
2. bantime = 1h
3. findtime = 10m
4. maxretry = 3
5. [sshd]
6. enabled = true

سپس sudo systemctl restart fail2ban و بررسی وضعیت با sudo fail2ban-client status sshd. صادقانه بگوییم: اگر گام ۲ را کامل انجام داده باشید و احراز هویت با رمز بسته باشد، حملات brute-face روی گذرواژه دیگر بی‌اثرند و fail2ban بیشتر یک لایه‌ی دفاع در عمق است تا خط اول دفاع. با این حال، ارزش دارد چون نویز و بار ناشی از اسکن‌ها را کم می‌کند و برای سرویس‌های دیگر (نه فقط SSH) هم قابل‌گسترش است.

گام ۵: به‌روزرسانی خودکار امنیتی

بسته‌ی unattended-upgrades طبق مستندات رسمی اوبونتو به‌صورت پیش‌فرض روی اوبونتو نصب است و نصب خودکار وصله‌های امنیتی را ممکن می‌کند. روشن‌بودن آن با دو کلید در /etc/apt/apt.conf.d/20auto-upgrades کنترل می‌شود؛ مقدار "1" برای هر دو، اجرای روزانه را فعال می‌کند:

1. APT::Periodic::Update-Package-Lists "1";
2. APT::Periodic::Unattended-Upgrade "1";

برای فعال‌سازی تعاملی می‌توانید sudo dpkg-reconfigure unattended-upgrades را اجرا کنید. رفتار به‌روزرسانی (مثل کدام مخازن و تنظیمات ری‌استارت) در /etc/apt/apt.conf.d/50unattended-upgrades تعریف می‌شود. اینجا یک نکته‌ی مهم و صادقانه هست: طبق مستندات اوبونتو، ری‌استارت خودکار به‌صورت پیش‌فرض خاموش است. اگر Unattended-Upgrade::Automatic-Reboot "true"; را روشن کنید، سرور برای اعمال به‌روزرسانی هسته بدون تأیید ری‌استارت می‌شود؛ این یعنی معامله‌ی «امنیت به‌روز» در برابر «قطعی ناگهانی». اگر آن را روشن می‌کنید، حتماً یک پنجره‌ی زمانی خارج از ساعات کاری تعیین کنید:

1. Unattended-Upgrade::Automatic-Reboot "true";
2. Unattended-Upgrade::Automatic-Reboot-Time "03:00";
3. Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

معایب و مرزهای این چک‌لیست

این پنج گام سطح حمله را به‌شدت کم می‌کنند، اما جادو نیستند و چند نکته را باید صادقانه بدانید:

1. خطر قفل‌شدن: ورود فقط با کلید یعنی اگر کلید خصوصی را گم کنید، تنها راه بازگشت، کنسول/rescue ارائه‌دهنده است. کلید را پشتیبان بگیرید.
2. قطعی ناشی از ری‌استارت خودکار: همان‌طور که گفتیم، به‌روزرسانی خودکار هسته می‌تواند در بدترین زمان سرور را ری‌استارت کند؛ روی سرویس‌های حساس یا بدون افزونگی، پنجره‌ی زمانی یا خاموش‌گذاشتن ری‌استارت خودکار عاقلانه‌تر است.
3. این پایه است، نه کل ماجرا: این چک‌لیست جایگزین پشتیبان‌گیری منظم، مانیتورینگ، مدیریت مخفی‌ها (secrets) و امن‌سازی خودِ برنامه‌ها نیست. امنیت شبکه در سطح ارائه‌دهنده هم موضوعی جداست.
4. fail2ban خط اول نیست: بزرگ‌ترین برد از آنِ کلیدمحورکردن SSH است؛ fail2ban و ufw limit لایه‌های مکمل‌اند، نه جایگزین آن.

قدم بعدی

یک قاعده‌ی ساده برای تصمیم: اگر سرور شما به اینترنت عمومی دید دارد و بیش از یک نشست را نمی‌بندید، همین امروز گام‌های ۱ و ۲ (کلید SSH و بستن رمز/root) را انجام دهید؛ این دو بیشترین کاهش ریسک را با کمترین کار می‌دهند. گام‌های ۳ تا ۵ را می‌توانید طی همان نیم‌ساعت کامل کنید. اگر هنوز در حال انتخاب زیرساخت هستید، پیش از خرید ببینید ارائه‌دهنده‌تان دسترسی کنسول/VNC و اسنپ‌شات می‌دهد یا نه — چون همان‌ها هستند که وقتی خودتان را از SSH بیرون انداختید نجاتتان می‌دهند. برای انتخاب محل و نوع سرور می‌توانید راهنمای مقایسه‌ی VPS ایران و خارج و صفحه‌ی سرور مجازی ایران (شیراز) را ببینید؛ برای بارهای سنگین‌تر هم سرورهای اختصاصی گزینه‌ی مناسبی هستند.

منابع

1. Automatic updates — Ubuntu Server documentation (unknown)
2. Firewalls (ufw) — Ubuntu Server documentation (unknown)
3. Using secure communications between two systems with OpenSSH — Red Hat Enterprise Linux 10 (unknown)
4. fail2ban jail.conf (official default configuration) (unknown)
5. Security — Ubuntu Server documentation (unknown)

پرسش‌های پرتکرار

امن‌سازی اولیه سرور اوبونتو واقعاً چقدر طول می‌کشد؟

پنج کنترل پایه — کاربر sudo و کلید SSH، سخت‌سازی sshd، فایروال ufw، fail2ban و به‌روزرسانی خودکار — روی هم حدود ۲۵ تا ۳۰ دقیقه زمان می‌برد و بیشترین کاهش ریسک را با کمترین کار به شما می‌دهد.

آیا باید ورود با رمز عبور در SSH را کامل غیرفعال کنم؟

بله، مؤثرترین کار غیرفعال‌کردن PasswordAuthentication و استفاده از کلید است. اما اول مطمئن شوید کلید عمومی‌تان در authorized_keys کاربر هست و از یک ترمینال جدا با آن وارد می‌شوید؛ در غیر این صورت ممکن است پشت در بمانید.

با روشن‌بودن ورود کلیدمحور، آیا هنوز به fail2ban نیاز دارم؟

وقتی احراز هویت با رمز بسته باشد، حملات brute-force روی گذرواژه بی‌اثرند و fail2ban بیشتر یک لایه‌ی دفاع در عمق است. با این حال نویز اسکن‌ها را کم می‌کند و برای سرویس‌های دیگر هم قابل‌گسترش است، پس ارزش نگه‌داشتن دارد.

آیا به‌روزرسانی خودکار امنیتی سرور را خودش ری‌استارت می‌کند؟

طبق مستندات اوبونتو، ری‌استارت خودکار به‌صورت پیش‌فرض خاموش است. اگر Automatic-Reboot را روشن کنید، سرور برای اعمال وصله‌های هسته ممکن است ری‌استارت شود؛ بهتر است یک پنجره‌ی زمانی خارج از ساعات کاری (مثلاً 03:00) تعیین کنید.

مقادیر پیش‌فرض fail2ban چیست و کجا باید تغییرشان دهم؟

مقادیر پیش‌فرض در jail.conf عبارت‌اند از bantime و findtime برابر ۱۰ دقیقه و maxretry برابر ۵. تنظیمات خود را در jail.local یا jail.d/*.local بگذارید، نه در jail.conf، تا با به‌روزرسانی‌ها بازنویسی نشود.