دو کلمه، دو رفتار کاملاً متضاد
وقتی سیلی از ترافیک میرسد، یک میزبان دو کار میتواند انجام دهد، و این صنعت هر دو را با عنوان «DDoS protection» میفروشد. اولی جذب (absorption) است: ترافیک به یک لایهی scrubbing بالادست سرور شما کشیده میشود، بستههای حمله همانجا حذف میشوند، بستههای مشروع ادامه مییابند، و سرویس شما در تمام این مدت در دسترس میماند. دومی blackholing است — که null-routing یا RTBH هم نامیده میشود، طبق RFC 5635 — که در آن آدرس IP شما از جدول مسیریابی خارج میشود تا اصلاً هیچچیزی به آن نرسد. سیل دیگر به دیتاسنتر برخورد نمیکند. کاربران شما، مانیتورینگ شما و نشست SSH شما هم همینطور. مهاجم دقیقاً همان نتیجهای را میگیرد که برایش پول داده بود.
هر دو مهندسی واقعیاند و هیچکدام فینفسه نادرست نیستند. Blackholing به این دلیل وجود دارد که جذبِ یک سیلِ بزرگ پول واقعی هزینه دارد — transit اندازهگیری و صورتحساب میشود، ظرفیت scrubbing خریداری و تأمین میشود — و یک میزبانِ ارزانقیمت که یک مشتری را null-route میکند تا چهارصد مشتری دیگر آنلاین بمانند، دارد تصمیمی قابلدفاع میگیرد. ترفند در ضمیر است. «DDoS protection» در هر دو حالت درست است؛ چیزی که فرق میکند این است که سرویسِ چه کسی محافظت میشود. هر کارتِ پلن را با این پرسش در ذهن بخوانید.
| واکنش | ترافیک حمله | سرویس شما | معمولاً چطور توصیف میشود |
|---|---|---|---|
| Scrubbing / جذب | در بالادست فیلتر میشود، در edge حذف میشود | روشن میماند، معمولاً بدون تغییر قابلمشاهده | «Always-on mitigation»، «anycast scrubbing» |
| Blackhole / null-route | همراه با ترافیک مشروع شما حذف میشود | در طول مدت آفلاین — معمولاً 1–24 h | «محافظت تا X Gbps»، «تعلیق موقت IP» |
| فقط rate-limit در edge | بخشی حذف میشود، تا حدی بهصورت تصادفی | افت کیفیت — کاربران واقعی packet loss میبینند | «محافظت پایه شامل است» |
| هیچچیز (تصمیم با carrier است) | تا وقتی یک بالادست prefix را blackhole کند به رک میرسد | آفلاین، و همسایگانِ رکِ شما هم همینطور | «محافظت DDoS موجود است» |
خواندنِ نکات ریز پیش از پرداخت
واژگان لو میدهند. «محافظت تا 10 Gbps» یک سقف است، و جملهی بلافاصله بعد از آن — همان که دربارهی عبورِ ترافیک از حد است — همان بندِ null-route است. «IP محافظتشده بهصورت افزودنی موجود است» یعنی آدرسی که بهطور پیشفرض میگیرید محافظتشده نیست. «Per-incident» یعنی فاکتور بعد از حمله میرسد. «Fair use» وقتی به mitigation وصل میشود یعنی یک سهمیه از حملات در ماه، که بعد از آن باید خودتان کاری کنید. هیچکدام از این عبارتها دروغ نیستند؛ فقط طوری نوشته شدهاند که با نگاهی سرسری از کنارشان رد شوید.
یک نمونهی نامبرده و منتشرشده، چون این خطمشیِ مستند است نه شایعه: BuyVM آدرسهای فیلترشده در برابرِ DDoS را بهصورت یک افزودنیِ جداگانهی $3/month به ازای هر IP میفروشد، و آدرسهای فیلترنشده در طول حمله null-route میشوند. ما این را بدون اظهارنظرِ چندانی در صفحهی مقایسهی BuyVM شرح دادهایم، چون یک IP ارزان و فیلترنشده وقتی بدانید دقیقاً چه چیزی خریدهاید، محصولی کاملاً منطقی است. حالتِ شکست این است که ساعت 03:00 و درحالیکه یک booter در حال اجراست، این را بفهمید.
چهار سؤال که ارزشِ فرستادن به پیشفروش را پیش از اولین فاکتور دارند. ظرفیتِ mitigation چقدر است، و این عدد مجموع است یا رقمِ در دسترس در یک point of presence؟ یک «شبکهی 2 Tbps» که در یک مرکزِ scrubbing واحد خاتمه مییابد، فقط یک لوله برای پر شدن دارد. آیا mitigation در این پلن شامل است یا یک افزودنی است؟ آیا هزینهی per-incident وجود دارد یا سهمیهی ماهانهای از رویدادهای کاهشیافته؟ در چه آستانهای null-route میکنید، و برای چه مدت؟ میزبانی که به آخرین سؤال با یک عدد جواب میدهد، ارزشش بیشتر از کسی است که با صفت جواب میدهد.
سه لایه، و اینکه چرا لایه تعیین میکند چه کسی میتواند آن را درست کند
Layer 3/4 حجمی. سیلهای SYN، سیلهای UDP، و reflection یا amplification از طریق سرویسهای باز NTP، DNS، memcached، CLDAP و SSDP. مهاجم مقدارِ کمی پهنایباند بالادست خرج میکند و چند برابرِ آن را به سمتِ شما برمیگرداند. این یک مسئلهی پهنایباند و packets-per-second است، و روی سرورِ خودتان بهطورِ قطعی غیرقابلحل است: تا زمانی که kernel شما بتواند بسته را drop کند، لولهای که آن را حمل میکند از قبل پر شده است. هیچچیز در nftables اینجا شما را نجات نمیدهد. فقط ظرفیتِ بالادستِ شما این کار را میکند.
Layer 4 state exhaustion. سیلهای SYN، ACK و اتصال، که اندازهشان نه برای پر کردنِ لوله بلکه برای پر کردنِ یک جدول است — SYN backlog کرنل، جدولِ conntrack، صفِ accept برنامهی شما. پهنایباند میتواند ناچیز باشد: چند صد Mbps یک سرورِ تیوننشده را از پا درمیآورد درحالیکه نمودار در سمتِ میزبان مثلِ یک بعدازظهرِ آرام به نظر میرسد. این لایه واقعاً نیمی مالِ شماست: با tcp_syncookies، یک nf_conntrack_max اندازهگذاریشده، و محدودیتهای per-source قابلِ عبور است، و بدونِ آنها قابلِ عبور نیست.
Layer 7 application. سیلهای HTTP ساختهشده از درخواستهای تکتک معتبر — دستدهیهای واقعیِ TLS، رشتههای User-Agent قابلِباور، گاهی مرورگرهای واقعی — که به سمتِ هر بخشِ گرانقیمتِ سایتِ شما نشانه رفتهاند: جستوجو، ورود، سبدِ خرید، یک صفحهی فهرست متکی به دیتابیس. کلاسِ HTTP/2 Rapid Reset نشان داد وقتی هر درخواست برای سرور گرانتر از کلاینت تمام شود، چقدر مگابیتِ کم کافی است. یک دستگاهِ scrubbing نمیتواند داخلِ نشستِ TLSای را که خاتمه نمیدهد ببیند، پس این لایه یا با قوانین در edge یا با reverse proxy خودتان مدیریت میشود — هرگز با ظرفیتِ خامِ حجمی.
| لایه | حملهٔ معمول | اندازهٔ معمول | کجا باید متوقف شود | روی سرور خودتان قابلرفع است؟ |
|---|---|---|---|---|
| L3/L4 حجمی | سیل UDP، amplification از DNS/NTP/memcached | 5 Gbps – 1+ Tbps | بالادست، در edge | خیر — لوله اول پر میشود |
| L4 state exhaustion | سیل SYN / ACK، اشباعِ conntrack | 0.1 – 10 Gbps | edge، بهعلاوهٔ تیونِ کرنل | تا حدی — syncookies، اندازهگذاریِ conntrack |
| L7 application | سیلِ درخواستِ HTTP(S)، POST کند، Rapid Reset | اغلب زیرِ 1 Gbps | قوانینِ edge یا reverse proxy خودتان | بله — rate-limit، challenge، cache |
یک حملهی واقعی راستش چقدر بزرگ است؟
تقریباً نه از هر ده حملهای که به یک سرورِ کوچکِ offshore میرسد، از یک booter یا stresser میآید — یک سرویسِ اشتراکی با هزینهی $10 تا $30 در ماه که ظرفیتِ amplification را دقیقهای بازفروش میکند. اینها چیزی بینِ 5 تا 50 Gbps را در انفجارهایی چند دقیقهای تحویل میدهند، و این همان چیزی است که یک سرورِ Minecraft، یک شبکهی IRC، یک رلهی Tor، یک فروم با یک مدیرِ سابقِ عصبانی یا یک لابیِ بازیِ رقابتی واقعاً با آن روبهرو میشود. این باند کاملاً قابلِ عبور است و همچنین کاملاً کافی است تا یک VPS محافظتنشدهی $5 را از پا دربیاورد.
باندِ بعدی — 100 تا 400 Gbps از یک باتنتِ اجارهای — چیزی است که وقتی کسی کینهای مشخص و بودجهای دارد میرسد. در برابرِ اهدافِ کوچک نادر است و در برابرِ سایتهای شرطبندی، استریمینگ و بزرگسالان معمول است. بالاتر از آن، رویدادهایی در کلاسِ رکورد قرار دارند که فروشندگانِ بزرگِ mitigation گزارش میکنند، اکنون در حدِ چند ترابیت بر ثانیه و صدها میلیون درخواست بر ثانیه اندازهگیری میشوند؛ ارقامِ فصلیِ Cloudflare Radar مرجعِ عمومیِ معمول هستند. تقریباً بهطورِ قطع شما هدفِ موردنظرِ هیچکدام از آنها نیستید.
بااینحال ممکن است قربانیِ یکی از آنها بشوید، و این بخشی است که هیچکس روی کارتِ پلن نمینویسد: آسیبِ جانبی از طریقِ prefix سفر میکند. اگر یک میزبان با دانهبندیِ /24 blackhole کند — که بسیاری اینطور عمل میکنند، چون این کوچکترین prefixی است که بیشترِ carrierها برای RTBH میپذیرند — آنگاه حملهای که به یک آدرس در سابنتِ شما نشانه رفته، هر آدرسِ داخلِ آن را از کار میاندازد. آپتایمِ شما به دشمنانِ یک غریبه بستگی دارد. حاشیهی ظرفیت همان چیزی است که این تصمیم را از اساس غیرضروری نگه میدارد.
اعدادِ خودمان را برایِ کالیبراسیون میآوریم نه برای پُز دادن: 1 Tbps از scrubbing حجمیِ anycast در سطحِ L3/L4، تقسیمشده روی چهار point of presence، که هرکدام بهتنهایی میتواند حدودِ 300 Gbps را جذب کند، با تشخیصِ خودکار در کمتر از 2 ثانیه. بزرگترین رویدادی که برایِ یک مشتری جذب کردهایم بیش از 600 Gbps علیهِ یک سرورِ بازی بود، و اتصالهای بازیکنان قطع نشد. معماری با جزئیاتِ بیشتر در صفحهی شبکه مستند شده است.
شاملِ پلن، per-incident، یا سهمیه — شکلِ تجاریِ آن اهمیت دارد
سه راه برای فروشِ mitigation وجود دارد و فاکتورهای بسیار متفاوتی تولید میکنند. شامل (Included): هزینه در قیمتِ پلن گنجانده شده و یک حمله هیچ چیزی در مبلغی که میپردازید تغییر نمیدهد. Per-incident: برای هر رویدادِ کاهشیافته هزینه میپردازید، گاهی بهازای هر ساعتِ mitigation. سهمیه (Quota): تعدادی رویداد در ماه، یا یک بندِ «fair use» که به میزبان اجازه میدهد تصمیم بگیرد دیگر کافی است.
مدلِ per-incident کلاهبرداری نیست. ترافیکِ scrubشده هنوز پیش از drop شدن از transit میزبان عبور میکند، و transit بر اساسِ صدکِ 95ام یا در برابرِ یک نرخِ تعهدشده صورتحساب میشود — یک کمپینِ پایدار علیهِ یک مشتری، یک ردیفِ واقعی روی فاکتورِ کسی است. مسئله عدالت نیست، پیشبینیپذیری است: در طولِ یک کمپینِ دوهفتهای، یک میزبانِ per-incident یک حمله علیهِ شما را به یک فاکتور برایِ شما تبدیل میکند، که در واقع یک حملهی دوم با چند مرحلهی اضافه است. پیش از اینکه به آن نیاز داشته باشید، بپرسید کدام مدل اعمال میشود.
موضعِ ما، بهروشنی بیانشده تا قابلِ بررسی باشد: shield بهطورِ پیشفرض روی هر پلنی فعال است، از Starter با $8.50 تا Citadel با $299.50؛ نه opt-inای هست، نه هزینهی per-incident، نه سهمیهی ماهانه و نه بندِ «fair use»ای وصل به mitigation. روی ارزانترین VPS همان fabric است که روی بزرگترین سرورِ اختصاصی — پلنهای VPS و سطوحِ اختصاصی را ببینید. چیزی که با سطح مقیاس میگیرد uplink و مجموعهی قوانینِ اختیاریِ Layer 7 است، نه اینکه اصلاً محافظت میشوید یا نه.
پخشِ anycast، و اینکه چرا زمانِ تشخیص از ظرفیتِ تبلیغاتی مهمتر است
یک مرکزِ scrubbing واحد یک سقفِ سخت دارد: transit به همان یک ساختمان. همچنین یک هزینهی latency دارد، چون در طولِ mitigation ترافیکِ همه ابتدا به همان ساختمان کشیده میشود — دلیلِ اینکه برخی میزبانها بهمحضِ شروعِ یک حمله برایِ کاربرانِ اروپایی بهطورِ محسوسی کندتر میشوند، و تا وقتی حمله تمام شود همینطور میمانند.
Anycast محاسبات را پیش از دخالتِ هر سختافزاری تغییر میدهد. همان prefix از هر point of presence اعلام میشود، پس یک باتنتِ توزیعشده در سطحِ جهانی صرفاً بهواسطهی توپولوژیِ اینترنت بینِ آن نقاط تقسیم میشود: یک حملهی 600 Gbps که از همهجا منشأ میگیرد، بهجایِ 600 Gbps در یک نقطه، بهصورتِ حدودِ 150 Gbps در چهار نقطه میرسد. پخششدگی بیشترِ کار را انجام میدهد؛ تجهیزاتِ scrubbing فقط باید آنچه را که جغرافیا از قبل تقسیم کرده، مدیریت کند.
زمانِ تشخیص عددی است که کمترین توجه را میگیرد. mitigationی که در 2 ثانیه فعال میشود برایِ یک نشستِ TCP نامرئی است؛ mitigationی که در 60 ثانیه فعال میشود بعد از این میرسد که کاربرانِ شما دو بار صفحه را reload کردهاند و رفتهاند، و بعد از اینکه یک لابیِ بازی خالی شده. وقتی یک میزبان ظرفیت را ذکر میکند اما تأخیرِ تشخیص را نه، رقمِ دوم را بخواهید — همان رقمی است که تعیین میکند آیا کاربرانِ شما اصلاً متوجه شدند یا نه.
اگر prefix خودتان را بیاورید، blackholing به یک تیغِ جراحی در دستِ خودتان تبدیل میشود، نه چیزی که روی شما انجام میشود. جوامعِ BGP ما شاملِ de-preference بهازای هر carrier (cs:100:carrier)، prepend منطقهای (cs:200:region) و blackhole انتخابی (cs:666:prefix) است، پس میتوانید یک آدرسِ زیرِ حمله را null-route کنید درحالیکه بقیهی تخصیصِ شما به سرویسدهی ادامه میدهد. این یعنی blackholing درست استفادهشده: جراحیگونه، کوتاه، و تصمیمِ خودتان.
پیچیدگیِ offshore بودن: یک proxy آمریکایی جلوی سرور، کلِ هدف را از بین میبرد
توصیهی استانداردِ هر فرومی این است که «فقط بگذاریدش پشتِ Cloudflare، سطحِ رایگان کافی است». برای یک سایتِ معمولی این توصیهی خوبی است. اگر شما یک میزبانِ offshore را به دلایلِ حقوقی انتخاب کردهاید، این کار بیسروصدا همهچیزی را که کنار گذاشته بودید برمیگرداند: حالا یک شرکتِ ثبتشده در آمریکا TLS شما را خاتمه میدهد و متنِ خامِ شما را میبیند، شکایاتِ سوءاستفاده و کپیرایت را دریافت میکند و طبقِ سیاستِ خودش عمل میکند، حسابی متصل به یک آدرسِ ایمیل و معمولاً یک روشِ پرداخت نگه میدارد، و میتواند طرفِ فرایندِ قانونیِ آمریکا قرار بگیرد. نادیدهگرفتنِ یک اخطارِ DMCA توسطِ میزبانِ شما وقتی CDN شما به آن عمل میکند، ارزشِ چندانی ندارد — مکانیزمها در توضیحدهندهی DMCA-ignored و افشاءِ حقوقی در راهنمای 14-Eyes آمده است.
یک proxy همچنین origin شما را پنهان نمیکند مگر اینکه origin را با فایروال فقط به prefixهای proxy محدود کنید و همینطور نگهش دارید. حتی در آن صورت هم آدرس از طریقِ تاریخچهی passive DNS، از طریقِ لاگهای certificate transparency اگر origin هرگز روی نامِ خودش به TLS پاسخ داده باشد، از طریقِ ایمیلِ ارسالشده مستقیماً از سرور، از طریقِ یک رکوردِ A قدیمی که هرگز حذف نشده، و از طریقِ هر صفحهی خطایی که hostname خودِ سرور را برمیگرداند، لو میرود. برخوردِ مستقیم با origin همان چیزی است که سایتهای «محافظتشده» را در نهایت از کار میاندازد. راهنمایِ میزبانیِ ناشناس کلِ سطحِ نشتی را مرور میکند.
اگر میخواهید یک لایهی proxy داشته باشید بدون هزینهی حقوقی، خودتان اجرایش کنید: یک نمونهی کوچکِ دوم در همان حوزهی قضایی یا حوزهای سازگار، که TLS را با کلیدِ خودتان خاتمه میدهد، درحالیکه فایروالِ origin هیچچیز جز آن آدرس را نمیپذیرد. شما caching و فیلترِ درخواست را نگه میدارید، و هیچ شخصِ ثالثی به زنجیرهی اعتماد ملحق نمیشود. هر دو ماشین پشتِ همان fabric scrubbing قرار دارند، پس proxy یک هدفِ نرمِ جدید نیست.
چه چیزی هنوز کارِ شماست، روی سرور
scrubbing بالادست لوله را محافظت میکند. کرنلِ شما را تیون نمیکند، و باندِ state-exhaustion جایی است که یک سرورِ تیوننشده به حملهای میمیرد که شبکه بهسختی آن را ثبت کرده. فهرستِ کوتاه، به ترتیبی که بیشترین سود را میدهد: net.ipv4.tcp_syncookies را فعال کنید و net.ipv4.tcp_max_syn_backlog را بالا ببرید (پارامترها در مرجعِ ip-sysctl کرنل مستند شدهاند)؛ nf_conntrack_max را متناسب با تعدادِ اتصالی که واقعاً انتظار دارید اندازهگذاری کنید، یا برایِ ترافیکِ بازیِ UDP با نرخِ بالا از notrack استفاده کنید تا اصلاً به جدول مراجعه نشود؛ بهجایِ اینکه روی جراحیگونهبودنِ edge حساب کنید، محدودیتهای نرخِ per-source را در nftables اضافه کنید.
در سمتِ application، limit_req و limit_conn در nginx هیچ هزینهای ندارند و بیشترِ سیلهای L7 را که عمداً طوری شکل نگرفتهاند تا انسانی به نظر برسند، متوقف میکنند. هرچه را که میشود cache کنید، چون بهترین هدفِ یک مهاجم همیشه همان صفحهای است که در هر درخواست از دیتابیس تولید میکنید. SSH و هر پنلِ کنترلی را از آدرسی که workload عمومی را سرویس میدهد دور نگه دارید، یا پشتِ یک allowlist بگذارید.
یک جهت که مردم فراموش میکنند: خودتان reflector نشوید. یک ریزالورِ DNS بازِ باز، یک دیمنِ NTP پیکربندینشده یا یک memcached افشاءشده روی سرورِ شما، شما را بخشی از حملهی amplification یک نفرِ دیگر میکند، و سوءاستفادهی خروجی بسیار جدیتر از ورودی برخورد میشود — زمانِ پاسخِ منتشرشده در AUP ما، null-route و تعلیق در کمتر از 2 ساعت است. سیلهای ورودی چیزی است که برایِ شما اتفاق میافتد؛ سیلهای خروجی چیزی است که شما مسئولِ آن هستید.
چکلیستی که ارزشِ اجرا پیش از خرید را دارد
نه سؤال، به ترتیبی که سریعترینبار میزبانها را از هم جدا میکند. ظرفیتِ mitigation چقدر است، و بهازای هر point of presence است یا مجموع؟ آیا در قیمتِ پلن شامل است یا بهازای هر IP فروخته میشود؟ آیا هزینهی per-incident وجود دارد، یا سهمیهای از رویدادهای کاهشیافته در ماه؟ تأخیرِ تشخیص چقدر است؟ آیا اصلاً فیلترِ Layer 7 موجود است، و در کدام سطوح؟ در چه آستانه و برایِ چه مدتی null-route میکنید، و آیا وقتی اتفاق میافتد به شما اطلاع داده میشود؟ آیا mitigation درحینِ فعالبودن مسیریابی یا latency من را تغییر میدهد؟ آیا محافظت روی آدرسی است که بهطورِ پیشفرض میگیرم؟ و — سؤالی که تقریباً هیچکس نمیپرسد — درحینِ اجرایِ mitigation، چه چیزی دربارهی ترافیکِ من نگهداری میشود؟
آن سؤالِ آخر در این بازار بیشتر از هر جایِ دیگری اهمیت دارد. scrubbing یعنی چیزی در بالادست دارد به بستههای شما نگاه میکند. بپرسید چه چیزی از رویداد باقی میماند. جوابِ ما، که در طولِ یک حمله تغییر نمیکند: تشخیص بر اساسِ شمارندههای تجمیعی در edge اجرا میشود — بسته و بیت بر ثانیه، بهازای هر prefix — نه بر اساسِ رکوردهای per-flow نگهداریشده، و موضعِ ثابتِ ما یعنی بدونِ netflow، بدونِ PCAP و بدونِ NIC mirroring که در سیاستِ حریمِ خصوصی منتشر شده، دقیقاً همانطور که در بقیهی زمان اعمال میشود، در طولِ mitigation هم اعمال میشود. میزبانی که نمیتواند به این جواب دهد، دارد چیزی را به شما میگوید.
اگر جوابها کممایه بودند، راهِ جایگزین ارزان است: یک ماه از کوچکترین پلن را بخرید، یک پروبِ مانیتورینگ روی آن بگذارید، و مستقیماً از پشتیبانی بپرسید وقتی سرور مورد اصابت قرار میگیرد چه اتفاقی میافتد. اینجا نه قراردادی هست و نه هزینهی راهاندازی، پس میزبانی که کتبی از این سؤال طفره میرود، فهمیدنش برایِ شما فقط $8.50 هزینه دارد. یک Starter را دیپلوی کنید، یا اگر workload بهاندازهی کافی بزرگ است که جواب سطح را عوض کند، VPS در برابرِ اختصاصی را بخوانید.
