محسن مهربان‌پور
محسن مهربان‌پور
خواندن ۷ دقیقه·۱ سال پیش

آسیب پذیری SYN flooding attack

فرض کنیم توی یک مغازه یک عالمه مشتری میفرستیم که فقط قیمت میپرسن و هیچکدومم خرید نمیکنن ! خریدار واقعی هم دم در کلافه میشه و اصلا جا نمیشه بره تو ! این میشه مصداق SYN flooding attack

توی این پست میخوام آنچه در مورد SYN flooding attack یاد گرفتم با شما به اشتراک بزارم ، پس اگر توهم برات جالبه که این آسیب پذیری protocol لایه transport رو بشناسی خوشحال میشم با من همراه باشی .

این آسیب پذیری واقع در پرتکل TCP واقع در لایه انتقال (transport layer) هست ، خوبه که برای شفاف تر شدن ماجرا اول یکم راجع به خود TCP صحبت کنیم تا برامون یادآوری بشه چیکار میکنه.

پرتکل TCP چی هست و چیکار میکنه ؟

به طور کلی پرتکل TCP همونطور که از لایه اش هم معلومه ، یک واسط بین application و لایه شبکه هست که میتونه بین process های فعال در دو سیستم مختلف داده جا به جا کنه (اصطلاحا بهش میگن Process-to-Process Communication)

این انتقال داده هم اینجوریه که به هر process یک port اختصاص داده میشه و این پرتکل میتونه با استفاده از همین port number داده رو به application ما برسونه.

این پرتکل داده رو از لایه application میگیره و در بسته هایی به نام segment ذخیره میکنه . هر segment خودش از دو بخش تشکیل میشه :

  • Data:

شامل داده هایی میشن که میخوایم ارسال کنیم

  • Header:

بخش header شامل داده های مختلفی میشه ، مثل source port number, destination port number , header length, … که ما چون موضوعمون تشریح پرتکل TCP نیست از بررسی اجزا هم فعلا صرف نظر میکنیم . اما یک تعداد flag توی header هستن که به دوتا موردش باید اشاره کنیم .

SYN (Synchronize sequence numbers):

این flag خیلی جزئیات داره اما بخوام خلاصه شرحش بدم که در ادامه درک مفهوم رو برای ما راحت کنه ، توی TCP وقتی داده رو میخوایم ارسال کنیم ، بایت های داده ای که در segment ها قرار میدیم شماره گذاری میشن تا به ترتیب سمت گیرنده دریافت بشن . از این flag برای اینکه مشخص کنیم ما از چه شماره ای شروع کردیم به شماره گذاری تا گیرنده بدونه شماره های ما (اصطلاحا بهش میگن sequence number) از چند شروع شده استفاده میکنیم

ACK (Acknowledgment):

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



کل این بسته میره توی دل بسته های لایه های پایین تر مثل IP که وظیفه مسیریابی در شبکه رو داره.

اما اصل داستان از جایی شروع میشه که ...

پرتکل TCP اصلا چطوری ارتباط برقرار میکنه ؟

توی پرتکل TCP برقراری ارتباط در سه گام اتفاق میوفته که بهش اصطلاحا میگن (Three-Way Handshaking)

تصور کنیم یک کلاینت میخواد با استفاده از پرتکل TCP به یک سرور وصل بشه .

اول از همه سرور به TCP خودش میگه آماده دریافت connection باش – به این فاز میگن passive open و سرور آماده ی دریافت درخواست از سرتاسر جهان میشه .

بعد نوبت میرسه به کلاینت که به امید برقراری ارتباط با یک سرور به اون سرور یک درخواست ارسال میکنه ، که به این مورد میگن active open و از این جا به بعد اون سه گام اتصال به وقوع می پیونده .


گام 1️⃣ : کلاینت یک SYN segment رو به سمت سرور میفرسته ، توی این بسته فقط SYN flag ست شده
و داره‌ میگه شماره گذاری های من از چه عددی شروع میشه

گام 2️⃣ : سرور در پاسخ به این بسته ارسالی از کلاینت یک segment حاوی flag های SYN و ACK رو
میفرسته به کلاینت که دوتا هدف رو دنبال میکنه ، با SYN داره میگه شماره گذاری هاش از چه عددی شروع
میشه و با ACK میگه من بسته ارسال شده توسط تورو دریافت کردم

گام 3️⃣ : کلاینت در جواب به این بسته سرور یک ACK segment میفرسته به سرور بگه آقا من بسته ارسالی
توسط تورو دریافت کردم

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

پس SYN flooding attack چیشد ؟

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

این حلمه در دسته حملات Denial of service که به اختصار DoS معروف هست قرار میگیره و توی این روش attacker از اون سه گامی که توضیح دادیم سوع استفاده میکنه .

برای رخ دادن این حمله :


  • با توجه به گام 1️⃣ ، مهاجم به جای یک SYN segment تعداد خییییلیی زیادی SYN segment به سمت سرور ارسال میکنه .
  • با توجه به گام 2️⃣ سرور برای پاسخ دادن به درخواست های گام 1️⃣ اقدام میکنه ، پاسخ رو به سمت کلاینت ما میفرسته (که اینجا کلاینت ما همون attacker هست) و بر اساس گام 3️⃣ منتظر میمونه کلاینت ACK segment رو به سمتش ارسال کنه و برای این امر یک پورت رو باز نگه میداره .

امااااا! اما اینجا کلاینت ما گام 3️⃣ رو بر نمیداره و سرور رو منتظر میزاره و به جاش دوباره گام یک رو تکرار میکنه ! دوباره کلاینت به سرور درخواست میده – سرور درخواستش رو پاسخ میده و یک پورت باز برای پاسخش در نظر میگیره و میوفته توی این چرخه – و این چرخه انقدررررر اتفاق میوفته که تمام پورت های سرور درگیر بشن و دیگه نتونه عملکردی که باید رو داشته باشه .

انواع مختلف SYN flooding attack

اصل داستان SYN flooding attack همون بود که در بخش قبل توضیحش دادیم ، به طور کلی این حمله رو به سه روش مختلف انجام میدن .

Direct attack

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

Spoofed Attack

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

Distributed attack (DDoS)

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

راهکار های ارائه شده برای کاهش حمله SYN flooding attack چیست؟

Increasing Backlog queue

توی لایه ی سیستم عامل اومدن گفتن که ما باید تعداد مشخصی کانکشن نیمه نصفه (half-open) داشته باشیم و برای بیشتر از اون به طور داینامیک باید مموری و منابع ای که میخوایم به کانکشن ها اختصاص بدیم رو مدیریت کنیم

Recycling the Oldest Half-Open TCP connection

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

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

SYN cookies

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

third party services such as cloudflare

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



شما چه روش های دیگه ای رو برای مقابله با این آسیب پذیری میشناسین ؟

خوشحال میشم نظراتتون رو برام کامنت کنین ❤

امنیتبرنامه نویسیهک و امنیتوبسایت
شاید از این پست‌ها خوشتان بیاید