حمله DDoS چیست؟ چرا هکرها سایت را از دسترس خارج می‌کنند؟

ببین، حمله DDoS همیشه با یک پیام ترسناک روی صفحه شروع نمی‌شه. ممکنه سایت فروش دوره کاملاً سالم به نظر برسه، اما درست وقتی دانشجو می‌خواد وارد حسابش بشه یا پرداخت رو انجام بده، صفحه اون‌قدر کند بشه که آخرش خطای ۵۰۳ بگیره. حالا آیا هر بار چنین چیزی دیدیم باید بگیم سایتمون رو هک کردن؟ نه. شاید فروش ویژه بازدید زیادی آورده، شاید دیتابیس قفل کرده یا حتی مشکل از سرویس‌دهنده باشه. ما باید بفهمیم دقیقاً چه منبعی زیر فشار رفته، نه اینکه از روی یک خطا اسم حمله انتخاب کنیم.

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

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

حمله DDoS چیست؟ ۳ نوع حمله و تفاوت با DoS

به زبان ساده، حمله DDoS یا Distributed Denial of Service یعنی چند منبع مختلف تلاش می‌کنن یک سرویس رو طوری تحت فشار بذارن که کاربر واقعی نتونه درست ازش استفاده کنه. ممکنه صفحه‌ها دیر باز بشن، درخواست‌ها Timeout بشن یا فقط یک بخش مهم مثل ورود و پرداخت از دسترس خارج بشه. هدف اصلی این حمله معمولاً مختل کردن دسترس‌پذیریه؛ پس نباید از روی وقوعش نتیجه بگیریم اطلاعات مشتری‌ها هم حتماً لو رفته.

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

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

تفاوت DoS و DDoS چیست؟

تفاوت DoS و DDoS رو می‌شه از روی منابع ایجاد فشار توضیح داد. در DoS ممکنه یک مبدأ یا یک جریانِ سوءاستفاده باعث محرومیت از سرویس بشه، اما در DDoS چند منبع توزیع‌شده درگیر می‌شن. همین پراکندگی کار دفاع رو سخت‌تر می‌کنه؛ چون بستن یک IP لزوماً چیزی رو حل نمی‌کنه. البته تعداد IP زیاد، به‌تنهایی نشانه حمله نیست؛ ترافیک یک رویداد واقعی هم ممکنه از هزاران کاربر متفاوت بیاد.

اگه در گزارش بنویسیم «سایت دیداس شده» ولی هنوز منشأ اختلال رو نفهمیده باشیم، تیم فنی رو از همون اول به مسیر اشتباه می‌بریم. بهتره دقیق بنویسیم: «در بازه مشخص، دسترس‌پذیری کاهش پیدا کرده و علت در حال بررسیه.» وقتی شواهد شبکه، رفتار درخواست‌ها و رویدادهای نرم‌افزار رو کنار هم گذاشتیم، تازه می‌تونیم درباره حمله DDoS با اطمینان بیشتری حرف بزنیم.

بات‌نت چیست و چه ربطی به هک شبکه دارد؟

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

یادت باشه آدرس IP اسم و مشخصات واقعی یک نفر نیست. ممکنه ده‌ها کاربر پشت یک NAT باشن، درخواست‌ها از پراکسی یا CDN رد بشن و حتی داده‌های بعضی حملات شبکه‌ای نشانی مبدأ قابل اعتمادی نداشته باشن. بنابراین وقتی داشبورد چند کشور یا هزاران IP نشون داد، نباید فوری بگیم «این کشور به سایت ما حمله کرده». تحلیل دقیق به شواهد بیشتری نیاز داره.

هکر در حمله دیداس چه چیزی را هدف می‌گیرد؟

به‌جای اینکه فقط نام حمله‌ها رو حفظ کنی، اول بپرس کدوم منبع سیستم کم آورده. پهنای باند؟ جدول اتصال فایروال؟ Workerهای وب‌سرور؟ اتصال‌های دیتابیس؟ یا صف پردازش کارها؟ در یک حمله DDoS ممکنه فشار از یک نقطه شروع بشه و اثرش چند لایه جلوتر دیده بشه. کاربر فقط صفحه‌ای رو می‌بینه که باز نمی‌شه، ولی وظیفه ما پیدا کردن همون گلوگاه واقعیه.

مثلاً دو درخواست HTTP رو در نظر بگیر. اولی تصویر یک محصوله که از کش تحویل داده می‌شه و شاید اصلاً به PHP نرسه. دومی درخواست رزرویه که باید ظرفیت رو از دیتابیس بخونه، موجودی رو بررسی کنه و جواب یک سرویس دیگه رو بگیره. روی نمودار هر دو یک «درخواست» حساب می‌شن، اما هزینه‌شون اصلاً یکی نیست. برای همین فقط شمارش درخواست‌ها بدون بررسی کار پشت هر درخواست، می‌تونه گمراه‌کننده باشه.

سه خانواده اصلی حملات DDoS را درست بشناسیم

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

حالا می‌فهمیم چرا نصب یک افزونه امنیتی روی وردپرس، هرچقدر هم خوب باشه، جواب همه حملات DDoS نیست. اگه لینک اینترنت قبل از رسیدن درخواست به PHP پر شده باشه، افزونه اصلاً فرصتی برای تصمیم‌گیری نداره. در عوض، وقتی فشار روی یک API سنگین وارد می‌شه، بهینه‌سازی برنامه، کش درست و کنترل نرخ می‌تونن خیلی مؤثر باشن. دفاع باید همون جایی قرار بگیره که فشار واقعاً ایجاد شده.

حمله حجمی چیست و چرا پهنای باند اهمیت دارد؟

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

شاید اسم‌هایی مثل UDP Flood یا DNS Amplification به گوشت خورده باشه. فعلاً لازم نیست روش ساخت این ترافیک رو بلد باشیم؛ موضوع اینه که بعضی روش‌ها داده زیادی رو به مسیر مقصد می‌رسونن و بعضی هم از پاسخ‌دهی سرویس‌های واسط سوءاستفاده می‌کنن. برای چنین فشاری، حفاظت نزدیک به مبدأ یا در شبکه بالادستی معمولاً مهم‌تر از نصب یک قانون روی وب‌سرور می‌شه.

حمله‌های پروتکلی چگونه روی تجهیزات شبکه فشار می‌آورند؟

در حمله‌های پروتکلی، گاهی تعداد بایت‌ها خیلی عجیب نیست، اما نحوه مدیریت اتصال تحت فشار قرار می‌گیره. مثال شناخته‌شده‌اش SYN Flood هست؛ جایی که فرایند برقراری اتصال TCP و منابعی که برای اون نگه داشته می‌شن اهمیت پیدا می‌کنن. از بیرون شاید فقط «اتصال برقرار نمی‌شه» ببینی، درحالی‌که مشکل دقیقاً با فشار روی یک مسیر سنگین PHP فرق داره.

با این حال هر اتصال نیمه‌کاره رو نشانه حمله ندون. شبکه ناپایدار، تنظیم اشتباه یا تغییر رفتار کلاینت هم ممکنه چنین نشونه‌ای بسازه. راه‌حل هم برای هر روتر و Load Balancer یکسان نیست. قبل از تغییر تنظیمات، باید بدونیم سیستم‌عامل و تجهیزات چطور اتصال‌ها رو مدیریت می‌کنن و چه مقدار ترافیک عادی دارن.

حمله لایه هفت چیست و چرا بعضی درخواست‌ها خیلی گران تمام می‌شوند؟

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

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

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

آیا DDoS همان هک سایت یا سرقت اطلاعات است؟

نه، حمله DDoS با سرقت اطلاعات یکی نیست. دیداس بیشتر می‌خواد امکان استفاده از سرویس رو مختل کنه؛ درحالی‌که خواندن دیتابیس، تغییر سفارش یا دزدیدن رمز به شکستن کنترل‌های متفاوتی مربوط می‌شه. ممکنه هم‌زمان چند حادثه داشته باشیم، اما از روی کند شدن سایت نمی‌شه حکم داد که اطلاعات کاربران لو رفته. این تفاوت رو توی بحث محرمانگی، یکپارچگی و دسترس‌پذیری هم می‌شه خوب دید.

برای مقایسه، توی درس SQL Injection دیدیم Query ناامن چه مشکلی می‌سازه و توی XSS درباره اجرای ناخواسته کد در مرورگر حرف زدیم. اما اینجا ممکنه هیچ ورودی‌ای به شکلی غیرمجاز خوانده نشده باشه و مسئله فقط قطع خدمات باشه. اینکه تفاوت این‌ها رو بلد باشی، کمک می‌کنه موقع یک حادثه دنبال شواهد درست بری.

پرونده آموزشی : چرا سایت رزرو کوره سفال‌گری ناگهان کند شد؟

بیا یک داستان بسازیم تا تحلیل رو با داده واقعی کاربران قاطی نکنیم. یک سامانه فرضی رزرو کوره سفال‌گری داریم که هر ماه ساعت هشت شب نوبت‌های جدیدش رو باز می‌کنه. صفحه معرفی کارگاه کش می‌شه، ولی استعلام ظرفیت و ثبت نهایی باید اطلاعات تازه رو از دیتابیس بگیرن. پس شلوغ شدن ساعت ۲۰:۰۰ از قبل قابل پیش‌بینیه؛ نکته مهم اینه که ببینیم سایت با این موج طبیعی چه رفتاری داره.

یک شب نرخ خطا ناگهان بالا می‌ره و مدیر می‌پرسه: «یعنی دیداس شدیم؟» هنوز زوده جواب بدیم. شاید مشتری‌های واقعی بیشتر از حد انتظار اومدن، شاید یک Query بعد از آخرین انتشار نسخه کند شده یا شاید ترافیکی غیرعادی روی API ظرفیت جمع شده. هر سه می‌تونن علامت شبیه هم بسازن. برای بررسی احتمال حمله DDoS باید داده‌های چند بخش رو کنار هم بذاریم.

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

ترافیک طبیعیِ زیاد چه فرقی با رفتار مشکوک دارد؟

به جدول نگاه کن. ساعت ۲۰:۰۰ تعداد درخواست‌ها از ۶۰ به ۴۲۰ در ثانیه رسیده، اما زمان پاسخ و خطا هنوز نسبتاً کنترل‌شده‌ست و نشست‌های متمایز هم بیشتر شدن. سه دقیقه بعد، RPS به ۱۸۵ رسیده ولی p95 تا ۲۶۰۰ میلی‌ثانیه بالا رفته، خطا ۲۸ درصد شده و دیتابیس ۹۶ درصد مصرف داره. اینجا باید مکث کنیم: چرا با درخواست کمتر، سیستم حال بدتری داره؟ یکی از فرضیه‌ها فشار عمدی به مسیر پرهزینه‌ست، نه نتیجه قطعی.

حتی با این جدول هم نمی‌تونیم بگیم حمله DDoS ثابت شده. ممکنه نشست‌ها درست ثبت نشده باشن، دیتابیس یک Query بد داشته باشه یا یک قفل طولانی عملیات رزرو رو کند کرده باشه. چیزی که داده‌ها واقعاً می‌گن اینه که «بازه ۲۰:۰۳ رو دقیق بررسی کن». فرق تحلیلگر خوب با کسی که از هر نمودار یک داستان هکری می‌سازه، همین احتیاطه.

مدل چهارپنجره‌ای بررسی اختلال : حجم، هزینه، الگو، نتیجه

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

پنجره اول : چند درخواست و چند بایت رسیده؟

در پنجره اول تعداد درخواست در ثانیه یا RPS رو می‌بینیم. برای فشارهای شبکه‌ای هم تعداد بسته در ثانیه یا PPS و حجم داده در ثانیه مهمن. اما حواست باشه ممکنه CDN بخش بزرگی از درخواست‌ها رو همون لبه پاسخ داده باشه و اصلاً چیزی به سرور اصلی نرسیده باشه. پس متریک Edge و Origin رو جدا بخون؛ یک عدد در یک داشبورد قرار نیست کل مسیر رو توصیف کنه.

پنجره دوم : هر درخواست چقدر منابع مصرف می‌کند؟

در پنجره دوم می‌پرسیم هر درخواست واقعاً چه کاری انجام می‌ده. چند Worker درگیره؟ Queryها چقدر طول می‌کشن؟ صف پردازش چند کار عقب افتاده؟ شاید لازم باشه یک مسیر بدطراحی‌شده رو اصلاح کنیم، نه اینکه صرفاً CPU بیشتری بخریم. فشار روی دیتابیس می‌تونه با RPS متوسط هم خیلی جدی باشه.

پنجره سوم : الگوی مراجعه طبیعی است یا غیرعادی؟

پنجره سوم کمک می‌کنه رفتار کاربران رو بفهمیم. آیا درخواست‌ها فقط به یک endpoint می‌رن؟ ثبت رزرو موفق هم داریم یا صرفاً صفحه بارها باز می‌شه؟ آیا ساعت شلوغی با تبلیغ یا شروع فروش هماهنگه؟ این نشونه‌ها به درد بررسی حمله DDoS می‌خورن، ولی کامل نیستن؛ کاربران پشت NAT مشترک و اپ‌هایی که کوکی ندارن ممکنه الگوهای عجیب بسازن.

پنجره چهارم : کاربر سالم واقعاً چه تجربه‌ای داشته؟

آخرین پنجره شاید از همه کاربردی‌تر باشه: کاربر هنوز می‌تونه کارش رو تموم کنه؟ ممکنه CPU سبز باشه ولی ثبت رزرو یا پرداخت خطا بده. از اون طرف، افزایش پاسخ ۴۲۹ شاید نشون بده محدودسازی درخواست فعال شده، نه اینکه سایت کاملاً از کار افتاده. p95، خطاها و درصد عملیات موفق رو با هم بخون تا بفهمی اختلال واقعاً چقدر به کاربران ضربه زده.

چه شاخص‌هایی برای تشخیص حمله DDoS ارزش بیشتری دارند؟

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

آزمایش Python : تحلیل رویداد بدون ارسال حتی یک بسته

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

import math

rows = [
    {"time": "19:55", "rps": 60, "p95_ms": 220, "errors_pct": 0.4, "db_pct": 25},
    {"time": "20:00", "rps": 420, "p95_ms": 390, "errors_pct": 0.8, "db_pct": 40},
    {"time": "20:03", "rps": 185, "p95_ms": 2600, "errors_pct": 28.0, "db_pct": 96},
]


def assess(row):
    if not isinstance(row, dict):
        raise TypeError("Each row must be a dictionary")
    time = row.get("time")
    if not isinstance(time, str) or len(time) != 5 or time[2] != ":":
        raise ValueError("Invalid HH:MM time")
    hh, mm = time[:2], time[3:]
    if not (hh.isascii() and mm.isascii() and hh.isdigit() and mm.isdigit()):
        raise ValueError("Invalid HH:MM time")
    if not (0 <= int(hh) <= 23 and 0 <= int(mm) <= 59):
        raise ValueError("Invalid HH:MM time")

    limits = {"rps": None, "p95_ms": None, "errors_pct": 100, "db_pct": 100}
    for key, maximum in limits.items():
        value = row.get(key)
        if type(value) not in (int, float) or not math.isfinite(value):
            raise ValueError(f"Invalid {key}")
        if value < 0 or (maximum is not None and value > maximum):
            raise ValueError(f"Out of range: {key}")

    signals = []
    if row["p95_ms"] > 1200:
        signals.append("slow-response")
    if row["errors_pct"] > 5:
        signals.append("server-errors")
    if row["db_pct"] > 85:
        signals.append("database-pressure")
    if row["rps"] > 300:
        signals.append("traffic-spike")
    status = "REVIEW" if len(signals) >= 2 else "NO-CONCLUSION"
    return status, signals


for row in rows:
    status, signals = assess(row)
    print(f'{row["time"]} | {status} | {", ".join(signals) or "no-threshold-crossed"}')

19:55 | NO-CONCLUSION | no-threshold-crossed
20:00 | NO-CONCLUSION | traffic-spike
20:03 | REVIEW | slow-response, server-errors, database-pressure

خروجی برنامه یک نکته جالب داره: ساعت ۲۰:۰۰ فقط «افزایش ترافیک» تشخیص داده می‌شه و هنوز مدرکی برای نتیجه‌گیری وجود نداره. اما ساعت ۲۰:۰۳ سه علامت هم‌زمان داریم؛ کندی شدید، خطای زیاد و فشار دیتابیس. این وضعیت ارزش بررسی بیشتری داره، ولی چاپ شدن REVIEW به معنی کشف حمله DDoS نیست. ما فقط یک ابزار کمک‌تصمیم ساخته‌ایم.

برای تمرین، در رکورد ۲۰:۰۰ مقدار RPS رو کم کن و p95 رو از آستانه بالاتر ببر. ببین علامت‌ها چطور تغییر می‌کنن و با چه ترکیبی برچسب REVIEW ظاهر می‌شه. بعد از خودت بپرس: اگه این موج از تبلیغ واقعی اومده باشه، مسدود کردن کاربران بر اساس همین چند عدد چه خسارتی می‌زنه؟ جواب مشخصه؛ تا وقتی لاگ و زمینه رو بررسی نکردیم نباید از این کد برای مسدودسازی استفاده کنیم.

از روی لاگ چطور بفهمیم مشکل از کدام مسیر است؟

برای بررسی لاگ لازم نیست اطلاعات شخصی همه کاربران رو جمع کنیم. خیلی وقت‌ها یک گزارش تجمیعی از تعداد درخواست‌های هر مسیر، زمان پاسخ، درصد خطا و تفاوت Edge با Origin کمک بیشتری می‌کنه. مثلاً اگه صفحه معرفی کارگاه سالمه ولی API ظرفیت کند شده، اول سراغ Queryها و کارهای همون مسیر برو. اگه از بیرون همه سرویس‌ها کندن و Origin فشار زیادی نداره، شبکه بالادستی هم باید بررسی بشه.

حواست به داده‌های حساس داخل لاگ باشه. URL، هدر و بدنه درخواست می‌تونن توکن ورود، اطلاعات خرید یا جزئیات کاربران رو لو بدن. برای بررسی حمله DDoS معمولاً آمار تجمیعی و شناسه‌های کم‌خطر کافی‌ترن. اگر لاگ جزئی لازمه، باید دسترسی محدود، مدت نگهداری مشخص و روش حذف یا پوشاندن اطلاعات حساس داشته باشه.

اگر سایت همین حالا زیر فشار است، از کجا شروع کنیم؟

اگه سایت همین الان از دسترس خارج شده، وسوسه می‌شی چند قانون فایروال و تنظیم کش رو یک‌جا عوض کنی. این کار رو نکن؛ چون بعدش حتی نمی‌فهمی کدوم تغییر کمک کرده. اول زمان شروع اختلال، سرویس‌های درگیر و خطاهای قابل مشاهده رو ثبت کن. بعد وضعیت هاست، CDN، شبکه، دیتابیس و صف‌ها رو کنار هم بذار. اگر سرویس ضد DDoS داری، لاگ و اقدام‌های مقابله رو هم از داشبوردش بگیر.

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

وقتی فشار از لایه شبکه میاد، سریع با میزبان یا ارائه‌دهنده حفاظت بالادستی هماهنگ شو؛ فایروال روی خود سرور نمی‌تونه لینکی رو که قبل از رسیدن ترافیک بهش پر شده نجات بده. اگر مشکل روی HTTP و API متمرکزه، قانون‌های WAF و مصرف منابع برنامه رو کنار هم ببین. هر تغییر رو با ساعت و نتیجه ثبت کن تا بشه فهمید چه چیزی بهتر شد، چه چیزی نشد و چرا.

چه اقداماتی واقعاً به جلوگیری از حمله DDoS کمک می‌کنند؟

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

لایه اول : حفاظت بالادستی و ظرفیت ارتباط

اول از شبکه شروع کنیم. اگر لینک پر شده، ترافیک مخرب باید قبل از رسیدن به گلوگاه فیلتر یا توزیع بشه. بعضی سرویس‌های ضد DDoS و معماری‌های Anycast برای همین شرایط ساخته شدن. اما دقت کن سرویس CDN وب لزوماً همه پورت‌ها یا دسترسی مستقیم به IP اصلی سرور رو محافظت نمی‌کنه؛ باید پوشش واقعی قراردادت رو بررسی کنی، نه فقط نام محصول رو.

لایه دوم : کش و کاهش کار تکراری

بعد نوبت کم کردن کارهای تکراریه. صفحات عمومی و کم‌تغییر رو می‌شه از کش پاسخ داد تا درخواست‌ها مدام PHP و دیتابیس رو بیدار نکنن. ولی سبد خرید، پرداخت، حساب کاربری و محتوای وابسته به نشست داستان دیگه‌ای دارن. کش عمومیِ اشتباه روی این بخش‌ها نه‌تنها مشکل کارایی رو حل نمی‌کنه، بلکه ممکنه داده خصوصی رو به نفر اشتباه نشون بده. این موضوع در مستندات رسمی کش ووکامرس هم تأکید شده.

لایه سوم : Rate Limiting و کنترل هزینه درخواست

محدودسازی نرخ یا Rate Limiting برای مسیرهایی مثل ورود و جست‌وجو مفیده، ولی اگر هر IP رو یک نفر فرض کنیم، ممکنه به کاربران واقعی آسیب بزنیم. مثلاً چند دانشجو در یک خوابگاه می‌تونن از یک IP مشترک وارد سایت بشن. پس قانون خوب باید به نوع درخواست، وضعیت احراز هویت، حجم معمول ترافیک و ظرفیت مسیر وابسته باشه؛ نه به یک عدد کپی‌شده از اینترنت.

لایه چهارم : برنامه، دیتابیس و صف‌ها

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

آیا CDN، WAF و Rate Limiting یک چیز هستند؟

نه، این سه تا یکی نیستن. CDN معمولاً محتوا رو از نقاط نزدیک‌تر تحویل می‌ده و فشار Origin رو کم می‌کنه؛ بعضی CDNها خدمات ضد DDoS هم دارن. WAF رفتار درخواست‌های HTTP/S رو با قواعد امنیتی می‌سنجه. Rate Limiting هم تعداد یا نرخ درخواست‌ها رو در یک بازه کنترل می‌کنه. ممکنه هر سه با هم استفاده بشن، اما هیچ‌کدوم جانشین کامل دیگری نیست.

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

Rate Limiting چه زمانی به کاربران واقعی آسیب می‌زند؟

تصور کن در ساعت باز شدن ثبت‌نام، دویست دانشجوی واقعی از اینترنت مشترک دانشگاه میان. اگر قانونت بگه از هر IP فقط چند درخواست مجازه، احتمالاً بیشتر این آدم‌ها رو با خطای ۴۲۹ رد می‌کنی. از نگاه داشبورد شاید تعداد درخواست کم شده باشه، ولی از نگاه دانشجو سایت خراب شده. پس موقع طراحی محدودیت باید اندازه بگیری چقدر ترافیک مخرب رو کم کردی و چند کاربر سالم رو هم ناخواسته متوقف کردی.

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

تفاوت حمله DDoS با ترافیک کمپین تبلیغاتی و خطای سایت

حالا سه سناریو رو کنار هم بذار. در اولی یک ویدیو وایرال شده و بازدید بالا رفته. در دومی نسخه جدید برنامه یک Query رو کند کرده. در سومی فشار غیرعادی از منابع مختلف روی یک مسیر سنگین جمع شده. هر سه می‌تونن خطای ۵۰۳ و کندی بسازن. برای تشخیص حمله DDoS باید تغییرات برنامه، زمان کمپین، توزیع درخواست‌ها و مصرف واقعی منابع رو با هم ببینی.

اگه افت سرعت درست بعد از Deploy شروع شده، اول احتمال مشکل نرم‌افزاری رو بررسی کن. اگه هم‌زمان با فروش ویژه کاربران واقعی وارد شدن و خریدهای موفق بیشتر شدن، شلوغی سالم یک توضیح محتمله. اما اگه درخواست‌های تکراری و نامتناسب به یک endpoint پرهزینه می‌رن، فرضیه سوءاستفاده جدی‌تر می‌شه. بازم می‌گم «فرضیه»؛ چون نشونه‌ها به‌تنهایی برای متهم کردن کسی کافی نیستن.

هک سایت با DDoS چه فرقی با Brute Force، ربات و خزنده گوگل دارد؟

هر ترافیک خودکاری حمله نیست. خزنده‌ها صفحه‌ها رو برای فهرست‌کردن می‌خونن، بات‌های مجاز می‌تونن کار مفید انجام بدن، Brute Force معمولاً دنبال حدس اطلاعات ورود می‌ره و حمله DDoS روی دسترس‌پذیری فشار میاره. گاهی رفتارها شبیه هم می‌شن، ولی علت و دفاع مناسبشون فرق داره. به همین خاطر قبل از تعریف قانون امنیتی باید بدونیم کدوم مشکل رو داریم حل می‌کنیم.

مثلاً دیدن Googlebot داخل User-Agent ثابت نمی‌کنه درخواست واقعاً از طرف گوگله؛ این هدر می‌تونه جعل بشه. از طرف دیگه، ربات قانونی هم ممکنه در یک بازه مصرف منابع زیادی داشته باشه و نیاز به مدیریت نرخ داشته باشه. تصمیم درست بر اساس هویت قابل بررسی، رفتار و سیاست خود سایته، نه فقط اسم کاربر یا ظاهر یک هدر.

اگر سایت وردپرسی یا ووکامرسی باشد، کجا را باید بررسی کنیم؟

روی سایت‌های وردپرسی و ووکامرسی این بحث خیلی ملموسه. یک صفحه محصول عمومی ممکنه از کش پاسخ داده بشه، اما سبد خرید، Checkout و صفحه حساب کاربری به نشست و اطلاعات شخصی وابسته‌ان. اگه برای جلوگیری از حمله DDoS همه این مسیرها رو یکسان کش یا محدود کنی، ممکنه صفحه اصلی سریع بمونه ولی خرید و ورود خراب بشه. پس پایش و دفاع این بخش‌ها باید جدا طراحی بشه.

درخواست‌هایی به مسیرهای wp-admin/admin-ajax.php، wp-json یا endpointهای خرید الزاماً مخرب نیستن؛ افزونه‌ها و کدهای معمول وردپرس هم ازشون استفاده می‌کنن. اما بعضی عملیات ممکنه پرهزینه باشن. برای هر مسیر نرخ طبیعی، زمان پاسخ، خطا و اثر روی کاربر رو اندازه بگیر و قبل از اجرای قانون گسترده، اون رو در محیط آزمون یا به‌شکل محدود بسنج.

برای یک سایت آموزشی، اختلال فقط یک نمودار قرمز نیست. شاید دانشجو وسط تماشای درس دسترسیش قطع بشه، شاید نتونه وارد حسابش بشه یا درست آخر پرداخت به خطا بخوره. بنابراین در گزارش حمله DDoS یا هر اختلال احتمالی، علاوه بر CPU و RPS باید ثبت کنی کدوم کار اصلی کاربر آسیب دیده. این اطلاعات به انتخاب اولویت بازیابی کمک می‌کنه.

آیا HTTPS، VPN یا قوی بودن رمز مدیر جلوی DDoS را می‌گیرد؟

رمز مدیر قوی، HTTPS معتبر و حتی VPN مهمن، اما مسئله یکسانی رو حل نمی‌کنن. HTTPS از داده در مسیر محافظت می‌کنه، نه از ظرفیت محدود دیتابیس. احراز هویت دومرحله‌ای دسترسی غیرمجاز به حساب رو سخت‌تر می‌کنه، نه اینکه همه حملات DDoS رو متوقف کنه. VPN هم ظرفیت سرور مقصد رو نامحدود نمی‌کنه. برای دسترس‌پذیری باید جداگانه برنامه داشته باشیم.

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

چند اشتباه خطرناک هنگام مقابله با دیداس

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

اشتباه‌های مهم دیگه هم داریم: پخش کردن لاگ خام و اطلاعات کاربران در گروه‌ها، انجام تست فشار بدون هماهنگی روی سرور عملیاتی و اعتماد به این جمله که «سرورمون قویه، پس DDoS نمی‌خوریم». فشار ممکنه قبل از سرور، روی شبکه یا روی یک API ناکارآمد ایجاد بشه. ابزار و سخت‌افزار خوب کمک می‌کنن، ولی جای تحلیل و طراحی دفاع رو نمی‌گیرن.

برای آمادگی قبل از حادثه چه چک‌لیستی داشته باشیم؟

بهتره قبل از اینکه روز بحرانی برسه چند چیز روشن باشه: چه کسی به پشتیبانی میزبان زنگ می‌زنه، چه کسی دسترسی داشبورد حفاظتی داره، مقدار طبیعی ترافیک چقدره و کدوم بخش‌ها مثل ورود و پرداخت اولویت بالاتری دارن. یک راه اطلاع‌رسانی بیرون از خود سایت هم لازم داری؛ چون اگه سایت خوابید، نمی‌تونی فقط از همون صفحه به کاربران توضیح بدی چه خبر شده.

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

سه تمرین برای اینکه فقط اسم حملات را حفظ نکنی

تمرین اول : حمله یا تبلیغ موفق؟

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

تمرین دوم : تعداد درخواست کمتر، آسیب بیشتر

تمرین دوم به همون ساعت ۲۰:۰۳ مربوطه؛ درخواست‌ها نسبت به ساعت ۲۰:۰۰ کمترن ولی خطا و فشار دیتابیس خیلی بیشتره. حالا فرض کن همون موقع نسخه جدید سایت هم منتشر شده. کدوم فرضیه قوی‌تره: حمله یا Query بد؟ بدون زمان Deploy، لاگ Queryهای کند، نمودار خطا و توزیع درخواست‌ها جواب قطعی نمی‌دیم. مهم اینه که شواهد لازم رو درست انتخاب کنی.

تمرین سوم : دفاعی که خودش اختلال می‌سازد

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

جمع‌بندی : از «سایت داون شد» تا تحلیل قابل دفاع

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

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

سؤالات متداول درباره حمله DDoS

منابع فنی برای مطالعه بیشتر

برای مطالعه دقیق‌تر، توضیح Cloudflare درباره انواع حملات DDoS و دفاع، راهنمای OWASP درباره محروم‌سازی از سرویس و مستندات فنی Cloudflare درباره تحلیل و مقابله رو ببین. بخش مربوط به کش سایت‌های فروشگاهی هم با راهنمای رسمی WooCommerce تطبیق داده شده. سناریوی سفال‌گری و عددهای تمرین، نمونه آموزشی ساختگی هستن و از یک حادثه واقعی برداشته نشدن.