ایمن‌سازی سرور لینوکس: راهنمای گام‌به‌گام

۱. ورود SSH را با کلید امن کنید

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

ssh-keygen -t ed25519 -C "your-name@your-machine"

بعد کلید عمومی را به سرور بفرستید:

ssh-copy-id user@server-ip

حالا فایل /etc/ssh/sshd_config را باز کنید و این سه خط را تنظیم کنید:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

و سرویس را بارگذاری مجدد کنید:

sudo systemctl reload ssh

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

نه، و امنیت واقعی اضافه نمی‌کند. بردن SSH از پورت ۲۲ به مثلاً ۲۲۲۲ فقط حجم لاگ را کم می‌کند چون ربات‌های ساده پیدایش نمی‌کنند. یک اسکنر جدی همهٔ پورت‌ها را می‌بیند. اگر از شلوغی لاگ خسته‌اید انجامش دهید، ولی به‌عنوان یک لایهٔ امنیتی حسابش نکنید — این «امنیت از راه پنهان‌کاری» است.

۲. فایروال را پیش‌فرض روی «بسته» بگذارید

روی Ubuntu و Debian ساده‌ترین راه ufw است:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

وضعیت را با این ببینید:

sudo ufw status verbose

نکتهٔ مهمی که اغلب فراموش می‌شود: اگر دیتابیس روی همان سرور است، پورتش (مثلاً ۳۳۰۶ یا ۵۴۳۲) نباید باز باشد. برنامه از طریق localhost به آن وصل می‌شود و نیازی به عبور از فایروال ندارد.

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

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

برای اینکه ببینید واقعاً کار می‌کند:

sudo unattended-upgrades --dry-run --debug

این تنظیم پیش‌فرض فقط وصله‌های امنیتی را نصب می‌کند، نه ارتقای نسخهٔ بسته‌ها. یعنی ریسک شکستن برنامه‌تان کم است. اگر سرویس حساسی دارید، در /etc/apt/apt.conf.d/50unattended-upgrades می‌توانید بسته‌های خاصی را در فهرست Unattended-Upgrade::Package-Blacklist بگذارید.

۴. کاربر جدا بسازید و root را کنار بگذارید

sudo adduser deploy
sudo usermod -aG sudo deploy

بعد کلید SSH را برای این کاربر هم بگذارید و با آن وارد شوید. وقتی مطمئن شدید کار می‌کند، ورود root را — همان‌طور که در بخش اول گفتیم — ببندید.

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

۵. سرویس‌هایی که لازم ندارید را خاموش کنید

sudo ss -tulpn | grep LISTEN

خروجی را خط به خط نگاه کنید. چیزی که روی 0.0.0.0 یا [::] گوش می‌دهد از بیرون در دسترس است؛ چیزی که روی 127.0.0.1 است فقط از خود سرور. اگر دیتابیس یا Redis روی 0.0.0.0 است، آن را به 127.0.0.1 محدود کنید.

سرویسی که لازم ندارید:

sudo systemctl disable --now servicename

۶. لاگ و تلاش‌های ناموفق را ببینید

تلاش‌های ناموفق ورود:

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

برای اینکه تلاش‌های مکرر خودکار مسدود شوند، fail2ban را نصب کنید:

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

با تنظیمات پیش‌فرض، هر IP که چند بار پشت سر هم اشتباه وارد شود برای مدتی بلاک می‌شود. وقتی ورود با رمز را بسته باشید این عملاً فقط لاگ را تمیز نگه می‌دارد — ولی اگر سرویس دیگری (مثل پنل مدیریت) دارید که با رمز کار می‌کند، ارزش واقعی دارد.

این کافی است؟

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

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