چگونه SSH را امن کنیم؟ آموزش کامل امن‌سازی SSH در لینوکس از حذف Root Login تا SSH Key و Fail2Ban
اگر یک سرور مجازی لینوکس دارید، یکی از اولین سرویس‌هایی که باید برای امنیت آن جدی بگیرید SSH است. تقریباً تمام مدیریت سرورهای لینوکسی از طریق SSH انجام می‌شود و به همین دلیل، اگر تنظیمات آن به شکل مناسبی انجام نشده باشد، می‌تواند یکی از نقاطی باشد که مهاجمان برای دسترسی به سرور بررسی می‌کنند.
در بسیاری از سرورهای تازه نصب‌شده، SSH با تنظیمات پیش‌فرض اجرا می‌شود؛ یعنی سرویس SSH روی پورت مشخصی در دسترس است، امکان ورود با نام کاربری و رمز عبور وجود دارد و در بعضی سیستم‌ها حتی ورود مستقیم کاربر root نیز امکان‌پذیر است.
این موضوع لزوماً به معنی ناامن بودن خود لینوکس نیست، اما باعث می‌شود سرور شما هدف مناسبی برای حملات خودکار، Password Spraying و Brute Force باشد.
در این آموزش قرار نیست فقط چند دستور را پشت سر هم اجرا کنیم. ابتدا وضعیت امنیتی سرور را بررسی می‌کنیم، سپس یک کاربر مدیریتی ایجاد می‌کنیم، ورود با SSH Key را راه‌اندازی می‌کنیم، دسترسی Root را محدود می‌کنیم، ورود با رمز عبور را در صورت مناسب بودن شرایط غیرفعال می‌کنیم، Fail2Ban را فعال می‌کنیم و در نهایت روش بررسی کاربران ناشناس، کلیدهای SSH مشکوک و لاگ‌های ورود را یاد می‌گیریم.
نکته مهم: این مقاله برای سرورهای مجازی لینوکس نوشته شده است و فرض می‌کند به SSH و همچنین کنسول یا VNC سرور دسترسی دارید. داشتن دسترسی کنسول بسیار مهم است؛ چون اگر در هنگام تغییر تنظیمات SSH اشتباهی رخ دهد، می‌توانید از طریق کنسول وارد سرور شوید و تنظیمات را اصلاح کنید.
SSH چیست و چرا باید آن را امن کنیم؟
SSH مخفف Secure Shell است و یکی از مهم‌ترین روش‌های مدیریت سیستم‌های لینوکسی از راه دور محسوب می‌شود.
با SSH می‌توانید کارهایی مانند موارد زیر را انجام دهید:
- ورود به سرور
- اجرای دستورات لینوکس
- نصب و حذف نرم‌افزار
- مدیریت سرویس‌ها
- انتقال فایل
- مدیریت کاربران
- مدیریت فایروال
- مشاهده لاگ‌ها
- مدیریت سرویس‌های وب
- مدیریت دیتابیس
- انجام عملیات مدیریتی با سطح دسترسی Root
OpenSSH امکان احراز هویت با روش‌هایی مانند رمز عبور و کلیدهای عمومی/خصوصی را فراهم می‌کند و فایل اصلی تنظیمات سرور معمولاً /etc/ssh/sshd_config است؛ البته در توزیع‌های جدید ممکن است تنظیمات اضافی از مسیر /etc/ssh/sshd_config.d/ نیز خوانده شوند.
بنابراین اگر فردی بتواند با موفقیت وارد SSH سرور شود، بسته به سطح دسترسی حساب کاربری می‌تواند اقدامات مختلفی روی سیستم انجام دهد.
آیا باز بودن پورت SSH به معنی هک شدن سرور است؟
خیر.
باز بودن پورت SSH به خودی خود نشانه هک شدن سرور نیست.
اگر یک سرور مجازی برای مدیریت از راه دور استفاده می‌شود، طبیعی است که SSH در شبکه قابل دسترسی باشد.
مشکل زمانی جدی‌تر می‌شود که مواردی مانند این‌ها وجود داشته باشند:
- رمز عبور ضعیف باشد.
- ورود مستقیم Root فعال باشد.
- ورود با Password بدون محدودیت در اینترنت باز باشد.
- نرم‌افزارهای سیستم قدیمی باشند.
- کلیدهای SSH ناشناس در سیستم وجود داشته باشند.
- کاربران ناشناس یا غیرضروری ایجاد شده باشند.
- سرویس‌های غیرضروری روی اینترنت باز باشند.
- لاگ‌های ورود بررسی نشوند.
- دسترسی کاربران بیش از نیازشان باشد.
بنابراین هدف ما این نیست که SSH را کورکورانه خاموش کنیم؛ هدف این است که مسیر مدیریت سرور را محدود و قابل کنترل کنیم.
قبل از شروع امن‌سازی SSH چه چیزهایی لازم داریم؟
قبل از اجرای دستورات این آموزش بهتر است موارد زیر را در اختیار داشته باشید:
- IP سرور مجازی
- نام کاربری فعلی SSH
- رمز عبور فعلی
- دسترسی SSH
- دسترسی Console یا VNC
- دسترسی Root یا کاربری که بتواند
sudoاجرا کند - یک کامپیوتر برای ساخت SSH Key
اگر ارائه‌دهنده سرور مجازی شما امکان Console یا VNC در پنل سرویس ارائه می‌کند، حتماً مطمئن شوید که می‌توانید از آن استفاده کنید.
این موضوع بسیار مهم است.
فرض کنید دستور زیر را اجرا کنید:
PermitRootLogin no
اما هنوز کاربر دیگری برای ورود ایجاد نکرده باشید.
اگر نشست SSH فعلی قطع شود، ممکن است دیگر نتوانید از راه دور وارد سرور شوید.
وجود Console یا VNC در چنین شرایطی می‌تواند نجات‌دهنده باشد.
مهم‌ترین قانون: قبل از تغییر SSH خودتان را قفل نکنید!
یکی از مهم‌ترین اصول Hardening این است:
تا زمانی که ورود با روش جدید را تست نکرده‌اید، روش قبلی ورود را قطع نکنید.
برای مثال اگر الان با root وارد سرور شده‌اید، ابتدا یک کاربر مدیریتی بسازید، SSH Key را برای او تنظیم کنید و در یک پنجره ترمینال جدید ورود با آن کاربر را آزمایش کنید.
بعد از اینکه مطمئن شدید ورود جدید کار می‌کند، سراغ غیرفعال کردن Root Login بروید.
مرحله اول: تشخیص نوع لینوکس
قبل از اجرای دستورات باید بدانیم روی چه توزیعی هستیم.
این دستور را اجرا کنید:
cat /etc/os-release
خروجی ممکن است چیزی شبیه این باشد:
NAME="Ubuntu"
VERSION="24.04 LTS"
یا:
NAME="Debian GNU/Linux"
VERSION="13"
یا:
NAME="AlmaLinux"
VERSION="9"
یا:
NAME="Rocky Linux"
VERSION="9"
یا:
NAME="CentOS Stream"
در ادامه هر جا تفاوتی بین Debian/Ubuntu و RHEL/AlmaLinux/Rocky/CentOS وجود داشته باشد، دستور مناسب همان خانواده را معرفی می‌کنیم.
مرحله دوم: بررسی وضعیت فعلی SSH
ابتدا ببینید سرویس SSH در چه وضعیتی قرار دارد.
در Ubuntu و Debian معمولاً:
systemctl status ssh
در AlmaLinux، Rocky، RHEL و CentOS معمولاً:
systemctl status sshd
اگر سرویس فعال باشد، چیزی شبیه این خواهید دید:
Active: active (running)
فایل تنظیمات SSH کجاست؟
فایل اصلی تنظیمات SSH معمولاً:
/etc/ssh/sshd_config
است.
اما در بسیاری از سیستم‌های جدید ممکن است فایل‌های دیگری نیز از مسیر زیر بارگذاری شوند:
/etc/ssh/sshd_config.d/
برای همین اگر تنظیمی را در sshd_config پیدا نکردید، حتماً فایل‌های داخل این پوشه را هم بررسی کنید.
در Ubuntu نیز مستندات رسمی استفاده از sshd_config.d را در کنار فایل اصلی پیکربندی توضیح می‌دهد.
قبل از تغییر تنظیمات SSH از فایل پشتیبان بگیرید
این کار ساده است اما در مواقع خطا بسیار مفید خواهد بود.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
اگر Root هستید:
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
اکنون یک نسخه از تنظیمات فعلی دارید.
مرحله سوم: بررسی تنظیمات واقعی SSH
گاهی اوقات فقط نگاه کردن به /etc/ssh/sshd_config کافی نیست؛ زیرا ممکن است تنظیمات دیگری از فایل‌های Include روی نتیجه نهایی تأثیر بگذارند.
برای مشاهده تنظیمات مؤثر SSH می‌توانید از:
sshd -T
استفاده کنید.
برای بررسی چند گزینه مهم:
sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
ممکن است خروجی مانند این باشد:
port 22
permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes
این یعنی SSH در حال حاضر اجازه ورود Root و احراز هویت با Password را می‌دهد.
مرحله چهارم: ایجاد یک کاربر مدیریتی جدید
اگر اکنون با Root وارد شده‌اید، بهتر است یک حساب مدیریتی جداگانه داشته باشید.
نام کاربر می‌تواند مثلاً:
admin
باشد.
Ubuntu و Debian
adduser admin
در ادامه لینوکس از شما رمز عبور می‌خواهد.
سپس کاربر را به گروه sudo اضافه کنید:
usermod -aG sudo admin
برای بررسی:
id admin
ساخت کاربر در AlmaLinux، Rocky، RHEL و CentOS
ابتدا:
useradd admin
سپس رمز عبور:
passwd admin
و برای اضافه کردن دسترسی مدیریتی:
usermod -aG wheel admin
در سیستم‌های خانواده RHEL معمولاً گروه wheel برای دسترسی sudo استفاده می‌شود.
آیا بهتر است نام کاربر را admin بگذاریم؟
ضرورتی ندارد.
می‌توانید نامی مانند:
sysadmin
serveradmin
operator
انتخاب کنید.
اما نباید تصور کنید تغییر نام root یا انتخاب یک نام عجیب به تنهایی امنیت SSH را بالا می‌برد.
امنیت اصلی از ترکیب چند لایه ایجاد می‌شود:
- SSH Key
- غیرفعال کردن Root Login
- محدود کردن کاربران
- رمز عبور مناسب
- Fail2Ban
- Firewall
- به‌روزرسانی سیستم
- بررسی لاگ‌ها
- کم کردن سرویس‌های غیرضروری
مرحله پنجم: ساخت SSH Key
یکی از مهم‌ترین بخش‌های این آموزش همین قسمت است.
در SSH Key به جای اینکه صرفاً به یک رمز عبور متکی باشیم، از یک جفت کلید استفاده می‌کنیم:
- Private Key
- Public Key
کلید خصوصی باید فقط نزد شما باقی بماند.
کلید عمومی روی سرور قرار می‌گیرد.
OpenSSH از روش‌های مختلف کلید پشتیبانی می‌کند و مستندات رسمی Ubuntu استفاده از Ed25519 را به دلیل اندازه کوتاه‌تر کلید و هزینه محاسباتی کمتر توصیه می‌کند؛ RSA با اندازه 4096 بیت نیز به عنوان گزینه جایگزین مطرح شده است.
ساخت SSH Key در ویندوز
اگر روی ویندوز 10 یا 11 هستید، در بسیاری از سیستم‌ها می‌توانید PowerShell یا Windows Terminal را باز کنید.
دستور زیر را اجرا کنید:
ssh-keygen -t ed25519
سپس چیزی شبیه این خواهید دید:
Enter file in which to save the key:
اگر مسیر پیش‌فرض مناسب است، Enter بزنید.
بعد از آن:
Enter passphrase:
از شما یک Passphrase می‌خواهد.
پیشنهاد می‌شود برای Private Key یک Passphrase مناسب تعیین کنید.
تفاوت Password و Passphrase چیست؟
Password معمولاً برای ورود به حساب کاربری استفاده می‌شود.
Passphrase از کلید خصوصی شما محافظت می‌کند.
فرض کنید Private Key شما به هر دلیلی از کامپیوترتان کپی شود.
اگر Private Key بدون Passphrase باشد، شخصی که آن فایل را به دست آورده ممکن است بتواند از آن استفاده کند.
اما اگر Private Key با Passphrase محافظت شده باشد، یک لایه امنیتی دیگر نیز وجود دارد.
بنابراین:
Private Key را مانند رمز عبور بسیار حساس در نظر بگیرید و آن را در اختیار دیگران قرار ندهید.
فایل‌های SSH Key کجا ذخیره می‌شوند؟
در ویندوز معمولاً چیزی شبیه:
C:\Users\USERNAME\.ssh\
خواهید داشت.
دو فایل مهم ایجاد می‌شود:
id_ed25519
id_ed25519.pub
فایل بدون .pub کلید خصوصی است.
فایل دارای .pub کلید عمومی است.
بسیار مهم
این فایل را هرگز عمومی نکنید:
id_ed25519
اما محتوای:
id_ed25519.pub
کلید عمومی است و برای قرار گرفتن روی سرور استفاده می‌شود.
مرحله ششم: قرار دادن Public Key روی سرور
اگر روی سیستم شما ssh-copy-id وجود داشته باشد، می‌توانید از آن استفاده کنید:
ssh-copy-id admin@SERVER-IP
اما در ویندوز همیشه این ابزار در دسترس نیست.
در چنین شرایطی می‌توانیم Public Key را به صورت دستی روی سرور قرار دهیم.
ساخت پوشه SSH برای کاربر
ابتدا با کاربر جدید وارد سرور شوید یا از Root این دستورات را اجرا کنید.
mkdir -p /home/admin/.ssh
سپس:
chmod 700 /home/admin/.ssh
فایل کلیدهای مجاز را ایجاد کنید:
touch /home/admin/.ssh/authorized_keys
و:
chmod 600 /home/admin/.ssh/authorized_keys
مالکیت را نیز اصلاح کنید:
chown -R admin:admin /home/admin/.ssh
اکنون محتوای فایل:
id_ed25519.pub
را در:
/home/admin/.ssh/authorized_keys
قرار دهید.
برای مثال:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI............. user@computer
کلید عمومی معمولاً در یک خط قرار می‌گیرد.
چرا Permission های SSH مهم هستند؟
اگر دسترسی فایل‌های SSH اشتباه باشد، OpenSSH ممکن است کلید را قبول نکند.
برای مثال:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
و مالکیت باید متعلق به همان کاربر باشد.
Ubuntu نیز در مستندات خود روی بررسی Permission فایل authorized_keys تأکید کرده است.
مرحله هفتم: تست ورود با SSH Key
این مرحله را جدی بگیرید.
هنوز Password Authentication را غیرفعال نکنید.
یک پنجره ترمینال جدید باز کنید و با کاربر جدید وارد شوید:
ssh admin@SERVER-IP
اگر همه چیز درست باشد، سیستم باید از SSH Key استفاده کند.
در صورت نیاز می‌توانید کلید مشخصی را معرفی کنید:
ssh -i ~/.ssh/id_ed25519 admin@SERVER-IP
در ویندوز مسیر ممکن است متفاوت باشد.
اگر SSH Key کار نکرد چه کنیم؟
فعلاً تنظیمات قبلی SSH را تغییر ندهید.
اول لاگ SSH را بررسی کنید.
در Ubuntu و Debian:
sudo journalctl -u ssh -n 50
در سیستم‌های RHEL:
sudo journalctl -u sshd -n 50
همچنین می‌توانید وضعیت Permission را بررسی کنید:
ls -la /home/admin/.ssh/
باید چیزی شبیه این داشته باشید:
drwx------ admin admin .ssh
-rw------- admin admin authorized_keys
اگر مالکیت اشتباه است:
chown -R admin:admin /home/admin/.ssh
مرحله هشتم: غیرفعال کردن ورود مستقیم Root
وقتی مطمئن شدید کاربر جدید با SSH Key می‌تواند وارد سرور شود، می‌توانیم Root Login را محدود کنیم.
فایل:
/etc/ssh/sshd_config
را باز کنید.
مثلاً با nano:
nano /etc/ssh/sshd_config
به دنبال:
PermitRootLogin
بگردید.
اگر وجود ندارد، می‌توانید اضافه کنید:
PermitRootLogin no
با این تنظیم، ورود مستقیم Root از طریق SSH غیرفعال می‌شود.
گزینه PermitRootLogin مشخص می‌کند که آیا حساب Root می‌تواند از طریق SSH وارد شود یا خیر. مقدار no ورود Root را از طریق SSH ممنوع می‌کند.
آیا بعد از PermitRootLogin no دسترسی Root کاملاً از بین می‌رود؟
خیر.
این نکته برای کاربران تازه‌کار مهم است.
وقتی می‌نویسیم:
PermitRootLogin no
منظور این است که ورود مستقیم Root از طریق SSH ممنوع می‌شود.
اگر کاربر admin دسترسی sudo داشته باشد، می‌تواند پس از ورود اجرا کند:
sudo -i
و در صورت داشتن مجوز مناسب وارد محیط Root شود.
بنابراین ساختار بهتر این است:
SSH
↓
admin
↓
sudo
↓
root
به جای:
SSH
↓
root
مرحله نهم: غیرفعال کردن ورود با Password
بعد از اینکه SSH Key را با موفقیت تست کردید، می‌توانید Password Authentication را نیز غیرفعال کنید.
در:
/etc/ssh/sshd_config
قرار دهید:
PasswordAuthentication no
همچنین:
PubkeyAuthentication yes
را فعال نگه دارید.
در مستندات Debian نیز استفاده از SSH Key و غیرفعال کردن Password Authentication به عنوان یکی از روش‌های Hardening SSH مطرح شده است.
Red Hat نیز در مستندات خود نمونه‌ای از تنظیم SSH با:
PermitRootLogin: no
PasswordAuthentication: no
ارائه می‌کند.
یک هشدار بسیار مهم قبل از PasswordAuthentication no
اگر این دستور را اجرا کنید:
PasswordAuthentication no
و SSH Key شما درست کار نکند، ممکن است دیگر نتوانید با رمز عبور وارد شوید.
بنابراین قبل از اعمال این تغییر:
- اتصال SSH فعلی را باز نگه دارید.
- Console یا VNC را باز نگه دارید.
- از یک پنجره جدید ورود با SSH Key را آزمایش کنید.
- مطمئن شوید کاربر جدید sudo دارد.
- سپس Password Authentication را غیرفعال کنید.
مرحله دهم: تست صحت تنظیمات SSH قبل از Restart
این یکی از مهم‌ترین مراحل مقاله است.
قبل از Restart یا Reload کردن SSH، تنظیمات را بررسی کنید.
sshd -t
اگر هیچ خروجی نمایش داده نشد، معمولاً یعنی Syntax فایل تنظیمات مشکلی ندارد.
اما اگر خطایی دیدید، هنوز SSH را Restart نکنید.
ابتدا خطا را اصلاح کنید.
Reload یا Restart؟
برای اعمال تنظیمات SSH معمولاً بهتر است ابتدا از Reload استفاده کنید:
Ubuntu/Debian:
systemctl reload ssh
RHEL/AlmaLinux/Rocky/CentOS:
systemctl reload sshd
در صورت نیاز می‌توان از Restart نیز استفاده کرد، اما Reload در بسیاری از تغییرات تنظیماتی، بدون قطع کردن Sessionهای موجود مناسب‌تر است.
مرحله یازدهم: بررسی پورت SSH
پورت پیش‌فرض SSH معمولاً:
22
است.
برای مشاهده پورت در تنظیمات:
sshd -T | grep '^port'
مثلاً:
port 22
آیا تغییر پورت SSH امنیت را زیاد می‌کند؟
تغییر پورت می‌تواند حجم اسکن‌ها و تلاش‌های خودکار روی پورت استاندارد را کاهش دهد، اما نباید آن را جایگزین روش‌های امنیتی اصلی بدانیم.
یعنی این کار:
22 → 2222
به تنهایی سرور را امن نمی‌کند.
اگر:
PasswordAuthentication yes
PermitRootLogin yes
باشد، تغییر پورت مشکل اصلی را حل نکرده است.
امنیت واقعی باید بر اساس احراز هویت قوی، محدود کردن کاربران، Firewall، به‌روزرسانی و مانیتورینگ انجام شود.
اگر خواستید پورت SSH را تغییر دهید
مثلاً:
Port 2222
را در تنظیمات قرار دهید.
اما یک نکته بسیار مهم وجود دارد:
اگر Firewall دارید، ابتدا مطمئن شوید پورت جدید اجازه عبور دارد.
همچنین اگر از سرویس VPS استفاده می‌کنید، ممکن است Firewall در دو سطح وجود داشته باشد:
Firewall داخل Linux
+
Firewall سمت پنل/شبکه ارائه‌دهنده VPS
بنابراین تغییر پورت بدون توجه به Firewall می‌تواند باعث قطع دسترسی شود.
مرحله دوازدهم: بررسی کاربران لینوکس
حالا که SSH را تا حد زیادی امن کرده‌ایم، باید بررسی کنیم چه حساب‌های کاربری روی سیستم وجود دارند.
دستور:
cat /etc/passwd
فهرست کاربران را نمایش می‌دهد.
اما همه کاربران موجود در /etc/passwd انسان نیستند.
لینوکس برای سرویس‌ها نیز حساب‌هایی مانند:
www-data
mysql
nginx
daemon
nobody
دارد.
بنابراین دیدن تعداد زیادی User لزوماً به معنی هک شدن نیست.
چگونه کاربران دارای Shell را پیدا کنیم؟
در بسیاری از سیستم‌ها می‌توان از:
grep -E '/bin/(bash|sh|zsh)$' /etc/passwd
استفاده کرد.
این دستور کمک می‌کند حساب‌هایی را که Shell تعاملی دارند راحت‌تر ببینید.
مثلاً:
root:x:0:0:root:/root:/bin/bash
admin:x:1000:1000::/home/admin:/bin/bash
حالا سؤال مهم این است:
آیا همه این کاربران را می‌شناسید؟
اگر کاربری را نمی‌شناسید، بلافاصله آن را حذف نکنید.
ابتدا بررسی کنید چرا ایجاد شده است.
ممکن است متعلق به یک نرم‌افزار یا سرویس باشد.
بررسی UID کاربران
در لینوکس UID صفر اهمیت ویژه‌ای دارد.
کاربری که UID آن 0 باشد عملاً سطح دسترسی Root دارد.
برای بررسی:
awk -F: '$3 == 0 {print $1}' /etc/passwd
در حالت عادی انتظار دارید:
root
را ببینید.
اگر User دیگری با UID صفر وجود داشت، باید با دقت بسیار بیشتری بررسی شود.
بررسی گروه‌های مدیریتی
در Ubuntu و Debian:
getent group sudo
در AlmaLinux، Rocky، RHEL و CentOS:
getent group wheel
بررسی کنید چه کاربرانی دسترسی مدیریتی دارند.
هر کاربری که بتواند:
sudo
اجرا کند، باید برای شما شناخته‌شده و ضروری باشد.
بررسی کلیدهای SSH کاربران
یکی از مهم‌ترین قسمت‌های بررسی امنیتی همین بخش است.
برای کاربر Root:
cat /root/.ssh/authorized_keys
برای کاربر admin:
cat /home/admin/.ssh/authorized_keys
اگر کاربران دیگری وجود دارند، مسیر Home آنها را نیز بررسی کنید.
مثلاً:
find /home -name authorized_keys -type f -print
اگر یک کلید ناشناس پیدا کردید، فوراً آن را پاک نکنید.
ابتدا بررسی کنید:
- متعلق به چه کاربری است؟
- چه زمانی ایجاد شده؟
- آیا یکی از اعضای تیم آن را اضافه کرده؟
- آیا مربوط به پنل یا نرم‌افزار خاصی است؟
- آیا اخیراً کسی برای مدیریت سرور کلید اضافه کرده است؟
اگر مطمئن شدید کلید متعلق به فرد یا سرویس مجاز نیست، آن را غیرفعال یا حذف کنید و سپس علت ایجاد آن را بررسی کنید.
آیا تغییر رمز Root یعنی سرور امن شده است؟
خیر.
این یک اشتباه رایج است.
فرض کنید متوجه شدید رمز Root احتمالاً لو رفته و آن را تغییر داده‌اید.
تغییر رمز کار درستی است، اما اگر فرد دیگری قبلاً روی سرور:
- SSH Key اضافه کرده باشد،
- کاربر جدید ساخته باشد،
- Cron Job ایجاد کرده باشد،
- سرویس مخفی اجرا کرده باشد،
- Script Startup اضافه کرده باشد،
- یا Backdoor ایجاد کرده باشد،
تغییر رمز به تنهایی مشکل را حل نمی‌کند.
به همین دلیل اگر احتمال می‌دهید رمز قبلی در اختیار فرد دیگری قرار گرفته، باید فرض کنید احتمال دسترسی غیرمجاز وجود داشته و سرور را بررسی کنید.
اگر فکر می‌کنیم سرور هک شده چه کار کنیم؟
اول از همه وحشت نکنید.
همچنین بدون بررسی، فایل‌ها و لاگ‌ها را پاک نکنید.
اگر احتمال جدی نفوذ وجود دارد:
- دسترسی غیرضروری را محدود کنید.
- حساب‌های ناشناس را بررسی کنید.
- کلیدهای SSH را بررسی کنید.
- Login Log ها را بررسی کنید.
- Processهای مشکوک را بررسی کنید.
- Cron Jobها را بررسی کنید.
- سرویس‌های جدید را بررسی کنید.
- بسته‌های سیستم را بررسی و به‌روزرسانی کنید.
- رمزهای حساس را تغییر دهید.
- در صورت اطمینان از Compromise، نصب مجدد سیستم‌عامل را به عنوان گزینه جدی در نظر بگیرید.
اگر سرور اطلاعات مهمی دارد، قبل از پاک کردن شواهد بهتر است از متخصص امنیت کمک بگیرید.
مرحله سیزدهم: بررسی Login های موفق و ناموفق
در Ubuntu و Debian معمولاً می‌توانید از:
last
استفاده کنید.
برای مشاهده تلاش‌های ناموفق:
lastb
ممکن است خروجی شامل IPهایی مانند:
root ssh:notty 192.0.2.10
admin pts/0 198.51.100.20
باشد.
بررسی لاگ SSH با Journalctl
در سیستم‌های جدید که از systemd استفاده می‌کنند:
Ubuntu/Debian:
journalctl -u ssh
RHEL/AlmaLinux/Rocky:
journalctl -u sshd
برای مشاهده آخرین خطوط:
journalctl -u ssh --since "24 hours ago"
یا:
journalctl -u sshd --since "24 hours ago"
در Debian و Ubuntu لاگ SSH کجاست؟
بسته به تنظیمات سیستم، اطلاعات احراز هویت معمولاً در:
/var/log/auth.log
قرار می‌گیرد.
برای مثال:
grep ssh /var/log/auth.log
و برای مشاهده تلاش‌های ناموفق:
grep "Failed password" /var/log/auth.log
در RHEL، AlmaLinux و Rocky لاگ‌ها کجا هستند؟
در سیستم‌های خانواده RHEL معمولاً می‌توانید از:
journalctl -u sshd
استفاده کنید.
در برخی سیستم‌ها نیز اطلاعات احراز هویت در:
/var/log/secure
وجود دارد.
مثلاً:
grep sshd /var/log/secure
Failed password به معنی هک شدن است؟
خیر.
اگر چنین چیزی مشاهده کردید:
Failed password for root from 203.0.113.50
این فقط نشان می‌دهد یک تلاش ناموفق برای ورود انجام شده است.
سرورهای متصل به اینترنت دائماً توسط Botها و Scannerها بررسی می‌شوند.
چیزی که باید جدی‌تر بررسی شود:
Accepted password
Accepted publickey
برای IP یا کاربری است که آن را نمی‌شناسید.
چگونه Login موفق را پیدا کنیم؟
برای SSH می‌توانید از:
grep "Accepted" /var/log/auth.log
در Ubuntu/Debian استفاده کنید.
در سیستم‌های RHEL:
grep "Accepted" /var/log/secure
یا:
journalctl -u sshd | grep "Accepted"
اگر مثلاً می‌بینید:
Accepted publickey for admin from 198.51.100.10
باید بررسی کنید آیا IP مربوط به خودتان است یا خیر.
اگر IP ناشناخته بود چه؟
ناشناخته بودن IP به تنهایی اثبات نفوذ نیست.
ممکن است:
- IP اینترنت شما تغییر کرده باشد.
- از VPN استفاده کرده باشید.
- از شبکه شرکت وارد شده باشید.
- از یک سرور واسط استفاده کرده باشید.
- ISP شما IP دیگری اختصاص داده باشد.
اما اگر Login موفقی را مشاهده کردید که واقعاً متعلق به شما یا تیم شما نیست، موضوع باید جدی بررسی شود.
مرحله چهاردهم: بررسی Session های فعلی
برای مشاهده کاربران لاگین‌شده:
who
یا:
w
می‌توانید استفاده کنید.
مثلاً:
USER TTY FROM
admin pts/0 198.51.100.20
اگر Session ناشناسی مشاهده کردید، ابتدا بررسی کنید متعلق به چه کسی است.
بررسی Process های در حال اجرا
برای مشاهده Processها:
ps aux
یا:
top
و در سیستم‌هایی که نصب شده باشد:
htop
اگر Process ناشناسی با مصرف غیرطبیعی CPU یا RAM مشاهده کردید، بدون بررسی آن را Kill نکنید.
نام Process، PID، مسیر فایل و کاربری که Process را اجرا کرده بررسی کنید.
پیدا کردن مسیر یک Process
فرض کنید PID برابر:
1234
است.
می‌توانید بزنید:
readlink -f /proc/1234/exe
و:
ps -fp 1234
این اطلاعات می‌تواند برای تشخیص اینکه Process متعلق به کدام نرم‌افزار است مفید باشد.
مرحله پانزدهم: بررسی Cron Job ها
یکی از مکان‌هایی که در بررسی امنیتی باید توجه ویژه‌ای به آن داشته باشید Cron است.
Cron برای اجرای خودکار دستورات استفاده می‌شود.
برای کاربر فعلی:
crontab -l
برای Root:
sudo crontab -l
همچنین:
ls -la /etc/cron.d/
و:
ls -la /etc/cron.daily/
و:
ls -la /etc/cron.hourly/
را بررسی کنید.
وجود یک Cron Job ناشناس می‌تواند نیازمند بررسی بیشتر باشد.
مرحله شانزدهم: نصب Fail2Ban
حالا که SSH را با Key امن‌تر کرده‌ایم، بهتر است یک لایه دیگر نیز برای مقابله با تلاش‌های مکرر ورود اضافه کنیم.
اینجا Fail2Ban وارد می‌شود.
Fail2Ban لاگ‌های سرویس‌ها را بررسی می‌کند و در صورت مشاهده الگوهای مشخصی از تلاش‌های ناموفق، می‌تواند IP مربوطه را برای مدت مشخصی مسدود کند.
Debian نیز Fail2Ban را به عنوان ابزاری برای شناسایی تلاش‌های متعدد ناموفق و Ban کردن IPها معرفی می‌کند.
نصب Fail2Ban در Ubuntu و Debian
ابتدا:
sudo apt update
سپس:
sudo apt install fail2ban -y
فعال کردن سرویس:
sudo systemctl enable --now fail2ban
بررسی:
sudo systemctl status fail2ban
نصب Fail2Ban در AlmaLinux، Rocky، RHEL و CentOS Stream
ابتدا مخزن مناسب سیستم را بررسی کنید.
در سیستم‌های مبتنی بر RHEL ممکن است بسته Fail2Ban از مخازن فعال سیستم در دسترس باشد.
در صورت در دسترس بودن:
sudo dnf install fail2ban -y
سپس:
sudo systemctl enable --now fail2ban
و:
sudo systemctl status fail2ban
تنظیم Fail2Ban برای SSH
بهتر است فایل اصلی:
jail.conf
را مستقیماً تغییر ندهید.
یک فایل Local بسازید:
/etc/fail2ban/jail.local
برای مثال:
sudo nano /etc/fail2ban/jail.local
سپس می‌توان تنظیماتی مانند این قرار داد:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
بعد:
sudo systemctl restart fail2ban
و بررسی:
sudo fail2ban-client status
برای Jail مربوط به SSH:
sudo fail2ban-client status sshd
Fail2Ban دقیقاً چه کاری انجام می‌دهد؟
فرض کنید تنظیم کرده‌ایم:
findtime = 10m
maxretry = 5
bantime = 1h
یعنی Fail2Ban در یک بازه زمانی مشخص، تلاش‌های ناموفق را بررسی می‌کند و اگر تعداد آنها از مقدار تعیین‌شده عبور کند، IP مربوطه را برای مدت مشخصی Ban می‌کند.
اما باید توجه داشت:
Fail2Ban جایگزین SSH Key، Firewall، به‌روزرسانی سیستم و تنظیمات صحیح SSH نیست.
همچنین Fail2Ban در برابر تمام انواع حملات مناسب نیست و در برابر حملات توزیع‌شده که از تعداد زیادی IP استفاده می‌کنند محدودیت دارد.
مرحله هفدهم: بررسی وضعیت Fail2Ban
برای مشاهده Jailها:
sudo fail2ban-client status
مثلاً:
Jail list: sshd
سپس:
sudo fail2ban-client status sshd
ممکن است اطلاعاتی مانند:
Currently failed:
Total failed:
Currently banned:
Total banned:
نمایش داده شود.
اگر IP خودمان Ban شد چه کنیم؟
این اتفاق ممکن است رخ دهد.
اگر به اشتباه IP خودتان Ban شد، ابتدا از Console یا یک IP مجاز دیگر وارد سرور شوید.
سپس:
sudo fail2ban-client set sshd unbanip YOUR-IP
البته نام Jail باید با تنظیمات سیستم شما مطابقت داشته باشد.
مرحله هجدهم: محدود کردن کاربران SSH
یکی از روش‌های دیگر برای کاهش سطح حمله این است که مشخص کنید چه کاربرانی اجازه ورود SSH دارند.
مثلاً:
AllowUsers admin
در این حالت فقط کاربر مشخص‌شده مجاز خواهد بود.
می‌توانید چند کاربر را نیز مشخص کنید:
AllowUsers admin operator
این قابلیت می‌تواند به محدود کردن حساب‌های مجاز برای SSH کمک کند. Debian نیز گزینه‌های AllowUsers و AllowGroups را در تنظیمات SSH معرفی می‌کند.
آیا AllowUsers همیشه ضروری است؟
خیر.
اگر فقط یک یا دو کاربر مدیریتی دارید، می‌تواند مفید باشد.
اما اگر سرور شما برای چند کاربر یا چند سرویس استفاده می‌شود، قبل از اعمال آن باید مطمئن شوید که حساب‌های موردنیاز حذف نمی‌شوند.
مرحله نوزدهم: بررسی SSH بعد از Hardening
بعد از انجام تغییرات:
sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
مثلاً وضعیت هدف می‌تواند چیزی شبیه این باشد:
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes
port 22
البته تنظیمات مناسب به نوع سرور و نیازهای شما بستگی دارد.
وضعیت ایده‌آل SSH برای یک VPS شخصی
برای یک سرور مجازی که فقط خود مدیر آن را مدیریت می‌کند، معماری معمول می‌تواند این باشد:
Internet
|
v
SSH
|
+---- SSH Key
|
+---- Fail2Ban
|
+---- Firewall
|
v
admin user
|
v
sudo
|
v
root
در این ساختار، Root مستقیماً از اینترنت Login نمی‌کند و کاربر مدیریتی با کلید SSH احراز هویت می‌شود.
مرحله بیستم: بررسی Firewall
امنیت SSH بدون Firewall کامل نیست.
در Ubuntu ممکن است UFW استفاده کنید.
بررسی:
sudo ufw status
اگر SSH روی پورت 22 است:
sudo ufw allow 22/tcp
اگر SSH روی پورت دیگری است، همان پورت را مجاز کنید.
سپس:
sudo ufw enable
هشدار
اگر قبل از Enable کردن Firewall دسترسی SSH خود را مجاز نکرده باشید، ممکن است ارتباط شما قطع شود.
بنابراین ابتدا Ruleهای موردنیاز را بررسی کنید.
اگر از پورت غیر استاندارد استفاده می‌کنیم
فرض کنید SSH روی:
2222
است.
باید:
sudo ufw allow 2222/tcp
را قبل از فعال کردن Firewall در نظر بگیرید.
آیا تغییر پورت SSH ضروری است؟
خیر.
این کار اختیاری است.
مهم‌ترین اقدامات عبارت‌اند از:
- SSH Key
- حذف Root Login مستقیم
- غیرفعال کردن Password Authentication در صورت امکان
- Firewall
- Fail2Ban
- به‌روزرسانی
- بررسی لاگ‌ها
- حذف حساب‌های غیرضروری
- بررسی کلیدهای SSH
تغییر پورت می‌تواند نویز و تعداد زیادی از اسکن‌های خودکار را کم کند، اما نباید به عنوان یک راهکار امنیتی اصلی معرفی شود.
مرحله بیست‌ویکم: به‌روزرسانی سیستم‌عامل
امنیت SSH فقط مربوط به فایل sshd_config نیست.
خود OpenSSH و سایر نرم‌افزارهای سرور نیز باید به‌روز باشند.
در Ubuntu و Debian:
sudo apt update
sudo apt upgrade
در سیستم‌های RHEL:
sudo dnf update
Debian نیز توصیه می‌کند به‌روزرسانی‌های امنیتی OpenSSH در اسرع وقت نصب شوند.
آیا بعد از تغییر SSH باید سیستم را Reboot کنیم؟
معمولاً برای تغییر تنظیمات SSH نیازی به Reboot کامل سیستم نیست.
بعد از بررسی Syntax:
sshd -t
می‌توانید سرویس SSH را Reload کنید.
Ubuntu/Debian:
sudo systemctl reload ssh
RHEL/AlmaLinux/Rocky:
sudo systemctl reload sshd
اگر SSH خراب شد و دیگر نمی‌توانیم وصل شویم چه کنیم؟
اینجا همان جایی است که Console یا VNC اهمیت پیدا می‌کند.
از طریق Console وارد سرور شوید.
ابتدا:
sshd -t
را اجرا کنید.
اگر خطا داشت، فایل:
/etc/ssh/sshd_config
را بررسی کنید.
اگر لازم بود Backup قبلی را برگردانید:
cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
سپس:
sshd -t
و بعد سرویس را Reload کنید.
اگر Password Authentication را اشتباهی خاموش کردیم چه؟
اگر هنوز یک Session باز دارید، آن را نبندید.
با همان Session تنظیمات را اصلاح کنید.
اگر هیچ Session فعالی ندارید، از Console یا VNC وارد شوید.
سپس:
nano /etc/ssh/sshd_config
تنظیم موردنظر را اصلاح کنید.
این دقیقاً یکی از دلایلی است که توصیه می‌شود هنگام Hardening SSH، دسترسی Console را در اختیار داشته باشید.
بررسی Backdoor های رایج در SSH
اگر شک دارید سرور قبلاً در معرض دسترسی غیرمجاز قرار گرفته، بررسی را فقط به sshd_config محدود نکنید.
موارد زیر را بررسی کنید:
/etc/passwd
/etc/shadow
/etc/sudoers
/etc/sudoers.d/
/root/.ssh/
/home/*/.ssh/
/etc/cron.d/
/etc/systemd/system/
/etc/rc.local
همچنین Processهای در حال اجرا، سرویس‌ها و فایل‌های Startup را بررسی کنید.
بررسی سرویس‌های فعال
برای مشاهده سرویس‌های فعال:
systemctl --type=service --state=running
اگر سرویس ناشناسی دیدید، نام آن را بررسی کنید.
مثلاً:
systemctl status SERVICE-NAME
و:
systemctl cat SERVICE-NAME
می‌تواند اطلاعات بیشتری درباره نحوه اجرای سرویس نشان دهد.
بررسی پورت‌های باز
برای مشاهده Socketهای Listening:
ss -tulpn
مثلاً:
LISTEN 0 128 0.0.0.0:22
LISTEN 0 128 0.0.0.0:80
LISTEN 0 128 0.0.0.0:443
اگر پورتی را نمی‌شناسید، باید بررسی کنید کدام سرویس آن را باز کرده است.
آیا دیدن پورت ناشناس یعنی Backdoor داریم؟
نه.
ممکن است آن پورت متعلق به:
- Docker
- Web Server
- Database
- Control Panel
- Monitoring
- DNS
- Mail Server
- VPN
- نرم‌افزار دیگری که خودتان نصب کرده‌اید
باشد.
اما هر Port ناشناخته باید شناسایی شود.
بررسی مالک یک Port
اگر مثلاً Port خاصی باز است، می‌توانید با:
ss -lntp
اطلاعات Process مربوط به آن را مشاهده کنید.
سپس PID را بررسی کنید:
ps -fp PID
بررسی فایل‌های تغییر یافته اخیر
برای بررسی ساده فایل‌های تغییر یافته در یک مسیر می‌توان از:
find /etc -type f -mtime -7
استفاده کرد.
این دستور فایل‌هایی را که در ۷ روز گذشته تغییر کرده‌اند نشان می‌دهد.
البته این روش به تنهایی ابزار تشخیص نفوذ نیست؛ فقط می‌تواند برای بررسی اولیه مفید باشد.
اگر رمز Root لو رفته باشد چه چیزهایی را باید تغییر دهیم؟
اگر احتمال می‌دهید رمز Root افشا شده، فقط رمز Root را تغییر ندهید.
بسته به وضعیت سرور، این موارد نیز باید بررسی شوند:
- رمز کاربران مدیریتی
- SSH Keys
- کلیدهای API
- رمز دیتابیس
- رمز پنل‌ها
- رمز FTP/SFTP
- رمز ایمیل‌های مدیریتی
- Tokenهای سرویس‌ها
- Credentialهای Docker
- فایل‌های
.env - Secretهای نرم‌افزارها
چون ممکن است مهاجم به اطلاعات دیگری نیز دسترسی پیدا کرده باشد.
آیا بعد از تغییر رمز می‌توانیم مطمئن باشیم مهاجم بیرون رفته است؟
نه، صرفاً تغییر رمز چنین تضمینی نمی‌دهد.
اگر مهاجم قبلاً دسترسی گرفته باشد، ممکن است مکانیزم دیگری برای دسترسی مجدد ایجاد کرده باشد.
برای همین در صورت وجود شواهد واقعی از نفوذ باید یک بررسی کامل امنیتی انجام شود.
در مواردی که اطمینان حاصل شود سیستم Compromise شده، نصب مجدد سیستم‌عامل از یک Image معتبر و سپس Restore کردن اطلاعات بررسی‌شده، می‌تواند از ادامه آلودگی جلوگیری کند.
آیا باید همیشه Root Login را کاملاً ببندیم؟
برای بسیاری از سرورهای عمومی، جلوگیری از ورود مستقیم Root و استفاده از یک حساب مدیریتی + sudo رویکرد مناسبی است.
اما زیرساخت‌ها و نیازها متفاوت هستند.
برای مثال:
- بعضی سیستم‌های Automation
- بعضی Backupها
- برخی نرم‌افزارهای مدیریت زیرساخت
- برخی محیط‌های خاص
ممکن است نیازهای متفاوتی داشته باشند.
بنابراین قبل از:
PermitRootLogin no
وابستگی‌های مدیریتی سرور را بررسی کنید.
SSH Key بهتر است یا Password؟
برای مدیریت سرور، SSH Key معمولاً انتخاب مناسب‌تری نسبت به اتکا به Password است، به‌خصوص وقتی کلید خصوصی با Passphrase محافظت شود.
اما امنیت SSH Key نیز به نگهداری صحیح Private Key وابسته است.
اگر لپ‌تاپ شما آلوده باشد و Private Key در اختیار مهاجم قرار بگیرد، SSH Key به تنهایی مشکل را حل نمی‌کند.
پس امنیت واقعی یک زنجیره است:
Secure Computer
+
Protected Private Key
+
SSH Key Authentication
+
No Direct Root Login
+
Firewall
+
Fail2Ban
+
Updates
+
Monitoring
آیا باید Password کاربر را هم حذف کنیم؟
اگر:
PasswordAuthentication no
باشد، احراز هویت Password از طریق SSH غیرفعال می‌شود.
اما این موضوع با حذف Password خود حساب لینوکس یکی نیست.
برای مثال ممکن است کاربر همچنان Password داشته باشد و برای sudo به آن نیاز داشته باشد.
بنابراین بین این دو تفاوت قائل شوید:
Password Authentication over SSH
و:
Linux account password
اشتباهات رایج هنگام امن‌سازی SSH
۱. خاموش کردن Root قبل از ساخت کاربر جدید
اشتباه خطرناک.
ابتدا کاربر جدید بسازید.
۲. خاموش کردن Password قبل از تست SSH Key
اشتباه بسیار رایج.
اول:
ssh admin@SERVER-IP
را در یک پنجره جدید تست کنید.
بعد Password Authentication را خاموش کنید.
۳. بستن پورت SSH در Firewall
اگر SSH روی پورت 22 است:
ufw allow 22/tcp
یا Rule معادل در Firewall خود را قبل از اعمال محدودیت‌ها تنظیم کنید.
۴. تصور اینکه تغییر Port یعنی امنیت کامل
تغییر Port فقط یکی از اقدامات جانبی است.
۵. حذف کاربران ناشناس بدون بررسی
ممکن است User مربوط به یک سرویس باشد.
ابتدا بررسی کنید.
۶. حذف کلیدهای SSH بدون بررسی
کلید ممکن است متعلق به مدیر دیگری باشد.
۷. Restart کردن SSH بدون Syntax Check
قبل از اعمال تغییرات:
sshd -t
۸. نداشتن Console یا VNC
قبل از Hardening مطمئن شوید در صورت Lockout راه برگشت دارید.
چک‌لیست نهایی امن‌سازی SSH
اگر می‌خواهید سریع وضعیت سرور خود را بررسی کنید، این چک‌لیست می‌تواند مفید باشد:
دسترسی
- Console یا VNC در دسترس است.
- کاربر مدیریتی غیر Root ایجاد شده است.
- کاربر مدیریتی sudo دارد.
- SSH Key ساخته شده است.
- Private Key در محل امن نگهداری می‌شود.
- Private Key دارای Passphrase است.
SSH
- ورود مستقیم Root غیرفعال شده است.
- SSH Key Authentication فعال است.
- Password Authentication در صورت امکان غیرفعال شده است.
-
sshd -tبدون خطا اجرا می‌شود. - پورت SSH مشخص و مستند شده است.
- کاربران مجاز SSH مشخص هستند.
سیستم
- سیستم‌عامل به‌روز است.
- OpenSSH به‌روز است.
- کاربران ناشناس بررسی شده‌اند.
- کاربران دارای UID 0 بررسی شده‌اند.
- گروه sudo/wheel بررسی شده است.
- کلیدهای
authorized_keysبررسی شده‌اند. - Cron Jobها بررسی شده‌اند.
- سرویس‌های ناشناس بررسی شده‌اند.
- Portهای Listening بررسی شده‌اند.
مانیتورینگ
- لاگ SSH بررسی می‌شود.
- Loginهای موفق بررسی شده‌اند.
- Loginهای ناموفق بررسی شده‌اند.
- Fail2Ban نصب شده است.
- Jail مربوط به SSH فعال است.
- Firewall تنظیم شده است.
تنظیمات پیشنهادی نهایی برای یک VPS معمولی
برای بسیاری از VPSهای شخصی یا سرورهای مدیریتی، یک وضعیت منطقی می‌تواند به شکل زیر باشد:
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
و در کنار آن:
Fail2Ban
+
Firewall
+
SSH Key
+
Non-root administrative user
+
sudo
+
System updates
+
Log monitoring
البته قبل از اعمال این تنظیمات باید مطمئن شوید که نرم‌افزارها و فرآیندهای مدیریتی شما به Login با Password یا Root مستقیم وابسته نیستند.
یک سناریوی کامل از صفر تا سرور امن
فرض کنیم یک VPS تازه با Ubuntu یا Debian دارید.
در ابتدا:
root
+
password
+
SSH port 22
فعال است.
مراحل پیشنهادی:
مرحله ۱
وارد SSH شوید.
مرحله ۲
سیستم را به‌روز کنید:
apt update
apt upgrade
مرحله ۳
کاربر جدید ایجاد کنید:
adduser admin
مرحله ۴
sudo بدهید:
usermod -aG sudo admin
مرحله ۵
SSH Key بسازید.
مرحله ۶
Public Key را در:
/home/admin/.ssh/authorized_keys
قرار دهید.
مرحله ۷
Permissionها را اصلاح کنید:
chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys
chown -R admin:admin /home/admin/.ssh
مرحله ۸
از یک پنجره جدید ورود را تست کنید:
ssh admin@SERVER-IP
مرحله ۹
تنظیمات SSH را تغییر دهید:
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
مرحله ۱۰
Syntax را بررسی کنید:
sshd -t
مرحله ۱۱
SSH را Reload کنید.
مرحله ۱۲
در یک پنجره جدید دوباره Login کنید.
مرحله ۱۳
Fail2Ban نصب کنید.
مرحله ۱۴
Firewall را تنظیم کنید.
مرحله ۱۵
کاربران، کلیدها و لاگ‌ها را بررسی کنید.
در پایان دیگر معماری ورود شما به شکل:
root + password
نیست.
بلکه:
admin + SSH Key
|
v
sudo
|
v
root
خواهد بود.
یک نکته مهم برای سرورهای فروش هاست و VPS
اگر سرور شما فقط یک VPS شخصی نیست و روی آن سرویس‌هایی مانند:
- وب‌سایت
- WHMCS
- cPanel
- DirectAdmin
- Docker
- دیتابیس
- Mail Server
- DNS
- پنل مدیریت
- سرویس‌های API
- نرم‌افزارهای مانیتورینگ
اجرا می‌شوند، Hardening SSH فقط یکی از بخش‌های امنیت سرور است.
ممکن است SSH کاملاً امن باشد اما یک نرم‌افزار وب آسیب‌پذیر باشد.
بنابراین امنیت سرور باید به صورت چندلایه انجام شود.
جمع‌بندی
امن کردن SSH یک کار تک‌مرحله‌ای نیست.
اینکه فقط پورت SSH را تغییر دهید یا رمز Root را قوی‌تر کنید، به تنهایی به معنی امن شدن سرور نیست.
برای یک VPS لینوکسی بهتر است امنیت SSH را به صورت مرحله‌ای پیاده کنید:
بررسی وضعیت فعلی
↓
ساخت کاربر مدیریتی
↓
ساخت SSH Key
↓
تست ورود با Key
↓
محدود کردن Root Login
↓
غیرفعال کردن Password Authentication
↓
بررسی Syntax
↓
Reload SSH
↓
Firewall
↓
Fail2Ban
↓
بررسی کاربران
↓
بررسی authorized_keys
↓
بررسی Login Logs
↓
بررسی Process و Portها
↓
به‌روزرسانی و مانیتورینگ
مهم‌ترین نکته این است که هیچ‌وقت قبل از آزمایش روش ورود جدید، روش قبلی را غیرفعال نکنید.
اگر SSH Key را به درستی راه‌اندازی کنید، ورود مستقیم Root را ببندید، Password Authentication را در شرایط مناسب غیرفعال کنید، Firewall را درست تنظیم کنید، Fail2Ban را فعال کنید و به شکل دوره‌ای Loginها و کاربران سیستم را بررسی کنید، سطح امنیت SSH سرور شما نسبت به یک نصب ساده و بدون Hardening به شکل قابل توجهی بهتر خواهد شد.
و در نهایت، اگر بعد از تغییر رمز یا مشاهده Loginهای مشکوک احتمال می‌دهید شخص دیگری قبلاً وارد سرور شده است، موضوع را صرفاً با «تغییر رمز» تمام‌شده فرض نکنید؛ باید کلیدهای SSH، کاربران، Cronها، سرویس‌ها، Processها و لاگ‌ها بررسی شوند و در صورت وجود شواهد واقعی از Compromise، اقدامات Incident Response جدی‌تری انجام شود.
دیدگاه‌ها
0 دیدگاه برای این مطلب ثبت شده است.