هجمات حجب الخدمة: SYN Flood والتّصدي لها في لينكس

هجمات حجب الخدمة كما هو واضح من اسمها يسعى فيها المهاجم إلى منع المستخدمين من الوصول إلى موقع أو خدمة ما. هناك أشكال متعدّدة لحجب الخدمة، في هذه المقالة ستناول نوعاً منها وهو SYN flood.

عندما يقوم نظام ما (حاسوب المستخدم المنزلي مثلاً) بالاتصال بنظام آخر طلباً لخدمة ما (مثلاً موقع على الإنترنت)، باستخدام برتوكول TCP فإن نظام المستخدم يقوم بمحاولة إنشاء اتصال مع الموقع (الخادم)، تعرف هذه المحاولة بـ Three HandShake (المصافحة الثلاثيّة إن صحّت التّرجمة 🙂 كما نرى في الشكل التّالي:

اتصال TCP

بعد ACK التي أرساله المستخدم للخادم، يتمّ فتح اتصال بين الاثنين لتبادل المعلومات (مثلاً محتوى صفحة على الإنترنت).

ولكن ما الذي سيحدث لو لم يقم المستخدم بإرسال الـ ACK للخادم؟ هذا يعني أنّ هناك نصف اتصال بين الخادم والمستخدم. ما الذي سيحدث لو قام مستخدم آخر بفتح اتصال؟ وثالث؟ ورابع؟ الخادم يقوم بحفظ معلومات الاتصال الخادم بكل مستخدم في ذاكرته. هذه الذّاكرة محدودة. عدد كبير من أنصاف الاتصال سيملئ ذاكرة الخادم. عندها سيتوقف الخادم عن استقبال اتصالات جديدة، وهو ما يؤدي في النّهاية إلى حجب الخدمة عن الموقع.

ولكن كيف يمكننا أن نقوم بفتح أنصاف اتصال مع الخادم؟

يمكننا القيام بذلك بسهولة إذا قمنا بعملية انتحال للعناوين (IP Spoofing). الخادم يتعامل مع هذا الاتصال على أنّه اتصال حقيقي وبالتّالي يقوم بإرسال SYN-ACK لهذا العنوان المزيّف، ولكنّه لن يحصل في المقابل على ACK المكمّلة للاتصال.

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

لنشاهد مثال على ذلك

في هذا المثال سنستخدم scapy، وهي أداة تستخدم في بناء (أو التلاعب) بحزم البروتوكولات.

send(IP(src=RandIP('10.0.0.0/8'), dst='192.168.1.8')/TCP(sport=RandShort(),dport=80),loop=1)

حسب ما هو واضح أعلاه اخترنا الشبكة 10.0.0.0/8 كأساس في العناوين المنتحلة، والضحيّة هو 192.168.1.8 والذي يقدم خدمة عبارة عن موقع ما.

الآن نقوم بالتّسمع على الشبكة عن طريق استخدام tcpdump لنشاهد شكل الحزم الخارجة

كما نشاهد في الصورة أعلاه عيّنة من العناوين المنتحلة والتي تقوم بإسارل SYN إلى الخادم.

لننتقل الآن إلى الخادم لنرى مالذي يحدث هناك

حالة الاتصال على الخادم

كما نشاهد في الشكل أعلاه هناك عدد كبير من انصاف الاتصال ممثلة في الحالة SYN_RECV ساعدتنا في اكتشافها الأداة netstat. بعد فترة قصيرة من انطلاق الهجوم توقف الموقع عن العمل.

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

1- زيادة سعة طابور TCP للاتصال النّصف مفتوحة

يمكن انجاز ذلك عبر تعديل قيمة الطابور  net.ipv4.tcp_max_syn_backlog إلى قيمة أكبر. القيمة الافتراضيّة هي 1024، يمكننا مضاعفتها لغاية 65536.

2- تقليل وقت الانتظار لاكمال اتصال نصف مفتوح

يمكن القيام بذلك عبر تعديل القيمة net.ipv4.tcp_synack_retries إلى 1 حيث أنّ القيمة الافتراضيّة هي 5. كل اتصال يستغرق حوالي 35 ثانية لذلك الوقت الافتراضي هو 180 ثانية.

3- تقليل كعكات TCP

يمكن القيام بذلك عبر تعديل القيمة net.ipv4.tcp_syncookies إلى 1 لتفعيل هذه الخاصيّة. القيمة الافتراضيّة هي 0.

بعض الأبحاث تنصح بعدم تفعيل syncookies كوسيلة للتّصدي لهجمات حجب الخدمة. ولكن من خلال تجربتي في الموضوع وجدّت أنّها أفضل تعديل يمكن أن يؤدي إلى الحدّ من هجوم حجب خدمة SYN flood عند مقارنته بالمتغيّرات الأخرى. فمثلاً بعد رفعي لقيمة backlog إلى الحدّ الأقصى بقي الخادم غير قادر على استقبال اتصالات جديدة وبالتالي تصفح الموقع التجريبي كان متعذراً. تغيير هذه القيمة ساعد فوراً في الحدّ من شدّة الهجوم وهو ما مكنني من تصفح الموقع بدون مشاكل.

ملاحظة: يمكن ترك قيمة ال backlog الافتراضيّة كما هي عند تفيعل syncookies.

في حال اعادة تشغيل النّظام فإنّ التعديلات التي أدخلتها سترجع الى قيمها الإفتراضيّة لذلك لضمان بقاء التعديلات حتى بعد إعادة التشغيل قم بتحديث الملف sysctl.conf والموجود في المجلّد /etc

آخيراً يمكننا وضع قاعدة في الجدار النّاري لتّحكم بعدد الاتصالات القادمة من عنوان معيّن:

iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 16 --connlimit-mask 24 -j REJECT

هنا حدّدنا القيمة ب 16 أي اتصال آخر يأتينا من المستخدم سيتم رفضه. مشكلة هذه الطريقة أنّ المستخدم العادي (وليس المهاجم) قد يتأثر بهذا التّحديد.

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