چک لیست امنیت سرور لینوکس بعد از نصب

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

مفاهیم کلی‌تر مثل SELinux، AppArmor و رمزنگاری را در راهنمای امنیت لینوکس ببینید؛ این مطلب فقط کارهای عملی و قابل تیک زدن را پوشش می‌دهد. دستورها برای Ubuntu و Debian و خانواده RHEL (Rocky Linux و AlmaLinux) نوشته شده‌اند. پیش از شروع مطمئن شوید به کنسول VNC یا کنسول پنل سرور دسترسی دارید و نشست SSH فعلی را تا پایان کار باز نگه دارید؛ اشتباه در تنظیم SSH یا فایروال ممکن است دسترسی شبکه را قطع کند.

خلاصه چک لیست امنیت سرور لینوکس

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

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

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades
sudo unattended-upgrade -d --dry-run
systemctl list-timers 'apt-daily*'

# RHEL / Rocky Linux / AlmaLinux
sudo dnf upgrade
sudo dnf install dnf-automatic
# in /etc/dnf/automatic.conf set: upgrade_type = security and apply_updates = yes
sudo systemctl enable --now dnf-automatic.timer

در Debian و Ubuntu گزارش کار unattended-upgrades در پوشه ‎/var/log/unattended-upgrades ذخیره می‌شود. در RHEL 10 و توزیع‌هایی که DNF5 دارند مسیر فایل تنظیمات dnf-automatic تغییر کرده است؛ مستندات همان نسخه را ببینید. وصله‌های کرنل تا ری‌استارت اعمال نمی‌شوند: در Ubuntu وجود فایل ‎/var/run/reboot-required و در خانواده RHEL خروجی needs-restarting -r نشان می‌دهد ری‌استارت لازم است. برای ری‌استارت یک پنجره زمانی ثابت تعیین کنید تا وصله‌ها هفته‌ها معطل نمانند.

۲. ساخت کاربر عادی با دسترسی sudo

کار روزانه با root یعنی هر اشتباه تایپی و هر رمز لورفته، دسترسی کامل به سرور می‌دهد. یک کاربر عادی بسازید و فقط از طریق sudo دسترسی مدیریتی بدهید:

# Debian / Ubuntu
sudo adduser deploy
sudo usermod -aG sudo deploy

# RHEL / Rocky Linux / AlmaLinux
sudo useradd -m deploy && sudo passwd deploy
sudo usermod -aG wheel deploy

# Verify
sudo -l -U deploy
awk -F: '$3 == 0 {print $1}' /etc/passwd     # should print only: root

در یک پنجره جدید با کاربر deploy وارد شوید و sudo whoami را اجرا کنید؛ خروجی باید root باشد. دستور awk کاربرانی را که UID صفر دارند فهرست می‌کند و هر نامی غیر از root در این فهرست باید بررسی شود. جزئیات گروه‌ها، فایل sudoers و محدود کردن دستورهای مجاز را در مدیریت دسترسی در لینوکس ببینید.

۳. امن‌سازی SSH: کلید به جای رمز

ورود با کلید، بستن ورود با رمز عبور و بستن ورود مستقیم root مؤثرترین کار این چک‌لیست است. مراحل ساخت کلید در ویندوز و لینوکس و دام فایل‌های sshd_config.d در ایمیج‌های ابری را در آموزش SSH Key و اتصال امن به سرور لینوکس با جزئیات آورده‌ایم؛ خلاصه دستورها:

# On your own computer
ssh-keygen -t ed25519
ssh-copy-id deploy@SERVER_IP

# On the server: /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3
AllowUsers deploy

# Check syntax, confirm effective values, then restart
sudo sshd -t
sudo sshd -T | grep -Ei "passwordauthentication|permitrootlogin|allowusers"
sudo systemctl restart ssh      # RHEL family: sshd

پیش از بستن نشست فعلی، ورود با کلید را در پنجره‌ای جدید تست کنید. خروجی sshd -T مقدار نهایی اعمال‌شده را نشان می‌دهد و اگر هنوز passwordauthentication yes می‌بینید، فایل دیگری در sshd_config.d مقدار شما را بازنویسی کرده است. تغییر پورت 22 تعداد تلاش‌های خودکار در لاگ را کم می‌کند، اما جایگزین کلید نیست.

۴. فایروال: فقط پورت‌های لازم باز باشند

سیاست پیش‌فرض را رد همه ترافیک ورودی بگذارید و فقط سرویس‌های لازم را باز کنید. SSH را پیش از فعال کردن فایروال باز کنید؛ در غیر این صورت اتصال فعلی قطع می‌شود.

# Ubuntu / Debian with ufw
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

# RHEL / Rocky Linux / AlmaLinux with firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

اگر SSH روی پورت دیگری است، همان پورت را باز کنید (مثلاً sudo ufw allow 2222/tcp). دستور sudo ufw limit OpenSSH اتصال IPی را که در ۳۰ ثانیه ۶ بار یا بیشتر برای اتصال تلاش کند رد می‌کند. اگر پنل دیتاسنتر فایروال یا Security Group دارد، آن را هم به‌عنوان لایه دوم تنظیم کنید. اگر بعداً Docker نصب می‌کنید، بدانید پورت‌هایی که Docker منتشر می‌کند ممکن است از قواعد ufw عبور کنند؛ آن‌ها را روی 127.0.0.1 منتشر کنید یا در فایروال شبکه ببندید. برای نوشتن قواعد دقیق‌تر، آموزش کانفیگ iptables در لینوکس را ببینید.

۵. سرویس‌ها و پورت‌های اضافه را ببندید

sudo ss -tulpn
systemctl list-unit-files --type=service --state=enabled
sudo systemctl disable --now SERVICE_NAME

هر سرویسی که روی 0.0.0.0 یا ‎[::]‎ گوش می‌دهد، در صورت باز بودن فایروال از اینترنت قابل دسترسی است. دیتابیس‌هایی مثل MySQL (پورت 3306) و PostgreSQL (پورت 5432) و Redis (پورت 6379) اگر فقط برنامه همان سرور از آن‌ها استفاده می‌کند، باید روی 127.0.0.1 گوش دهند. این مورد را در تنظیمات خود سرویس (مثلاً bind-address) اصلاح کنید و به فایروال بسنده نکنید. سرویسی را که نمی‌شناسید پیش از غیرفعال کردن بررسی کنید، چون ممکن است سرویس دیگری به آن وابسته باشد.

۶. نصب fail2ban برای محافظت از SSH

fail2ban لاگ‌ها را می‌خواند و IPی را که چند بار پشت سر هم ورود ناموفق داشته، برای مدتی در فایروال مسدود می‌کند. تنظیمات را در jail.local بنویسید و فایل jail.conf را دست نزنید، چون با به‌روزرسانی بسته بازنویسی می‌شود:

# Debian / Ubuntu
sudo apt install fail2ban
# Rocky Linux / AlmaLinux (EPEL repository)
sudo dnf install epel-release && sudo dnf install fail2ban

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 YOUR_OFFICE_IP

[sshd]
enabled = true
backend = systemd

# Enable and verify
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.5

مقادیر پیش‌فرض fail2ban برای bantime و findtime ده دقیقه و برای maxretry پنج است؛ در نمونه بالا مدت مسدودی به یک ساعت افزایش یافته است. backend = systemd برای سیستم‌هایی است که لاگ SSH فقط در ژورنال ثبت می‌شود و فایل auth.log ندارند. IP ثابت دفتر را در ignoreip بگذارید تا چند بار اشتباه تایپ رمز باعث مسدود شدن خودتان نشود. وقتی ورود با رمز بسته است، fail2ban بیشتر لاگ‌ها را خلوت و بار اتصال‌های خودکار را کم می‌کند و برای سرویس‌های دیگر مثل وب‌سرور و ایمیل هم jail دارد.

۷. زمان سرور، لاگ‌ها و نگهداری آن‌ها

timedatectl
sudo timedatectl set-timezone Asia/Tehran
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage
sudo journalctl -u ssh --since "24 hours ago" | grep -Ei "failed|accepted"    # RHEL family: -u sshd

در خروجی timedatectl عبارت System clock synchronized باید yes باشد. ساعت نادرست تطبیق لاگ‌های چند سرور را در بررسی یک حادثه تقریباً ناممکن می‌کند و اعتبارسنجی گواهی‌های TLS را هم به هم می‌زند. با ساختن پوشه ‎/var/log/journal، ژورنال با تنظیم پیش‌فرض Storage=auto روی دیسک ذخیره می‌شود و با ری‌استارت از بین نمی‌رود.

لاگی که فقط روی خود سرور است، در صورت نفوذ ممکن است توسط مهاجم پاک شود. اگر چند سرور دارید، لاگ‌ها را به یک سرور مرکزی بفرستید تا نسخه‌ای خارج از دسترس سرور آلوده باقی بماند.

۸. بکاپ خارج از سرور و تست بازیابی

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

• یک نسخه از داده روی سرور یا مکان دیگری نگهداری شود.
• سرور اصلی نتواند بکاپ‌های قدیمی را پاک یا بازنویسی کند؛ یا سرور بکاپ داده را بکشد (pull) یا مقصد فقط اجازه افزودن بدهد.
• بازیابی به‌صورت دوره‌ای تست شود؛ بکاپی که هیچ‌وقت بازیابی نشده، هنوز ثابت نکرده قابل استفاده است.

برای طراحی سیاست بکاپ و برنامه بازیابی، خدمات بکاپ گیری سرور و بازیابی بحران را ببینید.

۹. بررسی نهایی از بیرون سرور

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

# From another machine, against your own server only
nmap -Pn -p- SERVER_IP

# On the server
sudo ss -tulpn
sudo sshd -T | grep -Ei "passwordauthentication|permitrootlogin"
sudo fail2ban-client status

فهرست پورت‌های باز در خروجی nmap را با فهرست سرویس‌هایی که عمداً باز کرده‌اید مقایسه کنید؛ هر پورت اضافه یعنی خطا در فایروال یا سرویسی که باید بسته شود. این بررسی را پس از هر نصب مهم و هر چند ماه یک بار تکرار کنید، چون بسته‌های جدید گاهی سرویس‌های تازه‌ای باز می‌کنند. اگر می‌خواهید کارشناس نتیجه را از بیرون ارزیابی کند، اسکن امنیت سرور را درخواست کنید. اجرای کامل‌تر، از تنظیمات کرنل تا امنیت وب‌سرور و دیتابیس، در خدمات امنیت سرور و Server Hardening انجام می‌شود.

سوالات متداول

تغییر پورت SSH برای امنیت لازم است؟

لازم نیست، اما تعداد تلاش‌های خودکار ورود در لاگ‌ها را کم می‌کند. امنیت اصلی از ورود فقط با کلید و بستن ورود root می‌آید. اگر پورت را تغییر می‌دهید، پیش از ری‌استارت SSH آن را در فایروال و در صورت فعال بودن SELinux در سیاست آن تعریف کنید.

وقتی ورود فقط با کلید است، fail2ban هنوز لازم است؟

برای SSH ضرورتش کمتر است، ولی لاگ‌ها را خلوت و بار اتصال‌های مکرر را کم می‌کند. برای سرویس‌هایی که هنوز با رمز کار می‌کنند، مثل ورود به پنل وب یا ایمیل، fail2ban همچنان مفید است.

اگر پس از فعال کردن فایروال دسترسی SSH قطع شد چه کنم؟

از کنسول VNC یا کنسول پنل دیتاسنتر وارد شوید، با sudo ufw disable یا sudo systemctl stop firewalld فایروال را موقتاً خاموش کنید، قاعده SSH را اضافه کنید و دوباره فایروال را فعال کنید.

این چک‌لیست برای سروری که مدتی کار کرده هم کاربرد دارد؟

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