راه‌اندازی سرور لینوکس Ubuntu و امن‌سازی آن در ۸ گام

راه‌اندازی سرور لینوکس فقط نصب سیستم‌عامل و بالا آوردن اپلیکیشن نیست؛ چند دقیقه پس از روشن شدن هر سرور عمومی، ربات‌ها سراغش می‌آیند و رمزهای ضعیف SSH را امتحان می‌کنند. در این آموزش یک سرور Ubuntu تازه را در هشت گام کوتاه امن می‌کنیم: کاربر جدا، ورود با کلید، فایروال، Fail2ban و به‌روزرسانی خودکار امنیتی.

خلاصه در یک نگاه

• با کاربر root کار نکنید؛ یک کاربر sudo بسازید.
• ورود با کلید SSH را فعال و ورود با رمز عبور را خاموش کنید.
• پیش از روشن کردن ufw، اجازه SSH را بدهید.
• Fail2ban و unattended-upgrades را نصب و بررسی کنید.
• همیشه یک نشست SSH باز نگه دارید تا تغییرات را با خیال راحت آزمایش کنید.

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

این آموزش برای Ubuntu 26.04 LTS، تازه‌ترین نسخه با پشتیبانی بلندمدت (LTS)، نوشته شده و همه دستورهایش روی Ubuntu 24.04 LTS هم بدون تغییر کار می‌کند. طبق چرخه انتشار رسمی Ubuntu، نسخه‌های LTS هر دو سال یک بار منتشر می‌شوند و پنج سال به‌روزرسانی امنیتی استاندارد می‌گیرند.

به این موارد نیاز دارید:

• یک سرور مجازی (VPS) یا فیزیکی با آدرس IP عمومی و دسترسی اولیه root یا یک کاربر sudo.
• ترمینال روی سیستم خودتان: در لینوکس و مک ترمینال پیش‌فرض، در ویندوز PowerShell یا WSL.
• دسترسی کنسول وب در پنل ارائه‌دهنده سرور. اگر اشتباهی شما را از SSH بیرون انداخت، این کنسول راه نجات است.

اگر با دستورهای پایه ترمینال راحت نیستید، اول کار با cd، ls، nano و sudo را مرور کنید.

گام ۱: به‌روزرسانی سیستم و انتخاب میرور مناسب

اولین کار روی هر سرور تازه، نصب آخرین وصله‌های امنیتی است:

sudo apt update
sudo apt full-upgrade -y
sudo reboot

پس از راه‌اندازی دوباره، دوباره وارد شوید. اگر سرور شما در ایران است، دریافت بسته از مخزن‌های خارجی ممکن است کند یا ناپایدار باشد. در فهرست رسمی میرورهای Ubuntu در Launchpad چند میرور داخلی ثبت شده است. از Ubuntu 24.04 به بعد، آدرس مخزن‌ها در فایل /etc/apt/sources.list.d/ubuntu.sources است و کافی است مقدار URIs را با آدرس میرور انتخابی جایگزین کنید. فقط از میرورهایی استفاده کنید که در همین فهرست رسمی آمده‌اند؛ بسته‌ها با امضای Ubuntu بررسی می‌شوند، اما منبع ناشناس همچنان ریسک دسترس‌پذیری دارد.

گام ۲: ساخت کاربر غیر root با دسترسی sudo

کار روزمره با root یعنی هر اشتباه تایپی کل سیستم را در معرض خطر می‌گذارد. یک کاربر معمولی بسازید (در این آموزش نامش deploy است) و او را به گروه sudo اضافه کنید:

sudo adduser deploy
sudo usermod -aG sudo deploy

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

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

ورود با کلید SSH (SSH Key) در برابر حدس زدن رمز عملاً مقاوم است. مستندات Ubuntu الگوریتم ed25519 را توصیه می‌کند. روی سیستم خودتان (نه سرور) یک جفت کلید بسازید:

ssh-keygen -t ed25519 -C "deploy@my-server"

برای کلید یک عبارت عبور (Passphrase) بگذارید تا اگر لپ‌تاپ شما دزدیده شد، کلید به‌تنهایی قابل استفاده نباشد. حالا کلید عمومی را روی سرور قرار دهید. اگر فعلاً با رمز عبور وارد سرور می‌شوید:

ssh-copy-id deploy@203.0.113.10

بسیاری از ارائه‌دهنده‌ها از ابتدا فقط ورود با کلید برای root را فعال می‌کنند و ssh-copy-id با خطا روبه‌رو می‌شود. در این حالت، همان کلیدی را که root با آن وارد می‌شود برای کاربر جدید کپی کنید (این دستور را روی سرور و با root اجرا کنید):

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

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

ssh deploy@203.0.113.10
sudo whoami   # should print: root

گام ۴: مقاوم‌سازی تنظیمات SSH

طبق مستندات Ubuntu، خط Include /etc/ssh/sshd_config.d/*.conf در ابتدای فایل اصلی تنظیمات قرار دارد، پس بهتر است تغییرات را در یک فایل جدا بنویسید تا به‌روزرسانی بسته‌ها آن را بازنویسی نکند. یک نکته ظریف: در OpenSSH اولین مقداری که خوانده شود اعمال می‌شود و فایل‌های این پوشه به ترتیب الفبایی خوانده می‌شوند. در بعضی ایمیج‌های ابری، cloud-init فایلی مثل 50-cloud-init.conf در همین پوشه می‌سازد که ممکن است PasswordAuthentication yes داشته باشد؛ برای همین نام فایل ما با 00 شروع می‌شود تا زودتر خوانده شود:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy

خط AllowUsers فقط به کاربرهای نام‌برده اجازه ورود می‌دهد؛ اگر نام کاربر شما چیز دیگری است، همین‌جا اصلاحش کنید. با MaxAuthTries 3، اگر ssh-agent شما کلیدهای زیادی دارد ممکن است پیش از رسیدن به کلید درست خطای «Too many authentication failures» بگیرید؛ در این حالت کلید را با -i و گزینه -o IdentitiesOnly=yes مشخص کنید. سپس تنظیمات را آزمایش و سرویس را دوباره راه‌اندازی کنید. دستور اول اگر خطای نحوی باشد آن را گزارش می‌کند و دستور دوم تنها در صورت موفقیت اجرا می‌شود:

sudo sshd -t && sudo systemctl restart ssh.service
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers'

قانون طلایی: نشست فعلی SSH را نبندید. در ترمینال دوم دوباره با deploy وارد شوید. فقط وقتی ورود جدید موفق بود، نشست قبلی را ببندید.

گام ۵: روشن کردن فایروال ufw بدون قفل شدن پشت در

ابزار ufw (Uncomplicated Firewall) روی Ubuntu نصب است اما به‌طور پیش‌فرض خاموش است. سیاست پیش‌فرض را «رد ورودی، اجازه خروجی» بگذارید و پیش از روشن کردن فایروال اجازه SSH را بدهید:

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

اگر ترتیب این دستورها جابه‌جا شود، پس از ufw enable اتصال تازه SSH ممکن نیست و نشست فعلی هم ممکن است قطع شود؛ ufw هنگام روشن شدن همین را هشدار می‌دهد. بعدها برای وب‌سرور، پورت‌های لازم را جداگانه باز کنید؛ مثلاً sudo ufw allow 'Nginx Full' پس از نصب nginx. اگر فقط از یک IP ثابت به سرور وصل می‌شوید، می‌توانید SSH را به همان IP محدود کنید. اول قاعده جدید را اضافه کنید و بعد قاعده عمومی OpenSSH را حذف کنید؛ وگرنه قاعده عمومی همچنان همه را راه می‌دهد:

sudo ufw allow proto tcp from 198.51.100.7 to any port 22
sudo ufw delete allow OpenSSH
sudo ufw status numbered

این کار را فقط وقتی انجام دهید که IP شما واقعاً ثابت است؛ اگر IP اینترنت شما عوض شود، تنها راه ورود کنسول وب پنل خواهد بود.

یک هشدار: Docker برای پورت‌هایی که با -p منتشر می‌کند مستقیماً قواعد iptables می‌سازد و این پورت‌ها ممکن است از ufw عبور کنند. اگر کانتینر اجرا می‌کنید، سرویس‌های داخلی را فقط روی 127.0.0.1 منتشر کنید.

گام ۶: مسدود کردن تلاش‌های مکرر ورود با Fail2ban

Fail2ban لاگ‌های ورود ناموفق را می‌خواند و IP مهاجم را برای مدتی مسدود می‌کند:

sudo apt install -y fail2ban

در بسته Ubuntu 24.04 و 26.04، فایل پیش‌فرض defaults-debian.conf زندان (Jail) مربوط به SSH را فعال می‌کند و رویدادها را از systemd journal می‌خواند. برای تنظیم سخت‌گیری، یک فایل در پوشه jail.d بسازید و فایل‌های اصلی را دست نزنید:

sudo nano /etc/fail2ban/jail.d/sshd.local

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

خروجی دستور آخر تعداد تلاش‌های ناموفق و IPهای مسدودشده را نشان می‌دهد.

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

بسته unattended-upgrades روی Ubuntu Server معمولاً نصب است. مطمئن شوید فعال است و یک اجرای آزمایشی بگیرید:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade -v --dry-run

تنظیمات رفتار در /etc/apt/apt.conf.d/50unattended-upgrades است؛ از جمله گزینه Unattended-Upgrade::Automatic-Reboot برای راه‌اندازی دوباره خودکار. اگر ترجیح می‌دهید ریبوت دستی باشد، وجود فایل /var/run/reboot-required را مرتب بررسی کنید و در زمان کم‌ترافیک سرور را راه‌اندازی دوباره کنید.

گام ۸: جزئیات کوچک اما مهم

منطقه زمانی و نام میزبان را درست تنظیم کنید تا لاگ‌ها قابل‌خواندن باشند:

sudo timedatectl set-timezone Asia/Tehran
sudo hostnamectl set-hostname web-01
timedatectl status

چند عادت دیگر هم ارزش دارد:

• سرویس‌هایی را که لازم ندارید نصب نکنید؛ هر سرویس اضافه یک سطح حمله اضافه است.
• با sudo ss -tulpn ببینید چه پورت‌هایی باز است و چه برنامه‌ای پشت هرکدام گوش می‌دهد.
• پایگاه داده و کش را فقط روی 127.0.0.1 یا شبکه خصوصی در دسترس بگذارید، نه روی اینترنت.
• از داده‌ها نسخه پشتیبان خودکار روی مکانی جدا از خود سرور بگیرید و بازیابی را هم آزمایش کنید.

ورودها را زیر نظر بگیرید

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

sudo journalctl -u ssh --since "24 hours ago" | grep -i "failed\|accepted"

اگر ورود موفقی از IP یا در ساعتی دیدید که انتظارش را نداشتید، فوراً کلیدهای موجود در ~/.ssh/authorized_keys را بررسی کنید و کلید ناشناخته را حذف کنید.

چک‌لیست نهایی راه‌اندازی سرور لینوکس

قدم بعدی

سرور شما حالا پایه امنی دارد. برای اجرای اپلیکیشن، آموزش Docker برای توسعه‌دهندگان را ببینید و بعد استقرار را با CI/CD با GitHub Actions خودکار کنید. اگر اپلیکیشن وب منتشر می‌کنید، مرور راهنمای OWASP Top 10 کمک می‌کند امنیت را از لایه سرور تا کد ادامه دهید.