پروتکل کنترل انتقال (TCP) که در سال ۱۹۸۱ با استاندارد RFC 793 معرفی شد، ستون اصلی ارتباطات داده‌ای در اینترنت است. هنگام بروز خطا در سوکت یا قطع ناگهانی یکی از دو سر ارتباط، پروتکل TCP از پرچم بازنشانی (RST) برای بستن فوری اتصال و آزادسازی منابع سیستم‌عامل استفاده می‌کند. با این حال، از آنجا که سرآیندهای استاندارد TCP فاقد امضای رمزنگاری هستند، هر تجهیز میانی که قادر به مشاهده یا حدس زدن پارامترهای اتصال باشد می‌تواند بسته‌های RST جعلی بسازد.

این نوع اختلال به عنوان تزریق بسته TCP RST شناخته می‌شود. سامانه‌های بازرسی عمیق بسته‌ها (DPI)، تجهیزات میانی و مهاجمان شبکه با فرستادن این بسته‌ها اقدام به قطع دانلود فایل‌های بزرگ، قطع نشست‌های پایگاه داده، اختلال در پوسته امن (SSH) و قطع ارتباطات وب می‌کنند.

برای درک آسیب‌پذیری TCP در برابر حملات کور درون پنجره دریافت (blind in-window attacks)، باید محاسبات پنجره دریافت، سازوکار استاندارد RFC 5961 و جداسازی رمزنگاری لایه ۳ را بررسی کنیم.

[پذیرش بسته در پنجره طبق استاندارد اولیه RFC 793]
محدوده پنجره دریافت: [RCV.NXT = 10,000] <─────── ۱,۰۴۸,۵۷۶ بایت ───────> [1,058,576]
                                                    ▲
                                   بسته RST جعلی: SEQ = 450,000
                                   (پذیرفته شد! اتصال فوراً قطع می‌شود)

─────────────────────────────────────────────────────────────────────────────────────────────

[اعتبارسنجی سخت‌گیرانه طبق استاندارد RFC 5961]
محدوده پنجره دریافت: [RCV.NXT = 10,000] <─────── ۱,۰۴۸,۵۷۶ بایت ───────> [1,058,576]
                     ▲                              ▲
  تنها مقدار دقیق SEQ == 10,000 پذیرفته می‌شود!   بسته درون پنجره باعث ارسال Challenge ACK می‌شود؛
                                                  ارتباط پایدار و فعال باقی می‌ماند.

ساختار فنی تزریق بسته TCP RST و نقص پنجره دریافت

در مشخصات اولیه RFC 793، یک سوکت TCP در وضعیت برقراری ارتباط (ESTABLISHED) پس از دریافت بسته‌ای با پرچم RST، فقط بررسی ساده‌ای روی مرزهای پنجره انجام می‌دهد. این بسته در صورت برقراری شرط زیر معتبر شمرده می‌شود:

$$\text{RCV.NXT} \le \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$$

که در آن $\text{RCV.NXT}$ شماره ترتیبی بعدی مورد انتظار و $\text{RCV.WND}$ اندازه پنجره دریافت اعلام‌شده است.

در دهه ۱۹۸۰، حافظه سیستم‌ها محدود و اندازه پنجره‌ها معمولاً کمتر از ۶۴ کیلوبایت بود. اما در شبکه‌های پرسرعت امروزی، قابلیت مقیاس‌پذیری پنجره TCP Window Scale (استاندارد RFC 7323) اندازه پنجره دریافت را به چندین مگابایت (معمولاً بین ۲۵۶ کیلوبایت تا ۴ مگابایت) افزایش داده است.

این افزایش پنجره، حدس زدن شماره ترتیبی را برای مهاجمان بسیار آسان‌تر کرده است:

۱. کاهش فضای جستجو: در یک فضای ۳۲ بیتی ($۲^{۳۲} \approx ۴.۲۹ \times ۱۰^۹$ مقدار)، حدس زدن یک شماره ترتیبی دقیق نیازمند میلیون‌ها تلاش است. اما برای پنجره‌ای به وسعت ۲ مگابایت، کافی است شماره حدس‌زده‌شده درون یک بازه پیوسته از ۲,۰۹۷,۱۵۲ مقدار قرار گیرد. ۲. احتمال موفقیت بالا: احتمال قرارگیری یک شماره تصادفی درون پنجره معتبر برابر با $\frac{\text{RCV.WND}}{۲^{۳۲}}$ است. برای یک پنجره ۲ مگابایتی، فرستادن چند هزار بسته جعلی برای قطع حتمی اتصال کفایت می‌کند. ۳. عدم تقارن منابع: فرستنده مهاجم تنها با ارسال بسته‌های سبک ۴۰ تا ۵۴ بایتی پهنای باند اندکی مصرف می‌کند، در حالی که سوکت سیستم قربانی بلافاصله نابود شده و خطای قطع ارتباط به برنامه تحویل داده می‌شود.

دستگاه‌های بازرسی مستقر در مسیر عبور ترافیک حتی نیازی به حدس زدن ندارند؛ آن‌ها با خواندن پنج‌گانه مشخصات IP و سرآیند بدون رمزنگاری TCP، مقادیر جاری $\text{SEG.SEQ}$ را خوانده و هم‌زمان به هر دو طرف ارتباط بسته‌های RST ارسال می‌کنند.

استاندارد RFC 5961 و آسیب‌پذیری کانال جانبی Challenge ACK

در اوت ۲۰۱۰، کارگروه مهندسی اینترنت (IETF) استاندارد RFC 5961 را به منظور ارتقای امنیت TCP در برابر تزریق بسته‌های جعلی RST و SYN منتشر کرد. این استاندارد تغییرات زیر را اعمال نمود:

۱. اعتبارسنجی دقیق شماره ترتیبی برای بسته‌های RST

طبق بخش ۳.۲ از RFC 5961، بسته RST دریافتی برای بستن فوری اتصال فقط زمانی معتبر شناخته می‌شود که شماره ترتیبی آن دقیقاً برابر با شماره ترتیبی بعدی مورد انتظار باشد:

$$\text{SEG.SEQ} == \text{RCV.NXT}$$

اگر شماره ترتیبی در محدوده پنجره قرار گیرد اما کاملاً مساوی نباشد ($\text{RCV.NXT} < \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$)، پشته پروتکل نباید اتصال را ببندد؛ بلکه باید یک بسته تأیید چالش موسوم به Challenge ACK برای فرستنده ارسال کند:

مشتری (کلاینت)                                              سرور
      |                                                        |
      | ---- بسته جعلی RST (درون پنجره، اما SEQ != RCV.NXT) --->|
      |                                                        |
      | <--- بسته Challenge ACK (SEQ = SND.NXT, ACK = RCV.NXT) -|
      |                                                        |
      | (مهاجم بیرونی پاسخی ندارد؛ تبادل داده واقعی ادامه می‌یابد)

بسته Challenge ACK شماره واقعی $\text{RCV.NXT}$ را ارسال می‌کند. اگر درخواست بازنشانی از طرف سرور اصلی بوده باشد، سرور با یک بسته RST با شماره دقیق فیلد ACK پاسخ داده و ارتباط به شکل شفاف بسته می‌شود. اگر بسته ساختگی باشد، سرور مجاز بسته ناگهانی Challenge ACK را نادیده می‌گیرد و تبادل داده بدون وقفه ادامه می‌یابد.

۲. محدودسازی نرخ Challenge ACK و رخنه امنیتی CVE-2016-5696

پاسخ دادن به تمام بسته‌های نامعتبر می‌تواند شبکه را در معرض حملات محروم‌سازی از سرویس (DoS) قرار دهد. بنابراین RFC 5961 سازوکار محدودسازی نرخ ارسال Challenge ACK را تعیین کرد.

در هسته لینوکس، پارامتر net.ipv4.tcp_challenge_ack_limit این سقف را تعیین می‌کرد که ابتدا روی ۱۰۰ یا ۲۵۰ پاسخ در ثانیه برای کل سیستم تنظیم شده بود.

در سال ۲۰۱۶، محققان امنیتی به سرپرستی ژی‌یون چیان (Zhiyun Qian) رخنه‌ای جدی در این شمارنده سراسری کشف کردند (با شناسه CVE-2016-5696). از آنجا که شمارنده میان تمام اتصالات سیستم مشترک بود، مهاجم خارج از مسیر می‌توانست با برقراری یک اتصال معمولی با سرور هدف و ارسال بسته‌های آزمایشی به سوکت خود، شمارش Challenge ACK دریافتی را رصد کند. به این ترتیب او متوجه می‌شد که آیا ارسال بسته کاوشگر به سمت اتصال قربانی باعث مصرف سهمیه سراسری شده است یا خیر.

این کانال جانبی امکانات زیر را فراهم می‌کرد:

  • پیدا کردن درگاه پویای (ephemeral port) کلاینت در چند ثانیه.
  • استخراج بازه معتبر شماره ترتیبی اتصال بین دو سیستم دیگر.
  • تزریق داده‌های مخرب یا بستن اجباری اتصال با وجود فعال بودن RFC 5961.

این نقص بعداً با تصادفی‌سازی آستانه‌ها و جداسازی زمان‌سنج‌ها در هسته سیستم‌عامل‌ها ترمیم شد.

شناسایی بسته‌های RST تزریق‌شده در ترافیک شبکه

کارشناسان شبکه می‌توانند بسته‌های بازنشانی جعلی را با تحلیل فایل‌های ضبط‌شده در tcpdump یا Wireshark شناسایی کنند. این بسته‌ها معمولاً ناهنجاری‌های فیزیکی مشخصی نشان می‌دهند:

# ضبط بسته‌های مشکوک RST روی کارت شبکه eth0
sudo tcpdump -ni eth0 'tcp[tcpflags] & tcp-rst != 0' -vvv -c 20

چهار نشانه کلیدی برای شناسایی بسته‌های تزریق‌شده:

ویژگی سرآیند سرور اصلی و معتبر بسته جعلی تزریق‌شده
طول عمر بسته (IP TTL) کاهش تدریجی طبق تعداد گام‌ها (مثلاً ۵۳) مقدار نامتعارف (مثلاً ۶۴ از مسیریاب میانی)
اندازه پنجره TCP بازتاب‌دهنده حافظه واقعی درگاه مقادیر ثابت هاردکدشده (۰، ۵۱۲ یا ۱۶۳۸۴)
گزینه‌های TCP Options دارای گزینه‌های SACK-Permitted و مهر زمان خالی از گزینه‌ها (سرآیند ساده ۲۰ بایتی)
شناسه بسته (IPID) افزایشی یا تصادفی استاندارد صفر ثابت یا رفتار گسسته و نامنظم

جهش ناگهانی مقدار TTL از ۵۲ به ۶۲ در بسته RST دریافتی نشان می‌دهد که بسته از سوی مسیریاب میانی ایجاد شده است و نه سرور مقصد.

پیکربندی پارامترهای امنیتی هسته لینوکس

مدیران سیستم می‌توانند با تنظیم متغیرهای هسته مقاومت سیستم در برابر حملات کور را افزایش دهند:

# بررسی سقف نرخ ارسال Challenge ACK در لینوکس
sysctl net.ipv4.tcp_challenge_ack_limit

# افزایش حد نصاب و فعال‌سازی تصادفی‌سازی مدرن
sudo sysctl -w net.ipv4.tcp_challenge_ack_limit=2000

# اطمینان از فعال بودن مقیاس پنجره و تایید انتخابی
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.ipv4.tcp_sack=1

با این حال، اصلاحات سطح هسته تنها از حدس‌های کور جلوگیری می‌کند و در برابر تجهیزات میانی مستقر در مسیر کارایی ندارد.

کپسوله‌سازی رمزنگاری لایه ۳ با فناوری VPNRice RiceGuard

ریشه آسیب‌پذیری تزریق RST در عدم احراز اصالت سرآیندهای پروتکل‌های IPv4 و IPv6 است. تا زمانی که نشانگرهای کنترلی ترابری به صورت متن ساده در شبکه منتقل شوند، تجهیزات میانی امکان دستکاری آن‌ها را خواهند داشت.

رمزنگاری لایه کاربرد مانند TLS 1.3 محتوای داده را محفوظ می‌دارد، اما پوسته بیرونی IP و TCP را آشکار رها می‌کند. سامانه پایش شبکه با شناسایی نام دامنه (SNI) یا نشانی مقصد می‌تواند بلافاصله یک بسته RST بفرستد و اتصال را قطع کند.

[انتقال بدون رمزنگاری لایه ۳: آسیب‌پذیر در برابر تزریق RST توسط DPI]
سرآیند IP | سرآیند TCP (پرچم RST و شماره SEQ) | داده رمزگذاری‌شده TLS
                 ▲
                 تجهیز میانی بسته RST جعلی تزریق می‌کند -> اتصال قطع می‌شود!

─────────────────────────────────────────────────────────────────────────────────────────────

[کپسوله‌سازی در تونل VPNRice RiceGuard: حفاظت کامل رمزنگاری]
IP بیرونی | UDP بیرونی (WireGuard) | کد اصالت‌سنجی ChaCha20-Poly1305 | [IP درونی | TCP درونی | داده]
                                                         ▲
                                تمام سرآیندهای درونی رمزنگاری و امضا شده‌اند!
             بسته‌های جعلی به دلیل نداشتن کلید معتبر بلافاصله دور ریخته می‌شوند.

فناوری VPNRice با استفاده از معماری اختصاصی RiceGuard ترافیک شبکه را درون تونل‌های امن لایه ۳ محافظت می‌کند:

  • رمزنگاری احرازشده با داده‌های مرتبط (AEAD): تمامی بسته‌ها با الگوریتم ChaCha20 رمزگذاری و با کد احراز هویت پیام Poly1305 با طول ۱۲۸ بیت اعتبارسنجی می‌شوند.
  • پنهان‌سازی کامل سرآیندهای ترابری: شماره‌های ترتیبی TCP، پرچم‌ها و اندازه پنجره‌ها درون محتوای رمزنگاری‌شده بسته‌های UDP قرار دارند و برای تجهیزات میانی فقط داده‌های تصادفی غیرقابل تفکیک به نظر می‌رسند.
  • رد فوری داده‌های نامعتبر: هرگونه بسته RST تزریق‌شده از سوی عوامل میانی، به دلیل نداشتن امضای Poly1305 معتبر، در سطح هسته سیستم‌عامل و در کسری از میلی‌ثانیه دور ریخته می‌شود و هرگز به پشته TCP نمی‌رسد.
  • حفاظت از تبادلات DNS: تمام درخواست‌های تبدیل نام به نشانی IP از طریق سرورهای Anycast مستقر در حافظه رم (RAM-only) پردازش می‌شوند تا از افشای متادیتا جلوگیری شود.

انتقال اعتبارسنجی رمزنگاری به پایه رابط شبکه، تضمین می‌کند که نشست‌های TCP در مسیرهای ناامن ارتباطی پایدار، یکپارچه و در امان از قطع تحمیلی باقی بمانند.