آمار حملات DDoS در سال ۱۳۹۴

با توجه به پایان سال ۱۳۹۴ تصمیم بر این گرفتیم که گزارش آمار حملات DDoS به شبکه های سنترال هاستینگ را طی سال گذشته منتشر کنیم.
طبق مقالات سایت های معتبر امنیتی بین المللی پیش بینی می شد که در شروع سال میلادی ۲۰۱۶ ( زمستان ۱۳۹۴) شاهد افزایش حملات DDoS خواهیم بود ؛ اما این سیر صعودی حملات بر روی وب سایت های فارسی زبان برای ما نیز کمی عجیب بود.

مطالب گذشته:
سال جدید با دنیای جدید هکر و انتظار افزایش جنگ های مجازی
افزایش حملات DDoS در ماه آخر میلادی
بازگشت جوخه مارمولک (Lizard Squad)
انجام حملات DDoS با سرویس های ابری

در زمستان ۹۴ رکورد بزرگترین حملات به سرور های سنترال هاستینگ از زمان فعالیت ثبت شد؛ بزرگترین حمله به حجم ۱۱۴گیگابیت بر ثانیه و حدود ۹٫۸۰۰٫۰۰۰ پکت در ثانیه رخ داد و حدود یک ساعت به طول انجامید.
این حمله به قدری بزرگ محسوب می شود که واقعا می توان آن را به عنوان یک رکود در بین سایت های ایرانی ثبت کرد. این حجم حمله حدود ۱/۳ پهنای باند کل کشور است!

log2016-1

علاوه بر حمله فوق؛ حملات زیادی نیز با حجم ها و pps های بالا رخ داد که ما مجبور به ارتقا DDoS Protection شبکه برای جلوگیری از این حملات شده ایم.

همچنین علاوه بر افزایش فدرت حملات؛ شاهد افزایش کمی حملات نیز بوده ایم؛ ما در سال ۱۳۹۴ بالغ بر ۱۰۰۰۰ حمله DDoS را شناسایی کرده ایم. تصویر زیر نشان دهنده تعداد حملات DDoS در سال ۱۳۹۴ بر روی سرویس های سنترال هاستینگ است.

Book1

 

نکته: آمار حملات لایه ۷ – HTTP در نمودار فوق حدودی می باشد و امکان ارائه آمار دقیق به دلیل مسایل فنی وجود نداشته ؛ این رقم یک حداقل است که بر اساس لاگ ها و شواهد به دست آمده است.

این حملات با شروع سال جدید میلادی در زمستان ۹۴ به اوج خود رسید که گمان می رود به دلیل در دسترس قرار گرفتن ابزار های جدید و بوتر های کارامد تر است؛ همچنین با توجه به افزایش قدرت حملات UDP  پیشبینی می شود یک باگ جدید در سرویس دهندگان اینترنت توسط هکر ها کشف شده باشد که هنوز پتچ نشده است.
در سال ۲۰۱۲ وجود باگ در DNS سرور های شرکت ها و ISP های بزرگ منجر به استفاده ابزاری از آن سرور ها برای حملات بزرگ DDoS  می شد؛ به طوری که رکود بزرگترین حملات در آن سال شکست و تقریبا هیچ راه حلی برای این حملات وجود نداشت اما گروهی تصمیم به ایجاد پروژه ای عظیم گرفتند و نام آن را Open Resolver Project گذاشتند که در قالب تاسیس سایتی شروع به فعالیت کرد؛( جهت نمایش سایت اینجا کلیک کنید).همانطور که مشخص است وظیفه این سایت شناسایی و معرفی  DNS resolvers های باز بود که مورد سو استفاده قرار می گرفتند؛به مرور زمان این سایت به هدف نهایی خود رسید؛ افراد و شرکت هایی که مسئول این سرور ها بودند توسط این سایت و گزارش های کاربران متوجه وجود باگ های خود شدند آنها را برطرف نمودند و بعد از مدتی به صورت چشم گیری این حملات کاهش یافت اما آیا امکان دارد یک باگ جدید دوباره امنیت اینترنت را به خطر بی اندازد؟ احتمال اینکه یک باگ جدید دوباره شبکه ها و سرور ها را تهدید کند همیشه وجود دارد.

در خصوص حملات HTTP Flood بیشتر بدانید

HTTP flood یکی از مخرب ترین حملات DDoS محسوب می شود که برای مهاجمان به راحتی در دسترس است؛ HTTP Flood یک حمله در سطح لایه کاربردی (نرم افزاری – لایه ۷ مدل OSI ) است و ساختن بات نت های گسترده برای این نوع حمله برای هکرها بسیار آسان و جلوگیری از آن بسیار دشوار است.

سرورهایی که میزبان وب سایت ها هستند از وب سرور هایی همچون آپاچی؛ Nginx یا لایت اسپید استفاده می کنند. معمولا قدرت سرور نیز متناسب با نیاز  و مصرف انتخاب می شود و هر سرور می تواند در حد و توان خودش به صورت همزمان به یک تعداد حدودی از کاربران سرویس دهد ( مثلا ۱۰۰۰ کاربر همزمان) که البته این مورد بستگی به میزان مصرف منابع در هر بازدید یا ارائه سرویس نیز دارد.

زمانی که یک کاربر از یک وب سایت بازدید می کند یک ارتباط TCP میان کاربر و سرور برقرار می شود.
اول کلاینت یک بسته SYN به سرور می فرستد
دوم سرور یک بسته SYN ACK به کلاینت  می فرستد
سوم کلاینت یک بسته ACK به سرور می فرستد

HTTP Flood

HTTP Flood

زمانی که این اتفاق می افتد یک ارتباط باز بین سرور و کلاینت برای انتقال اطلاعات به وجود می آید و پکت های TCP بین آنها منتقل می شود که مرورگر این پکت های TCP را ترجمه کرده و محتوای یک .ب سایت را به شما نشان می دهد؛ دقیقا مثل همین صفحه ای که در حال خواندن آن هستید.
حملات HTTP flood شامل باز کردن یک اتصال TCP معتبر در سرور و اقدام به ارسال تعدادی رکوئست به سرور است؛ مثل دانلود هر چیزی که در یک صفحه وب هست یا درگیر کردن بخشی از سایت برای ایجاد پرس و جوی بیش از اندازه در دیتابیس و …
یک مثال از حملات HTTP flood که به صورت GET ارسال می شوند شبیه به زیر است :
T 198.19.0.2:42728 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .
T 198.19.0.2:40962 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .
T 198.19.0.2:51486 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .
T 198.19.0.2:55300 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .
T 198.19.0.2:56396 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .

ادامه مطلب

WAF چیست؟

در حال حاضر بیش از ۷۰ درصد حملات اینترنتی از طریق بستر وب صورت می‌گیرد، برنامه‌های کاربردی تحت وب به عنوان بزرگترین هدف مهاجمین جهت نفوذ به زیرساختهای اطلاعاتی سازمان‌ها تبدیل شده‌اند. با توجه به رشد روزافزون حملات تحت وب و عدم کارایی سیستم‌های تشخیص و جلوگیری از نفوذ محصول جدیدی در عرصه امنیت اطلاعات و ارتباطات با عنوان «فایروال برنامه‌های کاربردی تحت وب» (Web Application Firewall)  به منظور مقابله با این حملات توسعه یافته است.

web application firewall(WAF)یک نرم افزار؛سخت افزار و یا مجموعه ای از قوانین پیاده سازی شده بر روی پروتکل ارتباطی HTTP می باشد. به طور کلی این قوانین جهت جلوگیری از حملات معمول هکر ها به وب سایت ها مثل cross-site scripting (XSS)و یا SQL injection و … می باشد.

با ایجاد چنین قوانینی بر ارتباطات HTTP می توان بسیاری از حملات هکرها را تشخص و مهار کرد و ترافیک را اعتبارسنجی کرد؛ نقش WAF در جلوگیری از حملات Zero Day ( ناشناخته و پتچ نشده) بر روی اسکریپت های تحت وب غیر قابل انکار است!

WAF را به شکلهای مختلف میتوان به اجرا درآورد؛ نوع اول به صورت یک ماژول قابل اضافه شدن به برنامه های موجود در Application Server است، نوع دوم به عنوان یک برنامه مجزا بر روی Application Server اجرا میشود و در نوع سوم به عنوان یک سیستم مستقل بر روی سخت افزار مجزا از سامانه اینترنتی نصب و راه اندازی میشود.

ادامه مطلب

کلودفلر (CloudFlare) واقعا یک آنتی دیداس است؟

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

اما همانطور که در سایت کلودفلر هم می بینید و یا احتمالا شنیده اید؛ کلودفلر (CloudFlare) به عنوان یک سرویس آنتی دیداس نیز شناخته شده است و جالب تر این است که این سرویس به صورت رایگان نیز ارائه می شود! اما چگونه ممکن است در زمانی که شرکت های بزرگی همچون incapsula, blacklotus, prolexic, arbornetworks, staminus و …. سرویس های دیداس پروتکشن (آنتی دیداس)  خود را با قیمت های چند هزار دلاری ارائه می دهند؛ کلودفلر (CloudFlare)  این سرویس را به صورت رایگان ارائه دهد؟

در مرحله اول باید بدانیم یک حمله DDoS دقیقا چیست؟

حقیقت ماجرا این است که کلودفلر (CloudFlare) ممکن است در بعضی مواقع جلوی حملات DDoS – دیداس را بگیرد اما در واقع نحوه عملکرد آن را شبیه هیچ یکی از سرویس های آنتی دیداس شرکت های بالا نیست و اگر قرار باشد یک تعریف کلی از یک سرویس آنتی دیداس با توجه به مجموعه سرویس های شرکت های بزرگ در این زمینه داشته باشیم کلودفلر در پلن های رایگان و حتی ۲۰۰دلاری خود هیچ سرویس آنتی دیداسی ارائه نمی دهد!

کلود فلر یک سرویس برای میزبانی شما نیست؛یعنی شما نمی توانید یک سرور از کلودفلر بخرید و سرویس خود را راه اندازی کنید! شما فقط این امکان را دارید تا از نیم سرور های کلودفلر برای تغییرIP  رکورد A به سرور های آنها استفاده نمایید و این سرویس به نوعی یک رابط بین سرور شما و کاربرانتان فقط بر روی پورت ۸۰ و ۴۴۳ خواهد بود.

در حقیقت IP سرور شما مخفی می شود( که با محافظت شدن تفاوت دارد) در این روش اگر هکر (شخصی که قصد انجام حملات دیداس بر روی سرور شما را دارد) اگر بتواند به هر دلیلی IP سرور اصلی شما را به دست بیاورد می تواند به حملات خود بدون مشکل ادامه دهد چون مخفی کردن یک آی پی به این راحتی هم نیست!

مورد بعدی محدودیتی است که برای شما پیش می آید؛ اگر قصد داشته باشید به هر دلیلی از پورت های دیگر سرور برای سرویس های خود استفاده نمایید کلودفلر هیچ کنترلی بر روی آن نخواهد داشت و به راحتی می تواند باعث لو رفتن IP و انجام حملات شود یعنی در حقیقت سرویس هایتان مبتنی بر دامین است و هیچ سرویس مبتنی بر IP نخواهید توانست ارائه دهید.
این موارد در خصوص حملات لایه ۴ و ۳ شبکه می باشد ؛ اما در خصوص حملات لایه۷ که ترافیک شما بر خلاف سرویس های مبتنی بر IP ؛ از طریق دامین انجام می شود و به عبارتی از سرویس رابطه ای کلودفلر (CloudFlare) استفاده می کند به چه صورت است؟ ترافیک به صورت Real Time آنالیز و بررسی می شوند و حملات مهار می شوند؟ خیر !

حقیقت این است در سرویس های رایگان که هیچ، حتی در سرویس ۲۰۰ دلاری ماهیانه کلودفلر نیز حملات لایه ۷ بلاک و مهار نمی شوند و مستقیم بدون هیچ پروسس و هیچ فایروالی به سرورتان می رسند و می توانند برایتان به راحتی مشکل ساز شوند!

اما در عوض کلودفلر سیستم Under Attack را در اختیار کاربران می گذارد که در این روش در هنگام باز شدن سایت یک لودینگ ۵ ثانیه ای به نمایش در می آید و سپس کاربر به سایت اصلی شما هدایت می شود!  ممکن است افرادی مایل نباشند در اول سایتشان چنین لودینگی ظاهر شود یا به دلایل تکنیکی و سئو و…. وجود یک لودینگ اجباری در اول سایت جالب نباشد. اما اگر این روش یک راه حل صد در صد برای جلوگیری از حملات باشد شاید نتوان از آن چشم پوشی کرد! بیایید ببینیم در این لودینگ چه اتفاقی می افتد؟

اگر در سورس این لودینگ دقت کنید  یک form جهت پاس کردن یکسری مقادیر مشاهده می کنید:

مقادیر این فرم توسط یک پروسس جاوا اسکریپتی تکمیل می گردند:

CloudFlare solver script

و زمان پست می توانید مقادیر ارسالی را در هیدر ببینید:

CloudFlare DDoS challenge-response

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

پس در این پروسس ساده باید دو عامل جاوا اسکریپت و کوکی فعال باشد که در همه مرورگر ها فعال است اما بات نت ها این امکان را نداشتند( البته در زمان قدیم تر) یعنی اکثر بات نت ها با ارسال دستورات GET یا POST  سعی در حملات لایه ۷ داشتند که امکان پاس کردن این لودینگ و رفتن به سایت هدف را نداشتند و در حقیقت هیچ پروسس پیشرفته ای برای شناسایی حملات در کار نیست! هر کس جاوا را پاس کرد به راحتی وارد سایت می شود و پاس نکرد در پشت لودینگ می ماند.

اما در حال حاضر به راحتی امکان پاس کردن این مرحله و ورود به سایت توسط روبات ها و بات نت ها امکان پذیر است.ویروس in32/DoS.OutFlare.A یکی از مدرن ترین برنامه هایی است که برای بایپس کردن این پروسس کلود فلر استفاده شده است.

cloudflare-scrape نیز  برنامه ای است که به زبان Python نشوته شده است که با استفاده از Node.js می تواند به راحتی کلود فلر را بایپس کند ( دور بزند ).

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

حملات گسترده DDoS به واسطه جوملا

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

در سال ۲۰۱۲ یک حمله سازمان بافته بزرگ DDoS به بانک های آمریکایی آغاز شد؛ این گروه خود را “Izz ad-Din al-Qassam Cyber Fighters” نامید و عملیات گسترده دیداس خود را عملیات”ابابیل” نامید و این عملیات در جواب نمایش تریلر فیلم بحث برانگیزی در خصوص حضرت محمد(ص) بود.

این حملات بین ۶۰ تا ۱۰۰ گیگابیت در ثانیه انجام شد که باعث ضرر های سنگین مالی و افت سهام بعضی بانک ها شد.

برای راه اندازی چنین حمله سنگینی هکر ها ار یک شبکه بات گستره استفاده کردند اما چیزی که مشخص بود تفاوت این حمله و نوع بات آن با بات های دیگر و قدیمی بود؛در این نوع حمله از یک سرور اصلی به عنوان مرکز کنترل استفاده شد که “itsoknoproblembro” نام گرفت.

این سرور ابزار های مورد نیاز انجام حمله را از طریق باگ های PHP در سرور های مختلف دنیا قرار می داد؛ بدین صورت سرور ها بدون اینکه صاحبان آنها متوجه شوند به عنوان ابزار های قوی( بسیار قوی تر از بات نت پی سی های خانگی) دیداس مورد استفاده قرار می گرفتند که به سرور های نفوذ شده brobot می گفتند.

ادامه مطلب

کدهای وضعیت HTTP و معنی خطاهای سرور

هنگامی که در بستر پروتکل HTTP یا (Hypertext Transfer Protocol) در وب در حال گشت و گذار و مرور صفحات مختلف هستیم، با هر آدرس url ای که از طریق مرورگر خود از سرور سایت ها ی  مختلف درخواست می کنیم، کدهایی در پس زمینه بین واسط کاربری ما (مرورگر) و سرور رد و بدل می شوند که به آنها در اصطلاح کدهای وضعیت HTTP یا (HTTP response status codes) می گویند، این کدها توسط کنسرسیوم ها و بنیاد های جهانی استاندارد سازی وب از جمله IETF یا (Internet Engineering Task Force) و W3C یا (World Wide Web Consortium) تعریف و سازمان دهی شده اند و امروزه تقریبا سرور یا مرورگری وجود ندارد که از اصول آنها پیروی نکند،  کدهای وضعیت  HTTP چه به لحاظ فنی و چه به لحاظ کاربری، کاربردهای فراوانی دارند و لذا آشنایی با جزئیات و مفاهیم آنها می تواند به میزان زیادی به توسعه دانش و اطلاعات عمومی وب، کمک کند.

کدهای وضعیت HTTP را چگونه بررسی کنیم؟

http header

http header

برای مشاهده کدهای وضعیت HTTP، می توانید از قابلیت های مرورگرها (مخصوصا مرورگرهای جدید) برای توسعه دهندگان وب (web developers) استفاده کنید، معمولا در مرورگرهایی مثل فایر فاکس، گوگل کروم، اپرا و… قسمتی تحت عنوان ابزارهای توسعه دهندگان (developers tools) یا عناوینی شبیه آن وجود دارد که تمام فعل و انفعالات واسط کاربری (user agent) و سرور را نشان می دهد.

تفاوت HTTP 1/0 و HTTP 1/1

قبل از اینکه به بررسی کدهای وضعیت HTTP بپردازیم، بد نیست اشاره ای داشته باشیم به نسخه های مختلف آن، اعدادی که در مقابل تیتر بالا مشاهده می کنید (۱/۰ و ۱/۱) در واقع نسخه های مختلف پروتکل HTTP هستند که توسط گروه HTTP-WG که خود زیر مجموعه IETF یا (Internet Engineering Task Force) است، توسعه یافته، HTTP 1/0 نسخه ابتدایی و قدیمی این پروتکل است که در ابتدا مورد استفاده قرار می گرفت و به دلیل نقایص و نقاط ضعفی که وجود داشت، به تدریج توسعه داده شد و استاندارد HTTP 1/1 شکل گرفت، در بستر نسخه جدید پروتکل HTTP کدهای وضعیت بیشتری تعریف شده و امروزه بیشتر سرور ها و مرورگرها از آن استفاده می کنند.

کدهای سری ۱۰۰، مربوط به اطلاعات (Informational)

اولین سری از کدهای HTTP، با عدد ۱۰۰ شروع می شود که در مورد نقل و انتقال بسته های اطلاعات مثل ارسال و دریافت فایل، کاربرد دارند و حالت موقت پاسخ سرور را نشان می دهند، به فرض وقتی از متد POST در فرم های وب استفاده می کنیم، دریافت کد ۱۰۰ به معنی این است که سرور درخواست ما را پذیرفته و فرایند پردازش اطلاعات ادامه دارد، االبته بدون ارسال کد ۱۰۰ نیز این فرایند ادامه می یابد لذا ارسال آن از طرف سرور ضروری نیست و حتی در مرورگرهایی که از نسخه HTTP/1.0 استفاده می کنند، این کد قابل فهم و پردازش نیست.

کد ۱۰۰، ادامه ارسال (Continue)

کد ۱۰۰ به معنی این است که سرور درخواست مرورگر را دریافت کرده است و مرورگر می تواند ادامه اطلاعات را ارسال نماید، این کد مخصوصا در مواقعی که حجم زیادی از داده ها به فرض از طریق فرم های وب و متد POST ارسال می شود، کاربرد دارد و مرورگر با ارسال هدر Expect: 100-continue وضعیت سرور را جهت آمادگی ادامه ارسال اطلاعات بررسی می کند، اگر در جواب کد ۱۰۰ را دریافت کند، ادامه اطلاعات را ارسال می کند، در غیر این صورت کد ۴۱۷ Expectation Failed دریافت می شود.

کد ۱۰۱، تعویض پروتکل ها (Switching Protocols)

کد ۱۰۱ به معنی درخواست مرورگر از سرور جهت تعویض پروتکل نقل و انتقال داده است، در صورتی که سرور این تعویض پروتکل را مفید یا ضروری ارزیابی کند، از درخواست مرورگر پیروی خواهد کرد، به فرض تعویض پروتکل HTTP 1/0 به نسخه HTTP 1/1 می تواند مفید باشد، یا استفاده از پروتکل های real-time و همزمان (synchronous) نیز به همین صورت است، مثلا در برنامه هایی که از آژاکس (Ajax) استفاده می کنند، این کد می تواند کاربرد داشته باشد.

کد ۱۰۲، در حال پردازش (Processing)

از آنجایی که درخواست های مرورگر از سرور ممکن است شامل انجام کارهای مختلفی باشد که هر کدام نیاز به پردازش جداگانه دارند، سرور با ارسال کد ۱۰۲ به مرورگر می گوید که عملیات درخواستی، دریافت شده و در حال پردازش است، به این صورت مرورگر در انتظار پاسخ کامل سرور بوده و  از قطع ارتباط به دلیل به پایان رسیدن حداکثر زمان (time out)، جلوگیری می شود.

کدهای سری ۲۰۰، درخواست موفق (Success)

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

کد ۲۰۰، پاسخ موفق (OK)

کد استاندارد HTTP در وب، با عدد ۲۰۰ نشان داده می شود، دریافت پاسخ ۲۰۰ از سرور به این معنی است که آدرس درخواستی (در متد GET) یا عملیات مورد نظر (در متد POST) به طور کامل و موفقیت آمیز توسط سرور انجام شده است، در یک ارتباط بدون نقص بین واسط کاربری (user agent) و سرور، کدهای سری ۲۰۰ باید دریافت شوند.

کد ۲۰۱، ساخته شده (Created)

کد HTTP 201 به معنی دریافت موفقیت آمیز درخواست و ساخته شدن یک منبع جدید در سرور است (به فرض ایجاد یک فایل یا صفحه جدید)، ارسال کد ۲۰۱ تنها در صورتی صحیح است که سرور منبع جدید را ساخته باشد، در غیر اینصورت (اگر منبع هنوز ساخته نشده باشد) باید کد ۲۰۲ را ارسال کند.

کد ۲۰۲، موافقت شده (Accepted)

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

کد ۲۰۳، اطلاعات غیر معتبر (Non-Authoritative Information)

کد ۲۰۳ که از ورژن HTTP 1/1 تعریف شده، به این معنی است که سرور درخواست واسط کاربری را به طور موفقیت آمیز پاسخ داده، ولی اطلاعات ارسالی (در پاسخ سرور) از یک منبع غیر معتبر است (به فرض کپی ازاطلاعاتی است که درستی آن تایید نمی شود)، تنظیم این کد در سرورها معمولا غیر ضروری است و می توان به جای آن کد ۲۰۰ را ارسال کرد.

کد ۲۰۴، پاسخ بدون محتوا (No Content)

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

کد ۲۰۵، بازنشانی محتوا (Reset Content)

کد ۲۰۵ شباهت زیادی به عملکرد کد ۲۰۴ دارد، یعنی در اینجا نیز هیچ محتوایی از طرف سرور ارسال نمی شود، اما در سمت کاربر، اطلاعات فعلی بازنشانی یا Reset می گردند که این معمولا منجر به ایجاد محتوای خالی می شود، این کد مخصوصا برای پاک کردن اطلاعات فرم های وب می تواند مورد استفاده قرار گیرد.

کد ۲۰۶، محتوای جزئی (Partial Content)

کد ۲۰۶، برای حالت هایی که به فرض از امکاناتی نظیر ادامه دانلود (resume download) استفاده می کنیم، کاربرد دارد، با ارسال این کد توسط سرور، به قسمت خاصی از درخواست واسط کاربری به صورت جزئی پاسخ داده می شود، با این شیوه برنامه هایی که از GNU Wget یا نقل و انتقال داده از سرور پشتیبانی می کنند، قادر خواهند بود حتی پس از قطع ارتباط نیز به ادامه دریافت اطلاعات بپردازند، البته این قابلیت باید توسط سرور نیز پشتیبانی شود.

کدهای سری ۳۰۰، انتقال (Redirection)

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

کد ۳۰۰، انتخاب چندگانه (Multiple Choices)

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

کد ۳۰۱، انتقال همیشگی (Moved Permanently)

کد ۳۰۱ یکی از مهم ترین و حساس ترین کدهای HTTP مخصوصا در علم سئو است، دریافت این کد از طرف سرور، به معنی انتقال همیشگی یک آدرس وب، به آدرسی دیگر است، از این کد مخصوصا هنگامی که در آدرس لینک های سایت، به هر دلیل تغییراتی ایجاد می شود، می توان جهت هدایت ربات های خزنده یا کاربران به لینک اصلی، استفاده کرد.

کد ۳۰۲، پیدا شد (Found)

کد ۳۰۲ به این معنی است که منبع درخواستی یافت شده، اما مرورگر باید موقتا به آدرس دیگری منتقل شود (Moved Temporarily)، این حالت با کد ۳۰۱ متفاوت است،  در اینجا انتقال به صورت موقت انجام شده و آدرس اصلی همچنان معتبر و در دسترس خواهد بود، اما در ریدایرکت ۳۰۱، منظور از انتقال، انتقال همیشگی، حذف آدرس فعلی و جایگزینی آن با آدرس جدید است.

کد ۳۰۳، دیدن منبعی دیگر (See Other)

کد ۳۰۳ نیز مشابه کد ۳۰۲ عمل می کند، تفاوت در اینجا، تاکید روی متد GET است، در کد ۳۰۳ آدرس فعلی و آدرسی که کاربر به آن منتقل می شود، باید از طریق متد GET درخواست شوند که در حالت معمول نیز به اینصورت خواهد بود.

کد ۳۰۴، بدون تغییر (Not Modified)

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

کد  ۳۰۵، استفاده از پروکسی (Use Proxy)

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

کد ۳۰۶، تعویض پروکسی (Switch Proxy)

کد ۳۰۶ هم مشابه کد ۳۰۵ است و مربوط به درخواست تغییر پروکسی، این کد در حال حاضر کاربردی ندارد.

کد ۳۰۷، انتقال موقت (Temporary Redirect)

کد ۳۰۷ مربوط به مواقعی است که منبع لینک اصلی، موقتا در آدرسی دیگر قابل دسترسی است، این حالت با ریدایرکت ۳۰۲ و ۳۰۳ فرق دارد، در اینجا انتقال نیاز به تایید کاربر داشته و به صورت خودکار انجام نمی شود، متدهای استفاده شده نیز باید بین لینک اصلی و لینک انتقالی مشترک باشد، بقیه شرایط مشابه کدهای ۳۰۲ و ۳۰۳ است و واسط کاربری باید لینک فعلی را همچنان و در مراجعات بعدی به عنوان لینک اصلی مد نظر قرار دهد.

کدهای سری ۴۰۰، خطای سمت کاربر (Client Error)

کدهای سری ۴۰۰ مربوط به رویداد خطایی از جانب کاربر (سمت کاربر) در ارائه درخواست به سرور است، در پاسخ، سرور معمولا و به طور پیش فرض، به همراه کدهای HTTP عباراتی در توضیح خطای رخ داده ارسال می کند و دائمی یا موقتی بودن مشکل به وجود آمده را نیز تعیین خواهد کرد.

کد ۴۰۰، درخواست بد (Bad Request)

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

کد ۴۰۱، دسترسی نا معتبر (Unauthorized)

کد ۴۰۱ به معنی دسترسی غیر مجاز است، در این حالت منبع درخواستی به طور کامل محدود نشده است، بلکه درخواست کاربر نیاز به تایید مجوزهای دسترسی (به طور معمول نام کاربری و کلمه عبور) دارد، به همین دلیل سرور در پاسخ خود یک فرم از نوع WWW-Authenticate را ارسال کرده و از کاربر می خواهد تا اعتبار خود را اثبات کند.

کد ۴۰۲، نیاز به پرداخت (Payment Required)

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

کد ۴۰۳، دسترسی غیر مجاز (Forbidden)

کد ۴۰۳ مربوط به مواقعی است که کاربر درخواست منبعی را از سرور دارد که دسترسی به آن برای همه کاربران محدود شده است، این حالت با کد ۴۰۱ متفاوت است، در اینجا حتی با ورود نام کاربری و کلمه عبور نیز امکان دسترسی مقدور نخواهد بود، معمولا مدیران سایت ها، دسترسی مستقیم به فولدر ها و نمایش فایل ها به صورت لیست را غیر فعال می کنند، در نتیجه وقتی آدرس یک فولدر را از آن سرور درخواست می کنیم، با خطای ۴۰۳ مواجه خواهیم شد.

کد ۴۰۴، منبع درخواستی پیدا نشد (Not Found)

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

کد ۴۰۵، متد غیر مجاز (Method Not Allowed)

کد ۴۰۵ به این معنی است که متد استفاده شده توسط کاربر برای درخواست یک منبع از سرور مجاز نمی باشد، به فرض استفاد ه از متد GET در حالتی که منبع درخواستی نیاز به ارسال منابعی از طریق متد POST دارد، یا استفاده از PUT در نوشتن یک فایل، برای فایل هایی که فقط حالت خواندنی دارند (read-only)، در این حالت، معمولا سرور در پاسخ، متد مجاز را نیز ارسال خواهد کرد.

کد ۴۰۶، غیر قابل قبول (Not Acceptable)

کد ۴۰۶ ممکن است به دلیل وجود کاراکترهای غیر استاندارد در درخواست ارسالی رخ دهد، برخی از سرورها به دلایل امنیتی نیز ممکن است این کد را در پاسخ ارسال کنند، به طور مثال ماژول mod_security در سرورهای Apache از پذیرفتن برخی آدرس های وب (که از نظر امنیت، سرور آنها را مشکوک تشخیص دهد) خودداری کرده و پیام  Not Acceptable دریافت خواهید کرد.

کد ۴۰۷، نیاز به مجوز پروکسی (Proxy Authentication Required)

عملکرد کد ۴۰۷ نیز شبیه کد ۴۰۱ است، با این تفاوت که در اینجا ابتدا کاربر (واسط کاربری) باید از طریق یک پروکسی اعتبار خود را اثبات کند.

کد ۴۰۸، پایان حداکثر زمان درخواست (Request Timeout)

کد ۴۰۸ زمانی رخ می دهد که سرور در انتظار درخواست واسط کاربری است، اما هیچ پاسخی در زمان استاندارد دریافت نمی شود، به این صورت سرور کد ۴۰۸ را ارسال می کند و واسط کاربر می تواند مجددا و در دفعات بعدی درخواست خود را ارسال کند.

کد ۴۰۹، تعارض (Conflict)

کد ۴۰۹ به معنی تداخل یا تعارض درخواست کاربر با عملیاتی دیگر در سرور بر روی منبع مورد نظر است، به طور مثال وقتی دو کاربر به صورت همزمان در حال ویرایش یک فایل هستند و هر دو آن را ذخیره می کنند، ممکن است این خطا رخ دهد که باید به صورت دستی آن را رفع کرد.

کد ۴۱۰، محذوف (Gone)

کد ۴۱۰ به معنی حذف همیشگی منبع درخواستی از سرور است، بر خلاف خطای ۴۰۴، کد ۴۱۰ به واسط کاربری یا موتورهای جستجو می گوید که نباید مجددا آن منبع را درخواست کنند، چرا که برای همیشه حذف شده است، البته در عمل موارد استفاده از این کد خیلی محدود است و تنظیم خطای ۴۰۴ بهتر و اصولی تر است.

کد ۴۱۱، عدم ارسال طول درخواست (Length Required)

کد ۴۱۱ به این معنی است که سرور از پاسخ به درخواست واسط کاربری خودداری می کند، چرا که در درخواست ارسالی اندازه یا طول محتوا (Content-Length) وجود ندارد، در این حالت معمولا واسط کاربری باید در سربرگ های HTTP درخواست خود آن را اضافه کند.

کد ۴۱۲، پیش شرط رد شده(Precondition Failed)

کد ۴۱۲ به معنی این است که در درخواست واسط کاربری مواردی ارسال شده است (به فرض متد استفاده شده) که منبع سرور از آن طریق قابل دسترس نیست و نتیجه بررسی اولیه سرور false شده است.

کد ۴۱۳، درخواست خیلی طولانی (Request Entity Too Large)

کد ۴۱۳ در حالتی رخ می دهد که طول رشته درخواست ارسالی، بیش از حد توان و انتظار سرور است، لذا ارتباط توسط سرور قطع خواهد شد، اما اگر این حالت موقتی باشد، معمولا در پاسخ، سربرگ Retry-After نیز ارسال می شود و واسط کاربری مجددا و در دفعات بعدی می تواند درخواست خود را ارسال کند.

کد ۴۱۴، آدرس وب خیلی طولانی (Request-URI Too Long)

این خطا به معنی بیش از حد طولانی بودن آدرس وب (URI) درخواستی است و سرور قادر به پردازش آن نیست.

کد ۴۱۵، فرمت پشتیبانی نشده (Unsupported Media Type)

کد ۴۱۵ به دلیل ارسال فرمتی به همراه درخواست ارسالی (به فرض آپلود یک فایل یا تصویر) است که از نظر سرور قابل پذیرش نیست و سرور فرمت دیگری را پشتیبانی می کند.

کد ۴۱۶،  حد درخواستی غیر اقناع کننده (Requested Range Not Satisfiable)

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

کد ۴۱۷، انتظارات رد شده(Expectation Failed)

کد ۴۱۷ به معنی این است که سربرگ های HTTP ارسالی واسط کاربری با انتظارات و موارد مورد نیاز سرور همخوانی ندارد یا سربرگی ارسال نشده است.

کدهای سری ۵۰۰، خطای سمت سرور (Server Error)

کدهای سری ۵۰۰ به معنی نقص داخلی سرور است، با این حال سرور در مجموع سالم بوده و احتمالا به طور موقت در حال انجام به روزرسانی یا تغییراتی است و در ساعات آینده مشکل رفع خواهد شد.

کد ۵۰۰، خطای داخلی سرور (Internal Server Error)

کد ۵۰۰ به معنی وقوع یک خطای داخلی در سرور است و معمولا به دلیل نقص تنظیمات یا انجام به روزرسانی نرم افزاری یا سخت افزاری رخ می دهد، تنظیم این کد در مواقعی که می خواهیم در سایت، تغییراتی اعمال کنیم که باعث از دسترس خارج شدن آن می شود، می تواند مفید باشد.

کد ۵۰۱، غیر مجهز یا تکمیل نشده (Not Implemented)

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

کد ۵۰۲، خطای دروازه میانجی (Bad Gateway)

کد ۵۰۲ به دلیل عدم دریافت پاسخ از سرورهای بالادست (upstream) است و سرور فعلی به عنوان یک دروازه میانجی عمل می کند، در این حالت معمولا بین سرور اصلی و واسط کاربری، دروازه های میانجی (Gateway) وجود دارند که قادر به تکمیل فرایند ارسال و دریافت پاسخ نیستند، این حالت معمولا با چند بار تلاش مجدد از سمت کاربر رفع خواهد شد.

کد ۵۰۳، سرویس خارج از دسترس (Service Unavailable)

دریافت کد ۵۰۳ به معنی غیر قابل دسترس بودن سرور به دلیل ترافیک زیاد (overload) یا انجام به روزرسانی است، معمولا این حالت موقتی بوده و پس از چند دقیقه یا چند ساعت رفع خواهد شد.

کد ۵۰۴، پایان حداکثر زمان دروازه میانجی (Gateway Timeout)

کد ۵۰۴ نیز بدین معنی است که سرور به عنوان یک دروازه میانجی (Gateway) قادر به دریافت پاسخ از سرورهای بالا دست (upstream) در حداکثر زمان مجاز نیست.

کد ۵۰۵، نسخه HTTP پشتیبانی نمی شود (HTTP Version Not Supported)

کد ۵۰۵ به معنی پشتیبانی نشدن نسخه HTTP پروتکلی است که واسط کاربری از آن استفاده می کند، معمولا سرور دلیل پشتیبانی نکردن از آن نسخه را نیز به همراه سربرگ های پاسخ خود ارسال می کند.
علاوه بر موارد گفته شده که طبق استاندارد RFC 2616 W3C است، کدهای دیگری مربوط به سرورهای مایکروسافت و سایر پروتکل های وب وجود دارد که به جهت کاربردی نبودن از ذکر آنها خودداری کرده ایم.

منبع: وبگو