هجوم حجب الخدمة Slowloris

مقدمة

يَستعمل هجوم حجب الخدمة Slowloris (أو ما يعرف باسم Slowloris HTTP DOS Attack) طلبات HTTP GET لشغل جميع اتصالات HTTP المتاحة والمسموح بها على خادم الوب.

يَستغل هذا الهجوم الثغرة الموجودة في مخدمات الوب التي تعتمد في عملها على النياسب (thread-based web servers) التي تنتظر وصول ترويسة بروتوكول HTTP بتمامها قبل تحرير الاتصال. ومع أن بعض مخدمات الوب التي تعتمد على النياسب تستعمل مؤقتًا لانتظار اكتمال ترويسة HTTP بزمن قدره 300 ثانية (افتراضيًّا)، فإن هذا المؤقت يعاد تعيينه إذا أرسل الزبون أية بيانات. وهذا يتيح لمن يريد الأذية أن يفتح عدّة اتصالات مع المخدم عن طريق إرسال طلبات HTTP غير مكتملة، ويستطيع الحفاظ على هذا الاتصال محجوزًا عن طريق إرسال بيانات زائفة للمخدم قبل نفاد الوقت المعين للمؤقت ليعاد تعيينه من جديد. وهكذا يستطيع المهاجم الحفاظ على الاتصال مفتوحًا ما لم يغلقه بنفسه. وبطبيعة الحال إذا قام أحد المهاجمين بحجز جميع اتصالات HTTP المتاحة على مخدم الوب، فلن يتمكن المستعملون الشرعيون من حجز أية اتصالات سليمة على المخدم، لأنها ستقابَل بالرفض لعدم وجود أية موارد كافية لحجز اتصال جديد على المخدم. وهذا ما يعرف بهجوم حجب الخدمة.

تمكِّن هذه الثغرة المهاجم من منع الوصول إلى مخدم معين دون أن يحتاج إلى سرعة عالية (باستعمال عرض حزمة منخفض). يختلف هجوم Slowloris عن الأنواع الأخرى من هجومات حجب الخدمة مثل هجوم SYN flood الذي يسيء استعمال TCP SYN خلال عملية المصافحة في بروتوكول TCP (TCP three-way-handshake).

آلية عمل الهجوم

سنعرض ترويسات طلب HTTP GET لتساعدنا على فهم آلية عمل الهجوم. يكون طلب HTTP GET الكامل كما يلي:

GET /index.php HTTP/1.1[CRLF]

Pragma: no-cache[CRLF]

Cache-Control: no-cache[CRLF]

Host: testphp.vulnweb.com[CRLF]

Connection: Keep-alive[CRLF]

Accept-Encoding: gzip,deflate[CRLF]

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36[CRLF]

Accept: */*[CRLF][CRLF]

نلاحظ وجود [CRLF] عند نهاية كل ترويسة؛ وهو محرف character غير قابل للطباعة يُستعمل للدلالة على نهاية السطر على غرار محرر النصوص، قد يحوي طلب HTTP  على [CRLF] في نهاية السطر لبدء سطر جديد ومحرفين [CRLF] للدلالة على سطر فارغ، ويعتبر هذا السطر الفارغ في بروتوكول HTTP نهايةً لترويسة البروتوكول. تستفيد الهجمة من هذه الخاصة في بروتوكول HTTP في عدم إنهاء الاتصال، وذلك بعدم إرسال السطر الفارغ في نهاية الترويسة.

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

كشف هجوم Slowloris

هذا الهجوم فعّال وذو أهمية في خوادم الوب التي تعتمد في عملها على النياسب (thread-based web server) فقط، مثل: Apache و dhttpd. وهو غير فعّال في المخدمات التي تعتمد في عملها على الأحداث (event-based web server)، مثل: nginx و lighttpd التي صُمّمت لتعالج عددًا كبيرًا من الاتصالات المتزامنة (simultaneous connections).

يمكن لبعض الأدوات الكشف عن هذه الثغرة في مخدم الوب مثل Acunetix web vulnerability scanner[1] أو عن طريق الأداة Nmap[2].

منع وتخفيف هجوم Slowloris

ثمة عدد من التقنيات لمنع وتخفيف هجوم Slowloris، نذكر ثلاثة من أشهرها وأسهلها تنفيذًا على مخدم Apache HTTP:

باستعمال mod_reqtimeout

جرى اعتماد هذا المكوّن افتراضيًّا في مخدم Apache HTTP بدءًا من النسخة 2.2.15. يُستعمل هذا المكوّن لتحديد مهلة زمنية لاستقبال ترويسة طلب HTTP (HTTP request headers) ونص طلب (HTTP request body) HTTP من العميل، ونتيجة لذلك إذا أخفق أحد العملاء في إرسال بيانات الطلب (سواء الترويسة أو النص) خلال الوقت المحدد، ترسَل رسالة خطأ 408 REQUEST TIME OUT بواسطة المخدم.

المثال الآتي هو مثال على التهيئة التي يمكن استعمالها مع mod_reqtimeout.

<IfModule mod_reqtimeout.c>

  RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

</IfModule>

في الإعدادات السابقة سُمح بمدة 20 ثانية حتى يرسل العميل ترويسة طلب HTTP كاملة، بشرط أن يحقق حدًّا أدنى من معدل وصول البيانات (500 بايت في الثانية)، وكحد أقصى يَسمح المخدم بمدة 40 ثانية لإكمال ترويسة طلب HTTP.

إضافة الى ذلك تَسمح هذه الوحدة بمدة 20 ثانية لإكمال نص طلب HTTP مادام العميل يرسل بيانات الترويسة بمعدل 500 بايت في الثانية، وسينتظر المخدم حتى 40 ثانية ليكتمل نص طلب HTTP.

باستعمال mod_qos

هذا المكوّن مسؤول عن جودة الخدمة لخادم Apache HTTP التي تسمح بتنفيذ آليات تحكّم تستطيع بواسطتها توفير مستويات متعددة الأولوية لطلبات HTTP المختلفة.

فيما يلي مثال على كيفية تهيئة هذا المكوّن (mod_qos) للتخفيف من هجمات حجب الخدمة HTTP DOS Attacks:

<IfModule mod_qos.c>

   # handle connections from up to 100000 different IPs

   QS_ClientEntries 100000

   # allow only 50 connections per IP

   QS_SrvMaxConnPerIP 50

   # limit maximum number of active TCP connections limited to 256

   MaxClients 256

   # disables keep-alive when 180 (70%) TCP connections are occupied

   QS_SrvMaxConnClose 180

   # minimum request/response speed (deny slow clients blocking the server, keeping connections open without requesting anything

   QS_SrvMinDataRate 150 1200

</IfModule>

يتتبَّع هذا المكوّن ما يصل إلى 100 000 عملية اتصال، ويقيد الخادم لقبول 256 اتصالًا كحد أقصى، ويحدّ أيضًا من عدد الاتصالات إلى 50 اتصال لكل IP كحد أقصى، ومن عدد اتصالات TCP النشطة إلى 256 اتصالًا كحد أقصى، ويمنع HTTP keep-alive عندما يصل عدد الاتصالات إلى 180 اتصالًا (في الحالة المدروسة تشكل 70% من عدد الاتصالات المسموح بها)̣

أخيرًا يتطلب هذا التكوين حدًّا أدنى لمعدل نقل البيانات (150 بايت في الثانية) لكل اتصال، ويقيد معدل النقل للاتصال إلى 1200 بايت في الثانية عند الوصول إلى الحد الأعلى لعدد الزبائن MaxClients.

باستعمال mod_security

يُعدّ هذا المكوّن جدار حماية لتطبيق الوب (WAF web application firewall)، ويمكن استعماله مع خادم Apache HTTP. يعتمد هذا المكوّن على قواعد يمكن تطبيقها لتنفيذ وظائف محددة.

تُستعمل القواعد التالية للتخفيف من هجوم حجب الخدمة HTTP DoS attack.

SecRule RESPONSE_STATUS "@streq 408" "phase:5,t:none,nolog,pass,

setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60, id:'1234123456'"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,drop,

msg:'Client Connection Dropped due to high number of slow DoS alerts', id:'1234123457'"

تحدِّد هذه القواعد تصرُّف المخدم عندما يقدح الحالة 408 فيتتبع عدد المرات التي حدثت فيها هذه الحالة مع إمكان تمييز الطلبات المترابطة (الناتجة عن نفس الزبون IP-based)، فإذا أُطلقت هذه الحالة أكثر من 5 مرات في 60 ثانية، حُجبت الطلبات اللاحقة لهذا الزبون مدة 5 دقائق بواسطة المكوّن  mod_sercurity.

وثمة طرق أخرى للتخفيف من هجوم حجب الخدمة HTTP DoS attack مثلًا باستخدام الجدار الناري iptables على النحو الآتي:

iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-above 100 -j DROP

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

وهناك أيضًا آليات لموازنة الحمل على المخدم load balancer، وهي طريقة متبعة على المخدمات التي عليها ضغط كبير في الحالة الطبيعية، حيث يتوزع الرد على طلبات الزبائن على أكثر من مخدم ولنفس المحتوى.

الخاتمة

يعتبر هجوم حجب الخدمة Slowloris أحد أقوى هجمات حجب الخدمة، وذلك لأنه يعمل على طبقة التطبيقات ولا يحتاج الى معدل نقل بيانات عالٍ لتنفيذه. وثمة عدّة آليات للتخفيف من هذا الهجوم. غير أنه لما كان الهجوم يعمل على طبقة التطبيقات، فليس هناك نمط واضح لمنع مثل هذا الهجوم؛ فقد يكون الاتصال بطيئًا من الزبون، أو أن محتوى الموقع يتطلب القيام بعدد لا بأس به من الاتصالات. لذلك على مدير النظام أن يكون على دراية بالحالة الطبيعية لاستعمال مخدم الوب، وبناءً على ذلك يقوم باستعمال وإعداد التكوينات المناسبة لمنع مثل هذه الهجمات.

المصادر

1. https://www.acunetix.com/blog/articles/slow-http-dos-attacks-mitigate-apache-http-server/
2. https://sites.google.com/a/lclark.edu/application-layer-dos-lab/lab-exercise