هاردنینگ لینوکس: چک‌لیست امن‌سازی سرور لینوکس برای Ubuntu و RHEL

هاردنینگ لینوکس یعنی تبدیل نصب پیش‌فرض یک توزیع لینوکس به سروری که فقط سرویس‌های لازم را اجرا می‌کند، دسترسی را محدود و قابل ردیابی نگه می‌دارد و در برابر حملات رایج شبکه‌ای مقاوم است. لینوکس به‌طور پیش‌فرض امن‌تر از تصور عموم نیست: ورود با رمز عبور در SSH، سرویس‌های اضافه، نبود فایروال فعال و ممیزی ناکافی در بسیاری از سرورهای عملیاتی دیده می‌شود. این مقاله یک چک‌لیست عملی امن‌سازی سرور لینوکس با دستورات دقیق برای Ubuntu و RHEL (و توزیع‌های مشابه مانند Rocky و AlmaLinux) است.

سرورهای لینوکسی معمولاً مهم‌ترین بارهای کاری را میزبانی می‌کنند: وب‌سرور، پایگاه داده، کانتینرها و سرویس‌های رو به اینترنت. یک کلید SSH رها شده یا یک پورت مدیریتی باز کافی است تا مهاجم جای پا پیدا کند. مقاوم‌سازی Ubuntu و RHEL بر پایه CIS Benchmark این ریسک‌ها را به‌طور سیستماتیک کاهش می‌دهد.

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

حوزه	اقدام کلیدی	ابزار
SSH	ورود فقط با کلید، بدون root	sshd_config
کاربران	حساب شخصی، sudo با لاگ	visudo، pwquality، faillock
به‌روزرسانی	نصب خودکار وصله‌های امنیتی	unattended-upgrades، dnf-automatic
فایروال	مسدودسازی پیش‌فرض ورودی	ufw، firewalld، nftables
سرویس‌ها	حذف سرویس‌های بی‌استفاده	systemctl، ss
فایل‌سیستم	nodev، nosuid و noexec	/etc/fstab
هسته و شبکه	پارامترهای امن sysctl	/etc/sysctl.d
ممیزی	auditd، لاگ پایدار، SELinux/AppArmor	auditctl، journald

پیش از شروع، سه نکته را رعایت کنید: خط مبنای خود را بر اساس CIS Benchmark مربوط به نسخه دقیق توزیع انتخاب کنید، همیشه یک راه دسترسی جایگزین (کنسول مجازی‌سازی یا iLO/iDRAC) داشته باشید تا با اشتباه در تنظیم SSH یا فایروال قفل نشوید، و تغییرات را ابتدا روی سرور آزمایشی اجرا کنید و در نهایت با Ansible یا ابزار مدیریت پیکربندی روی همه سرورها اعمال کنید.

دسترسی: SSH، کاربران و sudo

امن‌سازی SSH

تنظیمات را در یک فایل جداگانه در پوشه sshd_config.d بگذارید. در OpenSSH اولین مقداری که خوانده شود اعمال می‌شود و فایل‌های این پوشه به ترتیب حروف خوانده می‌شوند؛ بنابراین نام 00-hardening.conf باعث می‌شود تنظیمات شما بر فایل‌هایی مثل 50-cloud-init.conf مقدم باشد.

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 3
X11Forwarding no
AllowTcpForwarding no
AllowGroups sshusers
LogLevel VERBOSE
EOF
sudo groupadd -f sshusers && sudo usermod -aG sshusers alice
sudo sshd -t && sudo systemctl reload ssh    # RHEL: sudo systemctl reload sshd
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowgroups'

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

کاربران، sudo و سیاست رمز عبور

هر مدیر باید حساب شخصی داشته باشد و کارهای مدیریتی را با sudo انجام دهد تا همه چیز قابل ردیابی باشد. حساب‌های مشترک و ورود مستقیم با root را کنار بگذارید:

awk -F: '($3 == 0) {print $1}' /etc/passwd          # only root should have UID 0
sudo awk -F: '($2 == "") {print $1}' /etc/shadow     # accounts with empty passwords
sudo visudo -f /etc/sudoers.d/10-hardening
# add these two lines in the editor:
#   Defaults use_pty
#   Defaults logfile="/var/log/sudo.log"

در فایل /etc/security/pwquality.conf مقدار minlen را دست‌کم 14 بگذارید و در /etc/security/faillock.conf مقادیر deny و unlock_time را برای قفل حساب پس از چند تلاش ناموفق تنظیم کنید. در RHEL، ماژول faillock با دستور sudo authselect enable-feature with-faillock فعال می‌شود؛ در Ubuntu باید آن را به پیکربندی PAM اضافه کنید.

به‌روزرسانی و فایروال

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

وصله‌های امنیتی باید بدون انتظار برای پنجره نگهداری ماهانه نصب شوند:

# Ubuntu / Debian
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# RHEL / Rocky / AlmaLinux: set upgrade_type = security and apply_updates = yes
# in /etc/dnf/automatic.conf, then:
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

به‌روزرسانی هسته بدون راه‌اندازی مجدد اثر ندارد. در Ubuntu وجود فایل /var/run/reboot-required و در RHEL خروجی needs-restarting -r را بررسی کنید و ری‌استارت‌ها را زمان‌بندی کنید.

فایروال: ufw، firewalld یا nftables

فقط یکی از ابزارها را استفاده کنید؛ ترکیب چند ابزار، قوانین را غیرقابل پیش‌بینی می‌کند. در Ubuntu معمولاً ufw و در RHEL معمولاً firewalld به کار می‌رود و هر دو در نهایت قوانین را در netfilter هسته اعمال می‌کنند:

# Ubuntu (ufw)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 10.10.50.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

# RHEL (firewalld)
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.50.0/24" service name="ssh" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

سرویس‌ها، فایل‌سیستم و مجوزها

سرویس‌های غیرضروری

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

systemctl list-unit-files --type=service --state=enabled
sudo ss -tulpn
sudo systemctl disable --now avahi-daemon.service avahi-daemon.socket

سرویس‌هایی مثل Telnet، rsh، FTP، NFS و سرور گرافیکی روی بیشتر سرورها لازم نیستند و CIS حذف آن‌ها را توصیه می‌کند.

همین منطق درباره ماژول‌های هسته هم صدق می‌کند. ماژول‌هایی مانند cramfs یا usb-storage روی سرور مرکز داده کاربردی ندارند و بهتر است بارگذاری آن‌ها مسدود شود. برای این کار در فایلی مانند /etc/modprobe.d/hardening.conf دو خط install usb-storage /bin/false و blacklist usb-storage را اضافه کنید. هر ماژولی که بارگذاری نشود، سطح حمله هسته را کوچک‌تر می‌کند.

گزینه‌های امن mount

پوشه‌های قابل نوشتن برای همه، مانند /tmp و /dev/shm، محل رایج اجرای بدافزار هستند. گزینه noexec اجرای فایل، nosuid اثر بیت SUID و nodev فایل‌های دستگاه را در آن‌ها غیرفعال می‌کند:

# /etc/fstab
tmpfs  /tmp      tmpfs  defaults,rw,nosuid,nodev,noexec,relatime,size=2G  0 0
tmpfs  /dev/shm  tmpfs  defaults,rw,nosuid,nodev,noexec,relatime         0 0

sudo mount -o remount /dev/shm
findmnt -no OPTIONS /dev/shm

اعمال تنظیم /tmp بهتر است با ری‌استارت در پنجره نگهداری انجام شود. noexec روی /tmp ممکن است برخی نصب‌کننده‌ها یا اسکریپت‌ها را مختل کند؛ پیش از استقرار آزمایش کنید. CIS همچنین پارتیشن جداگانه برای /var، /var/log و /home را توصیه می‌کند.

مجوز فایل‌های حساس

فایل	مجوز پیشنهادی	مالک
/etc/passwd و /etc/group	644	root:root
/etc/shadow	640 یا سخت‌گیرانه‌تر (در RHEL معمولاً 000)	root:shadow یا root:root
/etc/ssh/sshd_config	600	root:root
/etc/crontab	600	root:root

sudo find / -xdev -type f -perm -0002 -print          # world-writable files
sudo find / -xdev -type f -perm -4000 -print          # SUID binaries to review
sudo find / -xdev \( -nouser -o -nogroup \) -print    # files with no owner

تنظیمات sysctl شبکه و هسته

این پارامترها هدایت‌های ICMP، مسیریابی منبع و بسته‌های جعلی را کنترل می‌کنند:

sudo tee /etc/sysctl.d/60-hardening.conf > /dev/null <<'EOF'
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
fs.suid_dumpable = 0
EOF
sudo sysctl --system

توجه: روی روترها، میزبان‌های Docker و نودهای Kubernetes مقدار ip_forward باید 1 بماند؛ امن‌سازی این محیط‌ها را در مقاله هاردنینگ Docker و Kubernetes ببینید. rp_filter سخت‌گیرانه نیز ممکن است در مسیریابی نامتقارن مشکل ایجاد کند.

auditd، لاگ و SELinux/AppArmor

ممیزی با auditd

auditd تغییر فایل‌های حساس و اجرای دستورات با امتیاز root را ثبت می‌کند:

sudo apt install auditd audispd-plugins     # RHEL: sudo dnf install audit
sudo systemctl enable --now auditd
sudo tee /etc/audit/rules.d/50-hardening.rules > /dev/null <<'EOF'
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope
-w /etc/ssh/sshd_config -p wa -k sshd
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root_cmds
EOF
sudo augenrules --load
sudo auditctl -l
sudo ausearch -k identity --start today

مطمئن شوید journald لاگ‌ها را به‌صورت پایدار نگه می‌دارد (Storage=persistent در /etc/systemd/journald.conf) و لاگ‌ها با rsyslog یا عامل SIEM به یک مخزن مرکزی ارسال می‌شوند؛ لاگی که فقط روی همان سرور باشد، با نفوذ به سرور قابل پاک شدن است.

SELinux و AppArmor

کنترل دسترسی اجباری (MAC) حتی اگر سرویسی آلوده شود، دامنه آسیب را محدود می‌کند. RHEL از SELinux و Ubuntu از AppArmor استفاده می‌کند. رایج‌ترین خطا، غیرفعال کردن SELinux برای حل یک مشکل است؛ به‌جای آن، علت را با لاگ AVC پیدا کنید:

# RHEL: SELinux
getenforce
sudo setenforce 1        # also set SELINUX=enforcing in /etc/selinux/config
sudo ausearch -m AVC -ts recent
# Ubuntu: AppArmor (aa-enforce is in the apparmor-utils package)
sudo aa-status
sudo aa-enforce /etc/apparmor.d/<profile>     # switch a profile from complain to enforce

ممیزی با CIS برای Ubuntu و RHEL

پس از اعمال تنظیمات، باید انطباق را اندازه بگیرید. هر دو توزیع ابزار رسمی دارند:

# Ubuntu Pro: Ubuntu Security Guide (USG)
sudo pro enable usg
sudo apt install usg
sudo usg audit cis_level1_server

# RHEL: OpenSCAP with SCAP Security Guide
sudo dnf install openscap-scanner scap-security-guide
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results results.xml --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

دستور usg fix و گزینه remediate در OpenSCAP می‌توانند تنظیمات را خودکار اعمال کنند، اما فقط پس از آزمون روی سرور غیرعملیاتی. هاردنینگ یک‌باره کافی نیست؛ ممیزی باید دوره‌ای تکرار شود تا انحراف پیکربندی کشف شود. اصول کلی این چرخه را در راهنمای جامع هاردنینگ توضیح داده‌ایم.

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

نت‌گارد با اسکن احرازهویت‌شده، سرورهای Ubuntu، RHEL و توزیع‌های مشابه را در برابر CIS Benchmark و خط مبنای سفارشی سازمان ممیزی می‌کند؛ از تنظیمات SSH و sysctl تا مجوز فایل‌ها و وضعیت auditd. انحراف پیکربندی بین اسکن‌ها گزارش می‌شود، بسته‌های آسیب‌پذیر بر اساس اطلاعات بهره‌برداری و اهمیت دارایی اولویت‌بندی می‌شوند و ایمیج‌های کانتینر و Kubernetes نیز قابل بررسی‌اند. برای جزئیات، صفحه ممیزی هاردنینگ نت‌گارد را ببینید.

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

هاردنینگ لینوکس چیست؟

هاردنینگ لینوکس مجموعه اقداماتی برای کاهش سطح حمله سرور لینوکسی است؛ از جمله ورود SSH فقط با کلید، غیرفعال کردن ورود root، نصب خودکار وصله‌ها، فعال کردن فایروال، حذف سرویس‌های اضافه، تنظیم گزینه‌های امن mount و sysctl، و فعال کردن auditd و SELinux یا AppArmor. معمولاً بر پایه CIS Benchmark مربوط به همان توزیع انجام می‌شود.

مهم‌ترین تنظیمات امن‌سازی سرور لینوکس کدام‌اند؟

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

آیا برای مقاوم‌سازی Ubuntu ابزار رسمی وجود دارد؟

بله. Canonical ابزار Ubuntu Security Guide یا USG را در قالب اشتراک Ubuntu Pro ارائه می‌کند که می‌تواند سرور را در برابر پروفایل‌های CIS ممیزی کند و تنظیمات را به‌صورت خودکار اعمال کند. برای RHEL و توزیع‌های مشابه، OpenSCAP همراه با بسته scap-security-guide همین کار را انجام می‌دهد. ابزارهای ممیزی مستقل نیز می‌توانند انطباق را بسنجند.

آیا باید SELinux را غیرفعال کرد؟

خیر. غیرفعال کردن SELinux یکی از رایج‌ترین و پرهزینه‌ترین اشتباهات در سرورهای RHEL است، چون یک لایه مهم دفاعی را حذف می‌کند. اگر برنامه‌ای با SELinux مشکل دارد، لاگ‌های AVC را بررسی کنید، Context فایل‌ها را اصلاح کنید یا Boolean مناسب را فعال کنید. در صورت نیاز، فقط همان دامنه مشکل‌دار را موقتاً در حالت Permissive قرار دهید.

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

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