تصليب JBoss / WildFly ضد DDoS: حدود مستمع Undertow وخيوط الإدخال والإخراج

يُصلّب هذا الدليل خادمَي JBoss EAP وWildFly نفسيهما ضد الجزء المُستنزِف للاتصالات والخيوط من هجوم DDoS. وأول فرق مهم: في EAP أو WildFly حديث، خادم الويب هو Undertow لا موصّل JBossWeb القديم، وكل شيء يُضبط في نظام Undertow الفرعي عبر واجهة الإدارة CLI. فإن كنت لا تزال على JBoss AS 5/6 بـ JBossWeb فإن دليل Tomcat أقرب إلى إعدادك، والفكرة الأكبر أن خادماً انتهى دعمه هو بذاته ثغرة.

كما في Tomcat، فإن JBoss خادم تطبيقات ويُوضع خلف طبقة أمامية مُصلَّبة. وحدود Undertow أدناه هي الخط الثاني، يُطبَّق خلف تلك الطبقة. وتأتي كل خاصية مع أمر jboss-cli.sh والعدّاد الذي يُظهر عملها.

الجهاز	شكل الهجوم	خاصية Undertow	مسار CLI
ترويسة بطيئة / جسم بطيء	no-request-timeout, request-parse-timeout	/subsystem=undertow/server=*/http-listener=*
طوفان الاتصالات	max-connections; tcp-backlog	http-listener + socket-binding
استنزاف الخيوط / الإدخال والإخراج	io-threads, task-max-threads (worker)	/subsystem=io/worker=default
إساءة استخدام الطلبات الكبيرة	max-header-size, max-parameters, max-post-size	/subsystem=undertow/server=*/http-listener=*
التعرّض المباشر للإنترنت	اربط المستمع داخلياً؛ الطبقة الأمامية تُنهي الاتصال	واجهة socket-binding

مثل Tomcat، فإن JBoss خادم تطبيقات: التصميم القياسي يضع أمامه طبقة مُصلَّبة، وحدود Undertow هذه هي الخط الثاني خلفها. ولا ينفع أيٌّ منها حين يملأ الهجوم القناة.

0. أولاً القياسات المرجعية: اقرأ مقاييس المستمع ومجموعة العمل

يوفّر Undertow ونظام الإدخال/الإخراج الفرعي مقاييس وقت التشغيل عبر CLI. فعّل الإحصاءات واقرأها خلال أسبوع عادي:

# تفعيل إحصاءات Undertow
/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)

# الاتصالات النشطة والمعالجة على مستمع HTTP
/subsystem=undertow/server=default-server/http-listener=default:read-resource(include-runtime=true)

# مجموعة العمل: الخيوط المشغولة مقابل core/max
/subsystem=io/worker=default:read-resource(include-runtime=true)

عدد الاتصالات النشطة للمستمع وعدد الخيوط المشغولة في مجموعة العمل هما القياسان المرجعيان اللذان تُضبط كل قيمة أدناه قياساً عليهما.

1. الطبقة الأمامية أولاً

تأكّد أن Undertow ليس مكشوفاً مباشرةً على واجهة عامة:

# يجب أن يكون http socket-binding على واجهة داخلية لا عامة
/socket-binding-group=standard-sockets/socket-binding=http:read-resource(include-runtime=true)
ss -ltnp | grep 8080

إن كان عاماً فاربطه داخلياً ودع طبقة أمامية مُصلَّبة تُنهي اتصال الإنترنت. ويتناول تلك الطبقة دليلا nginx وApache. فالطبقة الأمامية تحمل TLS وتحديد المعدّل وطرد الاتصالات البطيئة أفضل مما ينبغي لخادم تطبيقات أن يحمله.

2. حدود اتصال المستمع ومُهَله الزمنية

يحمل http-listener سقف الاتصالات والمُهلتين اللتين تجيبان عن هجمات الطلب البطيء. اضبطهما عبر CLI:

# حدّ الاتصالات المتزامنة على المستمع
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-connections,value=8192)

# Slowloris: الوقت المتاح لتحليل ترويسات الطلب
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=request-parse-timeout,value=30000)

# اتصال خامل لم يُرسل طلباً
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=no-request-timeout,value=30000)

# طبّق عبر reload لا إعادة تشغيل
reload

كلتا المُهلتين غير مضبوطتين افتراضياً، لذا يجب ضبطهما صراحةً على أي مستمع مكشوف. request-parse-timeout يمسك من يُقطّر الترويسات؛ وno-request-timeout يمسك من يفتح اتصالاً ولا يُرسل شيئاً.

3. الفصل بين خيوط الإدخال/الإخراج وخيوط العمل

يفصل Undertow خيوط الإدخال/الإخراج غير الحاجبة عن مجموعة العمل الحاجبة. حدّد حجم كلٍّ منهما بشكل مستقل ولا تخلط بينهما:

# خيوط الإدخال/الإخراج تُدير حلقة الأحداث؛ حدّدها بعدد الأنوية (قاعدة شائعة: الأنوية أو الأنوية*2)
/subsystem=io/worker=default:write-attribute(name=io-threads,value=8)

# مجموعة العمل تعالج العمل الحاجب (servlet)؛ حدّدها بحسب ما تحتمله الكومة/التطبيق
/subsystem=io/worker=default:write-attribute(name=task-max-threads,value=128)

reload

تضخيم io-threads لا يفيد أمام عنق زجاجة في العمل الحاجب، وتضخيم task-max-threads فوق ما تحتمله الكومة يُبدّل استنزافاً باستنزاف للذاكرة. والاتصال البطيء تخدمه خيوط الإدخال/الإخراج بوصفه مخزناً مؤقتاً، ولهذا يقاوم Undertow هجوم Slowloris بحكم تصميمه. والمُهَل أعلاه تحوّل تلك المناعة شبه الكاملة إلى طرد فعلي.

4. حدود حجم الطلب

أغلق سطح الطلبات الكبيرة على المستمع:

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-header-size,value=8192)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-parameters,value=1000)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-headers,value=100)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-cookies,value=50)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-post-size,value=10485760)
reload

max-parameters وmax-headers مهمّتان لأكثر من الذاكرة: العدد غير المحدود وسيلة رخيصة لحرق المعالج في التحليل، وتاريخياً لإطلاق هجوم على تصادم الـ hash. والقيم الافتراضية سخيّة؛ وتضييقها على مستمع مكشوف لا يكلّف شيئاً مشروعاً.

5. طابور TCP backlog

قيمة backlog في socket-binding هي طابور الاتصالات على مستوى نظام التشغيل المنتظرة للقبول، وهي نظير acceptCount في Tomcat:

/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=backlog,value=200)
reload

أبقِ الـ backlog قصيراً لا كبيراً. الطابور الكبير يؤخّر فقط الرفض الذي يحمي مجموعة العمل.

6. عنوان العميل خلف الطبقة الأمامية

مع وجود طبقة أمامية، يجب تفعيل proxy-address-forwarding وإلا سجّلت كل سطر سجلّ وكل قاعدة عنوان الطبقةَ الأمامية لا العميل:

# تفعيل معالجة forwarded-for على المستمع
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)
reload

بدونه يُنسب كل طلب إلى الطبقة الأمامية — وهو خلل proxy-IP المتكرّر عبر السلسلة كلها.

العدّادات التي تُربط بالمراقبة

# 1. الاتصالات النشطة على المستمع (read-resource include-runtime) مقابل max-connections
# 2. خيوط العمل المشغولة مقابل task-max-threads (/subsystem=io/worker=default)
# 3. عدّادات request-parse-timeout وno-request-timeout (إحصاءات وقت تشغيل المستمع)
# 4. عدّادات الأخطاء/المعالجة من إحصاءات المستمع
/subsystem=undertow/server=default-server/http-listener=default:read-resource(include-runtime=true,recursive=true)

بلوغ الاتصالات النشطة قيمة max-connections مع انشغال مجموعة العمل علامة أن معدّل الطلبات تجاوز ما يقدر Undertow على استيعابه، وهي النقطة التي يجب فيها أن تأخذ الطبقة الأمامية أو طبقة أعلى الفائض.

الحدّ الصادق لتصليب JBoss

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

الأولى إشباع القناة: الحجم الذي يملأ الأنبوب لا يصل لا إلى الطبقة الأمامية ولا إلى Undertow.

والثانية طبقة نظام التشغيل تحت الخوادم، ويتناولها دليلا Linux وWindows. ويفترض تصليب JBoss أن الطبقة الأمامية وطبقة نظام التشغيل كلتيهما في مكانهما. وفوق القناة يكون الجواب في الطبقة الشبكية.

ترتيب التطبيق

1. تأكّد أن المستمع مربوط داخلياً؛ ضع أمامه طبقة مُصلَّبة.
2. فعّل إحصاءات Undertow؛ سجّل القياسات المرجعية.
3. اضبط max-connections ومُهلتَي الطلب عبر CLI.
4. حدّد io-threads بعدد الأنوية وtask-max-threads بحسب الكومة.
5. فعّل proxy-address-forwarding كي ترى السجلات والقواعد العميل الحقيقي.
6. اضبط حدود حجم الطلب وطابوراً قصيراً.
7. اربط مقاييس وقت التشغيل بالمراقبة.

وأكثر ما يغيّر النتيجة هو الخطوة الأولى مجدداً. حدود Undertow خط ثانٍ، والخط الثاني لا ينفع إلا بقدر نفع الخط الأول الذي يقف خلفه.