جان سالم به‌در بردن از یک حمله DDoS روی VPS شما

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

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

دو حمله متفاوت که یک اسم را به اشتراک می‌گذارند

«DDoS» یک کلمه است که دو مشکل را پوشش می‌دهد که تقریباً هیچ‌چیز مشترکی جز نتیجه‌شان ندارند. این دو در جاهای متفاوت، توسط افراد متفاوت، با ابزارهای متفاوت متوقف می‌شوند، و اشتباه‌گرفتن آن‌ها با هم دلیل اصلی این است که چرا این‌همه تلاش برای مقابله در لایه اشتباه هدر می‌رود.

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

«محافظت DDoS شامل می‌شود» واقعاً چه چیزی به شما می‌دهد

محافظت در لایه شبکه واقعی، باارزش، و تقریباً همیشه بد فهمیده‌شده است. وقتی ارائه‌دهنده‌ای فیلترینگ L3/L4 را تبلیغ می‌کند، منظورش این است که شبکه‌اش ترافیک مقصدش آدرس شما را زیر نظر دارد، و وقتی سیلی شناسایی شود، ترافیک از میان سخت‌افزار پالایش عبور داده می‌شود که بخش مخرب را حذف می‌کند و آنچه را مشروع به‌نظر می‌رسد پیش می‌فرستد. این کار بدون هیچ تیکت پشتیبانی‌ای انجام می‌شود و معمولاً بدون اینکه شما چیزی بیش از یک پرش کوتاه متوجه شوید.

این یک جمله کار زیادی روی دوش خودش دارد، پس ارزش دارد باز کنیم که چه چیزی را شامل می‌شود و چه چیزی را نه:

• حمله‌هایی را پوشش می‌دهد که به‌تنهایی نمی‌توانید از پسشان بربیایید. یک سیل تقویتی 200 Gbps علیه سروری با پورت 1 Gbps مشکل پیکربندی نیست. حساب و کتاب ساده است. پالایش بالادستی تنها پاسخی است که وجود دارد.
• نسبت به اپلیکیشن شما بی‌حالت (stateless) است. فیلتر نمی‌داند کدام URLهای شما پرهزینه‌اند، کدام بازدیدکننده‌ها لاگین‌کرده‌اند، یا اینکه یک درخواست به اندپوینت جست‌وجوی شما چهارصد برابر یک درخواست به لوگویتان هزینه دارد.
• به یک آستانه واکنش نشان می‌دهد، نه به رنج شما. شناسایی بر اساس حجم ترافیک فعال می‌شود. حمله‌ای که هیچ‌وقت از آن آستانه رد نشود، هیچ‌وقت آن را فعال نمی‌کند، مهم نیست چقدر کامل سایت شما را از کار انداخته باشد.
• در موارد شدید ممکن است موقتاً بلک‌هول کند. هر شبکه‌ای یک سقف دارد. اگر حمله‌ای زیرساخت مشترک را تهدید کند، ممکن است آدرس برای مدتی کنار گذاشته شود — این یک رویه استاندارد و همه‌جایی است و بهتر است پیش از رخ‌دادنش بدانیدش تا حین آن.

اول مشخص کنید که آیا اصلاً این یک حمله است

سهم قابل‌توجهی از رویدادهایی که به‌عنوان DDoS مشکوک می‌شوند، در واقع چیز دیگری‌اند که لباس آن را پوشیده‌اند، و راه‌حل‌ها قابل‌تعویض با هم نیستند. پیش از اینکه هرچیزی را محدودیت نرخ بزنید، دو دقیقه وقت بگذارید و بدلی‌ها را کنار بگذارید — تشخیص اشتباه این‌جا یک ساعت، و گاهی کاربران واقعی‌تان، برایتان هزینه دارد.

• پرطرفدار شده‌اید. یک لینک روی یک تجمیع‌کننده بزرگ، شکلی از ترافیک تولید می‌کند که دقیقاً شبیه یک سیل لایه 7 است، با این تفاوت که رفررها واقعی‌اند و درخواست‌ها برای صفحاتی هستند که یک انسان می‌خواهدشان. این یک مشکل ظرفیت با یک دلیل خوشحال‌کننده است؛ محدودیت‌نرخ‌زدنش به خودتان آسیب می‌زند.
• یک خزنده رفتار مؤدبانه‌اش را از دست داد. اسکرِیپرهای تهاجمی و بات‌های آموزش هوش مصنوعی به‌راحتی می‌توانند از پس یک سرور کوچک بربیایند. معمولاً user-agent لو می‌دهد، و راه‌حل robots.txt به‌همراه یک محدودیت هدفمند است، نه یک محدودیت عمومی.
• خودتان چیزی را خراب کرده‌اید. دیپلویی که کش را غیرفعال کرده، یک کرون‌جاب سرکش، پایگاه‌داده‌ای که یک ایندکس را از دست داده — همه این‌ها به شکل «بار ناگهانی، بدون دلیل مشخص» ظاهر می‌شوند. اگر زمان‌بندی با تغییری که خودتان دادید هم‌خوانی دارد، همان تغییر را باور کنید.
• مانیتورینگ خودتان همان سیل است. نادر، خجالت‌آور، و خیلی رایج‌تر از چیزی که کسی اعتراف کند. یک حلقه health-check که بدون backoff دوباره تلاش می‌کند می‌تواند نرخ درخواستی واقعاً چشمگیر تولید کند.

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

خواندن حمله از خود سرور

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

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

• vnstat -tr 10 — میانگین توان عملیاتی طی ده ثانیه، سریع‌ترین قرائت صادقانه از اشباع.
• cat /proc/net/dev دو بار، با فاصله یک‌ثانیه‌ای — تفاضل بسته و بایت به ازای هر اینترفیس، بدون نیاز به ابزار خاصی.

آیا یک سیل SYN است؟ اتصالات نیمه‌باز در وضعیت SYN-RECV روی هم انباشته می‌شوند. چند تا عادی است؛ هزاران تا عادی نیست:

• ss -s — خط خلاصه، شمار اتصالات به تفکیک وضعیت در یک نگاه.
• ss -tn state syn-recv | wc -l — همان عدد مشخصی که اهمیت دارد.

آیا لایه 7 است؟ اگر پهنای باند چیز خاصی نیست اما همه‌چیز کند است، درخواست‌ها به ازای هر کلاینت را در access log خودتان بشمارید. یک آدرس تنها با ده‌ها هزار بازدید کار یک آماتور است؛ صد هزار آدرس که هرکدام فقط سه بازدید دارند، همان چیز واقعی است:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• $1 را با $7 عوض کنید تا به‌جایش مسیرهای درخواستی را رتبه‌بندی کنید. اگر یک اندپوینت پرهزینه غالب است، هم هدف را پیدا کرده‌اید و هم نیمی از راه‌حل را.

واقعاً چه چیزی ته کشیده؟ میانگین بار به‌تنهایی چیز زیادی به شما نمی‌گوید. دنبال سقف مشخصی باشید که به آن خورده‌اید: همه فرزندان PHP-FPM مشغول، اتصالات پایگاه‌داده در سقف خودشان، توصیف‌گرهای فایل ته‌کشیده، یا کارگرهایی که در وضعیت D منتظر دیسک گیر کرده‌اند. آن سقف — نه ترافیک — چیزی است که سایت را از کار انداخته، و بالابردنش اغلب سریع‌تر از فیلترکردن هرچیزی است.

ده دقیقه اول

زیر فشار، آدم‌ها دست به بزرگ‌ترین اهرم در دسترس می‌برند، و بزرگ‌ترین اهرم معمولاً اشتباه است. این ترتیبی است که خسارت را محدود می‌کند، تقریباً از سریع‌ترین و امن‌ترین شروع می‌شود:

1. پیش از اقدام، دسته‌بندی کنید. اینترفیس اشباع یعنی حجمی؛ اینترفیس آرام با کارگرهای مشغول یعنی لایه 7. سی ثانیه که این‌جا صرف کنید، از یک ساعت رفع‌کردن لایه اشتباه نجاتتان می‌دهد.
2. اگر حجمی است، فوراً یک تیکت باز کنید و آدرس مقصد، زمان شروع و شمارنده‌های اینترفیس خودتان را در آن بگنجانید. بعد دست از تایپ‌کردن در سرور بردارید — این را نمی‌توانید از داخل خودش حل کنید.
3. اگر لایه 7 است، اول کش کنید. روشن‌کردن کش‌گذاری تهاجمی کل صفحه برای بازدیدکنندگان ناشناس، تک‌تنها سریع‌ترین راه برای تبدیل یک قطعی به یک شانه‌بالاانداختن است، و تنها اقدامی است که علیه ترافیک واقعی هم کمک می‌کند.
4. سپس محدودیت نرخ بگذارید — اول اندپوینت هدف، بعد بقیه چیزها. محتاطانه شروع کنید. محدودیتی که کاربران خودتان را هم از پا درمی‌آورد، ادامه‌ای خودخواسته از همان حمله است.
5. فقط چیزی را مسدود کنید که بدون ابهام است. ده‌دوازده آدرس که هرکدام صد هزار درخواست دارند، یک user-agent که آشکارا جعلی است، یک کشور که هیچ کاربری در آن ندارید. در برابر وسوسه نوشتن قوانین پیچیده وقتی زیر آتش هستید مقاومت کنید؛ ماه بعد آن‌ها را به یاد نخواهید آورد.
6. اگر لازم شد، عمداً بخشی از بار را کنار بگذارید. نمایش یک صفحه ایستای «در حال تعمیر» به بازدیدکنندگانی که لاگین نکرده‌اند، دستگاه را زنده نگه می‌دارد، API شما را بالا نگه می‌دارد، و برایتان وقت فکرکردن می‌خرد. خودتان تصمیم بگیرید چه چیزی را قربانی کنید بهتر از این است که این تصمیم به‌جای شما گرفته شود.
7. هرچه انجام دادید را یادداشت کنید. هر قانون موقتی که اضافه کردید، یک مین زمینی برای «خودِ آینده‌تان» است. قوانینی که کمک کردند دائمی می‌شوند؛ بقیه فردا برداشته می‌شوند.

محدودیت‌های نرخی که دوام می‌آورند، و اشتباهی که همه مرتکب می‌شوند

محدودیت نرخ ابزار اصلی برای لایه 7 است، و nginx این کار را خوب انجام می‌دهد با دو دایرکتیو که دو مشکل واقعاً متفاوت را حل می‌کنند. limit_req سقف نرخ درخواست را تعیین می‌کند — یعنی هر کلاینت چقدر می‌تواند تقاضا کند. limit_conn سقف همزمانی را تعیین می‌کند — یعنی هر کلاینت چند اتصال می‌تواند هم‌زمان باز نگه دارد. سیل‌ها به اولی نیاز دارند؛ حمله‌های slow-loris، که هزاران اتصال نزدیک‌به‌بیکار را باز نگه می‌دارند تا استخر کارگرهای شما را خالی کنند، به دومی نیاز دارند. اگر فقط یکی را پیاده کنید، فقط نیمی از مشکل پوشش داده می‌شود.

سه جزئیات، محدودیتی که واقعاً کار می‌کند را از محدودیتی که فقط تزئینی است جدا می‌کنند:

• از burst استفاده کنید، و از nodelay هم. مرورگرهای واقعی پرشی (bursty) عمل می‌کنند — یک بازدید تک از یک صفحه، ده‌دوازده درخواست منبع تقریباً هم‌زمان شلیک می‌کند. محدودیتی بدون فضای اضافه، بازدیدکنندگان واقعی را خفه می‌کند در حالی که مهاجمی که سرعتش را درست زیر آستانه نگه داشته، بدون مشکل عبور می‌کند.
• اندپوینت‌های پرهزینه را جداگانه محدود کنید. صفحه جست‌وجو، فرم لاگین، بازنشانی رمز عبور و هر اندپوینتی که در پایگاه‌داده می‌نویسد، سزاوار بودجه‌ای بسیار تنگ‌تر از منابع ایستای شما هستند. مهاجمان این‌ها را بدون تلاش پیدا می‌کنند، چون همین‌ها هستند که آسیب می‌زنند.
• 429 برگردانید، نه 503. این کد وضعیت، سیگنالی است به کلاینت‌های خوش‌رفتار و موتورهای جست‌وجو که این محدودسازی نرخ است نه خرابی — و از تبدیل‌شدن یک بعدازظهر بد به یک مشکل رتبه‌بندی جلوگیری می‌کند.

کش‌گذاری ارزان‌ترین اقدام مقابله‌ای است که تا به حال پیاده می‌کنید

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

چیزهایی که وقتی از سر ناچاری روشنش می‌کنید، اهمیت دارند:

• فقط برای بازدیدکنندگان ناشناس کش کنید. با یک کوکی نشست، کش را دور بزنید. نمایش صفحه یک کاربر لاگین‌کرده به کاربر دیگر، رویدادی به‌مراتب بدتر از همان قطعی‌ای است که داشتید رفعش می‌کردید.
• عمداً محتوای قدیمی تحویل دهید. proxy_cache_use_stale در nginx به‌همراه updating error timeout یعنی وقتی بک‌اند شما در حال دست‌وپنجه نرم‌کردن است، بازدیدکننده‌ها به‌جای خطا، صفحه‌ای کمی قدیمی می‌گیرند. در طول یک حمله، این تفاوت میان سایتی است که خوب به‌نظر می‌رسد و سایتی که مرده به‌نظر می‌رسد.
• میس‌های تکراری را ادغام کنید. proxy_cache_lock تضمین می‌کند که هزار درخواست هم‌زمان برای یک صفحه کش‌نشده، فقط یک درخواست به بک‌اند تولید کند، نه هزار تا. بدون آن، یک حمله دورزننده کش مستقیم از کش عبور می‌کند و با تمام قدرت روی پایگاه‌داده شما فرود می‌آید.
• رشته‌های کوئری دورزننده کش را خنثی کنید. ترفند استاندارد این است که یک ? و یک مقدار تصادفی اضافه شود تا هر درخواست یک کلید یکتا باشد و برای همیشه میس بخورد. کلید کش خودتان را طوری نرمال کنید که پارامترهای کوئری‌ای را که اپلیکیشن شما واقعاً استفاده نمی‌کند، نادیده بگیرد.

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

سقف‌هایی که تعیین می‌کنند آیا از پا می‌افتید یا نه

بیشتر سرورها به این دلیل نمی‌میرند که CPU‌شان تمام شده. آن‌ها به این دلیل می‌میرند که به یک سقف نامرئی می‌خورند که هیچ‌کس عمداً تنظیمش نکرده — یک پیش‌فرض از یک دهه پیش که روی سخت‌افزاری منطقی بود که دیگر هیچ‌کس از آن استفاده نمی‌کند. زیر حمله، این‌ها چیزهایی هستند که واقعاً اول از همه می‌شکنند:

• کارگرهای اپلیکیشن. pm.max_children در PHP-FPM، شمار کارگرهای Python شما، اندازه کلاستر Node شما. این سقف واقعی همزمانی سایت شماست. وقتی همه‌شان مشغول‌اند، هر بازدیدکننده اضافی در صف می‌ماند، و سایت از کار می‌افتد، مهم نیست CPU چقدر بیکار به‌نظر برسد. آن را فقط تا جایی بالا ببرید که حافظه اجازه می‌دهد — سواپ‌کردن بدتر از صف‌کشیدن است.
• صف پذیرش. net.core.somaxconn و backlog مربوط به listen شما تعیین می‌کنند چند اتصال می‌توانند منتظر پذیرفته‌شدن بمانند. یک backlog کوچک، یک هجوم قابل‌تحمل را به اتصالات ردشده تبدیل می‌کند.
• کوکی‌های SYN. net.ipv4.tcp_syncookies به کرنل اجازه می‌دهد به یک سیل SYN پاسخ دهد بدون اینکه برای اتصالاتی که هیچ‌وقت کامل نمی‌شوند حالتی تخصیص دهد. کرنل‌های مدرن آن را به‌صورت پیش‌فرض فعال می‌کنند؛ به‌جای فرض‌کردن، بررسی کنید، چون هیچ هزینه‌ای ندارد و شما را از رایج‌ترین سیلی که وجود دارد نجات می‌دهد.
• توصیف‌گرهای فایل. هر اتصال یک توصیف‌گر است. سقف پیش‌فرض nofile اغلب پایین‌تر از تعداد اتصالاتی است که سعی می‌کنید سرویس دهید، و حالت شکستش — accept هایی که شکست می‌خورند در حالی که همه‌چیز سالم به‌نظر می‌رسد — واقعاً ساعت سه بامداد گیج‌کننده است.
• اتصالات پایگاه‌داده. بالابردن شمار کارگرها بدون بالابردن استخر اتصال، فقط صف را به جایی می‌برد که دیدنش سخت‌تر است. این دو عدد باید با هم تنظیم شوند.

این‌ها را در یک روز آرام تنظیم کنید، نه حین یک رویداد. فایده دانستنشان این است که وقتی سایت از پا می‌افتد، می‌توانید به‌جای حدس‌زدن، دقیقاً نام سقفی را که به آن خورده بگویید — و سقفی که نامش را می‌دانید، سقفی است که رفع‌شدنی است.

قراردادن چیزی جلوی سرور اصلی

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

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

یک سرور اصلی پنهان بیش از هر فیلتری ارزش دارد

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

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

انتخاب سخت‌افزار و لوکیشن، طوری که حمله‌ها کسل‌کننده بمانند

بخشی از این ماجرا پیش از آنکه اصلاً حمله‌ای رخ دهد تصمیم‌گیری می‌شود، همان لحظه‌ای که یک پلن را انتخاب می‌کنید. سه ویژگی خیلی بیشتر از آنچه برگه مشخصات نشان می‌دهد اهمیت دارند:

• پهنای باند نامحدود. در یک پلن سهمیه‌ای، یک حمله فقط یک قطعی نیست — یک صورت‌حساب هم هست. ترافیکی که هیچ‌وقت نخواستید و نمی‌توانستید ردش کنید، باز هم از سهمیه شما کم می‌شود. انتقال نامحدود یک ریسک مالی را به یک ریسک کاملاً فنی تبدیل می‌کند، که رده بسیار بهتری از مشکل است.
• اینکه آیا پورت مال خودتان است یا نه. روی یک هاست مجازی‌سازی‌شده مشترک، همسایه‌ای که مورد حمله است می‌تواند شما را هم تحت‌تأثیر قرار دهد، و سقف محافظتی خودتان هم مشترک است. سخت‌افزار اختصاصی با پورت مخصوص به خودش، هر دو اثر را از بین می‌برد. برای پروژه‌ای که انتظار توجه خصمانه دارد، این روشن‌ترین دلیل برای ارتقا از یک VPS است — بیشتر از هسته یا RAM.
• شبکه کجا نشسته است. یک شبکه اروپایی با اتصال خوب و ظرفیت ترانزیت واقعی، سیلی را جذب می‌کند که یک شبکه با پیرینگ ضعیف جذبش نمی‌کند، و حوزه قضایی‌ای که به دلایل حقوقی انتخاب کرده‌اید هم ویژگی‌های شبکه‌ای خودش را دارد. ارزش دارد هنگام انتخاب از میان لوکیشن‌های موجود، هر دو را بررسی کنید.

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

پنج کاری که نباید انجام دهید

الگوهای شکست این‌جا آن‌قدر ثابت‌اند که بشود فهرستشان کرد، و هرکدام برای یک نفر یک آخر هفته هزینه داشته‌اند:

• خودتان را بلک‌هول نکنید. بلک‌هول‌کردن آدرس خودتان، به معنای واقعی کلمه به حمله پایان می‌دهد — هیچ‌کس نمی‌تواند به شما برسد، حتی کاربران خودتان. این ابزاری برای آخرین چاره در دست ارائه‌دهنده شماست، نه اقدامی که خودتان داوطلبانه انجام می‌دهید.
• fail2ban را محافظت DDoS تلقی نکنید. این ابزار خوبی است در برابر تلاش‌های brute-force از چند آدرس معدود. اما در برابر یک سیل توزیع‌شده، ظرف چند دقیقه به چیزی واکنش نشان می‌دهد که در چند ثانیه می‌رسد، و قانونی که هزاران آدرس را مسدود می‌کند می‌تواند در پردازش فایروال هزینه‌ای بیشتر از خود حمله رویتان بگذارد.
• باج ندهید. اکثریت قریب‌به‌اتفاق ایمیل‌های اخاذی که تهدید به یک حمله فاجعه‌بار می‌کنند، از افرادی می‌آیند که هیچ توانایی‌ای ندارند و هزاران پیام یکسان می‌فرستند. آن اقلیت کوچکی هم که می‌توانند عملی‌اش کنند، دوباره برمی‌گردند، چون ثابت کرده‌اید که پرداخت می‌کنید.
• تلافی نکنید. جدا از اینکه تقریباً همه‌جا غیرقانونی است، منابع حمله اشخاص ثالث نفوذشده‌اند. در واقع دارید به قربانی‌ها حمله می‌کنید، آن‌هم از آدرسی که بدون ابهام مال خودتان است.
• در وحشت مهاجرت نکنید. جابه‌جاکردن هاست وسط یک حمله یعنی آدرس جدید ظرف چند دقیقه عمومی می‌شود و شما هیچ پیکربندی کارآمدی ندارید. اول ثبات پیدا کنید، بعد با تأمل جابه‌جا شوید — و اگر واقعاً جابه‌جا می‌شوید، راهنمای ما درباره مهاجرت بدون قطعی دقیقاً برای همین وجود دارد تا خود جابه‌جایی به یک رویداد دوم تبدیل نشود.

نسخه کوتاه

بدون استدلال‌هایش، مدل کاری در هشت خط جا می‌شود:

1. اول دسته‌بندی کنید. اینترفیس اشباع یعنی حجمی و مال هاست شماست. اینترفیس آرام با کارگرهای ته‌کشیده یعنی لایه 7 و مال خودتان است.
2. برای حجمی، یک تیکت ثبت کنید با آدرس، برچسب زمانی و شمارنده‌های خودتان — بعد دست از دست‌زدن به سرور بردارید.
3. برای بازدیدکنندگان ناشناس تهاجمی کش کنید، زیر فشار محتوای قدیمی تحویل دهید، و میس‌های تکراری را ادغام کنید. این پراهرم‌ترین تغییری است که می‌توانید انجام دهید.
4. هم بر اساس نرخ درخواست و هم بر اساس همزمانی محدودیت نرخ بگذارید، تنگ‌ترین آن روی اندپوینت‌هایی که بیشترین هزینه را دارند، و 429 برگردانید.
5. پیش از هر چیز دیگری پیکربندی real-IP خودتان را درست کنید، وگرنه هر محدودیت به‌ازای هر کلاینت پشت یک پراکسی، یا بی‌فایده است یا فاجعه‌بار.
6. سقف‌های خودتان را بشناسید — کارگرها، backlog، توصیف‌گرها، اتصالات پایگاه‌داده — و آن‌ها را در یک روز آرام و با تأمل بالا ببرید.
7. آدرس سرور اصلی را مخفی و با فایروال محدود به نودهای جلویی خودتان نگه دارید. این بیش از تمام فیلترها روی هم ارزش دارد.
8. پهنای باند نامحدود بخرید تا ترافیکی که نخواسته‌اید هیچ‌وقت یک صورت‌حساب هم نباشد.

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