پنهان کردن IP سرور مبدأ

«آیا باید CDN را جلویش بگذارم؟» اولین سؤالی است که اکثر مردم پس از خرید یک سرور آفشور می‌پرسند، و پاسخ واحدی ندارد، چون در واقع دو سؤال است که در یک لباس پنهان شده‌اند. جذب یک حمله و ناپیدا ماندن، دو مسئله‌ی متفاوت با راه‌حل‌های متفاوت‌اند، و آرایشی که یکی را حل می‌کند می‌تواند بی‌سروصدا دیگری را خنثی کند.

این سردرگمی در هر دو جهت هزینه‌بر است. برخی یک CDN بزرگ آمریکایی را جلوی محتوایی می‌گذارند که دقیقاً به‌خاطر میزبانی نادیده‌گیرنده‌ی DMCA برایش انتخاب کرده بودند، و دفتر شکایات را دقیقاً به همان نوع واسطه‌ای پس می‌دهند که از آن دوری می‌کردند. برخی دیگر همه‌چیز را نادیده می‌گیرند، هدف یک سیل لایه‌ی کاربرد قرار می‌گیرند که فیلترینگ شبکه هرگز برای دیدنش طراحی نشده، و نتیجه می‌گیرند که محافظت DDoS دروغ بوده. این راهنما این دو مسئله را از هم جدا می‌کند، می‌گوید هر لایه واقعاً چه کاری انجام می‌دهد، و بیشترین بخشش را به آن قسمتی اختصاص می‌دهد که در هر صورت نتیجه را تعیین می‌کند: شش راهی که آدرس مبدأ حتی وقتی همه‌چیز درست پیکربندی شده باز هم لو می‌رود.

دو مسئله که شبیه یکی به‌نظر می‌رسند

هر چیزی که جلوی یک سرور می‌گذارید، یکی از این دو کار را انجام می‌دهد: دور نگه‌داشتن یک حمله از آن، یا پنهان نگه‌داشتن آدرسش. این دو آن‌قدر هم‌پوشانی دارند که با هم اشتباه گرفته شوند، و آن‌قدر متفاوت‌اند که حل‌کردن نادرست‌شان اتلاف پول باشد.

ردیف آخر را دوبار بخوانید، چون همان چیزی است که مردم را غافلگیر می‌کند. بقیه‌ی این صفحه مهندسی است. آن ردیف نیست.

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

فیلترینگ لایه‌ی 3 و لایه‌ی 4 در همه‌ی پلن‌هایی که می‌فروشیم گنجانده شده، بدون هزینه‌ی اضافی، و در لبه‌ی شبکه اجرا می‌شود نه روی سرور شما — که تنها جایی است که می‌تواند کار کند، چون یک آپلینک اشباع‌شده را هیچ‌چیزی که پشت آن اجرا می‌شود نمی‌تواند درست کند. پهنای‌باند نامحدود است، پس یک حمله تبدیل به فاکتور نمی‌شود. برای اکثریت قریب‌به‌اتفاق آنچه مردم «یک DDoS» می‌نامند، داستان همین است.

آنچه نمی‌تواند ببیند، نوع دیگر است. پانصد درخواست در ثانیه به یک اندپوینت جست‌وجو از چهل‌هزار آدرس خانگی، ترافیک بدشکل نیست؛ ترافیک است. اتصالات Slowloris که هر چند ثانیه یک هدر را قطره‌چکانی می‌فرستند، تک‌تک، مؤدبانه‌اند. یک فرم ورود که با بدنه‌های POST واقعی کوبیده می‌شود، در سطح بسته از یک دوشنبه‌ی شلوغ قابل‌تشخیص نیست. هیچ فیلتر بسته‌ای کمک نمی‌کند، چون هیچ‌ایرادی در بسته‌ها نیست.

یک جهت از ترافیک هست که واقعاً روی آن اقدام می‌کنیم، و ارزش دارد صریح گفته شود: حملات و اسپم انبوهی که از شبکه‌ی ما سرچشمه می‌گیرند ممکن است null-route شوند تا بقیه‌ی زیرساخت سالم بماند. این یک اقدام عملیاتی است، نه محتوایی — تمایزی که راهنمای میزبانی نادیده‌گیرنده‌ی DMCA ما با جزئیات بیشتری روشن می‌کند.

CDN چه چیزی را پنهان می‌کند، و چه دفتر شکایاتی به ارث می‌رسد

مکانیزم ساده و واقعاً مؤثر است. دامنه‌ی شما به آدرس‌های ارائه‌دهنده resolve می‌شود، کلاینت‌ها به آنجا وصل می‌شوند، و ارائه‌دهنده از مبدأ شما داده می‌گیرد. آدرس واقعی هرگز در اتصال یک کلاینت ظاهر نمی‌شود، پس هیچ‌کس که فقط دامنه را می‌داند نمی‌تواند به آن حمله کند. همین ترفند دلیل آن است که fronting با CDN برای پراکسی‌های مقاوم در برابر سانسور کار می‌کند: یک سانسورگر ترافیکی به سمت آدرسی می‌بیند که نمی‌تواند از پس مسدودکردنش بربیاید.

سه چیز همراه آن می‌آید، و هیچ‌کدام در حروف ریز پنهان نیست:

• لبه، TLS شما را terminate می‌کند. ترافیک از قصد و طراحی، داخل شبکه‌ی ارائه‌دهنده متن ساده است — کش‌کردن و فیلترینگ همین‌طور کار می‌کنند. هرچه کاربرانتان تایپ می‌کنند، پیش از رسیدن به شما، به یک شخص ثالث می‌رسد.
• کانال شکایاتی که قبلاً وجود نداشت. شکایات می‌توانند مستقیماً علیه CDN ثبت شوند، و CDN به آن‌ها پاسخ می‌دهد: با ارجاع به شما، با نام‌بردن از ارائه‌دهنده‌ی میزبانی‌تان، یا با قطع‌کردن سرویس شما. اگر دلیل شما برای آفشور بودن این است که شکایات به‌جایی نمی‌رسند، گذاشتن یک واسطه‌ی آمریکایی جلویش، همان زنجیره‌ای را که برای شکستنش پول داده بودید دوباره وصل می‌کند.
• یک حساب کاربری. آدرس ایمیل، روش پرداخت، اغلب یک شماره تلفن، که به دامنه‌ی شما گره خورده و برای مدت نامحدود نگه‌داشته می‌شود. بیشتر درباره‌ی این موضوع در ادامه، چون معمولاً ضعیف‌ترین حلقه‌ی کل این آرایش است.

هیچ‌کدام از این‌ها CDN را اشتباه نمی‌کند. آن را به یک تصمیم دو سویه تبدیل می‌کند: عالی برای یک فروشگاه یا اپلیکیشن با کاربران واقعی و فشار واقعی لایه 7، و به‌شدت ضدهدف برای انتشاری که اخطارهای حذف جلب می‌کند. پاسخ خودمان به این سؤال در صفحه‌ی میزبانی نادیده‌گیرنده‌ی DMCA همیشه نسخه‌ی کوتاه همین بوده: برای مقاومت در برابر حذف، از فیلترینگ شبکه‌ای که از قبل دارید استفاده کنید و از CDN صرف‌نظر کنید.

شش راهی که آدرس مبدأ در هر صورت لو می‌رود

این بخشی است که اهمیت دارد، چون پنهان‌کاری یک محصول نیست که بخرید — یک ویژگی است که یا نگهش می‌دارید یا از دستش می‌دهید، معمولاً ظرف چند روز، به دست یکی از این شش چیز. سرورهای مبدأ هر روز، پشت پیکربندی‌های کاملاً درست CDN، پیدا می‌شوند.

• لاگ‌های Certificate Transparency. هر گواهی مورد اعتماد عمومی که برای دامنه‌ی شما صادر می‌شود، ظرف چند دقیقه در لاگ‌های عمومی، دائمی و قابل‌جست‌وجو منتشر می‌شود. آن‌ها آدرس شما را منتشر نمی‌کنند؛ hostnameهای شما را منتشر می‌کنند — staging، mail، vpn، همان ساب‌دامنه‌ای که یک‌بار در 2024 راه انداختید. هرکدام یک نامزد برای resolve شدن‌اند، و یک رکورد تنها که به جلو اشاره نکند، کل ماجرا را تمام می‌کند.
• تاریخچه‌ی DNS. سرویس‌های passive-DNS هر آدرسی را که دامنه‌ی شما تا به‌حال به آن resolve شده آرشیو می‌کنند. رفتن پشت یک CDN بعداً، آنچه را قبلاً ثبت شده از انتشار خارج نمی‌کند — پنهان‌کاری باید پیش از اولین resolve شدن دامنه شروع شود، وگرنه به یک آدرس تازه نیاز دارید، نه یک جلوی تازه.
• رکوردهایی که نمی‌توانند proxy شوند، و آن‌هایی که فراموش‌شان کردید. mail exchangerها باید به چیزی قابل‌دسترس اشاره کنند. یک رکورد AAAA که وقتی فقط IPv4 را proxy کردید جا مانده هم همین‌طور است، یا یک hostname قدیمی FTP یا پنل، یک wildcard، یا هاست توسعه‌ی «موقتی» که حالا سه سال از عمرش می‌گذرد.
• هرچیزی که سرور بفرستد. ایمیل از مبدأ، آدرسش را در هدرهای Received حمل می‌کند — یک پیام بازنشانی رمز عبور، افشاگری خودخواسته است. webhookها، fetchهای خروجی تصویر، پیش‌نمایش لینک، pingbackها، بررسی‌های به‌روزرسانی و crash reporterها، همه از آدرس واقعی بیرون می‌زنند، و هرکس که بتواند اپلیکیشن شما را وادار کند با هاستی که کنترل می‌کند صحبت کند، آن را می‌فهمد.
• اسکن کل اینترنت. هر آدرس IPv4 پیوسته توسط سرویس‌های عمومی اسکن و ایندکس می‌شود، و نتایج ظرف چند ثانیه قابل‌جست‌وجو هستند. اگر مبدأ شما روی پورت 443 با گواهی‌تان پاسخ بدهد، یا صفحه‌ی اصلی‌تان را به هر هدر Host بدهد، تطبیق‌دادنش فقط یک کوئری در برابر یک هش بدنه، یک اثر انگشت گواهی، یا یک هش فاویکون است. اکثر سرورهای مبدأ این‌طور پیدا می‌شوند، و برای پیداکننده هیچ هزینه‌ای ندارد.
• اپلیکیشنی که درباره‌ی خودش حرف می‌زند. URLهای مطلق و ریدایرکت‌هایی که آدرس خام را دارند، اندپوینت‌های status یا metrics که باز مانده‌اند، stack traceهای پرگویی که هاست‌های داخلی را نام می‌برند، هدرهایی که backend را لو می‌دهند، و virtual hostِ پیش‌فرضی که با خوشحالی سایت شما را به هرکس که با آدرس بپرسد تحویل می‌دهد.

قفل‌کردن مبدأ تا فقط جلو بتواند به آن برسد

پنهان‌کاری‌ای که به حدس‌نزدن آدرس توسط دیگران متکی باشد، پنهان‌کاری نیست. این آرایش فقط وقتی پابرجا می‌ماند که مبدأ با هیچ‌کس جز جلو حرف نزند، تا یک آدرس لو‌رفته یک مزاحمت باشد، نه یک رویداد.

• پیش‌فرض رد کنید، بعد فقط جلو را اجازه بدهید. 80 و 443 را فقط از بازه‌های آدرسی منتشرشده‌ی ارائه‌دهنده بپذیرید، و آن فهرست را به‌طور خودکار به‌روز کنید — بازه‌ها تغییر می‌کنند، و یک فهرست کهنه در بدترین لحظه یا باز می‌ماند یا بسته می‌شود. بقیه‌چیزها، از جمله SSH، باید روی یک تانل یا یک آدرس مدیریتی باشند، همان‌طور که در چک‌لیست سخت‌سازی ساعت اول ما آمده.
• جلو را احراز هویت کنید. گواهی‌های کلاینت میان CDN و مبدأ شما — که معمولاً authenticated origin pull نامیده می‌شود — یعنی حتی یک آدرس درست به‌علاوه‌ی یک هدر Host درست، بدون گواهی چیزی به‌دست نمی‌آورد.
• بهتر: اصلاً هیچ پورت ورودی‌ای نباشد. یک تانل فقط-خروجی از مبدأ به لبه — چه connector خود CDN باشد چه WireGuard به یک نودی که خودتان اجرا می‌کنید — یعنی مبدأ هرگز روی یک اینترفیس عمومی گوش نمی‌دهد. اسکن نمی‌تواند چیزی را پیدا کند که پاسخ نمی‌دهد، و این قوی‌ترین نسخه‌ی این آرایش است.
• یک virtual host، یک هدر Host. سرور پیش‌فرض نباید چیز مفیدی برگرداند. اگر سایت شما با آدرس بارگذاری شود، ظرف یک هفته توسط یک اسکنر تطبیق داده خواهد شد.
• ایمیل را از مبدأ وب جدا کنید. ایمیل باید قابل‌دسترس باشد و باید خودش را معرفی کند؛ آن را روی دستگاه جداگانه‌ی خودش نگه دارید، همان‌طور که راهنمای راه‌اندازی سرور ایمیل فرض می‌کند.
• از بیرون تأیید کنید. هر بررسی در این فهرست، وقتی از خود سرور اجرا شود، بی‌معناست. از شبکه‌ای که مال شما نیست تست کنید.

نود جلویی خودتان به‌جای یک CDN

گزینه‌ی سوم نادیده گرفته می‌شود چون بودجه‌ی بازاریابی ندارد: یک VPS کوچک به‌عنوان چهره‌ی عمومی، یک تانل رمزشده به دستگاهی که داده را نگه می‌دارد، و nginx یا HAProxy که ترافیک را میان آن‌ها رد‌و‌بدل می‌کند. از بیرون، شبیه هر سرور وب دیگری به‌نظر می‌رسد. سرور واقعی جای دیگری است، بدون هیچ پورت ورودی‌ای.

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

چیزی که به‌دست نمی‌آورید، ظرفیت anycast است. یک نود، ظرفیت یک نود را دارد، و درحالی‌که فیلترینگ شبکه‌ی ما دقیقاً مثل هر سرور دیگری از آن محافظت می‌کند، یک حمله‌ی حجمی واقعاً بزرگ یک مسابقه‌ی پهنای‌باند است که یک شبکه‌ی جهانی برنده‌اش می‌شود. موضع صادقانه این است: یک نود جلویی پاسخ درستی برای پنهان‌کردن یک backend سنگین یا گران‌قیمت است — یک آرایه‌ی ذخیره‌سازی، یک دستگاه GPU، یک سرور ایمیل، یک پایگاه‌داده — و برای تفکیک حوزه‌های قضایی. جایگزین یک CDN زیر فشار مداوم لایه 7 نیست.

انتخاب، در یک جدول

حساب کاربری معمولاً ضعیف‌ترین حلقه است

به آنچه پیش می‌آید فکر کنید وقتی زیرساخت کامل است اما کاغذبازی نیست. سرور با Monero پرداخت شده، بدون مدارک هویتی و بدون آدرس ایمیل — همان آرایشی که در صفحات میزبانی بدون KYC ما توصیف شده. بعد یک حساب CDN با یک کارت، یک آدرس شخصی و یک شماره تلفن باز می‌شود، که دامنه‌ای را که محافظت می‌کند فهرست می‌کند. آن حساب، رکورد هویتی قوی‌تر و پایدارتری نسبت به هر چیزی روی سرور است، که یک شرکتی نگهش می‌دارد که به احضاریه‌ها پاسخ می‌دهد، و کاملاً حریم‌خصوصی پرداخت را از بین می‌برد.

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

بررسی میزان افشای خودتان در ده دقیقه

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

• هر hostnameای که تا به‌حال برایش گواهی گرفته‌اید فهرست کنید. دامنه‌ی اصلی‌تان را در یک موتور جست‌وجوی Certificate Transparency جست‌وجو کنید و هر نتیجه را resolve کنید. هرچیزی که به جلو اشاره نکند یک نشتی است، حتی هاست‌هایی که دیگر استفاده نمی‌کنید.
• تاریخچه‌ی DNS خودتان را بخوانید. یک جست‌وجوی passive-DNS آدرس‌هایی را نشان می‌دهد که دامنه‌ی شما پیش از CDN به آن‌ها resolve شده. اگر مبدأ دیروز هنوز مبدأ امروز است، پنهان‌کاری هرگز واقعی نبوده.
• مستقیماً از مبدأ بپرسید. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — اگر سایت پاسخ بدهد، فایروال شما جلو را محدود نمی‌کند و هرکس با یک آدرس نامزد می‌تواند آن را در یک درخواست تأیید کند.
• با بی‌ادبی از آن بپرسید. curl -skI https://198.51.100.10/ باید چیز قابل‌تشخیصی برنگرداند. virtual hostِ پیش‌فرضی که صفحه‌ی اصلی شما را سرو می‌کند، رایج‌ترین اشتباه تکی در این صفحه است.
• هر نوع رکورد را بررسی کنید، نه فقط A. dig +short AAAA example.com، dig +short MX example.com، و همین کار برای هر ساب‌دامنه‌ای که لاگ‌های transparency آشکار کرده‌اند. IPv6 که proxy نشده یک کلاسیک است.
• از اپلیکیشن برای خودتان ایمیل بفرستید. یک بازنشانی رمز عبور راه بیندازید و کل زنجیره‌ی Received را بخوانید. اگر آدرس مبدأ آنجاست، در هر پیامی هم که تا به‌حال فرستاده‌اید هست.
• مطمئن شوید پورت‌ها بسته‌اند. از یک شبکه‌ی نامرتبط، nmap -Pn -p80,443 198.51.100.10 باید filtered نشان بدهد، نه open.
• در اسکنرها جست‌وجو کنید. اثر انگشت گواهی‌تان و هش فاویکون صفحه‌ی اصلی‌تان را در یک ایندکس عمومی اسکن اینترنت جست‌وجو کنید. اگر مبدأ شما ایندکس شده، همین‌طور پیدا خواهد شد.

وقتی آدرس از قبل سوخته است

فرض کنید سوخته می‌ماند. آدرسی که در passive DNS و ایندکس‌های اسکن ظاهر شده، در رکورد عمومی دائمی است، و هیچ تغییر پیکربندی‌ای پسش نمی‌گیرد. واکنش درست، مکانیکی است نه زیرکانه.

• اول نشتی را برطرف کنید. چرخش به یک آدرس تازه بدون بستن سوراخ، ظرف چند روز همان وضعیت را دوباره تولید می‌کند، و شما یک مهاجرت را صرف کرده‌اید بدون یادگرفتن هیچ‌چیز.
• بعد بچرخانید. یک جایگزین را دیپلوی کنید — در یک حوزه‌ی قضایی متفاوت اگر دلیل قانونی بوده نه فنی — بازیابی کنید، و سوییچ کنید. چون هیچ هویتی به سرور اول گره نخورده بود، این یک شروع تازه است نه یک مذاکره، که همان دستاورد عملی و بی‌زرق‌وبرق خرید سرور بدون تاریخچه‌ی حساب کاربری است.
• پیش از وضعیت اضطراری، سوییچ را آماده کنید. یک TTL کوتاه DNS، پیکربندی‌ای که می‌توانید از یک repository دوباره دیپلوی کنید، و یک بازیابیِ تست‌شده، یک بعدازظهر بد را به بیست دقیقه تبدیل می‌کند. هیچ‌کس این را حین یک حمله ترتیب نمی‌دهد.
• آدرس قدیمی را درست بازنشسته کنید. سرور قدیمی را روی آدرس قدیمی، در حال سرو همان محتوا، پارک نکنید؛ این یک تأیید زنده برای هرکسی است که تماشا می‌کند، و رکورد را تازه نگه می‌دارد.

نسخه‌ی کوتاه

فیلترینگ سطح شبکه، حملات حجمی را مدیریت می‌کند، همراه سرور می‌آید و هزینه‌ی اضافی ندارد. یک CDN لایه‌ی کاربرد را مدیریت می‌کند و مبدأ را پنهان می‌کند، به قیمت یک واسطه که TLS شما را terminate می‌کند، به شکایات پاسخ می‌دهد و می‌داند شما چه کسی هستید. نود جلویی خودتان پنهان‌کاری را بدون واسطه می‌خرد، اما بدون ظرفیت جهانی. حوزه‌ی قضایی سؤال حقوقی را تعیین می‌کند و هیچ‌کدام از این سه به آن دست نمی‌زند. و همه‌شان با یک رکورد proxy‌نشده، یک ایمیل از مبدأ، یا یک virtual host پیش‌فرض، خنثی می‌شوند.

بر اساس هدف تصمیم بگیرید نه عادت، بعد آن ده دقیقه را صرف بررسی کنید — این کار بیش از هر ارتقایی، افشای واقعی پیدا می‌کند. اگر معماری را بدون شخص ثالث می‌خواهید، یک VPS کوچک به‌عنوان جلو و کار واقعی روی سخت‌افزار اختصاصی پشت آن، همان آرایشی است که بیشتر در میان کسانی می‌بینیم که قبلاً یک‌بار پیدا شده‌اند.