يستخدم موقعي الإلكتروني Discourse. في البداية، لم يكن محميًا بواسطة Cloudflare وتعرض لهجوم DDoS.
لاحقًا، قمت بتغيير عنوان IP وقمت بتطبيق Cloudflare. ومع ذلك، تعرض الموقع لهجوم DDoS مرة أخرى، ويبدو أنه بسبب تسرب عنوان IP الخاص بالخادم الأصلي.
عند استخدام Cloudflare CDN، كيف يمكننا منع تسرب عنوان IP الخاص بالخادم الأصلي؟ هل لدى أي شخص طرق جيدة؟ شكراً لكم.
لا أعرف، ولكن سيتم تسريب عنوان IP الخاص بكل خادم متصل بالإنترنت في نفس الوقت الذي يتم فيه إنشاؤه.
يمكنك منع الكثير من التسرب عن طريق القيام بما يلي
- إعداد خادم وكيل مثل Tinyproxy على خادم افتراضي خاص مختلف
- تعيين متغير البيئة
HTTPS_PROXYوHTTP_PROXYحتى يستخدم Discourse ذلك (قم بتعيينهما في قسمenvمنapp.ymlالخاص بك) - تعيين
NO_PROXY='127.0.0.1, localhost, \u003cinternal-network\u003e'
انظر أيضًا Install discourse with internet access only via proxy ، Configuration outbound proxy و Discourse Link previews through a proxy server? - #14 by supermathie
أيضًا، عندما تكون خلف CF، يمكنك تعديل جدار الحماية على مضيف Discourse الخاص بك للسماح فقط بحركة المرور الواردة من عناوين IP الخاصة بـ Cloudflare (والمضيف الذي تصل إليه بنفسك)
4 إعجابات
هذا هو الحل. الأمان عن طريق الإخفاء ليس آمنًا. بعد ذلك لن يهم إذا كانت معلومات IP الخاصة بك معروفة للجميع.
3 إعجابات
هذا أو بدلاً من ذلك، نهج أبسط هو استخدام ما يسمى بنفق Cloudflare. يجب أن يكون إعدادًا لمرة واحدة وبعد ذلك يجب أن تكون قادرًا على إغلاق جدار الحماية الخاص بك لمعظم الاتصالات الواردة.
إعجابَين (2)
أعتقد أنني اتبعت هذا منذ فترة (بدون إعداد الوكيل الذي ذكرته). لست متأكدًا مما إذا كان هذا ينطبق على جميع جدران الحماية (أو ربما شيء ما في إعداداتي)
ولكن في حالتي مع ufw، تجدر الإشارة إلى أن docker يتجاوز ufw افتراضيًا، لذا تحتاج إلى التأكد من تطبيق القواعد على عناوين IP الداخلية الخاصة بـ docker أيضًا.
لقد مر وقت طويل، ولكن يمكنني البحث عن مزيد من التفاصيل إذا كنت لا تزال بحاجة إلى ذلك، في وقت لاحق من هذا الأسبوع.
ونعم، أنفاق Cloudflare مذهلة! @itsbhanusharma
إعجاب واحد (1)
ستحتاج إلى استخدام جدار الحماية الذي يوفره لك مزود خدمة الخادم الافتراضي الخاص بك. سيكون استخدام جدار حماية يعتمد على المضيف أقل فعالية بكثير في مكافحة هجمات DDoS نظرًا لأن حركة المرور تصل بالفعل إلى مكدس الشبكة الخاص بك.
3 إعجابات
أعتقد أن معظم المزودين الكبار يقدمون حماية ضد هجمات DDoS افتراضيًا؟ ألا ينبغي أن يكون هذا كافيًا؟ إضافة عناوين IP الخاصة بـ Cloudflare يدويًا عبر الواجهة تبدو مزعجة (برنامجي النصي المخصص بلغة bash يستغرق ثانيتين ويجلب عناوين IP الخاصة بـ Cloudflare تلقائيًا على سبيل المثال).
يجب أن أقول إنني عادةً ما أقرأ العكس، جدار الحماية المحلي / ufw فوق جدار الحماية الخاص بالمزود 
تعديل؛ أنا أفهم المنطق هنا، من منظور هجمات DDoS، هذا ربما يكون أكثر فعالية وأنت على حق. ومع ذلك، إذا تم إخفاء عنوان IP الرئيسي بشكل صحيح منذ البداية، فلا ينبغي أن تكون هجمات DDoS مشكلة، أليس كذلك؟
إعجاب واحد (1)
معظم المزودين لديهم واجهة برمجة تطبيقات (API) لهذا الغرض هذه الأيام؟
صحيح! ولكن هذا “إذا” كبير جدًا…
إعجابَين (2)
في الواقع خطأ. لمجرد أن عنوان IP ليس مخفيًا أبدًا. لا تعد هجمات الحرمان من الخدمة (DDoS) مشكلة إذا كان لدى وكيل عكسي أو ما شابه أدوات لمنعها. وحتى في ذلك الحين، عندما يكون هناك هجوم حقيقي، يلزم شيء أكثر من حلول للمبتدئين. وإذا كانت الروبوتات أو المستخدمون العبيد يطرقون المنافذ المغلقة أو المنافذ المحدودة بعنوان IP، فهذه ليست مشكلة كبيرة. أسمي هذا يوم خميس آخر في عالم ووردبريس، لكن ديسكورس عالم آخر بالعديد من الطرق.
من ناحية أخرى، أنا لست خبيرًا في هذا.
لكنني فضولي… ما مقدار حركة المرور المطلوبة لنجاح هجوم الحرمان من الخدمة (DDoS)؟ بالطبع يعتمد الأمر على موارد الإعداد، ولكن يرجى إعطائي بعض الأرقام.
إعجاب واحد (1)
يعتمد الأمر على تعريفك لـ مخفي. نعم، جميع عناوين IP عامة. ولكن بعد ذلك، أي من مليارات عناوين IP هو العنوان الصحيح؟ أعتقد أنه بالنسبة لهذا النقاش، يمكن اعتبار عنوان IP مخفيًا إذا لم تكن هناك طريقة لتحديد عنوان IP (عناوين IP) لخادم يخدم منتدى Discourse معين (لذا فإن الدالة f(h) غير محددة حيث تعطيك الدالة f عنوان IP الحقيقي للمضيف)
بالنظر إلى:
- أنك لست Cloudflare
- أن المنتدى لا يكشف عن عنوان IP الخاص به من خلال حركة المرور الصادرة مثل oneboxing أو رؤوس البريد الإلكتروني الصادرة أو أي طريقة أخرى
لكنني أتفق معك في أن “مخفي” مصطلح مربك وغير صحيح. “غير معروف” ربما يكون أفضل.
هذا يعتمد على نوع هجوم DDoS. بالنسبة لهجوم على مستوى التطبيق، قد يكون هذا صحيحًا، ولكنه أيضًا صعب نظرًا لأنه سيتطلب نوعًا من تحديد المعدل مع فحص الطلبات. ولكن بالنسبة لهجوم على مستوى الشبكة (مجرد إغراق حركة المرور عن طريق التضخيم أو هجوم syn) قد لا يكون هذا صحيحًا. علاوة على ذلك، ما تقوله في الأساس هو “إنها ليست مشكلة إذا كان بإمكانك التخفيف منها” وهو أمر بديهي إلى حد ما، ولكنه أيضًا صعب و/أو مكلف.
يعتمد الأمر أيضًا على نوع الهجوم. سيحتاج هجوم مستوى التطبيق إلى تخصيصه لـ Discourse ولكنه قد يقوم على سبيل المثال بتشغيل بعض الاستعلامات الثقيلة مثل عمليات البحث لإغراق خوادم التطبيق، بينما يمكن أن يكون هجوم مستوى الشبكة أكثر عمومية، ويأخذ المزيد من حركة المرور ويمكنه ببساطة سد nginx أو شبكة VPS.
4 إعجابات
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.