حمله‌ی SYN flood در دسته‌ی حمله‌های DDoS قرار می‌گیرد و مانند این حمله‌ها، سعی می‌کند با ارسال درخواست و مشغول نگه داشتن سرور، ظرفیت سرور برای پاسخ‌گویی به درخواست‌ها را به حداقل ممکن برساند و مانع دسترسی کاربران به سرویس شود.
عملکرد حمله‌ی SYN flood
زمانی که یک کاربر (برای نمونه یک مرورگر) قصد دارد با استفاده از پروتکل TCP به سروری وصل شود، ابتدا یک پیام SYN برای سرور ارسال می‌کند. کاربر با ارسال این پیام، اطلاعاتی را در اختیار سرور می‌گذارد که از آن‌ها پس از ایجاد TCP connection و برای تبادل اطلاعات استفاده می‌شود.
سرور در جواب پیام SYN، یک پیام ACK ارسال می‌کند که نشان‌دهنده‌ی دریافت پیام SYN کاربر است. سپس، به‌شکل هم‌زمان یک پیام SYN را نیز، برای کاربر ارسال می‌کند. در پایان اگر کاربر هم برای سرور جواب ACK را ارسال کند، TCP connection برقرار می‌شود.
سرور، به ازای هر پیام SYN که دریافت می‌کند، پاسخ SYN/ACK را ارسال می‌کند، تا مدت‌زمان مشخصی ارتباط TCP تشکیل شده را برقرار نگه می‌دارد و منتظر دریافت پاسخ از کاربر می‌ماند. با در نظر گرفتن این شرایط، حمله‌ی SYN flood به این شکل است که حمله کننده با تعداد زیادی کاربر و IPهای مختلف، پیام SYN برای سرور ارسال می‌کند و پس از دریافت پاسخ، جواب ACK را ارسال نمی‌کند. چون منابع سرور در نگه‌داری connectionهای باز محدود هستند، درخواست جدید را نمی‌تواند قبول کند و سرویسی که ارایه می‌دهد از دسترس خارج می‌شود.
یکی دیگر از راه‌های پیاده‌سازی این حمله آن است که، حمله‌کننده پیام‌های SYN با IPهای مبدا دست‌کاری شده و مختلف ارسال کند. در این حالت، هنگامی که آدرس‌های IP استفاده شده، جواب SYN/ACK را دریافت می‌کنند، آن را به عنوان یک پیام بی‌معنی در نظر می‌گیرند و جوابی ارسال نمی‌کنند.
راه‌های مقابله با حمله‌ی SYN flood
- هر راهی که سبب شود تعداد connectionهای باز و غیرواقعی سرور کاهش پیدا کند، تا حدودی می‌تواند جلوی حمله‌ی SYN flood را بگیرد. یکی از این راه‌ها، استفاده از SYN cookie است. زمانی که سرور پاسخ SYN/ACK را ارسال می‌کند، به همراه آن یک cookie که براساس اطلاعات connection تا این لحظه (شامل آدرس IP کاربر، شماره پورت و …) تنظیم شده است، ارسال می‌کند و connection را باز نگه نمی‌دارد. در ادامه، کاربر پاسخ ACK را همراه cookieای که قبل‌تر دریافت کرده بود، ارسال می‌کند. اگر cookie و ACK هر دو معتبر باشند، سرور connection را ایجاد می‌کند و از این به بعد برای این connection منابعی را اختصاص می‌دهد.
- اگر بتوان کاری کرد که کاربر پس از دریافت یک جواب، دوباره درخواست خود را ارسال کند، تا حدودی می‌توان از واقعی بودن کاربر اطمینان داشت. برای این کار، لازم است سرور پس از دریافت اولین پیام SYN، یک پیام SYN/ACK نامعتبر ارسال کند. کاربر پس از دریافت این پیام، یک پیام RST ارسال می‌کند که به این معنی است که درباره‌ی جوابی که دریافت کرده مشکلی وجود دارد. پس از این‌که سرور این پیام را دریافت کرد، پیام SYN/ACK واقعی را ارسال می‌کند و با ادامه‌ی این روند، connection ایجاد می‌شود. این کار، جلوی حمله‌هایی را که در آن‌ها مهاجم IP مبدا را تغییر می‌دهد یا پس از ارسال پیام SYN، بررسی بیش‌تری انجام نمی‌شود ، می‌گیرد.
- هم‌چنین کاهش منابع اختصاص داده شده به یک connection که هنوز کاملن ایجاد نشده‌اند، می‌تواند سبب شود که سرور منابع آزاد بیش‌تری داشته باشد و در نتیجه connectionهای بیش‌تری را ایجاد کند. برای نمونه، به جای نگه‌داشتن تمام اطلاعات مربوط به یک connection ناکامل، تنها بخش ضروری آن را نگه دارد. هم‌چنین می‌تواند با کاهش زمانی که یک connection باز را نگه می‌دارد، منابع اختصاص داده شده را سریع‌تر آزاد کند.
- استفاده از proxy هم تا حدودی می‌تواند از این حمله جلوگیری کند. یک proxy، قبل از آن که پیام‌های SYN به سرور اصلی برسد، آن‌ها را دریافت می‌کند و از طرف سرور اصلی جواب SYN/ACK را ارسال می‌کند. اگر پاسخ ACK را دریافت کرد و connection ایجاد شد، اطلاعات مربوط به connection ایجاد شده را به عنوان یک connection معتبر به سرور اصلی می‌دهد و از این پس کاربر می‌تواند با پروتکل TCP با سرور ارتباط برقرار کند. البته در استفاده از این روش، تمام مشکل‌هایی که برای سرور در حمله‌ی SYN flood ایجاد می‌شد، می‌تواند برای proxy ایجاد شود و از آن‌جایی که ممکن است سرور proxy قدرت پردازش کم‌تری نسبت به سرور اصلی داشته باشد، حمله‌ی SYN flood روی proxy server می‌تواند اثر بیش‌تری داشته باشد بنابراین برای انتخاب این روش باید دقت کرد و تنها در مواردی از آن استفاده کرد که مطمین بود، اثرات حمله کم‌تر می‌شود.
محصول DDoS protection امنیت ابری آروان در چهار سطح مختلف از کسب و کارهای آنلاین در برابر انواع حملات DDoS محافظت می‌کند.
