پروتکل کنترل انتقال (TCP) که در سند RFC 793 استانداردسازی شده است، پیش از مبادله داده‌ها میان برنامه‌های کاربردی، نیازمند یک فرایند دست‌تکانی سه‌مرحله‌ای با حفظ وضعیت (Three-Way Handshake) است. کلاینت با ارسال بسته همگام‌سازی (SYN) درخواست اتصال می‌کند. سرور با بازگرداندن بسته تایید (SYN-ACK) پاسخ می‌دهد و همزمان فضایی از حافظه هسته را برای ساختار بلوک کنترل انتقال (TCB) اختصاص می‌دهد. اتصال تا زمان دریافت پاسخ نهایی (ACK) در حالت انتظار (SYN-RECEIVED) باقی می‌ماند.

این طراحی که متکی بر تخصیص زودهنگام منابع است، بستری آسیب‌پذیر در برابر حملات محروم‌سازی از سرویس به نام TCP SYN Flood فراهم می‌آورد. مهاجم با ارسال انبوهی از بسته‌های SYN با نشانی‌های IP جعلی و خودداری از ارسال بسته ACK نهایی، صف اتصالات سرور را اشباع کرده و دسترسی کاربران مجاز را مختل می‌سازد.

خنثی‌سازی چنین حملاتی نیازمند حذف ثبت وضعیت در مراحل ابتدایی اتصال است. در حالی که وب سنتی در لایه ۴ از مکانیزم SYN Cookies طبق استاندارد RFC 4987 بهره می‌گیرد، پروتکل‌های نوین VPN نظیر WireGuard از سازوکار تایید هویت دو سطحی پیام‌ها (mac1 و mac2) برای مهار حملات منع سرویس (DoS) استفاده می‌کنند.

نحوه اجرای حمله TCP SYN Flood و سرریز صف اتصالات

هنگامی که هسته سیستم‌عامل بسته SYN معتبری را در درگاه شنود دریافت می‌کند، درخواست را در یک صف حافظه موقت موسوم به صف اتصالات نیمه‌باز (SYN backlog) ثبت می‌نماید.

کلاینت (مهاجم)                     سرور (قربانی)
       |                                   |
       |------- SYN (IP جعلی الف) -------->| تخصیص TCB در صف حافظه
       |------- SYN (IP جعلی ب) ---------->| تخصیص TCB در صف حافظه
       |------- SYN (IP جعلی ج) ---------->| تخصیص TCB در صف حافظه
       |                                   | (سرریز و اشباع صف SYN!)
       |                                   | دور انداختن بسته‌های جدید SYN
       |                                   | مسدود شدن کاربران مجاز

در شرایط عادی، این ورودی‌ها چند ثانیه در انتظار پاسخ کلاینت باقی می‌مانند. در جریان حمله SYN Flood:

  1. جعل نشانی مبدا (IP Spoofing): مهاجم بسته‌های TCP SYN را با فرکانس بسیار بالا و همراه با نشانی‌های IP تصادفی یا نامعتبر تولید و ارسال می‌کند.
  2. اتلاف منابع سیستمی: از آنجا که میزبان‌های فرضی هرگز بسته SYN-ACK را دریافت نمی‌کنند، تایید پایانی فرستاده نمی‌شود. در نتیجه، هزاران ساختار TCB رهاشده در حافظه هسته انباشته شده و منابع رم و سوکت‌ها را اشغال می‌کنند.
  3. سرریز صف پذیرش: هنگامی که ظرفیت صف به سقف تعیین‌شده می‌رسد، سیستم‌عامل تمامی درخواست‌های جدید را رد کرده و کاربران واقعی را از اتصال محروم می‌سازد.
مرحله دست‌تکانی TCP اتصال استاندارد سناریوی حمله SYN Flood
ارسال بسته اولیه SYN کلاینت شماره توالی اولیه را ارسال می‌کند ارسال طوفانی بسته‌های جعلی با IP نامعتبر
پاسخ سرور میزبان تخصیص TCB و ارسال پاسخ SYN-ACK ثبت ساختار حافظه برای میزبان‌های غیرواقعی
ارسال بسته پایانی ACK کلاینت فرایند سه‌مرحله‌ای را تکمیل می‌کند عدم دریافت تایید و ایجاد وقفه طولانی
وضعیت هسته سیستم‌عامل انتقال به وضعیت پایدار ESTABLISHED اشباع کامل صف و رد اتصال‌های قانونی

فناوری RFC 4987 SYN Cookies: ارتباط بدون حالت مبتنی بر رمزنگاری

فناوری SYN Cookies در سند RFC 4987 روشی ریاضی برای تغییر ماهیت دست‌تکانی TCP از باحالت به کاملا بدون حالت (Stateless) در زمان مواجهه با بار ترافیکی سنگین ارائه می‌دهد.

به جای ثبت ساختار TCB در حافظه هنگام دریافت SYN، سرور یک شماره توالی اولیه ساختگی (ISN) را از طریق فرمول‌های رمزنگاری محاسبه کرده و در قالب پاسخ SYN-ACK به سمت کلاینت می‌فرستد. سرور بی‌درنگ اطلاعات مربوط به نشست را از حافظه پاک می‌کند.

این شماره ۳۲ بیتی پارامترهای اتصال را در خود ذخیره می‌کند:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| زمان (۵ بیت)  | MSS (۳ بیت) |             هش رمزنگاری اختصاصی (۲۴ بیت)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

اجزای این عدد ۳۲ بیتی شامل موارد زیر است:

  • شمارنده زمان (۵ بیت): مقداری با افزایش تدریجی (معمولا هر ۶۴ ثانیه) برای جلوگیری از تکرار مجدد شماره‌های منسوخ.
  • شاخص اندازه سگمنت (۳ بیت): انتخابی از میان ۸ اندازه استاندارد حداکثر سگمنت (MSS) به منظور توافق بر سر ظرفیت بدون مصرف حافظه.
  • چکیده رمزنگاری (۲۴ بیت): هش محاسبه‌شده از ترکیب IP مبدا، IP مقصد، درگاه‌ها، شمارنده زمان و کلید مخفی اختصاصی سرور.

هنگامی که کلاینت واقعی بسته نهایی ACK را ارسال می‌کند، شماره تایید آن برابر با شماره کوکی به علاوه یک (Cookie + 1) خواهد بود. سرور یک واحد از آن کم کرده، پارامترهای زمان و اندازه سگمنت را استخراج می‌کند و مجددا هش را با کلید مخفی خود محاسبه می‌نماید. در صورت تطابق، صحت نشانی کلاینت تایید شده و تنها در این لحظه حافظه لازم برای اتصال ایجاد می‌شود.

کوکی‌های MAC2 در پروتکل WireGuard: دفاع بدون حالت در لایه ۳

اگرچه SYN Cookies کارایی بالایی در اتصالات TCP دارد، شبکه‌های خصوصی مجازی عمدتا بر بستر پروتکل UDP در لایه ۳ فعالیت می‌کنند. علاوه بر آن، دروازه‌های VPN با خطر مصرف توان پردازنده ناشی از محاسبات پرهزینه رمزنگاری نامتقارن (نظیر تبادل کلید Curve25519) روبرو هستند.

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

چالش بار پردازشی نامتقارن

هنگامی که یک کلاینت به سرور WireGuard متصل می‌شود، یک بسته آغازین (Handshake Initiation) ارسال می‌کند. در شرایط عادی، سرور محاسبات مربوط به تبادل کلید Curve25519 Diffie-Hellman را برای اشتقاق کلیدهای نشست انجام می‌دهد.

با این وجود، توان محاسباتی مورد نیاز برای انجام عملیات Curve25519 صدها برابر بیشتر از ارسال یک بسته ساده UDP است. یک شبکه بات‌نت می‌تواند با ارسال مکرر درخواست‌های آغازین ساختگی، تمام توان پردازنده سرور را به خود اختصاص داده و ارتباط کاربران واقعی را مختل سازد.

معماری اعتبارسنجی MAC دو سطحی

در پایان هر بسته آغازین دست‌تکانی در WireGuard، دو بخش اعتبارسنجی ۱۶ بایتی قرار می‌گیرد:

+---------------------------------------------------------------+
|                    محتوای پیام آغازین دست‌تکانی               |
+---------------------------------------------------------------+
|                       بخش mac1 (۱۶ بایت)                      |
+---------------------------------------------------------------+
|                       بخش mac2 (۱۶ بایت)                      |
+---------------------------------------------------------------+

۱. بخش mac1 (تمامیت و انطباق نشانی): کدی که با استفاده از کلید عمومی سرور مقصد محاسبه می‌شود. در صورت نادرست بودن یا غیبت این بخش، بسته بدون انجام هیچ‌گونه پردازش سنگین دور انداخته می‌شود. ۲. بخش mac2 (اثبات درستی مسیر بازگشت بسته): در شرایط بار معمولی، این بخش با صفر پر می‌شود. به محض اینکه حجم درخواست‌ها از آستانه امنیتی عبور کند (هنگام وقوع حمله DoS)، سرور به وضعیت دفاع کوکی سوئیچ می‌کند.

فرایند خودکار مبادله کوکی

سرور در زمان مواجهه با ترافیک غیرعادی، از اجرای مستقیم عملیات ریاضی صرف‌نظر کرده و فرایند زیر را طی می‌کند:

۱. تولید کوکی رمزنگاری‌شده: سرور با استفاده از الگوریتم ChaCha20-Poly1305 توکنی حاوی نشانی IP فرستنده، درگاه و کلید اختصاصی در حال چرخش (تغییر هر ۲ دقیقه) تولید می‌کند. ۲. ارسال پاسخ حاوی کوکی: توکن به نشانی مبدا فرستاده می‌شود. در صورتی که IP جعلی باشد، بسته از بین رفته و مهاجم به آن دسترسی نخواهد داشت. ۳. تکرار درخواست همراه با mac2: کلاینت واقعی توکن را دریافت و ذخیره کرده و درخواست اولیه را مجددا ارسال می‌کند؛ این بار با پر کردن بخش mac2 به کمک کوکی دریافت‌شده. ۴. بررسی سریع متقارن: سرور بخش mac2 را با توابع سریع متقارن ارزیابی می‌کند. این سازوکار فیلتر کردن میلیون‌ها بسته جعلی در هر ثانیه را بدون فشار به پردازنده میسر می‌سازد.

طی این چرخه، سرور هیچ‌گونه وضعیتی در حافظه ذخیره نکرده و کاملا بدون حالت باقی می‌ماند.

بهینه‌سازی پارامترهای هسته لینوکس با Sysctl

مدیران سیستم می‌توانند با تنظیم صحیح پارامترهای شبکه، تاب‌آوری سرورهای خود را در مواجهه با ترافیک‌های غیرعادی ارتقا دهند:

فعال‌سازی و تنظیمات SYN Cookies

بررسی وضعیت فعال بودن این مکانیزم در سیستم:

# بررسی وضعیت SYN Cookies (مقدار ۱ نشان‌دهنده فعال بودن است)
sysctl net.ipv4.tcp_syncookies

جهت بهینه‌سازی صف‌ها، تنظیمات زیر را در فایل /etc/sysctl.d/99-network-dos-protection.conf قرار دهید:

# فعال‌سازی مکانیزم دفاعی SYN Cookies
net.ipv4.tcp_syncookies = 1

# افزایش گنجایش صف اتصالات نیمه‌باز
net.ipv4.tcp_max_syn_backlog = 8192

# افزایش سقف سوکت‌های در حال شنود
net.core.somaxconn = 8192

# کاهش تلاش‌های مجدد SYN-ACK برای آزادسازی سریع سوکت‌های معلق
net.ipv4.tcp_synack_retries = 2

# افزایش ظرفیت صف ورودی بسته‌های کارت شبکه به ازای هر هسته پردازنده
net.core.netdev_max_backlog = 16384

اعمال بدون نیاز به راه‌اندازی مجدد:

sudo sysctl --system

پایش اتصالات و بررسی بسته‌های ردشده

نظارت بر وضعیت سوکت‌های فعال شبکه:

# مشاهده آمار تفکیکی سوکت‌های TCP
ss -s

# بررسی بسته‌های ردشده به دلیل اشباع صف‌ها
netstat -s | grep -i "listen"

ساختار دفاعی یکپارچه در زیرساخت VPNRice

حفاظت در برابر حملات توزیع‌شده نیازمند هماهنگی در سطوح مختلف شبکه است:

۱. پردازش بدون حالت در هسته RiceGuard: گره‌های ارتباطی VPNRice با تکیه بر بررسی اعتبارسنجی mac1 و mac2، طوفان‌های ورودی بسته‌های جعلی را بدون افت منابع پردازشی و حافظه مدیریت می‌کنند. ۲. پالایش اولیه با فناوری eBPF/XDP: در لایه‌های لبه شبکه، کدهای eBPF بسته‌ها را مستقیما در درایور کارت شبکه بررسی کرده و ترافیک مخرب را پیش از ورود به پشته پردازش هسته متوقف می‌سازند. ۳. جداسازی ترافیک کلاینت در لایه ۳: داده‌ها درون تونل‌های رمزنگاری‌شده RiceGuard عبور می‌کنند که ارتباط کاربران را در برابر مخاطرات صف‌های محلی TCP و جعل نشانی در شبکه‌های عمومی ایمن نگه می‌دارد.

تلفیق الگوریتم‌های بدون حالت و ایزولاسیون رمزنگاری‌شده تضمین می‌کند که شبکه VPNRice حتی در زمان وقوع اختلالات بزرگ ترافیکی، خدماتی پایدار با کمترین تاخیر زمانی ارائه دهد.