چک‌لیست سخت‌سازی سرور لینوکس؛ به ترتیب اثر

سرور را تحویل گرفته‌اید، IP را می‌زنید و با root وارد می‌شوید. تا اینجا هیچ اتفاق بدی نیفتاده. اتفاق بد از جایی شروع می‌شود که journalctl -u ssh را باز می‌کنید و می‌بینید در ۲۴ ساعت گذشته ۴٬۳۰۰ تلاش ناموفق ورود از ۱۹۰ آی‌پی مختلف ثبت شده. این عدد را روی هر سروری که پورت ۲۲ آن به اینترنت باز است می‌بینید؛ نه چون هدف خاصی هستید، بلکه چون اسکنرها کل فضای IPv4 را می‌گردند. سخت سازی سرور یعنی همین‌جا تصمیم بگیرید چه چیزی را اول ببندید، چون ترتیب کارها تعیین می‌کند چند ساعت وقت بگذارید و چند بار سرور را از دست بدهید.

ترتیب درست سخت سازی سرور: از دسترسی تا پایش

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

1. کاربر غیر روت با sudo بسازید و ورود مستقیم root را ببندید.
2. ورود با کلید عمومی را جای رمز عبور بگذارید.
3. فایروال را بالا بیاورید و فقط پورت‌های لازم را باز بگذارید.
4. به‌روزرسانی خودکار امنیتی را فعال کنید.
5. fail2ban یا معادلش را روی SSH بگذارید.
6. پایش لاگ و هشدار را راه بیندازید.

اگر این ترتیب را جابه‌جا کنید، معمولاً در مرحلهٔ سوم خودتان را بیرون می‌بندید. این را در ادامه با جزئیات می‌گویم.

کاربر غیر روت و بستن ورود root

اول یک کاربر بسازید و به گروه sudo اضافه کنید:

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

آن خط rsync را جدی بگیرید. اگر کلید عمومی را به خانهٔ کاربر جدید کپی نکنید و بعد PermitRootLogin no بگذارید، تا وقتی کسی از بیرون به پنل کنسول سرور دسترسی نداشته باشد، عملاً قفل شده‌اید. من این اشتباه را دیده‌ام که کسی این کار را روی سرور ابری بدون KVM انجام داد و مجبور شد تیکت بزند و منتظر بماند.

بعد در /etc/ssh/sshd_config این خطوط را تنظیم کنید:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy

قبل از systemctl restart sshd یک ترمینال دیگر باز بگذارید و با کاربر جدید وارد شوید. اگر آن ترمینال کار کرد، سشن فعلی را ببندید. اگر کار نکرد، سشن فعلی را نبندید. همین یک عادت، بیشتر از هر بکاپی نجات‌تان داده است. جزئیات بیشتر دربارهٔ کلیدها و fail2ban در امنیت SSH؛ از تغییر پورت تا fail2ban و کلید عمومی آمده است.

فایروال: کدام پورت‌ها واقعاً لازم‌اند

روی اوبونتو ۲۲.۰۴ و بالاتر، ufw کافی است. روی سرورهایی که ترافیک سنگین دارند یا NAT و forwarding دارند، nftables مستقیم بهتر است چون لایهٔ انتزاعی اضافه ندارد و قواعد را دقیق‌تر می‌بینید.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

نکته‌ای که خیلی‌ها را زمین می‌زند: اگر پورت SSH را عوض کرده‌اید، قاعدهٔ ۲۲ را حذف نکنید تا مطمئن شوید پورت جدید کار می‌کند. ترتیب ufw enable و تغییر پورت را اشتباه انجام دهید، نتیجه‌اش یک سرور کاملاً غیرقابل‌دسترس است.

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

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

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

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

در /etc/apt/apt.conf.d/50unattended-upgrades مطمئن شوید مخزن security فعال است و Automatic-Reboot را روی false بگذارید مگر اینکه پنجرهٔ ری‌استارت مشخصی داشته باشید. کرنل بدون ری‌استارت وصله نمی‌شود و اینجا اشتباه می‌کنند: فکر می‌کنند چون apt upgrade بدون خطا تمام شد، سرور وصله شده. بعد uname -r همان نسخهٔ قدیمی را نشان می‌دهد و آسیب‌پذیری سر جایش است.

fail2ban و پایش

با MaxAuthTries 3 هر آی‌پی بعد از سه تلاش رد می‌شود، ولی همچنان می‌تواند بی‌نهایت بار تلاش کند. fail2ban این را در سطح فایروال می‌بندد:

apt install fail2ban
fail2ban-client status sshd

خروجی درست چیزی شبیه این است: Currently banned: 47. اگر عدد بن شده صفر می‌ماند، یعنی jail روی لاگ اشتباهی تنظیم شده؛ روی سیستم‌های systemd باید backend = systemd بگذارید، نه مسیر /var/log/auth.log که ممکن است وجود نداشته باشد.

پایش بدون هشدار فایده ندارد. یک logwatch روزانه یا یک اسکریپت ساده که تعداد ورودهای موفق را می‌شمارد کافی است. اگر می‌خواهید بدانید چه چیزی باید ثبت شود و چطور لاگ را دست‌نخورده نگه دارید، لاگ ممیزی چیست و چگونه آن را دست‌نخورده نگه داریم؟ را بخوانید.

چیزهایی که در سخت سازی سرور اثر کمتری دارند

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

نصب یک آنتی‌ویروس روی سرور وب هم معمولاً اثر کمی دارد. سطح حملهٔ واقعی روی سرور لینوکس، سرویس‌های در حال اجرا و نسخهٔ آن‌هاست، نه فایل‌های روی دیسک. با ss -tulpn ببینید چه چیزی گوش می‌دهد و هر سرویسی که نمی‌شناسید را ببندید. این کار پنج دقیقه وقت می‌گیرد و بیشتر از چند ابزار امنیتی اثر دارد.

یک محدودیت که باید بدانید

هیچ‌کدام از این کارها جلوی آسیب‌پذیری خود اپلیکیشن را نمی‌گیرد. اگر وردپرس دارید و نسخهٔ افزونه‌ای وصله نشده باشد، SSH سخت‌شده هیچ کمکی نمی‌کند چون مهاجم از راه وب وارد می‌شود، نه از راه پوسته. برای آن مسیر، امنیت وردپرس؛ از wp-config تا افزونه‌هایی که خودشان حفره‌اند نقطهٔ شروع درستی است. سخت‌سازی سرور و امن‌سازی اپلیکیشن دو لایهٔ جدا هستند و هیچ‌کدام جای دیگری را نمی‌گیرد.

وقتی سرور را از دست می‌دهید، چه چیزی نشان می‌دهد کجا را اشتباه کرده‌اید

سه نشانهٔ رایج:

• Connection refused روی پورت SSH: فایروال یا سرویس sshd بالا نیست. از کنسول سرور systemctl status sshd را بزنید.
• Permission denied (publickey) با کلیدی که قبلاً کار می‌کرد: مجوزهای ~/.ssh روی 777 یا 775 است. باید 700 برای پوشه و 600 برای authorized_keys باشد. sshd به‌صورت پیش‌فرض این را رد می‌کند و پیام گویایی هم نمی‌دهد.
• ورود موفق ولی sudo کار نمی‌کند: کاربر در گروه sudo نیست یا باید دوباره وارد شوید تا عضویت گروه اعمال شود.

اگر سرورتان پشت یک شبکهٔ شرکتی است و کارمندان از بیرون وصل می‌شوند، سخت‌سازی SSH کافی نیست؛ باید مسیر دسترسی را هم کنترل کنید. راهنمای جامع VPN سازمانی برای دسترسی امن کارکنان همین لایه را پوشش می‌دهد.

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

اگر ترجیح می‌دهید این لایه را خودتان نگه ندارید، خدمات امنیت سرورنت همین کارها را به‌عنوان سرویس پوشش می‌دهد؛ ولی حتی در آن حالت هم باید بدانید چه چیزی روی سرورتان تنظیم شده، چون روزی که مشکلی پیش بیاید، اولین سؤال همین است.

پرسش‌های پرتکرار

آیا تغییر پورت SSH واقعاً امنیت را بالا می‌برد؟

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

چرا بعد از فعال کردن فایروال دیگر به سرور وصل نمی‌شوم؟

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

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

بله، و دلیل اصلی‌اش ری‌استارت خودکار است. اگر Automatic-Reboot روی true باشد، سرور در ساعت نامناسبی بالا می‌آید و سرویس‌های وابسته ممکن است درست بالا نیایند. آن را false بگذارید و ری‌استارت را در پنجرهٔ maintenance خودتان انجام دهید.

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

یک کاربر غیر روت با کلید عمومی بسازید، PermitRootLogin no و PasswordAuthentication no را تنظیم کنید، و ufw را با فقط پورت‌های لازم بالا بیاورید. این چهار کار کمتر از نیم ساعت وقت می‌گیرد و بیشتر تلاش‌های خودکار ورود را از بین می‌برد. بقیهٔ چک‌لیست بعد از این‌ها معنا پیدا می‌کند.