سروری که تازه تحویل گرفته‌اید، با یک رمز root در ایمیل و پورت 22 باز به روی کل اینترنت، در واقع یک هدف آماده است. تجربه نشان می‌دهد که تلاشهای ورود خودکار (brute force) معمولاً چند دقیقه پس از فعال شدن IP آغاز می‌شوند؛ بنابراین کارهایی که در ساعت اول انجام میدهید، امنیت و پایداری ماه‌های بعد را تعیین میکند. این راهنما یک چک‌لیست ۱۵ مرحله‌ای برای راه‌اندازی اولیهٔ سرور Ubuntu 24.04 LTS است: از ساخت کاربر غیر root و کلید SSH گرفته تا فایروال، بهروزرسانی خودکار، Swap و مانیتورینگ پایه‌ای، همراه با دستور دقیق و دلیل هر مرحله.
ورود نخست و ساخت کاربر مدیریتی
اولین اتصال را با همان رمز root که ارائهدهنده فرستاده برقرار کنید، اما از همین لحظه هدف شما این است که دیگر هرگز با root وارد نشوید. ایمیج‌های برخی ارائه‌دهندگان ورود root با رمز را باز گذاشته‌اند؛ پس فرض را بر باز بودن بگذارید.
ساخت کاربر با دسترسی sudo
adduser deploy
usermod -aG sudo deploy
su - deploy
sudo -vنام کاربر را چیزی غیر از admin یا ubuntu انتخاب کنید؛ فهرست‌های حمله دقیقاً همین نام‌های رایج را امتحان میکنند. دستور آخر فقط بررسی میکند که رمز و عضویت در گروه sudo درست کار میکند و هنوز چیزی را تغییر نمی‌دهد.
انتقال کلید SSH و قطع ورود با رمز
روی سیستم خودتان یک کلید Ed25519 (کوتاه‌تر و سریع‌تر از RSA) بسازید و کلید عمومی را به سرور منتقل کنید.
ssh-keygen -t ed25519 -C "deploy@laptop"
ssh-copy-id deploy@SERVER_IPپیش از بستن ورود با رمز، در یک ترمینال دوم با کلید وارد شوید و مطمئن شوید sudo کار میکند. سپس در فایل /etc/ssh/sshd_config.d/10-hardening.conf (نه فایل اصلی، تا به‌روزرسانی‌های بسته آن را بازنویسی نکند) این مقادیر را قرار دهید:
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
MaxAuthTries 3
AllowUsers deployبا sudo sshd -t نحو فایل را بررسی و با sudo systemctl restart ssh سرویس را راه‌اندازی مجدد کنید. اگر پورت SSH را تغییر میدهید، به خاطر داشته باشید که Ubuntu 24.04 از socket activation استفاده میکند و پورت باید در ssh.socket نیز تغییر کند، وگرنه تنظیم شما نادیده گرفته می‌شود.
بهروزرسانی سیستم و حذف بستههای اضافی
ایمیج‌هایی که ارائه‌دهندگان می‌سازند معمولاً چند هفته یا چند ماه قدیمی هستند. پیش از نصب هر چیزی، فهرست مخازن را تازه و همهٔ بسته‌ها را بهروز کنید:
sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove --purge -y
[ -f /var/run/reboot-required ] && sudo rebootاگر کرنل بهروز شده باشد، فایل reboot-required ساخته می‌شود و راه‌اندازی مجدد ضروری است؛ در غیر این صورت سرور با کرنل قدیمی و وصله‌نشده ادامه می‌دهد. در همین مرحله بستههای بلااستفاده مثل snapd را حذف کنید تا حافظه آزاد شود و سطح حمله کوچک‌تر بماند.
ابزارهای پایه‌ای که در ایمیج حداقلی وجود ندارند
ایمیج‌های minimal اوبونتو حتی curl و vim را هم ندارند. مجموعه‌ای که در عمل تقریباً روی هر سروری لازم می‌شود: curl wget git vim htop tmux unzip ncdu ca-certificates gnupg. نصب آن‌ها تنها چند ثانیه‌ای زمان می‌برد و از جست‌وجوی بعدی هنگام عیب‌یابی جلوگیری میکند.
فایروال UFW و محدودسازی تلاشهای ورود
Ubuntu 24.04 با UFW عرضه می‌شود که پوسته‌ای ساده روی nftables است. قاعدهٔ کلی: همه‌چیز بسته، فقط پورت‌هایی که سرویس عمومی دارند باز.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verboseگزینهٔ limit به‌جای allow برای SSH، آدرسی را که در ۳۰ ثانیه، بیش از ۶ اتصال باز کند موقتاً مسدود میکند. اگر پنل مدیریت یا دیتابیس روی پورت دیگری گوش می‌دهد، آن را فقط برای IP مشخص باز کنید: sudo ufw allow from 203.0.113.10 to any port 3306.
Fail2ban برای تلاشهای تکراری
Fail2ban لاگ SSH را می‌خواند و IPهایی را که چند بار رمز اشتباه وارد کرده‌اند برای مدت مشخصی مسدود میکند. پس از نصب با sudo apt install fail2ban، یک فایل /etc/fail2ban/jail.local بسازید و در بخش [sshd] مقادیر enabled = true، maxretry = 4 و bantime = 1h را قرار دهید. در Ubuntu 24.04 لاگ‌ها در journald هستند، بنابراین backend = systemd را هم در بخش [DEFAULT] اضافه کنید وگرنه Fail2ban چیزی نمی‌بیند.
نام میزبان، زمان و منطقهٔ زمانی
ساعت اشتباه خطاهای عجیبی می‌سازد: گواهی‌های SSL با ساعت اشتباه نامعتبر شناخته می‌شوند، cron در زمان غلط اجرا می‌شود و لاگهای چند سرور قابل مقایسه نیستند.
sudo hostnamectl set-hostname web1.example.com
sudo timedatectl set-timezone Asia/Tehran
timedatectl statusدر Ubuntu 24.04 سرویس systemd-timesyncd به‌صورت پیش‌فرض فعال است و معمولاً کافی است؛ خروجی timedatectl باید System clock synchronized: yes را نشان دهد؛ در غیر این صورت آدرس یک سرور NTP داخلی را در /etc/systemd/timesyncd.conf قرار دهید. نام میزبان را در /etc/hosts هم اضافه کنید تا sudo هر بار هشدار «unable to resolve host» ندهد.
Swap، محدودیت‌ها و چند تنظیم کرنل
بسیاری از ایمیج‌های VPS بدون Swap تحویل می‌شوند. روی سروری با 2 یا 4 گیگابایت رم، یک Swap کوچک (به‌عنوان قاعدهٔ سرانگشتی نصف رم تا حداکثر 4 گیگابایت) مانع از آن می‌شود که OOM Killer در اوج مصرف، MySQL یا PHP-FPM را بکشد.
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/90-swap.confتنظیمات sysctl که روی وب‌سرور به کار می‌آید
مقدار vm.swappiness=10 به کرنل می‌گوید تا جای ممکن از Swap استفاده نکند و آن را فقط برای شرایط اضطراری نگه دارد. برای سرورهای وب، فعال کردن BBR به‌عنوان الگوریتم کنترل ازدحام TCP در کرنل 6.8 اوبونتو تنها دو خط در /etc/sysctl.d/ است (net.core.default_qdisc=fq و net.ipv4.tcp_congestion_control=bbr) و به‌ویژه روی مسیرهای پرتأخیر خارج از کشور تفاوت محسوسی ایجاد میکند. تغییرات را با sudo sysctl --system اعمال کنید.
بهروزرسانی خودکار امنیتی و مانیتورینگ پایه‌ای
سروری که فقط هنگام بروز مشکل به آن سر می‌زنید، باید بتواند وصله‌های امنیتی را خودش نصب کند. بستهٔ unattended-upgrades در Ubuntu 24.04 از پیش نصب است، اما اطمینان حاصل کنید که فعال باشد:
sudo dpkg-reconfigure -plow unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgradesبه‌صورت پیش‌فرض فقط مخزن -security بهروز می‌شود و راه‌اندازی مجدد خودکار خاموش است؛ این ترکیب برای اغلب سرورهای تولیدی مناسب است. اگر می‌خواهید سرور شبانه ری‌استارت شود، Automatic-Reboot-Time را روی ساعتی کم‌ترافیک مثل 04:30 بگذارید.
چه چیزی را باید زیر نظر داشته باشید؟
حداقل مانیتورینگ برای یک سرور تازه سه چیز است: فضای دیسک، مصرف رم و زنده بودن سرویس‌های اصلی. ابزارهای ساده‌ای مانند htop و ncdu برای بررسی دستی کافی هستند، اما برای هشدار خودکار، یک نمونهٔ Uptime Kuma یا Netdata روی همین سرور یا سرور دیگری نصب کنید. بکاپ خارج از سرور را هم از همین روز اول برنامه‌ریزی کنید. برای کسانی که ترجیح می‌دهند این مراحل را به تیم متخصص بسپارند، سرویس مدیریت سرور دقیقاً همین امن‌سازی و پایش را به‌صورت مستمر انجام می‌دهد.
چک‌لیست ۱۵ مرحله‌ای در یک نگاه
جدول زیر ترتیب پیشنهادی را نشان می‌دهد. مراحل ۱ تا ۵ را پیش از هر کار دیگری و در همان نشست اول انجام دهید؛ سایر مراحل می‌توانند تا پایان روز اول صبر کنند.
| مرحله | کار | ابزار / فایل | چرا مهم است |
|---|---|---|---|
| 1 | ساخت کاربر غیر root با sudo | adduser, usermod | حذف وابستگی به root |
| 2 | انتقال کلید Ed25519 | ssh-copy-id | حذف رمز از مسیر ورود |
| 3 | سخت‌گیری sshd | sshd_config.d/ | بستن ورود root و رمز |
| 4 | فعال کردن UFW | ufw | فقط پورت‌های لازم باز |
| 5 | بهروزرسانی کامل و ری‌بوت | apt full-upgrade | بستن حفره‌های شناخته‌شده |
| 6 | نصب Fail2ban | jail.local | مسدودسازی خودکار مهاجم |
| 7 | حذف بستههای بلااستفاده | apt purge | سطح حمله کمتر |
| 8 | نام میزبان و /etc/hosts | hostnamectl | لاگ و ایمیل درست |
| 9 | منطقهٔ زمانی و NTP | timedatectl | SSL و cron دقیق |
| 10 | ساخت Swap | /swapfile | پیشگیری از OOM |
| 11 | تنظیمات sysctl و BBR | /etc/sysctl.d/ | شبکهٔ سریع‌تر |
| 12 | بهروزرسانی خودکار امنیتی | unattended-upgrades | وصله بدون دخالت |
| 13 | نصب ابزارهای پایه‌ای | apt install | عیب‌یابی سریع |
| 14 | مانیتورینگ و هشدار | Uptime Kuma / Netdata | اطلاع پیش از کاربر |
| 15 | برنامهٔ بکاپ خارج از سرور | rsync / restic | بازیابی پس از فاجعه |
اگر این چک‌لیست را بیش از یک بار اجرا می‌کنید، آن را در قالب یک اسکریپت Bash نگه دارید تا هیچ مرحله‌ای از قلم نیفتد. روی سرور مجازی ایران می‌توانید همین اسکریپت را بلافاصله پس از تحویل اجرا کنید.
جمع‌بندی
راه‌اندازی اولیهٔ سرور Ubuntu 24.04 بیش از آنکه کار پیچیده‌ای باشد، کار منظمی است: کاربر غیر root، کلید SSH، فایروال و بهروزرسانی، چهار مرحله‌ای هستند که بیشترین اثر را دارند و باید در همان ساعت اول انجام شوند. Fail2ban، Swap، زمان درست و بهروزرسانی خودکار، سرور را برای ماه‌های بدون نظارت آماده میکنند. چک‌لیست را یک بار به اسکریپت تبدیل کنید تا هر سرور جدید از روز اول در وضعیت امن و قابل پیش‌بینی باشد.
سوالات متداول
آیا باید پورت SSH را از 22 تغییر دهم؟
تغییر پورت امنیت واقعی اضافه نمیکند و اسکنرهایی مثل Shodan پورت جدید را هم پیدا میکنند، اما حجم تلاشهای خودکار و لاگهای بیهوده را بهشدت کم میکند. اگر تغییر میدهید، حتماً ssh.socket را هم بهروز کنید و پورت جدید را پیش از بستن پورت قدیمی در UFW باز کنید.
چرا بعد از فعال کردن UFW هنوز پورت کانتینر Docker از بیرون باز است؟
Docker قواعد خودش را مستقیماً در iptables و قبل از زنجیرهٔ UFW ثبت میکند. راه حل این است که پورت کانتینرها را فقط روی 127.0.0.1 منتشر کنید (مثلاً -p 127.0.0.1:8080:80) و دسترسی عمومی را از طریق Nginx بدهید، یا در فایل /etc/docker/daemon.json گزینهٔ "iptables": false را تنظیم کنید و قواعد را خودتان بنویسید.
اگر کلید SSH را گم کنم چگونه وارد سرور شوم؟
از کنسول VNC یا KVM پنل ارائهدهنده استفاده کنید که مستقل از SSH است. سپس یا کلید عمومی جدید را به ~/.ssh/authorized_keys اضافه کنید یا موقتاً PasswordAuthentication yes را فعال کرده و پس از انتقال کلید دوباره آن را ببندید.
آیا Swap روی سرور با رم زیاد هم لازم است؟
روی سرورهایی با 16 گیگابایت رم یا بیشتر، Swap کوچکی در حد 1 تا 2 گیگابایت همچنان مفید است تا کرنل بتواند صفحات بلااستفاده را کنار بگذارد و از کشته شدن ناگهانی پروسه‌ها در اوج لحظه‌ای جلوگیری کند. swappiness پایین تضمین میکند که در حالت عادی از آن استفاده نشود.
فرق apt upgrade و apt full-upgrade چیست؟
دستور upgrade هرگز بستهای را حذف نمیکند و بهروزرسانیهایی را که نیازمند حذف باشند نگه میدارد. full-upgrade اجازهٔ حذف بستههای متعارض را دارد و برای بهروزرسانی کرنل لازم است. روی سرور تازه، full-upgrade انتخاب درستی است.
