یک VPS تازهراهاندازیشده ظرف چند دقیقه پس از آنلاین شدن در معرض حملات خودکار قرار میگیرد — این چکلیست شما را در طول اولین ساعت سختسازی که سرور را در اختیار خودتان نگه میدارد، همراهی میکند.
هر سرور جدید زندگی خود را با ضعفهای یکسانی آغاز میکند: ورود پیشفرض با root، دربی برای SSH که فقط با رمز عبور باز میشود، فایروال کاملاً باز و بدون وصلهگذاری خودکار. رباتها بهطور مداوم کل فضای IPv4 را اسکن میکنند، بنابراین این جمله که «هنوز کسی IP من را نمیداند» هرگز درست نیست.
این راهنما یک چکلیست سختسازی مرتب و آماده کپی است. روی یک سرور تازه Debian یا Ubuntu از بالا به پایین پیش بروید تا حفرههایی را ببندید که مهاجمان واقعاً از آنها استفاده میکنند، نه آنهایی که فقط در نمایش امنیتی نگرانکننده به نظر میرسند.
پیش از آنکه به سرور دست بزنید
دو تصمیم که پیش از اولین ورود شما گرفته میشوند، ساعتها زمان را بعداً ذخیره میکنند. کلید SSH خود را آماده کنید و یک نام کاربری غیر از root انتخاب کنید.
- 1
یک کلید SSH مدرن تولید کنید
روی دستگاه خودتان دستور ssh-keygen -t ed25519 -C "you@device" را اجرا کنید. کلیدهای Ed25519 کوتاه، سریع و قویتر از پیشفرض قدیمی RSA-2048 هستند.
- 2
کلید خصوصی را از سرور دور نگه دارید
بخش خصوصی هرگز نباید لپتاپ شما را ترک کند. شما فقط فایل .pub را به سرورها کپی میکنید. نادیده گرفتن این قاعده همان چیزی است که باعث میشود افراد خودشان را مجبور به راهاندازی مجدد سرور کنند.
- 3
اطلاعات ورود اولیه سرور را یادداشت کنید
بیشتر ارائهدهندگان یک رمز عبور موقت root را ایمیل میکنند یا کلید شما را در زمان ساخت سرور تزریق میکنند. اگر کلیدی تزریق شده باشد، میتوانید مستقیماً به مرحله ایجاد کاربر بروید.
اگر ارائهدهنده سرور شما کلید SSH را در زمان استقرار تزریق کند، اصلاً هیچگاه پنجرهای مبتنی بر رمز عبور نخواهید داشت — بزرگترین سطح حمله حتی پیش از بوت شدن سرور از بین میرود.
گام ۱ — همهچیز را وصله کنید، سپس آن را وصلهشده نگه دارید
یک کرنل یا OpenSSL وصلهنشده تنها نقصی است که هیچ قانون فایروالی نمیتواند آن را برطرف کند. پیش از پیکربندی هر چیز دیگری، سیستم را بهروزرسانی کنید.
- Debian/Ubuntu: دستور apt update && apt full-upgrade -y را اجرا کنید و اگر کرنل تغییر کرد، سرور را ریستارت کنید.
- unattended-upgrades را فعال کنید تا وصلههای امنیتی بهطور خودکار اعمال شوند: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- ریستارت را طبق برنامهای که خودتان کنترل میکنید انجام دهید — مقدار Unattended-Upgrade::Automatic-Reboot را روی یک ساعت کمترافیک تنظیم کنید، بهجای اینکه کرنلها نیمهاعمالشده باقی بمانند.
گام ۲ — یک کاربر واقعی بسازید و استفاده از root را کنار بگذارید
ورود با root به این معناست که یک نشست هکشده بهتنهایی کنترل کل ماشین را در دست میگیرد و هیچ ردی از حسابرسی باقی نمیگذارد. در عوض یک حساب sudo با نام مشخص برای خودتان بسازید.
- 1
کاربر را اضافه کنید
ابتدا adduser deploy سپس usermod -aG sudo deploy را اجرا کنید (در سیستمهای خانواده RHEL از گروه wheel استفاده کنید).
- 2
کلید خود را برای آن کاربر نصب کنید
از لپتاپ خودتان: ssh-copy-id deploy@your-server-ip را اجرا کنید. این دستور کلید عمومی شما را با مجوزهای صحیح در ~/.ssh/authorized_keys مینویسد.
- 3
پیش از بستن در، آن را تست کنید
یک ترمینال دوم باز کنید و مطمئن شوید که میتوانید با ssh deploy@server وارد شوید و دستور sudo -v را اجرا کنید. تا زمانی که یک نشست تازه کار نکند، هرگز root یا رمزهای عبور را غیرفعال نکنید.
قانون طلایی سختسازی SSH: نشست فعلی خود را باز نگه دارید و پیش از تغییر هر تنظیم احراز هویتی، در یک پنجره دوم ثابت کنید که ورود جدید کار میکند. همین یک عادت جلوی تقریباً هر قفلشدنی را میگیرد.
گام ۳ — سختسازی SSH، مهمترین بخش کار
SSH درِ ورودی هر VPS است و اکثر تلاشهای خودکار برای ورود دقیقاً روی همینجا متمرکز میشوند. فایل /etc/ssh/sshd_config (یا یک فایل drop-in در /etc/ssh/sshd_config.d/) را ویرایش کنید و این مقادیر را تنظیم کنید.
با sshd -t صحت نحو را بررسی کنید، سپس systemctl restart ssh را اجرا کنید. اگر sshd -t خطایی گزارش داد، پیش از ریستارت آن را برطرف کنید، وگرنه ممکن است دیمن از کار بیفتد.
تغییر پورت SSH از 22 اختیاری است و فقط نویز لاگ را کم میکند — این ابهامسازی است، نه امنیت واقعی. زمانی که PasswordAuthentication خاموش باشد، رباتهای اسکنکننده پورت چیزی برای حدس زدن ندارند، پس تلاش خود را روی کلیدها متمرکز کنید نه بازی با پورتها.
گام ۴ — یک فایروال با سیاست پیشفرض رد فعال کنید
حتی یک دیمن SSH سختسازیشده هم همچنان ماشین را با هر سرویس دیگری که در حال شنود است به اشتراک میگذارد. فایروال باعث میشود «بسته مگر اینکه خودم بازش کرده باشم» به حالت پیشفرض تبدیل شود.
- 1
خط پایه را تنظیم کنید
با ufw: دستورهای ufw default deny incoming و ufw default allow outgoing را اجرا کنید.
- 2
فقط چیزی را مجاز کنید که ارائه میدهید
ufw allow OpenSSH را اجرا کنید، و ufw allow 80,443/tcp را فقط در صورتی اضافه کنید که این سرور واقعاً ترافیک وب را میزبانی میکند.
- 3
فعال کنید و تأیید کنید
ابتدا ufw enable سپس ufw status verbose را اجرا کنید. هر چیزی که در لیست نباشد اکنون از اینترنت غیرقابلدسترسی است.
پیش از فعال کردن ufw، قانون SSH را در فایروال وارد کنید. فعال کردن فایروال با سیاست پیشفرض رد بدون داشتن یک قانون مجاز برای پورت خودتان، نشست شما را قطع خواهد کرد.
گام ۵ — با Fail2ban حملات brute force را کند کنید
حتی با غیرفعال بودن رمزهای عبور، رباتها همچنان به در میزنند و لاگهای شما را متورم میکنند. Fail2ban متخلفان مکرر را در سطح فایروال مسدود میکند.
- apt install fail2ban را اجرا کنید — jail پیشفرض sshd بدون هیچ تنظیم اضافهای کار میکند.
- jail.conf را در jail.local کپی کنید و مقدار bantime (مثلاً 1h) را افزایش و maxretry (مثلاً 3) را طبق سلیقه خود کاهش دهید.
- با دستور fail2ban-client status sshd عملکرد آن را بررسی کنید تا تعداد IPهای مسدودشده را ببینید.
گام ۶ — سطح حمله را کاهش دهید
امنترین سرویس، سرویسی است که اصلاً در حال اجرا نیست. آنچه را که در حال شنود است بررسی کنید و هرچه نیاز ندارید حذف کنید.
پورتهای باز را بررسی کنید
دستور ss -tulpn تمام سوکتهای در حال شنود و پردازش پشت آنها را فهرست میکند. هر چیزی را که خودتان عمداً راهاندازی نکردهاید بررسی کنید.
بستههای غیرضروری را حذف کنید
سرویسهایی را که استفاده نمیکنید غیرفعال یا حذف کنید — یک پایگاه داده یا عامل ایمیل که بدون استفاده در حال اجراست، صرفاً یک ریسک است.
سرویسها را ایزوله کنید
دیمنهای داخلی مانند پایگاههای داده را به 127.0.0.1 محدود کنید تا حتی اگر فایروال دچار مشکل شود، هرگز در معرض دید قرار نگیرند.
مجوزها را قفل کنید
مطمئن شوید که مجوز ~/.ssh برابر 700 و authorized_keys برابر 600 است. مجوزهای نادرست باعث میشود sshd بهطور خاموش کلید شما را نادیده بگیرد.
گام ۷ — ثبت وقایع، پایش و شناخت خط پایه خود
سختسازی یک رویداد یکباره نیست. باید متوجه شوید که چه زمانی چیزی تغییر میکند.
- فعالیتهای احراز هویت را با journalctl -u ssh یا lastb برای ورودهای ناموفق بررسی کنید.
- برای داشتن یک رکورد ضدتغییر از اقدامات ممتاز، استفاده از auditd را در نظر بگیرید.
- یک نسخه پشتیبان خارج از سرور از /etc و دادههای خود نگه دارید تا در صورت هک شدن سرور، بتوانید آن را از صفر و بهصورت تمیز بازسازی کنید، بهجای اینکه بعد از حادثه به آن اعتماد کنید.
جایی که خود ارائهدهنده میزبانی اهمیت دارد
سختسازی نرمافزاری از سیستمعامل محافظت میکند، اما این ارائهدهنده است که تعیین میکند زیر آن چه چیزی قرار دارد — فیلترینگ شبکه، رد پرداخت، و اینکه آیا هویتی به سرور گره میخورد یا نه. در ChainVPS هر پلن با فیلترینگ DDoS و پهنای باند نامحدود عرضه میشود، و پرداخت سرورها از موجودی پیشپرداختشده کریپتویی در 21 ارز از جمله Monero و بدون KYC انجام میشود. اگر مدل تهدید شما شامل عدم پیوند دادن سرور به هویتتان است، پلنهای VPS آفشور ما دقیقاً برای همین ساخته شدهاند.
موقعیت جغرافیایی هم بخشی از سختسازی است: شش مورد از پانزده منطقه ما در حوزههای قضایی سطح حریم خصوصی قرار دارند (NL, CH, RO, IS, MD, LU). ترکیب یک سیستمعامل سختسازیشده با یک سرور اختصاصی آفشور، هم سطح نرمافزاری و هم سطح حقوقی را محکم نگه میدارد.
چکلیست یکساعته، بهطور خلاصه
- بهروزرسانی کامل سیستم + فعالسازی وصلههای امنیتی خودکار
- کاربر sudo با نام مشخص ساخته شد، کلید نصب شد، ورود تست شد
- ورود root از طریق SSH و احراز هویت با رمز عبور، هر دو غیرفعال شدند
- پیکربندی SSH با sshd -t تأیید شد و مجدداً بارگذاری شد
- فایروال با سیاست پیشفرض رد فعال است، فقط پورتهای موردنیاز باز هستند
- Fail2ban روی jail مربوط به sshd در حال اجراست
- پورتهای باز بررسی شدند، سرویسهای استفادهنشده حذف شدند
- پشتیبانگیری خارج از سرور و بررسی لاگها برقرار است
آیا باید پورت SSH را به چیزی غیر از 22 تغییر دهم؟
این کار اختیاری است و فقط نویز لاگ را کاهش میدهد، نه ریسک واقعی را. زمانی که احراز هویت با رمز عبور غیرفعال باشد و کلید الزامی باشد، تغییر پورت بیشتر ابهامسازی است تا امنیت — در اولویت اول، غیرفعال کردن رمزهای عبور را قرار دهید.
اگر فقط یک کلید داشته باشم، آیا غیرفعال کردن احراز هویت با رمز عبور امن است؟
بله، به شرطی که ورود با کلید را در یک نشست جداگانه تست کرده باشید و یک نسخه پشتیبان از کلید خصوصی نگه دارید. بسیاری از ارائهدهندگان همچنین یک کنسول وب یا حالت بازیابی ارائه میدهند، بنابراین هرگز واقعاً از سختافزار قفل نمیشوید.
اگر SSH تنها سرویس است، آیا باز هم به فایروال نیاز دارم؟
بله. یک فایروال با سیاست پیشفرض رد شما را از سرویسهایی که فراموش کردهاید نصب کردهاید و از هر چیزی که یک بسته آینده بهآرامی شروع به شنود روی آن میکند، محافظت میکند. هیچ هزینهای ندارد و جلوی غافلگیریها را میگیرد.
هر چند وقت یکبار باید سختسازی را دوباره بررسی کنم؟
بهروزرسانیهای امنیتی خودکار کار روزانه را انجام میدهند، اما پس از هر نصب نرمافزاری مهم و حداقل ماهی یکبار، پورتهای در حال شنود و لاگهای احراز هویت را بررسی کنید. یک خط پایه سختسازیشده را چیزی بدانید که باید بررسیاش کنید، نه چیزی که یکبار تنظیم میکنید و فراموشش میکنید.
