مبحث یکم : مقدمه و تاریخچه
مبحث دوم: مراحل نفوذ کردن / جلوگیری از نفوذ
مبحث سوم: حملات شبکه ای
مبحث چهارم - کار عملی
مبحث پنجم - DHCP
مبحث ششم - وب و حملات مطرح در آن
مبحث هفتم - حملات DoS
مبحث هشتم - سیستم عامل
مبحث نهم - مهندسی اجتماعی
مبحث دهم - Vulnerability (آسیب پذیری)

(Slow) HTTP POST DoS

در حملات DoS که با ترافیک بالا انجام می شوند صرفاً کافی است تا ترافیک بالا را ایجاد کرد به گونه ای که این ترافیک از فیلترها رد شود و به مقصد برسد. در حال حاضر در وب تمام روترها و سوییچ ها جلوی broadcast را می گیرند.

ارتباطات تحت وب با استفاده از پروتکل های مختلف https،gopher، http و … انجام می شود.

پیام های HTTP به دو دسته تقسیم می شند:

  • از طرف مشتری به سرویس دهنده وب ارسال می شوند (HTTP Request).
  • از طرف سرویس دهنده وب به مشتری ارسال می شوند (HTTP Response).

نفوذگر یک proxy به صورت local  راه اندازی می کند مثل foxy proxy، paros. بدین ترتیب می تواند ترافیکی که در حال ارسال از سیستم خود به سرور است را تحلیل و در صورت نیاز آن را تغییر دهد که با تغییبر آن می‌تواند نفوذهایی را انجام دهد. در این ترافیک می توان پیام های HTTP Request و HTTP Response را دید.

تمرین: request for comment (RFC) 822 را در اینترنت پیدا کنید.

این استانداردها توسط  IETF(Internet Engineering Task Force) تدوین می شود و مورد تأیید قرار می گیرد و تحت عنوان RFC ارائه می شود. برنامه های مختلف با استفاده از این RFC ها (با مطابقت با این RFCها) ایجاد می شوند تا بتوانند در کل جهان مورد استفاده قرار بگیرند. برای مثال اگر شما خواستید یک وب سرور از Base بسازید اول باید RFC آن را بخوانید.

در این قالب قسمتی مخصوص قرارگیری یک سری اطلاعات کنترلی قرار دارد این اطلاعات کنترلی رفتار وب سرور و مشتری را مشخص می کند. به این اطلاعات کنترلی، Header گفته می شود (مثال این اطلاعات کنترلی User-Agent است که در آن نوع مرورگر کاربر تعیین می شود). بدین ترتیب وب سرور می فهمد مرورگر کاربر چه قابلیت هایی را دارد. Header هم در پیام Request و هم در پیام Response وجود دارد.

      شکل پیام HTTP

خط آغازین

سرآیند HTTP

بدنه اصلی پیام HTTP

(همان داده ای که قرار است رد وبدل می شود)

سایر اطلاعات

Request Line  یا Status Line

 

اطلاعات کنترلی موجود در Request و Response

HTTP Response Header   HTTP Request Header
     
Age   Accept
Cache-Control   Authorization
Content-Length   Content-Length
Set-Cookie   Max-Forward
.

.

.

  .

.

.

 

فیلد Content-Length در هر دو header وجود دارد. با توجه به اطلاعات قرار داده شده در سرآیندها، سرویس دهنده و مشتری در مورد نحوه ادامه ارتباط با یکدیگر تصمیم خواهند گرفت.

فیلد Content-Length مشخص کننده طول اطلاعاتی است که در بدنه اصلی پیام قرار می گیرد. در صورتی که طول این فیلد، بیشتر از طولی باشد که به عنوان حداکثر پیام در نظر گرفته شده، آن گاه گیرنده منتظر می ماند تا ادامه پیام در بسته های بعدی دریافت شود. در طول زمان انتظار، نشستی که برقرار شده، گیرنده پیام منتظر می ماند تا ادامه پیام در بسته های بعدی دریافت شود. در طول زمان انتظار نشستی که برقرار شده به صورت باز باقی خواهد ماند (حداکثر طول پیام را چیزی شبیه MTU – Maximum Transfer Unit در LAN در نظر بگیرید). دقت کنید که این روال پروتکل است.

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

این فاصله زمانی به چه چیزی مربوط می شود؟ ای مسأله با توجه به config وب سرور تعیین می شود. می توان برای جلوگیری از این مسأله در config وب سرور تعیین کرد که با توجه به این که قرار نیست کسی به سایت اطلاعات خیلی زیاد بفرستد پس time out نشست مثلاً 30 ثانیه قرار داده شود یا اگر درخواستی می خواهد بیشتر از 5M  ارسال کند جلوی آن گرفت شود.

حال نفوذگر با برقراری چند نسخه از این نوع نشست ها در نهایت قادر خواهد بود یک حمله DoS یا DDoS موفق را انجام دهد. یکی از مؤلفه های وب سرور تعیین می کند که چند session به طور همزمان وجود داشته باشد. حال اگر به سقف این تعداد برسد عملاً وب سرور دیگر نمی تواند session جدید باز کند. یعنی دیگر نمی تواند سرویس دهد. یکی از راه های جلوگیری از این حمله می تواند این باشد که ایجاد sessionهای همزمان توسط یک IP را محدود کنیم.

لازم به ذکر است از آنجایی که این مشکل به ساختار سرآیندهای HTTP مربوط می شود هیچ کدام از سازندگان برنامه های وب سرور مثل IIS، apache تا کنون وصله ای (patch) ارائه نکرده اند.

این مفهوم کلی حمله بود این مسأله را به قسمت های مختلف پروتکل بسط می دهند. این نوع حمله ممکن است به صورت ناقص گذاشتن سرآیند Get HTTP نیز صورت پذیرد. در این صورت سیستم مقصد همواره در انتظار اتمام سرآیند، باقی خواهد ماند  هر چند شرکت مایکروسافت در مقابله با این قضیه، زمان انتظار را در مورد فرآیند HTTP نیز به کار برده که ممکن است حمله ناکام بماند. اگر time out با عدد نادرستی set شود ممکن است کاربران نتوانند از این سیستم استفاده کنند. مثلاً در کشوری ممکن است سرعت اینترنت سرعت خوبی نباشد در نتیجه مجبوریم برای آن که کاربران بتوانند سایت را ببینند یک time out بالاتری قرار دهیم.

Content-headerدر سه جای کلی وجود دارد. در متود post که می خواهد data بفرستد. در متود Get که می خواهد data دریافت کند و در Header که تراکنش می خواهد ارسال شود.

برای مثال از local proxy ها می توان برای تغییر content – length استفاده کرد.

نفوذگر برای یافتن میزان session time out سرور می تواند مقادیر مختلف را آزمایش کند. مثلاً اگر5 ثانیه، 5 ثانیه بفرستد session، time out خواهد شد اما اگر 2ثانیه، 2 ثانیه بفرستد time out نمی شود.

حمله ارسال آهسته بسته های post پروتکل  HTTP از آن جایی که کاملاً شبیه به یک ارتباط کند می باشد به سختی توسط IDS ها و سایر سیستم های حفاظتی قابل تشخیص می باشد.

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

اسکادا Supervisory Control And Data Acquisition: به سامانه های کنترل و اندازه گیری در مقیاس بزرگ گفته می شود (ویکی پدیا)

دو ابزاری که در این زمینه استفاده می شود R-U-Dead-Yet و slowloris هستند که برای تست وب خودتان می توانید از آن ها استفاده کنید.

اسکرول به بالا