سخت‌سازی یک VPS جدید: اولین ساعت پس از استقرار

اولین ساعت اختیاری نیست

فضای IPv4 اینترنت آن‌قدر کوچک است که اسکن‌کردن کل آن برای یک غریبهٔ خوش‌بودجه چند دقیقه، و برای یک لپ‌تاپ چند ساعت طول می‌کشد. بازه‌های هاستینگ منتشر، کاتالوگ و پیوسته دوباره اسکن می‌شوند، پس یک آدرس تازه گمنام نیست — یک سطر تازه در فهرستی است که از قبل وجود دارد. در عمل، اولین تلاش خودکار برای ورود SSH روی یک باکس تازه‌بوت‌شده مدت‌ها پیش از آنکه خواندن ایمیل خوش‌آمدگویی‌تان تمام شود از راه می‌رسد، و هزاران تلاش دیگر از منابع نامرتبط در پی آن خواهند آمد، همه در حال امتحان‌کردن همان چند صد رمز عبور روی همان چند نام‌کاربری. هیچ‌کدام از این‌ها معطوف به شما نیست. این یک ماشین است که اینترنت را به پاسخ می‌دهد و پاسخ نمی‌دهد دسته‌بندی می‌کند، و تنها چیزی که تعیین می‌کند در کدام دسته بیفتید، همان کاری است که در اولین ساعت انجام داده‌اید.

خبر خوب این است که این کار خسته‌کننده و متناهی است. چهار کنترل تقریباً همهٔ کار را انجام می‌دهند: احراز هویت با کلید به‌جای رمز عبور، رد کردن هر پورت ورودی‌ای که عمداً سرویس‌دهی نمی‌کنید، اعمال به‌روزرسانی‌های امنیتی بدون نیاز به درخواست و کنار گذاشتن کار با حساب root. هرکدام چند دقیقه طول می‌کشد و هیچ‌کدام عجیب‌وغریب نیست. آنچه نوشتن این‌ها را مشخصاً برای یک سرور آفشور و بدون KYC ارزشمند می‌کند، عدم‌تقارنی است که در سمت دیگر ماجرا وجود دارد — مسیر بازیابی. روی یک میزبان جریان اصلی (mainstream)، یک sshd_config خراب با یک تیکت پشتیبانی، بررسی مدرک هویتی و یک نشست کنسول پایان می‌یابد. اینجا هیچ هویتی در پرونده نیست که بررسی شود، که خودِ همین هدف اصلی این محصول است و هم‌زمان دلیلی است که یک ضربه‌کلید بی‌احتیاطانه به‌جای ۲۰ دقیقه، خود دستگاه را از شما می‌گیرد. هر مرحله در ادامه با این نکته در ذهن نوشته شده است.

چه چیزی واقعاً به یک سرور کوچک حمله می‌کند

دو جمعیت بسیار متفاوت در لاگ‌ها ظاهر می‌شوند و ارزش دارد آن‌ها را از هم جدا کرد، چون هرکدام با چیز متفاوتی شکست می‌خورند. اکثریت قریب‌به‌اتفاق، اسکن انبوه و بی‌تمایز است: بات‌هایی که در سراسر فضای آدرس‌ها می‌گردند و به‌دنبال SSH‌هایی هستند که رمز عبور می‌پذیرند، پایگاه‌داده‌هایی که به 0.0.0.0 بایند شده‌اند، پنل‌های مدیریتی با اطلاعات ورود پیش‌فرض، کپی‌های staging فراموش‌شده و اپلیکیشن‌های وب وصله‌نشده با یک اکسپلویت عمومی. این جمعیت اهمیتی نمی‌دهد سرور شما برای چیست. نمی‌شود با آن استدلال کرد، هرگز متوقف نمی‌شود، و چک‌لیست این راهنما به‌طور کامل آن را شکست می‌دهد — نه چون این چک‌لیست باهوشانه است، بلکه چون این بات‌ها به‌دنبال ماشین‌هایی می‌گردند که آن را نادیده گرفته‌اند و از این ماشین‌ها فراوان وجود دارد.

جمعیت دوم هدفمند است — کسی که دقیقاً همان باکس شما را می‌خواهد — و این نادر، پرهزینه است و تقریباً هیچ‌وقت از راه SSH وارد نمی‌شود. این جمعیت از راه اپلیکیشنی که مستقر کرده‌اید، وابستگی‌ای که ممیزی نکرده‌اید، اطلاعات ورودی که دوباره استفاده کرده‌اید یا لپ‌تاپی که پیش از آنکه به سرور دست بزند از قبل آلوده شده بود، وارد می‌شود. به همین دلیل است که سخت‌سازی در فایروال تمام نمی‌شود: سؤال‌های واقعی این می‌شوند که سرویس شما با چه کاربری اجرا می‌شود، به کجا می‌تواند به‌صورت خروجی دسترسی داشته باشد و با چه سرعتی وصله می‌زنید. نکته‌ای که ارزش دانستن دارد پیش از برنامه‌ریزی: پلن‌های VPS ما مجازی‌سازی کامل KVM هستند، پس کرنل خودتان را اجرا می‌کنید و کل جعبه‌ابزار — nftables، ufw، namespaces، seccomp، sysctl سفارشی — واقعاً کار می‌کند، که در محصولات "VPS" مبتنی‌بر کانتینر، جایی که کرنل متعلق به کس دیگری‌ست، این‌طور نیست.

SSH: کلیدها و دقیقاً یک در

احراز هویت با رمز عبور روی یک پورت عمومی SSH، بزرگ‌ترین ریسکی است که خودتان به یک سرور اجاره‌ای تحمیل می‌کنید، و حذف آن پرارزش‌ترین پنج دقیقهٔ این راهنماست. یک جفت‌کلید Ed25519 روی دستگاه خودتان بسازید — هرگز روی سرور، جایی که نیمهٔ خصوصی دقیقاً روی همان میزبانی به دنیا می‌آید که می‌خواهید از آن محافظت کنید — آن را با یک عبارت عبور محافظت کنید، و در یک agent بارگذاری‌اش کنید تا عبارت عبور، به‌جای هر بار ورود، فقط یک‌بار در هر نشست از شما گرفته شود. نیمهٔ عمومی را بالا کپی کنید، مطمئن شوید کار می‌کند، و تنها پس از آن رمزهای عبور را خاموش کنید. با برقراری PasswordAuthentication no و KbdInteractiveAuthentication no، هزاران حدس روزانه از ریسک‌بودن دست می‌کشند و به صرفاً نویز تبدیل می‌شوند: هیچ رمز عبوری برای حدس‌زدن وجود ندارد، پس تلاش پیش از آنکه حتی جالب شود، شکست می‌خورد.

root تصمیم جداگانهٔ خودش را می‌طلبد. PermitRootLogin prohibit-password دسترسی root مبتنی‌بر کلید را برای موارد اضطراری نگه می‌دارد؛ PermitRootLogin no سخت‌گیرانه‌تر است و هر نشست را از میان یک حساب نام‌دار با sudo عبور می‌دهد، که همان چیزی است که از لحظه‌ای که بیش از یک نفر به باکس دست می‌زند، می‌خواهید. AllowUsers را اضافه کنید تا یک حساب سرگردان که توسط یک بسته ساخته شده، هرگز نتواند مسیر ورود باشد. جابه‌جا کردن دیمن از پورت 22 ارزش انجام‌دادن دارد، اما دربارهٔ دلیلش صادق باشید: این یک کنترل امنیتی نیست — هرکس که آدرس شما را اسکن کند، پورت جدید را در چند ثانیه پیدا می‌کند — این بهداشت لاگ (log hygiene) است، و اکثریت بزرگ نویز خودکار را حذف می‌کند تا سطرهای باقی‌مانده در auth.log چیزهایی باشند که واقعاً باید بخوانید. هرچه را تغییر می‌دهید، پیش از reload با sshd -t اعتبارسنجی کنید و نشست فعلی‌تان را باز نگه دارید تا زمانی که یک ترمینال دوم با موفقیت متصل شده باشد. این عادت، تفاوت میان یک غلط تایپی و از دست‌دادن سرور است.

Default-deny و نیمی از فایروال که هیچ‌کس پیکربندی نمی‌کند

فایروال روی یک سرور فقط یک وظیفه دارد: پاسخ به این سؤال که "اینجا چه چیزی listen می‌کند؟" را دقیقاً برابر با فهرست چیزهایی کند که عمداً منتشر کرده‌اید. ورودی را به‌صورت default-deny تنظیم کنید، خروجی را مجاز کنید، سپس پورت‌ها را یکی‌یکی و هرکدام با یک دلیل مشخص باز کنید. پیش از نوشتن حتی یک قانون، ss -tulpen را اجرا کنید و بخوانید چه چیزی از قبل bind شده — یک نصب پیش‌فرض روی چیزهای بیشتری از آنچه اغلب مردم انتظار دارند listen می‌کند، و یک پایگاه‌داده یا کش که به‌جای 127.0.0.1 به 0.0.0.0 بایند شده، همان روش کلاسیکی است که یک سرور کوچک سر از دیتاست یک نفر درمی‌آورد. اول سرویس‌های محلی را به loopback بایند کنید؛ فایروال خط دفاعی دوم شماست، نه تنها خط دفاعی‌تان.

بعد نیمی وجود دارد که معمولاً نادیده گرفته می‌شود. هر پلن اینجا یک /64 از IPv6 در کنار IPv4 خودش ارائه می‌دهد، و بیشتر دیمن‌های امروزی با خوشحالی به هر دو خانواده بایند می‌شوند. اگر قوانین شما فقط v4 را پوشش دهند، سرویسی که فکر می‌کنید پشت فایروال است، از راه v6 برای هرکسی که آدرس را resolve کند در دسترس است — و اسکن IPv6 روی یک پیشوند هاستینگ شناخته‌شده کاملاً روتین است. ufw واقعاً هر دو را مدیریت می‌کند، اما فقط وقتی IPV6=yes در /etc/default/ufw تنظیم شده باشد؛ این را با ufw status verbose تأیید کنید، نه با فرض‌کردن. Docker هم همین شک را می‌طلبد: منتشر کردن یک پورت کانتینر با -p، قوانینی را در زنجیرهٔ iptables خودش وارد می‌کند که پیش از قوانین ufw ارزیابی می‌شوند، پس کانتینری که فکر می‌کردید محافظت‌شده است، اغلب کاملاً باز است. آن را صریحاً به 127.0.0.1:port بایند کنید و یک reverse proxy جلویش بگذارید. هرچه را پیکربندی می‌کنید، از جایی دیگر روی اینترنت تستش کنید — قانونی که فقط خوانده شده، قانونی است که هرگز تست نشده است.

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

نرم‌افزار وصله‌نشده همان چیزی است که بیشتر سرورهای کوچک را واقعاً از دست می‌دهد، و دلیلش انسانی است نه فنی: patch زدن کاری خسته‌کننده است که با هرچیز دیگری که باید انجام دهید رقابت می‌کند. کانال امنیتی را خودکار کنید و مشکل ناپدید می‌شود. unattended-upgrades روی Debian و Ubuntu، به‌روزرسانی‌های امنیتی را طبق یک زمان‌بند اعمال می‌کند و سر راه نمی‌ماند؛ آن را به بستهٔ امنیتی محدود کنید نه هر ارتقای در دسترس، تا یک انتشار معمولیِ ویژگی جدید هرگز اپلیکیشن شما را ساعت سه بامداد ری‌استارت نکند. این نکته روی یک باکس آفشورِ خودمدیریت‌شده، بیشتر از یک پلتفرم مدیریت‌شده اهمیت دارد، چون هیچ‌کس آن را برایتان patch نمی‌زند و هیچ مدیر حسابی برایتان دربارهٔ یک CVE بحرانی ایمیل نمی‌زند — چون هیچ آدرس ایمیلی در پرونده نیست که به آن دسترسی داشته باشد.

به‌روزرسانی‌های کرنل برای اعمال‌شدن به یک ری‌استارت نیاز دارند، پس سیاست ری‌استارت‌تان را عمداً تعیین کنید، نه اینکه بعداً کشفش کنید. needrestart به شما می‌گوید کدام سرویس‌ها هنوز روی کتابخانه‌های حذف‌شده در حال اجرا هستند، و یک بازهٔ Unattended-Upgrade::Automatic-Reboot در ساعات اولیهٔ بامداد برای یک سرویس بدون‌حالت (stateless) مناسب است. یک تعامل مهم: اگر راهنمای رمزنگاری کامل دیسک ما را دنبال کرده‌اید و فایل‌سیستم root شما رمزنگاری‌شده است، یک ری‌استارت خودکار روی درخواست عبارت عبور متوقف می‌شود و همان‌جا می‌ماند تا آن را از راه شبکه باز کنید. یا روی این ماشین‌ها ری‌استارت خودکار را خاموش نگه دارید، یا مطمئن شوید باز کردن قفل از راه دور تست شده و شما بیدار خواهید بود. هرکدام را انتخاب می‌کنید، آن را یادداشت کنید — سیاستی که فقط در ذهن شما زندگی می‌کند، همان لحظه‌ای که به مرخصی می‌روید از وجود بازمی‌ایستد.

محدودسازی نرخ، fail2ban و کف نویز

وقتی احراز هویت با رمز عبور خاموش باشد، حملهٔ brute force علیه SSH نمی‌تواند موفق شود. ارزش دارد روشن گفته شود ابزارهایی مثل fail2ban بعد از آن نقطه دقیقاً چه چیزی به شما می‌دهند: نه دفاعی در برابر حدس‌زدن — که از قبل ناممکن است — بلکه یک لاگ آرام‌تر، CPU کمتر صرف‌شده روی handshakeهای محکوم‌به‌شکست، و یک کنترل واقعی روی لایه‌هایی که در آن‌ها رازها هنوز هم قابل‌حدس‌اند. آن را به‌سمت جاهایی نشانه بگیرید که اهمیت دارند: فرم ورود یک اپلیکیشن وب، SMTP AUTH یک میل‌سرور، یک مسیر مدیریتی که کسی دارد شماره‌گذاری‌اش (enumerate) می‌کند. ufw limit بدون هیچ نرم‌افزار اضافه‌ای، یک سقف ارزان برای نرخ اتصال به شما می‌دهد. چند تنظیم کرنل هم به‌اندازهٔ همان پنج دقیقه ارزش دارند — SYN cookies روشن، فیلتر reverse-path روشن، پاسخ‌دهی به broadcastهای ICMP خاموش و نادیده‌گرفتن اعلان‌های مسیریاب (router advertisements) IPv6 روی سروری که آدرس ثابت دارد.

اما بدانید کجا کار میزبان (host) تمام می‌شود. هیچ‌کدام از این‌ها در برابر یک حملهٔ حجمی (volumetric) دوام نمی‌آورد، چون یک سیل (flood) لولهٔ شبکه را مدت‌ها پیش از آنکه مزاحم CPU شود پر می‌کند: تا زمانی که بسته‌ها به قوانین nftables شما برسند، از قبل همان پهنای‌باندی را مصرف کرده‌اند که می‌خواستید از آن محافظت کنید. به همین دلیل است که پاک‌سازی (scrubbing) لایهٔ L3/L4 تا سقف 1.5 Tbps بالادستِ کل ناوگان قرار دارد و روی هر پلن گنجانده شده، نه اینکه به‌عنوان یک افزودهٔ جداگانه فروخته شود، همراه با یک سپر اختیاری L7 برای سیل‌های لایهٔ اپلیکیشن که شبیه درخواست‌های مشروع به‌نظر می‌رسند. فایروال میزبان شما دقت را مدیریت می‌کند؛ شبکه حجم را مدیریت می‌کند. رفتار با هرکدام به‌عنوان جایگزین دیگری، همان چیزی است که باعث می‌شود آدم‌ها غافلگیر شوند.

قفل‌شدن خودتان بیرون از سرور، ریسک واقعی اینجاست

از میان هرچیزی که ممکن است در این اولین ساعت اشتباه پیش برود، محتمل‌ترین پیامد به‌طرز قاطعی یک نفوذ نیست. این خودتان هستید، در انتهای یک نشست طولانی، که یک sshd_config خراب را reload می‌کنید یا فایروالی را فعال می‌کنید که قانون allow آن یک غلط تایپی دارد، و کشف می‌کنید که در پشت سرتان بسته شده است. روی یک ارائه‌دهندهٔ جریان اصلی، این یک دردسر است. اینجا سزاوار احترام واقعی است، چون ثبت‌نام یعنی یک هندل و یک رمز عبور همراه با هشت کد بازیابی و بدون هیچ ایمیلی در هیچ جای این چرخه، دقیقاً به این دلیل که هیچ هویتی برای لو رفتن وجود نداشته باشد — و ارائه‌دهنده‌ای که نمی‌تواند هویت شما را تأیید کند، نمی‌تواند شما را به سرورتان هم بازگرداند. هیچ‌کس نمی‌تواند برایتان ضمانت کند. این ویژگی همان محصولی است که طبق طراحی کار می‌کند، و به همین دلیل تدابیر ایمنی زیر عادت‌اند، نه پیشنهاد.

چهار مورد از آن‌ها هیچ هزینه‌ای ندارند. پیش از دست‌زدن به SSH یا فایروال، یک اسنپ‌شات بگیرید تا یک reload خراب یک rollback باشد نه یک بازسازی از صفر. یک کلید عمومی دوم از یک دستگاه متفاوت ثبت کنید — یک گوشی، یک لپ‌تاپ کاری، یک بک‌آپ آفلاین — چون یک کلید روی یک دیسک، فقط یک فنجان قهوهٔ ریخته‌شده تا هیچ‌کلید‌نداشتن فاصله دارد. وقتی چیزی را تغییر می‌دهید که می‌تواند نشست اول را قطع کند، یک ترمینال دوم را متصل نگه دارید، و همیشه پیکربندی جدید را از یک اتصال تازه تست کنید پیش از آنکه قدیمی را رها کنید. و بپذیرید نردبان بازیابی کجا تمام می‌شود: اسنپ‌شات‌ها روی همان میزبان زندگی می‌کنند و یک راحتیِ rollback‌اند، نه یک بک‌آپ، پس هرچیزی که واقعاً دلتنگش می‌شوید باید در ذخیره‌سازی خارج از میزبان (off-host) باشد — افزونهٔ بک‌آپ‌های رمزنگاری‌شدهٔ روزانه، یا کپی‌های رمزنگاری‌شده در سمت کلاینت خودتان که به‌جای دیگری فرستاده‌اید. بدترین حالت شما باید استقرار دوباره و بازیابی باشد، که با دقیقه اندازه‌گیری می‌شود، نه از دست‌رفته.

بعدش چه چیزی اضافه کنید، بسته به اینکه باکس چه‌کار می‌کند

چک‌لیست بالا، کف کار است و برای هر ماشینی یکسان است. اینکه چه چیزی روی آن اضافه می‌شود، کاملاً به وظیفهٔ باکس بستگی دارد. یک وب‌سرور عمومی به TLS نیاز دارد، یک reverse proxy که آن را terminate کند، اپلیکیشنی که با یک کاربر بدون‌امتیاز اجرا می‌شود و پایگاه‌داده‌ای روی loopback یا کاملاً روی باکسی دیگر. یک نقطهٔ پایانی VPN شکل متفاوتی دارد — یک پورت UDP، بدون استک وب، اصلاً بدون سرویس عمومی — و از ابتدا تا انتها در راه‌اندازی VPN WireGuard خودتان کار شده است. میل‌سرور سخت‌گیرترین این سه است و به کنترل rDNS روی آدرس نیاز دارد، که هر پلن آن را شامل می‌شود؛ میزبانی خوداستقرار میل روی یک VPS آفشور نیمهٔ deliverability را پوشش می‌دهد. یک رلهٔ Tor عمداً برعکسِ ناشناس‌ماندن است — یک سرویس منتشرشده و قابل‌تماس است — و مصالحه‌های آن در اجرای یک رله روی یک VPS بدون KYC شرح داده شده‌اند. هرچیزی که وضعیت خصوصی را در حالت سکون (at rest) نگه می‌دارد هم باید رمزنگاری شود، که یک کنترل جداگانه با حالت‌های شکست خودش است و در LUKS و باز کردن قفل از راه دور پوشش داده شده.

ارزش دارد با این نکته تمام کنیم که سخت‌سازی کجای تصویر بزرگ‌تر جا می‌گیرد، چون فقط یکی از سه لایه است و این لایه‌ها مستقل از هم شکست می‌خورند. اینکه میزبان دربارهٔ شما چه می‌داند، لایهٔ اول است، و اینجا این مقدار تقریباً هیچ است: یک هندل که با یک موجودی رمزارزی پیش‌پرداخت از $30.00 تأمین مالی شده، بدون کارت و بدون هیچ مدرکی در زنجیره — موضوع پرداخت ناشناس برای هاستینگ. اینکه قانون از آنِ چه کسی باشد، لایهٔ دوم است، که با این تعیین می‌شود سخت‌افزار در کدام‌یک از 6 منطقهٔ ما قرار دارد نه اینکه شما کجا نشسته‌اید، و منطقه‌به‌منطقه در کدام موقعیت آفشور را انتخاب کنید؟ کار شده است. اینکه خودِ ماشین چه چیزی را اجازه می‌دهد، لایهٔ سوم است، و آن یکی فقط مال شماست — هیچ ارائه‌دهنده‌ای نمی‌تواند آن را برایتان پیکربندی کند. یک VPS از $8.00 در ماه در حدود 15 min آنلاین می‌شود، که یعنی همان ساعتی که پس از آن می‌آید، جایی است که امنیت واقعی این دستگاه در آن تعیین می‌شود. آن را عمداً خرج کنید.

گام‌به‌گام

1. 01

   استقرار کنید، سپس پیش از هر کاری وارد شوید

   از پنل استقرار دهید و توزیعی را انتخاب کنید که واقعاً patch‌زده نگهش می‌دارید — یک Debian به‌روز یا یک Ubuntu LTS همان پاسخ خسته‌کننده و درست است. یک VPS در حدود 15 min آنلاین می‌شود و اطلاعات ورود root آن در پنل شما قرار می‌گیرد. بلافاصله متصل شوید، سیستم را کاملاً به‌روز کنید، و یک hostname تنظیم کنید تا لاگ‌های بعدی خوانا باشند. تا وقتی بقیهٔ این مراحل انجام نشده‌اند، هیچ اتفاق دیگری روی این باکس نمی‌افتد.

   ssh root@203.0.113.10
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y ufw unattended-upgrades needrestart

2. 02

   دور شدن از root: یک کاربر نام‌دار، یک کلید و sudo

   جفت‌کلید را روی لپ‌تاپ خودتان بسازید، هرگز روی سرور. سپس یک حساب نام‌دار روی باکس بسازید، نیمهٔ عمومی را در authorized_keys آن قرار دهید و sudo را به آن بدهید. یک ترمینال دوم باز کنید و همین حالا با آن کاربر وارد شوید — پیش از آنکه چیز دیگری را تغییر دهید، درحالی‌که root از راه SSH هنوز به‌عنوان fallback کار می‌کند.

   # on your own machine
   ssh-keygen -t ed25519 -C "laptop"
   ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10
   
   # on the server
   adduser --disabled-password --gecos "" ops
   usermod -aG sudo ops
   install -d -m 700 -o ops -g ops /home/ops/.ssh
   cp /root/.ssh/authorized_keys /home/ops/.ssh/
   chown ops:ops /home/ops/.ssh/authorized_keys
   chmod 600 /home/ops/.ssh/authorized_keys

3. 03

   دیمن SSH را قفل کنید — با یک ترمینال دوم باز

   تغییرات را در یک فایل drop-in بنویسید، نه با ویرایش پیکربندی پیش‌فرض، تا یک ارتقای توزیع هرگز آن‌ها را بی‌سروصدا برنگرداند. پیش از reload، سینتکس را با sshd -t اعتبارسنجی کنید، reload کنید، سپس آن را از یک اتصال کاملاً تازه اثبات کنید درحالی‌که اتصال فعلی هنوز زنده است. اگر اتصال جدید شکست بخورد، همچنان یک نشست کارآمد دارید که در آن می‌توانید تغییر را برگردانید. یک تلهٔ مربوط به توزیع: روی Ubuntu 24.04 دیمن به‌صورت socket-activated است، پس Port در sshd_config نادیده گرفته می‌شود — به‌جایش پورت را با systemctl edit ssh.socket تنظیم کنید، یا واحد سوکت را غیرفعال کنید.

   cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
   Port 2222
   PermitRootLogin prohibit-password
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   AllowUsers ops
   X11Forwarding no
   MaxAuthTries 3
   LoginGraceTime 20
   EOF
   sshd -t && systemctl reload ssh
   # new terminal, do not close the old one:
   ssh -p 2222 ops@203.0.113.10

4. 04

   فایروال را روی هر دو خانوادهٔ IP، به‌صورت default-deny تنظیم کنید

   تأیید کنید IPv6 در ufw فعال است، سپس همه‌چیز را در ورودی رد کنید و فقط پورت‌هایی را باز کنید که عمداً سرویس‌دهی می‌کنید — از جمله پورت جدید SSH، که باید پیش از فعال‌کردن فایروال مجاز شده باشد. حالا که اینجایید، بررسی کنید واقعاً چه چیزی listen می‌کند و هرچیزی را که باید محلی باشد به loopback منتقل کنید.

   grep IPV6 /etc/default/ufw          # must read IPV6=yes
   ufw default deny incoming
   ufw default allow outgoing
   ufw limit 2222/tcp
   ufw allow 80,443/tcp
   ufw enable
   ufw status verbose
   ss -tulpen                           # anything on 0.0.0.0 or :: ?

5. 05

   به‌روزرسانی‌های امنیتی بدون دخالت (unattended) را روشن کنید

   فقط کانال امنیتی را فعال کنید، تا patchها بدون اینکه یک ارتقای ویژگی، اپلیکیشن شما را بدون اطلاع ری‌استارت کند، اعمال شوند. سیاست ری‌استارت را صریحاً تعیین کنید — و اگر فایل‌سیستم root رمزنگاری‌شده است و به باز کردن قفل دستی نیاز دارد، ری‌استارت‌های خودکار را خاموش نگه دارید.

   dpkg-reconfigure -plow unattended-upgrades
   cat > /etc/apt/apt.conf.d/51-local <<'EOF'
   Unattended-Upgrade::Automatic-Reboot "false";
   Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
   EOF
   unattended-upgrade --dry-run --debug | tail -20

6. 06

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

   fail2ban را برای لایه‌هایی اضافه کنید که در آن‌ها هنوز می‌شود یک راز را حدس زد، و آن چند مقدار sysctl را تنظیم کنید که روی یک سرور عمومی با آدرس ثابت، به‌سادگی درست‌اند. این کار ارزان است، و لاگ‌ها را ارزش خواندن می‌بخشد.

   apt install -y fail2ban
   cat > /etc/sysctl.d/99-harden.conf <<'EOF'
   net.ipv4.tcp_syncookies = 1
   net.ipv4.conf.all.rp_filter = 1
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   net.ipv4.conf.all.accept_redirects = 0
   net.ipv6.conf.all.accept_ra = 0
   kernel.kptr_restrict = 2
   EOF
   sysctl --system

7. 07

   از بیرون تأیید کنید، سپس runbook را بنویسید

   به دیدی که از اینترنت دارید اعتماد کنید، نه دیدی که از داخل باکس دارید. تأیید کنید پورت قدیمی SSH از بین رفته، هیچ‌چیز غیرمنتظره‌ای پاسخ نمی‌دهد و ورود فقط-با-کلید واقعاً اعمال شده است. سپس سه واقعیتی را که در بدترین روزتان لازم خواهید داشت یادداشت کنید: کلید دومتان کجا زندگی می‌کند، کدام اسنپ‌شات را گرفته‌اید، و بک‌آپ خارج از میزبان کجاست.

   # from another machine
   ssh -p 22 ops@203.0.113.10          # must time out or be refused
   ssh -p 2222 -o PreferredAuthentications=password ops@203.0.113.10
   # expected: Permission denied (publickey)
   ssh -p 2222 ops@203.0.113.10 'sudo ufw status verbose; uptime'