حقن حزم TCP RST وهجمات النافذة العمياء: دفاعات RFC 5961 ونفق L3

يعد بروتوكول التحكم في النقل (TCP)، المقنن في الوثيقة RFC 793 منذ عام 1981، العمود الفقري لنقل البيانات عبر شبكة الإنترنت العالمية. عند حدوث خلل برمجي أو إنهاء مفاجئ للاتصال من أحد الطرفين، يعتمد البروتوكول على راية إعادة التعيين (RST) لإنهاء الجلسة فوراً وتحرير موارد الذاكرة في نواة نظام التشغيل. ومع ذلك، نظراً لأن ترويسات بروتوكول TCP التقليدية تفتقر إلى التوقيعات المشفرة، فإن أي جهاز وسيط قادر على مراقبة حركة المرور أو تخمين معلمات الجلسة يمكنه تزييف حزم RST لقطع الاتصال.

تُعرف هذه التقنية باسم حقن حزم TCP RST (أو TCP RST Injection). تستغلها بوابات الفحص العميق للحزم (DPI) وموجهات التوزيع لإسقاط عمليات تنزيل الملفات الكبيرة، وقطع جلسات قواعد البيانات، وإنهاء اتصالات القشرة الآمنة (SSH) وحركة مرور الويب.

لفهم أسباب هشاشة بروتوكول TCP القياسي أمام هجمات التخمين الأعمى داخل نافذة الاستقبال (blind in-window attacks)، يتعين فحص رياضيات نافذة الاستقبال، والحلول التي وضعتها الوثيقة المعيارية RFC 5961، وطريقة الحماية عبر التغليف المشفر في الطبقة الثالثة.

[قبول الحزم داخل النافذة وفقاً لمعيار RFC 793 الأصلي]
نطاق نافذة الاستقبال: [RCV.NXT = 10,000] <─────── 1,048,576 بايت ───────> [1,058,576]
                                                     ▲
                                    حزمة RST مزورة: SEQ = 450,000
                                    (تم القبول! إنهاء الاتصال فوراً)

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

[التحقق الصارم من إعادة التعيين وفقاً للمعيار RFC 5961]
نطاق نافذة الاستقبال: [RCV.NXT = 10,000] <─────── 1,048,576 بايت ───────> [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}$ الحجم المعلن لنافذة الاستقبال.

في حقبة الثمانينيات، كانت سعة الذاكرة المؤقتة صغيرة ولا تتعدى 64 كيلوبايت. أما في الشبكات الحديثة عالية السرعة، فتعتمد الأنظمة عالمياً على ميزة توسيع نافذة TCP Window Scale (المعيار RFC 7323)، مما يرفع حجم نافذة الاستقبال إلى عدة ميغابايت (عادة بين 256 كيلوبايت و 4 ميغابايت).

أدى هذا التوسع الكبير في حجم النافذة إلى خفض أمان أرقام التسلسل بصورة ملحوظة:

1. انكماش مساحة البحث: في فضاء أرقام تسلسل مكون من 32 بت ($2^{32} \approx 4.29 \times 10^9$ قيمة محتملة)، يتطلب تخمين رقم تسلسل محدد ملايين المحاولات. ولكن لإصابة نافذة بحجم 2 ميغابايت، يكفي المهاجم إصابة أي رقم ضمن نطاق متصل يضم $2,097,152$ رقماً.
2. احتمالية نجاح مرتفعة: تبلغ نسبة سقوط رقم عشوائي ضمن النافذة الصالحة $\frac{\text{RCV.WND}}{2^{32}}$. وعند استخدام نافذة بحجم 2 ميغابايت، تكفي بضعة آلاف من الحزم المزورة لإسقاط الجلسة تماماً.
3. عدم تكافؤ استهلاك الموارد: يرسل المهاجم حزماً خفيفة بحجم 40 إلى 54 بايت باستهلاك ضئيل لعرض النطاق، بينما يقوم النظام المستهدف فوراً بتفكيك موارد المقبس وإشعار التطبيق بحدوث انقطاع.

أما بالنسبة للأجهزة الوسيطة الواقعة مباشرة على مسار حركة المرور (in-path middlebox)، فلا حاجة لأي تخمين؛ إذ تقرأ الخماسية المفتوحة للشبكة وترويسات TCP غير المشفرة، وتستخرج قيم $\text{SEG.SEQ}$ الحالية، ثم ترسل حزم RST مزورة في كلا الاتجاهين.

دفاعات المعيار RFC 5961 ومخاطر القناة الجانبية Challenge ACK

في أغسطس 2010، أصدرت مجموعة هندسة الإنترنت (IETF) الوثيقة المعيارية RFC 5961 لتعزيز متانة بروتوكول TCP ضد هجمات الحقن العشوائي لرايات RST و SYN والبيانات. وقد شملت التعديلات الجوهرية ما يلي:

1. المطابقة الصارمة لرقم التسلسل لحزم RST

بموجب البند 3.2 من المعيار RFC 5961، لا تُقبل حزمة RST لإنهاء الاتصال فوراً إلا إذا تطابق رقم تسلسلها تماماً مع رقم التسلسل المتوقع:

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

إذا وقع رقم التسلسل داخل النافذة دون تطابق دقيق ($\text{RCV.NXT} < \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$)، يُمنع مكدس TCP من إنهاء الاتصال. وبدلاً من ذلك، يتوجب عليه إنشاء وإرسال حزمة إشعار تحدي تسمى Challenge ACK إلى الطرف الآخر:

العميل                                                       الخادم
  |                                                            |
  | ------- حزمة RST مزورة (داخل النافذة، SEQ != RCV.NXT) -----> |
  |                                                            |
  | <------ حزمة Challenge ACK (SEQ = SND.NXT, ACK = RCV.NXT) - |
  |                                                            |
  | (المهاجم الخارجي لا يستطيع الرد؛ تدفق البيانات الأصلي مستمر)   |

تحمل حزمة Challenge ACK قيمة $\text{RCV.NXT}$ الحقيقية. وإذا كان طلب الإنهاء صادراً بالفعل عن الطرف الآخر (مثل إعادة تشغيل الجهاز)، فسيستجيب بحزمة RST مطابقة تماماً لرقم الإشعار، مما ينهي الجلسة بانتظام. وإذا كانت الحزمة مزورة، سيتجاهل الطرف الحقيقي حزمة Challenge ACK وتستمر حركة نقل البيانات بصورة طبيعية.

2. تقييد معدل Challenge ACK وثغرة CVE-2016-5696

قد يؤدي الرد على كل حزمة غير صالحة إلى فتح ثغرة هجمات حجب الخدمة (DoS). لذلك فرض المعيار RFC 5961 تقييداً لمعدل توليد حزم Challenge ACK.

في نواة نظام لينكس، ضُبط هذا المعيار عبر متغير sysctl المسمى net.ipv4.tcp_challenge_ack_limit، والذي كان محدداً مبدئياً بـ 100 أو 250 حزمة في الثانية لكامل نظام التشغيل.

في عام 2016، اكتشف فريق من الباحثين بقيادة تشيون تشيان (Zhiyun Qian) ثغرة خطيرة ناتجة عن مشاركة هذا العداد العام (CVE-2016-5696). وبما أن العداد كان عاماً ومشتركاً بين كافة الاتصالات، تمكن مهاجم خارجي من إنشاء اتصال TCP طبيعي مع الخادم وإرسال حزم استكشافية إلى مقبسه الخاص مع رصد عدد حزم Challenge ACK المستلمة. ومن خلال ذلك، استطاع استنتاج ما إذا كانت حزمة الاستكشاف المرسلة إلى اتصال الضحية قد استهلكت حصة العداد العام.

أتاحت هذه القناة الجانبية:

• تحديد المنفذ المؤقت للعميل بدقة خلال ثوانٍ.
• كشف نطاق أرقام التسلسل للجلسة النشطة.
• حقن بيانات ضارة أو إجبار الاتصال على التوقف رغم وجود معيار RFC 5961.

عولجت الثغرة لاحقاً بتوزيع حدود التقييد عشوائياً وتخصيص موقتات منفصلة لكل اتصال داخل نواة النظام.

تمييز حزم RST المزورة عبر تحليل حركة البيانات

يستطيع مهندسو الشبكات كشف عمليات حقن الحزم بفحص السجلات المجمعة بواسطة tcpdump أو Wireshark. وتظهر الحزم المزورة الصادرة من الأجهزة الوسيطة مؤشرات واضحة:

# التقاط حزم RST المشبوهة عبر واجهة الشبكة eth0
sudo tcpdump -ni eth0 'tcp[tcpflags] & tcp-rst != 0' -vvv -c 20

أربعة معايير تفريق رئيسية بين الحزم الحقيقية والمزورة:

يعد الارتفاع المفاجئ لقيمة TTL من 52 إلى 62 في حزمة RST دليلاً قاطعاً على أنها صادرة عن موجه وسيط في مسار الشبكة وليس عن الخادم الوجهة.

إعدادات الأمان في نواة نظام التشغيل

يستطيع مديرو الأنظمة التحقق من معلمات النواة ذات الصلة بالمعيار RFC 5961 وضبطها لرفع مستوى مقاومة النظام:

# فحص الحد الحالي لمعدل 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 أو SSH حمولة البيانات الأصلية، لكنه يترك ترويسات IP و TCP مكشوفة. ويمكن لأجهزة الفحص عند رصد اسم الخادم (SNI) أو العنوان المستهدف أن ترسل فوراً حزمة RST لقطع الاتصال دون الحاجة لفك تشفير محتوى TLS.

[النقل غير المشفر في الطبقة الثالثة: عرضة لحقن RST عبر DPI]
ترويسة IP | ترويسة TCP (راية RST ورقم SEQ) | بيانات مشفرة بـ TLS
                 ▲
                 جهاز وسيط يحقن RST مزورة -> ينقطع الاتصال فوراً!

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

[التغليف التشفيري عبر VPNRice RiceGuard: حماية مشفرة كاملة]
IP خارجي | UDP خارجي (WireGuard) | رمز التحقق ChaCha20-Poly1305 | [IP داخلي | TCP داخلي | بيانات]
                                                              ▲
                               جميع ترويسات التحكم مشفرة وموقعة بالكامل!
            الحزم المزورة تفتقر إلى رمز التحقق السليم ويتم إسقاطها فوراً.

تعالج خدمة VPNRice هذه الثغرة البنيوية من خلال عزل وتغليف كافة حركات البيانات داخل نفق آمن في الطبقة الثالثة يعمل بمحرك RiceGuard:

• تشفير معتمد مع بيانات ملحقة (AEAD): تُشفر كافة الحزم المارة عبر النفق بخوارزمية ChaCha20 مع رمز مصادقة الرسائل Poly1305 بطول 128 بت.
• إخفاء ترويسات التحكم بالكامل: تُحفظ أرقام التسلسل لبروتوكول TCP والرايات وحجم النوافذ والإشعارات داخل الحمولة المشفرة لحزم UDP الخارجية، ولا تظهر للمراقبين إلا كبيانات تشفيرية عشوائية.
• إسقاط فوري للحزم المزورة: إذا حاول طرف وسيط حقن حزمة RST في تدفق البيانات، فستفشل الحزمة في اختبار التحقق Poly1305 ويتم التخلص منها فوراً على مستوى نواة النظام بأقصى سرعة دون أن تصل إلى مكدس TCP الداخلي.
• حماية استعلامات DNS: تمر كافة طلبات تحليل النطاقات عبر خوادم Anycast تعمل في الذاكرة العشوائية فقط (RAM-only)، مما يمنع تسرب البيانات الوصفية التي قد تحفز عمليات الحقن.

من خلال تثبيت التحقق التشفيري في قاعدة واجهة الشبكة، يضمن التغليف التشفيري بقاء جلسات TCP مستقرة ومحمية تماماً ضد محاولات القطع العشوائي على طول مسارات الاتصال الوسيطة.