ده کار ضروری بعد از خرید سرور مجازی (فهرست بازبینی امنیت اولیه)

سرور مجازی تازه تحویل‌گرفته‌شده، یک سیستم کاملاً باز است: رمز ریشه فعال، فایروال خاموش، بسته‌ها قدیمی و پورت SSH روی مقدار پیش‌فرض. ربات‌های اسکن اینترنت معمولاً ظرف چند دقیقه آن را پیدا می‌کنند و آزمایش رمز شروع می‌شود. این فهرست، ده کاری است که بعد از خرید سرور مجازی و پیش از راه‌اندازی هر سرویسی باید انجام دهید.

چرا این کارها را نمی‌شود به بعد موکول کرد؟

یک تصور رایج این است که «سرور من که هنوز سایتی رویش نیست، چیزی برای دزدیدن ندارد». اما مهاجم خودکار دنبال محتوای شما نیست؛ دنبال یک ماشین سالم با اینترنت پرسرعت می‌گردد تا از آن برای ارسال هرزنامه، استخراج ارز دیجیتال یا حمله به دیگران استفاده کند. نتیجهٔ این ماجرا برای شما مسدود شدن آی‌پی، پر شدن ترافیک ماهانه و در بدترین حالت تعلیق سرویس از سوی شرکت میزبان است.

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

۱. سیستم را به‌روز کنید

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

apt update && apt upgrade -y
apt autoremove -y

روی توزیع‌های خانوادهٔ RHEL به‌جای آن از dnf upgrade -y استفاده کنید.

۲. یک کاربر عادی با دسترسی مدیریتی بسازید

کار روزمره با کاربر ریشه، یعنی هر اشتباه تایپی می‌تواند سیستم را از کار بیندازد. یک rm اشتباه با کاربر ریشه، بدون هیچ پرسشی اجرا می‌شود.

adduser hamoon
usermod -aG sudo hamoon

از این پس هر دستوری که واقعاً به دسترسی مدیریتی نیاز دارد را با پیشوند sudo اجرا می‌کنید. این یک لحظه مکث ایجاد می‌کند که در عمل جلوی بخش بزرگی از اشتباهات را می‌گیرد. مزیت دوم این است که تمام دستورهای مدیریتی در لاگ ثبت می‌شوند و اگر چند نفر به سرور دسترسی داشته باشند، می‌دانید چه کسی چه کاری کرده است.

پیش از بستن دسترسی ریشه، حتماً در یک پنجرهٔ جداگانه با کاربر جدید وارد شوید و مطمئن شوید کار می‌کند.

۳. ورود با کلید را جایگزین رمز کنید

از کامپیوتر خودتان یک جفت کلید بسازید و روی سرور بگذارید:

ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id hamoon@SERVER_IP

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

سپس در فایل /etc/ssh/sshd_config این سه مقدار را تنظیم کنید:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

و سرویس را بازخوانی کنید: systemctl reload ssh

احتیاط: تا وقتی ورود با کلید را عملاً آزمایش نکرده‌اید، احراز هویت با رمز را نبندید. در غیر این صورت تنها راه بازگشت، کنسول تحت وب پنل شرکت میزبان است.

۴. پورت SSH را تغییر دهید

این کار امنیت رمزنگاری را بیشتر نمی‌کند، اما حجم تلاش‌های خودکار را به شکل چشمگیری کاهش می‌دهد و لاگ‌ها را خواندنی نگه می‌دارد. در همان فایل پیکربندی، مقدار Port را به عددی بین ۱۰۰۰۰ تا ۶۵۰۰۰ تغییر دهید و پیش از راه‌اندازی مجدد سرویس، پورت جدید را در فایروال باز کنید.

۵. فایروال را روشن کنید

روی اوبونتو و دبیان، ساده‌ترین ابزار UFW است:

ufw allow 22000/tcp     # پورت جدید SSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status numbered

قاعدهٔ کلی: هر پورتی که سرویس فعالی پشتش نیست، باید بسته بماند.

۶. حفاظت در برابر تلاش‌های مکرر ورود

ابزار Fail2ban آی‌پی‌هایی را که چند بار رمز اشتباه می‌زنند موقتاً مسدود می‌کند:

apt install fail2ban -y
systemctl enable --now fail2ban
fail2ban-client status sshd

۷. منطقهٔ زمانی و همگام‌سازی ساعت

ساعت نادرست، لاگ‌ها را بی‌فایده و گواهی‌های امنیتی را ناسازگار می‌کند:

timedatectl set-timezone Asia/Tehran
timedatectl status

۸. فضای مبادله برای سرورهای کم‌حافظه

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

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

۹. به‌روزرسانی خودکار وصله‌های امنیتی

apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

این کار وصله‌های امنیتی را بدون دخالت شما نصب می‌کند و برای سروری که هر روز سر نمی‌زنید حیاتی است.

۱۰. پشتیبان‌گیری بیرون از سرور

نسخهٔ پشتیبانی که روی همان سرور نگهداری می‌شود، در برابر خرابی دیسک یا حذف اشتباهی هیچ کمکی نمی‌کند. حداقل کار، یک پشتیبان شبانه روی فضای جداگانه است:

0 3 * * * tar -czf /tmp/web-$(date +%F).tar.gz /var/www && 
  rsync -az /tmp/web-*.tar.gz backup@BACKUP_HOST:/backups/

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

جدول اولویت‌بندی

سه اشتباه رایج که کار را خراب می‌کند

بستن ورود با رمز پیش از آزمودن کلید

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

باز گذاشتن پورت پایگاه داده روی اینترنت

پورت‌های ۳۳۰۶ و ۵۴۳۲ نباید از بیرون قابل دسترس باشند. اگر برنامه و پایگاه داده روی یک سرور هستند، سرویس را فقط روی 127.0.0.1 گوش کنید. برای بررسی وضعیت فعلی:

ss -tulnp | grep -E "3306|5432"

پشتیبانی که هرگز آزمایش نشده

فایل پشتیبانی که خراب است یا رمز رمزنگاری‌اش گم شده، دقیقاً به اندازهٔ نداشتن پشتیبان بی‌ارزش است — با این تفاوت که حس امنیت کاذب هم می‌دهد. یک بار در ماه، آخرین نسخه را روی یک سرور آزمایشی بازیابی کنید.

بعد از این ده کار، قدم بعدی چیست؟

حالا سرور شما در وضعیت پایه‌ای امنی است و می‌توانید سراغ راه‌اندازی سرویس بروید:

1. نصب وب‌سرور و مفسر زبان برنامه‌نویسی مورد نیازتان.
2. گرفتن گواهی امنیتی رایگان و فعال کردن تمدید خودکار آن.
3. راه‌اندازی یک سرویس پایش بیرونی که هر چند دقیقه وضعیت سرور را بررسی کند و در صورت قطعی به شما اطلاع دهد.
4. تنظیم چرخش لاگ‌ها تا فایل‌های ثبت وقایع دیسک را پر نکنند.

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