كيفية تجنب هجوم DOS باستخدام مآخذ بيركلي في C ++

Question

أنا أعمل طريقي برمجة شبكة يونيكس حجم 1 بواسطة Richard Stevens ومحاولة كتابة عميل TCP Echo يستخدم بروتوكول Telnet. ما زلت في المراحل المبكرة ومحاولة كتابة وظائف القراءة والكتابة.

أود أن أكتبها لاستخدامها لاستخدام I / O متعددة الوظائف ومحدد، لأنها تحتاج إلى أن تكون متعددة العميل ولا أريد أن أحاول أن أحاول وتعالج تعلم الخيوط C ++ بينما أحاول تعلم مكتبة بوركلي مآخذ في نفس الوقت. في نهاية الفصل عن I / O، يوجد لدى Stevens مقطع صغير حول هجمات DOS حيث يقول إن الطريقة التي كنت أخطط لها على استخدام هجمات DOS التي ببساطة إرسال بايت واحد بعد الاتصال ثم تعليقها. يذكر 3 حلول ممكنة بعد ذلك - غير الحلق IO، خيوط (خارج)، ووضع مهلة في عمليات الإدخال / الإخراج.

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

أيه أفكار؟

Answer 1

... هل هناك أي طرق أخرى لتجنب مثل هذا الهجوم؟

نعم، أنا / س غير متزامن هو نهج عام آخر.

إذا كانت المشكلة هي حجب read() قد تعلق إعدامك إلى أجل غير مسمى، فإن التدابير المضادة العامة الخاصة بك هي:

1. لديك مواضيع متعددة للتنفيذ

   متعدد الخيوط، متعددة العملية، كلاهما.

2. الوقت - الحد من عملية الحظر

   على سبيل المثال، لحظية (غير الحظر I / O)، أو لا (SO_RCVTIMEO, alarm(), ، إلخ.)

3. تشغيل غير متزامن

   على سبيل المثال، aio_read

... أي من هذه هي الأفضل؟

للوافد الجديد، أود أن أقترح عدم حجب I / O مجتمعة مع وقت محدود select()/poll(). وبعد يمكن للتطبيق الخاص بك تتبع ما إذا كان الاتصال قد ولادته "بيانات كافية" (على سبيل المثال، خط كامل) في "وقت قصير بما فيه الكفاية".

هذه تقنية قوية ومحطة للغاية ومشتركة.

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

Answer 2

القراءة الأساسية: مشكلة C10K.

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

باستخدام IO غير متزامن لوضع جميع المقابس في سلسلة واحدة ليست كود واضح (ملفوفة بشكل جيد بواسطة Libvent و Libev2.) ولكن هو أكثر قابلية للتوسعة - محدود من خلال عدد الملفات المفتوحة مقابض نظامك يسمح بنظام Linux مؤخرا على سبيل المثال - يمكن قياسها بملايين! تستخدم معظم خوادم الويب والخوادم الأخرى IO غير متزامن لهذا السبب.

ومع ذلك، لا يزال الخادم الخاص بك موردا محددا يمكن استنفاده، وهناك الكثير من الهجمات nastier من مجرد نفاد القدرة على التعامل مع الاتصالات الجديدة.

جدران الحماية والتقييد الضرر مثل النسخ الاحتياطية، DMZS وغيرها هي العناصر الأساسية في خدمات حقيقية مواجهة للإنترنت.

Answer 3

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

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

Answer 4

سؤالي هو، هل هناك أي طرق أخرى لتجنب مثل هذا الهجوم؟

لخادم أريد مؤقتا على مستوى التطبيق:

• إدخال بيانات الإدخال لكل اتصال
• يقرأ رمز قراءة المقبس البكم البيانات من المقبس في المخزن المؤقت للإدخال
• رمز التطبيق الخاص بالتطبيق يوزع محتوى المخزن المؤقت الإدخال

يمكن لرمز التطبيق الخاص بالتطبيق إنهاء الاتصال المرتبط بمخازن المخازن المؤقتة للمخططات التي تم السماح لها بمخطهد "لفترة طويلة".

القيام بذلك يعني أن Asynch I / O، أو مؤشر ترابط I / O مخصص [S].

Answer 5

ما قمت به من قبل، للمساعدة في هذا (Circa 1997 :) كان يتطلب إرسال رقم سحري في غضون فترة معينة أخرى تم إغلاق الاتصال.

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

هذا ليس مثاليا، ولكن من أجل قلقك الحالي، قد يساعد ذلك في حلها، واسمحوا بالموارد غير المستهلكة من خلال جعل الكثير من الاتصالات.

لذلك يتطلب خيط رئيسي وخيط ثان للتنظيف، لذلك ليس خيوط واحدة.