هل يمنع TCP/IP إعادة تشغيل الحزم؟

Question

هل يمنع TCP/IP نسخًا متعددة من نفس الحزمة من الوصول إلى الوجهة؟أم أن الأمر متروك لنقطة النهاية لطبقة منطق العجز فوقها؟

الرجاء الرجوع إلى فقرات محددة من مواصفات TCP/IP إن أمكن.

Answer 1

إنها مهمة مكدس TCP للتعافي من الحزم المكررة:

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

-- آر إف سي 793 - بروتوكول التحكم في النقل، القسم 1.5

ومع ذلك، إذا كانت نفس الحزم بأرقام تسلسلية جديدة، فلا.

Answer 2

يستخدم TCP أرقام التسلسل لاكتشاف التكرار في حالة إعادة الإرسال، مما سيمنع أيضًا هجمات إعادة التشغيل التافهة.

من RFC 793، القسم 3.3 - الأرقام التسلسلية:

تتمثل الفكرة الأساسية في التصميم في أن كل ثمانية من البيانات المرسلة عبر اتصال TCP لها رقم تسلسل.نظرًا لأن كل ثماني متسلسل ، يمكن الاعتراف بكل واحد منها.إن آلية الإقرار المستخدمة هي تراكمية بحيث يشير إقرار رقم التسلسل X إلى أنه تم استلام جميع الثمانيات حتى لا تضم ​​X.تتيح هذه الآلية اكتشاف مكررة مباشرة في وجود إعادة الإرسال.إن ترقيم الثمانيات داخل القطاع هو أن أول ما بعد البيانات التي تلي رأس العنوان هي أدنى ترقيم ، ويتم ترقيم الثمانيات التالية على التوالي.

سيضمن اكتشاف التكرارات عدم إمكانية إعادة إرسال نفس الحزمة بشكل تافه.ستضمن الأرقام التسلسلية أيضًا ملاحظة إدراج البيانات (بدلاً من استبدالها) في تدفق البيانات، حيث أن الحزم المشروعة الإضافية التي تتبع الحزم المزورة سيكون لها أرقام تسلسلية مكررة، مما سيؤدي إلى تعطيل تدفق البيانات.من المحتمل أن يتسبب هذا في إسقاط تلك الحزم كنسخ مكررة، مما قد يؤدي على الأرجح إلى كسر البروتوكول المستخدم.

يمكن العثور على مزيد من المعلومات حول مواصفات TCP/IP الأصلية (1981) في آر إف سي 793, والعديد من طلبات RFC الأخرى التي تتضمن امتدادات أو تعديلات على بروتوكول TCP/IP.

Answer 3

نعم، تمنع طبقة TCP الحزم المكررة.طبقة IP الموجودة تحتها لا تفعل ذلك.

التفاصيل في آر إف سي 1122.

Answer 4

يبدو أنك قلق بشأن شيئين مختلفين:

1. ما هي الضمانات التي يوفرها التسليم الموثوق لـ TCP؟
2. هل يمكن للمهاجم أن يؤثر على عملية الخادم الخاص بي من خلال هجوم إعادة التشغيل

الإجابة على 1:

يضمن TCP تسليمًا موثوقًا ومرتبًا لسلسلة من البايتات.ما هي البيانات التي يرسلها تطبيق العميل إلى TCP عبرها write() سوف يخرج بالضبط نفس الشيء خلال الخادم read() يتصل.

الرد على 2:

لا تعمل هجمات إعادة التشغيل بشكل جيد مع TCP، نظرًا لأن كل اتصال يعتمد على رقمين عشوائيين 32 بت يتم إنشاؤهما بواسطة العميل والخادم على التوالي.لكي ينجح هجوم إعادة التشغيل، يجب على المهاجم تخمين الرقم التسلسلي الذي أنشأه الخادم للاتصال المزيف الذي بدأه (من الناحية النظرية، لدى المهاجم فرصة 1 / 2**32 للتخمين بشكل صحيح).إذا قام المهاجم بالتخمين بشكل غير صحيح، فسوف يتسبب في أسوأ الأحوال في حدوث بعض التخزين المؤقت للبيانات في نظام التشغيل الخاص بك.

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

Answer 5

يمكن للطبقات الموجودة أسفل TCP تجربة حزم متعددة أو حزم مُسقطة.لا تواجه الطبقات الموجودة فوق TCP التكرار أو الحزم المسقطة.

Answer 6

لا أعرف شيئًا عن تكرار الحزم، لكنني لم أواجهها مطلقًا باستخدام TCP/IP وأعلم أنها تضمن وصول جميع الحزم وبالترتيب الصحيح، لذلك لا أستطيع أن أفهم سبب عدم حدوث ذلك.

Answer 7

يعتمد الأمر حقًا على كيفية تلقيك لبياناتك - على الرغم من أنه من الناحية الفنية لا ينبغي أن يمنحك البروتوكول نسخًا مكررة (على سبيل المثال.الحزم التي لها نفس المجموع الاختباري لـ TCP)، قد تؤدي عوامل أخرى إلى ظهور نسخ مكررة - على سبيل المثال، أجهزة الشبكة التي تستخدمها؛أيضًا إذا كنت تستخدم المتشممون للنظر إلى تدفقات tcp، بدلاً من مجرد قراءة مأخذ توصيل مفتوح في تطبيقك، فمن الممكن الحصول على حزم dup من المتشممين حتى لو كانت تدفقات tcp الفعلية التي كانوا يراقبونها لا تحتوي على حزم dup.

لإعطاء مثال من العالم الحقيقي - في الوقت الحالي، أعمل على بعض تحليلات برنامج التعاون الفني (TCP) للشبكات الداخلية لبورصة كبرى، والبيانات التي أطلع عليها تأتي من عدة متشممين ويتم ربطها معًا مرة أخرى.لذلك، عند سحب البيانات، وجدت أنني بحاجة إلى القيام بعدد من خطوات المعالجة المسبقة، بما في ذلك البحث عن التكرارات وإزالتها.على سبيل المثال، في تدفق قرأته للتو، من بين ما يقرب من 60.000 حزمة بيانات، قمت بتحديد موقع 95 حزمة مكررة وإزالتها.

الإستراتيجية التي أتبعها هنا هي الاحتفاظ بنافذة متجددة لأحدث 10 مجاميع اختبارية لـ TCP، وتجاهل الحزم التي تطابق تلك المجاميع الاختبارية.لاحظ أن هذا يعمل بشكل جيد مع حزم PSH، ولكنه ليس جيدًا بالنسبة لحزم ACK - لكنني أقل اهتمامًا بها على أي حال.

لقد كتبت مجموعة خاصة بغرض تتبع هذه النافذة المتدرجة للمجموعات الاختبارية لـ TCP، والتي قد تكون مفيدة للآخرين:

/// <summary>
/// Combination of a double-linked-list and a hashset with a max bound; 
/// Works like a bounded queue where new incoming items force old items to be dequeued; 
/// Re-uses item containers to avoid GC'ing;
/// Public Add() and Contains() methods are fully thread safe through a ReaderWriterLockSlim;
/// </summary>
public class BoundedHashQueue<T>
{
    private readonly int _maxSize = 100;
    private readonly HashSet<T> _hashSet = new HashSet<T>();
    private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
    private readonly Item _head;
    private readonly Item _tail;
    private int _currentCount = 0;

    public BoundedHashQueue(int maxSize)
    {
        _maxSize = maxSize;
        _head = _tail = new Item();
    }

    private class Item
    {
        internal T Value;
        internal Item Next;
        internal Item Previous;
    }

    public void Add(T value)
    {
        _lock.Write(() =>
            {
                if (_currentCount == 0)
                {
                    Item item = new Item();
                    item.Value = value;
                    _head.Next = item;
                    item.Previous = _head;
                    item.Next = _tail;
                    _tail.Previous = item;
                    _currentCount++;
                }
                else
                {
                    Item item;
                    if (_currentCount >= _maxSize)
                    {
                        item = _tail.Previous;
                        _tail.Previous = item.Previous;
                        _tail.Previous.Next = _tail;
                        _hashSet.Remove(item.Value);
                    }
                    else
                    {
                        item = new Item();
                        _currentCount++;
                    }
                    item.Value = value;
                    item.Next = _head.Next;
                    item.Next.Previous = item;
                    item.Previous = _head;
                    _head.Next = item;
                    _hashSet.Add(value);
                }
            });
    }

    public bool Contains(T value)
    {
        return _lock.Read(() => _hashSet.Contains(value));
    }
}}

Answer 8

أنت لا تفهم المشكلة بشكل كامل.انظر هذا الرابط:http://en.wikipedia.org/wiki/Transmission_Control_Protocol

في هذه الصفحة يكتب :

"تساعد الطوابع الزمنية لـ TCP، المحددة في RFC 1323، TCP في حساب وقت الرحلة ذهابًا وإيابًا بين المرسل والمستقبل.تتضمن خيارات الطابع الزمني قيمة طابع زمني 4 بايت، حيث يقوم المرسل بإدراج قيمته الحالية لساعة الطابع الزمني الخاصة به، وقيمة الطابع الزمني لرد الصدى 4 بايت، حيث يقوم المتلقي عمومًا بإدراج قيمة الطابع الزمني الأحدث التي استلمها.يستخدم المرسل الطابع الزمني لرد الصدى في الإقرار لحساب إجمالي الوقت المنقضي منذ إرسال المقطع الذي تم الإقرار به.[2]

تُستخدم الطوابع الزمنية لـ TCP أيضًا للمساعدة في حالة مواجهة أرقام تسلسل TCP لـ 2 ^ 32 و"التفاف حول" مساحة الرقم التسلسلي.يُعرف هذا المخطط باسم الحماية من أرقام التسلسل الملتفة، أو PAWS (راجع RFC 1323 للحصول على التفاصيل)."

التحيات ، المفصل (بولندا)