دليل شامل لتطبيق Netfilter و Suricata على نظام Linux

إنفورماتيك ديجيتال » موارد » دليل شامل لتطبيق Netfilter و Suricata على نظام Linux

إذا كنت تعمل مع الشبكات على نظام GNU/Linux ( أفضل توزيعات لينكس للأمان والخصوصية ) وترغب في تجاوز جدار الحماية الثابت التقليدي، فربما تتساءل عن كيفية دمج Netfilter وNFQUEUE وSuricata لبناء نظام كشف ومنع التسلل (IDS/IPS) مرن حقًا دون إنفاق مبالغ طائلة على أجهزة احتكارية. هذا هو المجال الذي سنتناوله في هذه المقالة، حيث نمزج بين العناصر الأساسية (النواة، قوائم الانتظار، لغة C) والأدوات المتقدمة (Suricata، القواعد، MySQL، Memcached، pfSense).

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

NFQUEUE و Netfilter: رفع مستوى جدار الحماية إلى مساحة المستخدم

في نظام GNU/Linux النموذجي، تُستخدم قواعد Netfilter/iptables (أو nftables) عادةً كسياسات ثابتة موجودة بالكامل في مساحة النواة . تقوم الواجهات الأمامية والأجهزة (بما في ذلك العديد من الحلول القائمة على Netfilter أو Packet Filter من BSD) بتخزين الإعدادات في ملفات نصية أو XML أو SQLite، وعند حدوث أي تغيير، تُعيد هذه الأجهزة إنشاء القواعد وتحميلها. هذا النظام مرن، لكن المنطق يبقى أشبه بلقطة لجدار الحماية مع تعديلات ديناميكية طفيفة (مثل حدود عدد الاتصالات في الثانية، وتتبع الاتصالات، ومطابقة البلدان، وطبقة 7 إن وجدت، إلخ).

ما يقترحه NFQUEUE يُعدّ نقلة نوعية: فبدلاً من أن تتخذ النواة القرار النهائي دائمًا، يُمكننا تفويض هذا القرار إلى عملية مستخدم . تقوم النواة بتخزين الحزمة في قائمة انتظار مرقمة، ثم يقوم تطبيق يستخدم مكتبة libnetfilter_queue باسترجاعها وتحليلها، ثم يُصدر قرارًا بشأنها: قبولها، أو رفضها، أو حتى توجيهها وفقًا لسياسة التوجيه. يُشبه الأمر وجود "قاضٍ" قابل للبرمجة مكتوب بلغة C أو Python أو Perl يعمل فوق جدار الحماية.

يكمن جمال هذا في أن برنامجنا قادر حرفيًا على فعل ما نشاء: الاستعلام من /dev/urandom، أو قاعدة بيانات، أو خدمة ويب، أو ذاكرة تخزين مؤقت موزعة، أو خوارزمية معقدة قبل الاستجابة لنواة النظام. من الناحية المعمارية، لم يعد جدار الحماية مجرد مجموعة بسيطة من القواعد الثابتة، بل أصبح مسارًا تتكامل فيه Netfilter وقوائم الانتظار وتطبيقات المستخدم كقطع أحجية.

يتكون NFQUEUE من جزأين: هدف NFQUEUE في iptables ، الذي يرسل الحزم إلى قائمة انتظار محددة، ومكتبة المستخدم libnetfilter_queue ، التي تتيح لك قراءة تلك الحزم وإصدار حكم بشأنها. إنه ليس مجرد أداة تحليل بسيطة مثل tcpdump: هنا لدينا القدرة على تحديد المسار الذي تسلكه الحزمة مباشرةً.

تكوين iptables الأساسي مع NFQUEUE

من وجهة نظر iptables، فإن استخدام NFQUEUE أمر بسيط للغاية: يمكنك إضافة قاعدة إلى السلسلة التي تهمك لإرسال الحزم التي تستوفي معايير معينة إلى قائمة الانتظار (عنوان IP المصدر/الوجهة، والمنافذ، والحالات، والوحدات الإضافية مثل GeoIP أو الطبقة 7 إذا كانت متاحة، وما إلى ذلك).

على سبيل المثال، إذا أردنا إرسال جميع طلبات الاتصال التي تصل إلى المضيف نفسه إلى NFQUEUE:

iptables -I INPUT -p icmp -j NFQUEUE

يُرسل هذا الأمر حزم ICMP الواردة إلى قائمة الانتظار رقم 0 (إلا إذا تم تحديد خلاف ذلك). يمكننا تحديد قائمة انتظار أخرى باستخدام خيار مثل `--queue-num 3` . عند عرض القواعد مع العدادات (`iptables -L -n -v -x`)، سنلاحظ زيادة في العدادات، مما يشير إلى وجود حزم في قائمة الانتظار . ملاحظة هامة: إذا كانت هناك حزم في قائمة الانتظار ولم يقم أي برنامج مستخدم باسترجاعها ومعالجتها، فإن السلوك الافتراضي هو رفضها، وبالتالي فإن أي عطل في التطبيق، بحسب التصميم، سيؤدي إلى حظر حركة البيانات.

البرمجة باستخدام مكتبة libnetfilter_queue: برنامج "مرحباً بالعالم" بلغة C

للانضمام إلى قائمة الانتظار من مساحة المستخدم، تُستخدم مكتبة libnetfilter_queue (التي بدورها تعتمد على libnfnetlink). في توزيعات مثل دبيان، ما عليك سوى تثبيت حزم التطوير.

apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc

يتألف الهيكل الأساسي لبرنامج بسيط يقبل الحزم دائمًا من بضع خطوات واضحة جدًا: فتح المكتبة، وإلغاء ربط أي معالجات موجودة، والربط ببروتوكول AF_INET، وإنشاء قائمة انتظار باستخدام دالة رد نداء، وتحديد وضع النسخ، والدخول في حلقة استقبال . يتم تنفيذ دالة رد النداء لكل حزمة في قائمة الانتظار، حيث تستخرج المعرّف وتعيد النتيجة.

عمليًا، يكون التسلسل كالتالي: `nfq_open` للحصول على المؤشر، `nfq_unbind_pf` لتنظيفه، `nfq_bind_pf` لربطه بـ AF_INET، `nfq_create_queue` لتسجيل دالة الاستدعاء في قائمة الانتظار 0، `nfq_set_mode` لتحديد ما إذا كنا نريد البيانات الوصفية أو الحزمة بأكملها، حلقة باستخدام `recv()` على الواصف، و`nfq_handle_packet` لمعالجة كل حزمة . عند الخروج، تُدمر قائمة الانتظار باستخدام `nfq_destroy_queue` ويُغلق المؤشر باستخدام `nfq_close`.

يُتيح هذا النوع من "مرحباً بالعالم" قياسًا دقيقًا لتأثير NFQUEUE. إذا قمنا بتجميع المثال باستخدام شيء مثل:

gcc -o nttest code.c -lnfnetlink -lnetfilter_queue

وإذا قمنا بتجميع حركة البيانات من iperf (على سبيل المثال، منفذ TCP 5001 في قسمي الإدخال والإخراج)، فسنجد أن الكود الذي يستقبل الحزم ببساطة لا يؤثر بشكل ملحوظ على الأداء في شبكة جيجابت . مع ذلك، ثمة تفصيل مهم: طباعة المعلومات في دالة الاستدعاء (printf، fflush، إلخ) تُقلل الإنتاجية بشكل كبير، كما يتضح عند مقارنة iperf مع وبدون تصحيح أخطاء الشاشة.

خيارات NFQUEUE المتقدمة: التجاوز، والموازنة، والفتح عند الفشل

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

يُمكّنك الأمر `--queue-bypass` من ضمان عدم إسقاط الحزم في حال عدم وجود أي عملية تستمع إلى قائمة الانتظار، بل إعادة توجيهها إلى الوجهة التالية في سلسلة iptables. قد يكون هذا مفيدًا إذا كنت ترغب في أن "يبقى النظام مفتوحًا" عند تعطل خدمة المستخدم، مع العلم أنه سلاح ذو حدين من منظور أمني.

يُتيح لك خيار `--queue-balance` توزيع الحزم على نطاق من قوائم الانتظار (على سبيل المثال، من 0 إلى 3)، ثم السماح لعدة عمليات أو خيوط مستقلة باستهلاك الحزم من كل قائمة انتظار . يضمن كود Netfilter أن تنتهي الحزم من نفس التدفق دائمًا في نفس قائمة الانتظار، مما يُبسط بشكل كبير الحفاظ على اتساق منطق اتخاذ القرار.

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

لمراقبة ما يحدث مع قوائم الانتظار، يعرض Netfilter المعلومات في نظام الملفات الوهمي /proc/net/netfilter/nfnetlink_queue ، والتي يمكن الاستعلام عنها بسهولة من البرامج النصية أو أدوات المراقبة.

دمج منطق الأعمال: الاختبار باستخدام Memcached وMySQL

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

في حالة Memcached، يتم تثبيت البرنامج (apt-get install memcached) ويتم تحميل مفتاح، على سبيل المثال authorized ، بعنوان IP المطلوب. يمكننا القيام بذلك باستخدام أمر echo و netcat، ثم التحقق باستخدام أمر get من تخزين القيمة بشكل صحيح. بعد ذلك، يقوم برنامج NFQUEUE، بالإضافة إلى الحصول على مُعرّف الحزمة، باستقبال الحزمة كاملةً باستخدام NFQNL_COPY_PACKET ، واستخراج رأس IP (struct iphdr)، وتحويل عنوان المصدر إلى سلسلة نصية باستخدام inet_ntop.

لتجنب إضاعة الوقت في فتح الاتصالات مع كل حزمة، يتم تهيئة اتصال Memcached مرة واحدة فقط في الدالة الرئيسية (memcached_create، memcached_server_list_append، memcached_server_push)، ويتم تخزين معالج الاتصال في متغيرات عامة. في دالة الاستدعاء، يتم استدعاء memcached_get مع المفتاح المطلوب، ويتم مقارنة عنوان IP المصدر بالقيمة المسترجعة، وإذا تطابقا، يتم إرجاع NF_ACCEPT؛ وإلا، يتم إرجاع NF_DROP. إذا كان المفتاح غير موجود أو حدث خطأ، يتم إسقاط الحزمة كإجراء احترازي.

باستخدام أداة iperf، تُقلل هذه الاستراتيجية معدل نقل البيانات إلى حوالي 140 ميجابت/ثانية على شبكة جيجابت ، ويُلاحظ أن قائمة الانتظار تبدأ في فقدان بعض البيانات (يُشار إلى ذلك، على سبيل المثال، برموز داخل الكود نفسه). بعبارة أخرى، مجرد استدعاء خدمة التخزين المؤقت لكل حزمة بيانات يُكبّد تكلفة كبيرة، على الرغم من أنها تظل مجدية لأحجام حركة البيانات المتوسطة إذا تم تحسينها.

مع MySQL، يكون النهج مشابهًا ولكنه أكثر تعقيدًا: يتم تثبيت مكتبة الخادم والعميل، ثم يتم إنشاء قاعدة بيانات (مثل nfqueue) تحتوي على جدول بسيط باسم authorized(ip varchar(50))، ويتم إدخال عنوان IP المسموح به. في البرنامج، يتم تشغيل الدالتين `mysql_init` و`mysql_real_connect` عند بدء التشغيل، وفي دالة الاستدعاء، يتم إنشاء استعلام مثل `select * from authorized where ip like 'xxxx'`. إذا تم تنفيذ الاستعلام بنجاح وتم العثور على صف، يتم قبول الحزمة؛ وإلا، يتم تجاهلها.

مع تفعيل خاصية التخزين المؤقت للاستعلامات في MySQL، تُظهر الاختبارات سرعة نقل بيانات تبلغ حوالي 188 ميجابت/ثانية ، وتنخفض إلى 103 ميجابت/ثانية عند تعطيل هذه الخاصية. هذه الأرقام، وإن كانت بعيدة عن سرعات الجيجابت، تُبين أنه حتى مع أبسط الطرق (باستخدام خيط معالجة واحد، دون تحسين) ، يُمكن التعامل مع أحجام بيانات كبيرة باستخدام قرارات تعتمد على قاعدة البيانات أو التخزين المؤقت.

الأداء، والمعالجة المتعددة، واستخدام وحدة المعالجة المركزية

أظهرت الاختبارات باستخدام iperf وMemcached وMySQL بوضوح أن الحد الأقصى للأداء لا يفرضه NFQUEUE نفسه بقدر ما يفرضه المنطق الذي نضيفه في مساحة المستخدم وكيفية تنفيذه. يحقق برنامج تنفيذي يُرجع NF_ACCEPT فقط سرعة تقارب الجيجابت دون عناء يُذكر؛ ولكن بمجرد إدخال عمليات الإدخال/الإخراج أو استدعاءات الشبكة، ينخفض ​​معدل النقل، ويُستنزف معالج جهاز NFQUEUE أو خادم Memcached أو MySQL إلى أقصى حد.

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

من التحسينات الواضحة الأخرى تقييد حركة البيانات التي تمر عبر NFQUEUE . في الاختبارات، تم وضع تدفق iperf بالكامل في قائمة الانتظار، ولكن في سيناريو واقعي، يمكننا وضع الحزم ذات الحالة الجديدة فقط في قائمة الانتظار، والسماح بمرور الحزم ذات الحالة المُنشأة/المرتبطة، وتخصيص المنطق المُكلف لعمليات تسجيل الدخول أو الأنماط المشبوهة.

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

التوجيه الديناميكي مع علامة Netfilter التجارية

لا يقتصر NFQUEUE على مجرد قول "قبول" أو "رمي". يمكن استخدامه أيضًا لتطبيق علامات Netfilter (fwmark) على الحزم ودمجها مع قاعدة ip و iproute2 لإنشاء مخططات توجيه سياسية مرنة للغاية وخفيفة الوزن تقريبًا على غرار VRF.

الإجراء، بشكل عام، سيكون كالتالي: تعريف عدة جداول توجيه في /etc/iproute2/rt_tables ، على سبيل المثال slow و fast؛ تعيين مسار افتراضي مختلف لكل جدول (واحد عبر الألياف وآخر عبر رابط أكثر محدودية)؛ استخدام قاعدة ip لتحديد أن الحزم التي تحمل علامة fwmark 1 تذهب إلى جدول fast، وتلك التي تحمل علامة fwmark 2 إلى جدول slow، وما إلى ذلك؛ وأخيرًا، استخدام NFQUEUE لوضع علامة على الحزم بشكل مناسب قبل إرجاع النتيجة.

لتعيين نتيجة من دالة الاستدعاء، تُستخدم الدالة `nfq_set_verdict2` ، وهي تشبه الدالة `nfq_set_verdict` ولكنها تسمح لك بتعيين قيمة نتيجة ستراها الدالة `ip rule`. بدمج كل هذا، يمكنك إنشاء موجه IP يحدد وجهة التوجيه بناءً على معايير عشوائية: من أمور غير منطقية مثل حجم الحزمة الزوجي/الفردي إلى مدخلات خارجية مثل خوارزميات التنبؤ بحركة المرور، وأحداث وسائل التواصل الاجتماعي، أو إشارات من أنظمة المراقبة.

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

NFQUEUE و Suricata: نظام منع التسلل عالي المستوى في GNU/Linux

يمكن برمجة كل ما سبق يدويًا بلغة C، ولكن عندما يتعلق الأمر بكشف الاختراقات وفحص الحزم المتعمق، فإن الخيار الأمثل عادةً هو الاعتماد على محرك IDS/IPS متطور . وهنا يأتي دور Suricata، الذي صُمم خصيصًا كبديل متعدد العمليات لـ Snort، مع إمكانيات IPS منذ البداية وتركيز كبير على الاستفادة من أنوية المعالجات المركزية العديدة المتاحة اليوم.

تم تطوير برنامج Suricata من الصفر وتوزيعه بموجب ترخيص GPLv2 ؛ وتتولى مؤسسة أمن المعلومات المفتوحة (OISF) صيانة كلٍ من المحرك ونظام بيئي شامل من القواعد والوثائق. على عكس Snort 2.x، الذي ورث نواة أحادية الخيوط وتم تعديلها، صُمم Suricata لتقسيم عبء العمل على خيوط متعددة: الالتقاط، وفك التشفير، والكشف، والإخراج، مع استراتيجيات مختلفة لتقاسم الحمل.

على المستوى الوظيفي، يوفر Suricata دعمًا أصليًا لـ IPv6، وفحص الطبقة 7 (HTTP متقدم للغاية عبر مكتبة HTP)، والتعرف على البروتوكول بشكل مستقل عن المنافذ ، وإعادة بناء التدفق، ونظام قوي للغاية لمتغيرات الجلسة (flowbits) لربط المراحل المختلفة للهجوم المنتشر عبر عدة اتصالات TCP.

ومن نقاط قوته الإضافية توافقه مع قواعد Snort وقدرته على استخدام مجموعتي توقيعات Sourcefire VRT و Emerging Threats (الإصدار المجاني ET Open والإصدار التجاري ET Pro). علاوة على ذلك، يُصدّر الأحداث بتنسيقات مفيدة للغاية (fast.log، JSON في eve.json) للتكامل مع أنظمة SIEM و ELK و Splunk وغيرها.

سوريكاتا كنظام منع التسلل في لينكس: أوضاع الالتقاط وNFQUEUE

في نظام GNU/Linux، يمكن لبرنامج Suricata العمل بأوضاع مختلفة تبعًا لكيفية اعتراض حركة البيانات: NFQUEUE، AF_PACKET، PF_RING، libpcap، NFLOG، IPFW، DAG، Napatech ... لكل وضع مزاياه ومتطلباته. على مستوى أنظمة منع الاختراق (IPS) البحتة، يُعدّ كل من NFQUEUE وAF_PACKET الأكثر أهمية.

في وضع NFQ (NFQUEUE) ، يكون التدفق مشابهًا لما وُصف سابقًا: تقوم مجموعة من قواعد iptables بإرسال الحزم إلى قائمة انتظار؛ يقوم برنامج Suricata، الذي يعمل في مساحة المستخدم، بقراءة هذه القائمة، وفحص محتوياتها وفقًا لقواعده، ثم يُعيد قرارًا إلى النواة: NF_ACCEPT أو NF_DROP أو NF_REPEAT. يمكن استخدام الخيار الثالث لإعادة إدخال الحزمة إلى جدول iptables نفسه بعد تطبيق علامات أو تعديلات إضافية.

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

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

في كلا الوضعين، يمكن دمج Suricata مع Netfilter، لكن NFQUEUE يناسب بشكل خاص السيناريوهات التي نريد فيها إعادة استخدام جميع منطق iptables (السياسات، والنطاقات، والقواعد السابقة) وإرسال حركة المرور التي نهتم بفحصها بعمق فقط إلى Suricata.

تثبيت أساسي لبرنامج Suricata من الكود المصدري

بالنسبة لأولئك الذين يفضلون تجميع Suricata بدلاً من استخدام الحزم، فإن العملية على توزيعات Debian/Ubuntu تتضمن أولاً تثبيت تبعيات التجميع (build-essential، libpcre، libpcap-dev، libnet-dev، libyaml-dev، zlib، libcap-ng-dev، libjansson-dev، إلخ)، وتنزيل ملف tarball من الموقع الرسمي، وتشغيل الأوامر الكلاسيكية ./configure، make، make install.

أثناء مرحلة التهيئة، سيشير البرنامج النصي إلى ميزات الدعم التي تم تفعيلها: AF_PACKET نعم/لا، PF_RING، NFQUEUE نعم/لا، NFLOG، IPFW، دعم libnss، libjansson، Prelude، PCRE JIT، Lua، GeoIP، إلخ. من المهم التحقق من تفعيل NFQUEUE إذا أردنا العمل في هذا الوضع ، ومن تحديد موقع مكتبة الالتقاط التي نهتم بها.

بعد تثبيت الملف التنفيذي، يمكنك تشغيل الأمر `make install-conf` لنشر إعدادات افتراضية في `/etc/suricata`، والأمر `make install-rules` لتنزيل مجموعة من قواعد التهديدات الناشئة ووضعها في `/etc/suricata/rules`. ويمكن تحديث هذه المجموعات لاحقًا باستخدام أدوات مثل `suricata-update`.

في أنظمة Red Hat/CentOS، يكون المنطق مشابهًا، حيث يُستخدم yum أو dnf لإدارة التبعيات (مثل libpcap-devel وpcre-devel وlibnet-devel وlibyaml-devel وjansson-devel، إلخ)، ثم يتم التجميع بنفس الخطوات. ولأسباب تتعلق بالأداء، يُنصح أيضًا بتعطيل LRO/GRO في واجهة الالتقاط باستخدام ethtool، لأن وظائف التفريغ هذه قد تؤثر على رؤية الحزم على مستوى نظام كشف التسلل (IDS).

تكوين Suricata: YAML، والمتغيرات، والترابط

يوجد ملف التكوين الرئيسي لبرنامج Suricata في المسار /etc/suricata/suricata.yaml . وهو ملف YAML سهل القراءة نسبيًا ويحتوي على تعليقات كثيرة، حيث يتم فيه تحديد كل شيء بدءًا من مسارات السجلات ومجموعات القواعد وصولًا إلى سياسات نظام التشغيل المستهدف ومعلمات تعدد الخيوط.

أحد الحقول الأساسية هو `default-log-dir` ، الذي يُحدد مكان تخزين ملفات السجل (افتراضيًا، `/var/log/suricata`). يحتوي قسم `vars` على متغيرات مثل `HOME_NET` و`EXTERNAL_NET` و`HTTP_PORTS` و`SHELLCODE_PORTS` و`SSH_PORTS`، والتي تُستخدم كاختصارات في القواعد. عادةً ما يتم تكوين `HOME_NET` بنطاق الشبكة المحلية المراد حمايتها، بينما يُعرَّف `EXTERNAL_NET` عادةً على أنه `!HOME_NET`.

جزءٌ آخر مهم هو سياسة نظام التشغيل المضيف ، التي تُحدد لبرنامج سوريكاتا نظام التشغيل المُناسب لتشغيل نطاقات عناوين IP مُعينة. يسمح هذا للبرنامج بتعديل كيفية إعادة تجميع بروتوكول TCP أو تفسير سلوكيات مُعينة لمكدس الشبكة ، مما يُصعّب التهرب من البروتوكولات بناءً على الاختلافات بين المكدسات (ويندوز مقابل لينكس، إلخ). يُمكن تخصيص نطاقات مُحددة لفئات مثل ويندوز، لينكس، بي إس دي، فيستا، ويندوز 2003، إلخ.

فيما يتعلق بالمعالجة المتعددة، يتيح لك قسم المعالجة المتعددة ضبط تقارب وحدة المعالجة المركزية وعدد خيوط الكشف بدقة. عادةً ما يكون خيار `set-cpu-affinity` معطلاً افتراضيًا، مما يسمح لمُجدول النظام بتوزيع الخيوط على النوى. يشير المعامل `detect-thread-ratio` إلى عدد خيوط الكشف التي يتم إنشاؤها لكل نواة متاحة؛ فعند استخدام `detect-thread-ratio: 1.5` على جهاز ثماني النوى، سيُنشئ برنامج Suricata اثني عشر خيط كشف، بالإضافة إلى خيوط الالتقاط والإدارة.

ينعكس هذا النموذج بالكامل في المخرجات عند بدء تشغيل البرنامج الخفي: حيث يظهر خيط التقاط (مثل pcap) وعدة خيوط كشف، بالإضافة إلى مديري التدفق ومديري الإحصائيات. هذه البنية متعددة العمليات هي ما يسمح لبرنامج Suricata بالتوسع بشكل أفضل بكثير من المحركات أحادية الخيوط عند التعامل مع روابط بسرعة 10/40 جيجابت/ثانية.

تحديثات القواعد والتوقيعات في سوريكاتا

يعتمد برنامج Suricata على مجموعات القواعد لاكتشاف أنماط الهجوم والسلوكيات الشاذة وإساءة استخدام البروتوكولات. بالإضافة إلى قبول القواعد بصيغة Snort ، فإن النظام البيئي الأكثر شيوعًا هو نظام Emerging Threats: ET Open (مجاني) وET Pro (تجاري)، مع قواعد مصممة خصيصًا للتهديدات الحالية.

تتضمن العديد من التوزيعات الحديثة أداة `suricata-update` ، التي تُسهّل إدارة القواعد: فهي تُحدّث المصادر، وتُفعّل أو تُعطّل مُزوّدي خدمات مُحدّدين، وتُنزّل أحدث إصدارات مجموعات التوقيعات. وتتمثل آلية العمل النموذجية في تثبيت `suricata-update` (على سبيل المثال، عبر pip)، ثم تشغيل `suricata-update` لأول مرة لتنزيل ET Open، وعرض قائمة المصادر باستخدام `suricata-update list-sources`، وتفعيل مصادر إضافية مثل `ptresearch/attackdetection` و`oisf/trafficid` و`sslbl/ssl-fp-blacklist`، ثم تشغيل `suricata-update` مرة أخرى لإعادة إنشاء ملف القواعد.

يتم تعديل ملف suricata.yaml ليشير إلى مسار القواعد الصحيح، ومن ثم يبدأ برنامج Suricata بإصدار تنبيهات تُسجل في ملف fast.log (نص سريع وسهل القراءة) وملف eve.json (بيانات JSON منظمة تحتوي على معلومات شاملة) . يُعد هذا التنسيق الأخير مفيدًا بشكل خاص لتغذية لوحات المعلومات، وأنظمة الربط، أو البرامج النصية المخصصة.

بالإضافة إلى التوقيعات، يشتمل برنامج Suricata على أجهزة فك التشفير والمحللات لبروتوكولات متعددة ، مما يسمح له بأن يكون أقل اعتمادًا على المنافذ: يمكنه تحديد حركة مرور HTTP حتى لو مرت عبر منافذ غير قياسية، واكتشاف SSH وTLS وDNS وما إلى ذلك عبر منافذ ومستويات تغليف مختلفة (بما في ذلك أنفاق IPv4/IPv6 المختلطة).

الاستخدام العملي: من اكتشاف الثغرات الأمنية على الإنترنت إلى الحظر التلقائي

تتمثل إحدى أكثر حالات الاستخدام المرغوبة في بيئات الاستضافة أو مراكز البيانات في اكتشاف محاولات استغلال الثغرات الأمنية في تطبيقات الويب (مثل WordPress وملحقاتها) والتفاعل تلقائيًا، عادةً عن طريق حظر أو إدراج عنوان IP المصدر في القائمة السوداء في جدار الحماية.

يستطيع نظام سوريكاتا، المدعوم بقواعد مُحدَّثة، التعرّف على أنماط هجوم مُحدَّدة تستهدف عناوين URL، والمعلمات، وحمولات HTTP ، وحتى تسلسلات الطلبات التي تُطابق الثغرات الأمنية المعروفة. يمكن لنظام كشف التسلل (IDS) العمل في الوضع السلبي، حيث يستقبل حركة البيانات عبر النسخ المتطابق من منفذ المحوّل (SPAN)، ولكن لكي يعمل كنظام منع التسلل (IPS) ويحظر الهجمات، يجب دمجه مع طبقة التوجيه.

هناك نهجان شائعان: الأول هو إعداد نظام كشف التسلل كجسر عبر الإنترنت، بحيث يمرّ الترافيك فعليًا عبر الجهاز (باستخدام iptables أو AF_PACKET أو PF، حسب النظام الأساسي)، والثاني هو ترك بنية الشبكة كما هي مع دمج النسخ المتطابق مع إجراءات على جدار الحماية المركزي عبر واجهة برمجة التطبيقات أو البرامج النصية أو NFQUEUE . يقلل النهج الأول من زمن الاستجابة بين الكشف والحظر، ولكنه يضيف عنصرًا آخر "في منتصف" الشبكة؛ أما النهج الثاني فيوفر مرونة وقدرة أكبر على الصمود، ولكنه يزيد من تعقيد عملية التنسيق.

من الممكن تمامًا لنظام كشف التسلل (IDS) اكتشاف محاولة استغلال ثغرة أمنية في إضافة ووردبريس، ثم إضافة عنوان IP الخاص بالمهاجم إلى قائمة الحظر في iptables، إما مباشرةً أو عبر مكون مرتبط. يمكن تحقيق ذلك باستخدام مخرجات JSON الخاصة بـ Suricata وبرامج نصية تستدعي iptables/nftables ، أو بتفويض بعض العمليات المنطقية إلى NFQUEUE، حيث يتخذ المحرك نفسه أو عملية مرتبطة به القرار فورًا دون انتظار تحديث قائمة خارجية.

يتيح لك هذا التركيز على التهديدات المهمة حقًا (الاستغلالات، ومحاولات التصعيد، وعمليات المسح العدوانية للغاية)، وتجاهل أو ببساطة تسجيل الضوضاء الخلفية مثل عمليات مسح المنافذ الأساسية التي لا تثير القلق في حد ذاتها في كثير من السياقات.

سوريكاتا على بيفسنس: جدار حماية مفتوح المصدر مع نظام كشف ومنع التسلل المتكامل

لا يستطيع الجميع، أو لا يرغبون، في تحمل تكلفة جدار حماية متطور خاص مثل Palo Alto. في كثير من البيئات، يُعدّ إعداد حل مفتوح المصدر باستخدام pfSense وSuricata خيارًا أكثر جاذبية ، إذ يُغطي احتياجات جدار الحماية المتقدمة (مثل الشبكات الواسعة المتعددة، وشبكات VLAN، وشبكات VPN، وNAT، إلخ) وأنظمة كشف ومنع التسلل (IDS/IPS).

يعمل Pfsense، المبني على FreeBSD و Packet Filter، بشكل جيد للغاية مع البيئات الافتراضية (Proxmox و KVM وما إلى ذلك)، باستثناء أنه يوصى باستخدام بطاقات E1000 بدلاً من Virtio في أجهزة KVM إذا كنت ترغب في تجنب مشاكل الأداء والانهيارات تحت الحمل، إلا إذا قمت بتطبيق توصيات Netgate (تعطيل تفريغ مجموع التحقق للأجهزة في النظام > متقدم > الشبكات وإعادة التشغيل، مع العلم أن هذا قد لا يكون كافيًا مع الأحمال العالية جدًا).

يمكن أن تكون متطلبات الأجهزة الدنيا لمختبر مزود بـ Suricata على Pfsense متواضعة (معالج واحد بسرعة 500 ميجاهرتز، وذاكرة وصول عشوائي 1 جيجابايت، وقرص صلب 4 جيجابايت)، ولكن للاستخدام الجاد، يوصى بما لا يقل عن معالجين، وذاكرة وصول عشوائي 4 جيجابايت، ومساحة تخزين 16 جيجابايت ، مع عدم نسيان وجود العديد من واجهات الشبكة (واحدة لشبكة WAN، وأخرى لشبكة LAN، والمزيد إذا كنت تريد شبكات WAN متعددة أو شبكات VLAN معقدة).

تثبيت pfSense سريع للغاية: ما عليك سوى الإقلاع من ملف ISO، والموافقة على الترخيص، واختيار التثبيت، وتحديد اللغة وتخطيط لوحة المفاتيح، وترك تقسيم القرص على الوضع التلقائي (Auto UFS إذا كنت ستستخدم القرص بالكامل)، وفي غضون دقائق قليلة يكون النظام جاهزًا للإقلاع الأول. توفر وحدة التحكم قائمة لتعيين الواجهات، وإعادة التشغيل، وتشغيل سطر الأوامر، وما إلى ذلك.

في المختبر، على سبيل المثال في VirtualBox، من الشائع تعطيل جدار الحماية Pfsense مؤقتًا من وحدة التحكم باستخدام pfctl -d من أجل الوصول إلى واجهة الويب عبر WAN (اسم المستخدم admin، كلمة المرور pfsense) وإكمال المعالج الأولي: البيانات العامة، وخوادم NTP، وتكوين WAN (عادةً ما يكون DHCP كافيًا في المختبر)، وLAN، وتغيير كلمة مرور المسؤول وتطبيق التكوين.

بمجرد استقرار الوصول، يمكنك إنشاء قاعدة في جدار حماية الشبكة الواسعة (WAN) تسمح بالوصول عبر HTTPS من أي مصدر إلى عنوان IP الخاص بـ pfsense، مع إضافة فواصل وصفية لتنظيم القواعد بصريًا (على سبيل المثال، "الوصول إلى جدار الحماية"). يُنصح أيضًا بتعطيل خيار حظر الشبكات الخاصة على الشبكة الواسعة (WAN) إذا كنت في بيئة اختبار باستخدام عناوين RFC1918، لتجنب الحاجة إلى استخدام الأمر `pfctl -d` باستمرار.

تثبيت برنامج Suricata على pfSense ونظرة عامة

بعد تشغيل نظام pfSense الأساسي، يصبح تثبيت Suricata بسيطًا للغاية، إذ يكفي الانتقال إلى النظام > مدير الحزم > الحزم المتاحة ، والبحث عن Suricata، ثم تثبيت الحزمة. قد تستغرق عملية التنزيل بعض الوقت حسب مواصفات جهازك، ولكنها مدعومة بالكامل عبر واجهة الويب.

بعد التثبيت، يظهر إدخال Suricata في تبويب الخدمات، حيث يمكنك تهيئة الخوادم حسب الواجهة (WAN، LAN، VLANs، إلخ)، واختيار مجموعات القواعد المراد استخدامها، وتفعيل وضع IDS أو IPS ، وضبط معايير الأداء والتسجيل. خيارات التهيئة واسعة النطاق (تكفي لكتابة مقالات كاملة عنها)، لكن الميزة تكمن في أن العديد من المهام التي تتطلب في Linux تعديل YAML يدويًا تُدار هنا باستخدام النماذج ومربعات الاختيار.

ملاحظة هامة: على الرغم من أنه قد يكون من المغري فتح إدارة pfSense مباشرةً للإنترنت في بيئة تجريبية، إلا أنه في بيئة الإنتاج، من الضروري تقييد الوصول إلى عناوين IP الثابتة، واستخدام شبكات VPN للإدارة عن بُعد، وتجنب ترك وحدة تحكم الويب مكشوفة بأي ثمن . يتميز pfSense بمرونة عالية، ولكن يجب التعامل معه كعنصر بالغ الأهمية.

مع تفعيل Suricata على pfSense، تحصل على بيئة يمر فيها تدفق البيانات عبر pfSense لجدار الحماية وNAT، ويقوم Suricata بفحصه وفقًا لقواعده ويمكنه حظره في وضع IPS . هذا الدمج، الذي يُدار من واجهة ويب واحدة، يُبسط بشكل كبير نشر حماية DPI في الشبكات الصغيرة والمتوسطة الحجم.

في العديد من عمليات النشر، يتم استكمال ذلك من خلال ربط Pfsense/Suricata بنظام SIEM أو منصة سجلات مركزية، والاستفادة من تنسيقات الإخراج المنظمة لربط الأحداث واكتشاف الحملات الأوسع.

مراقبة الأحداث وسجلات الأمثلة في سوريكاتا

بمجرد تشغيل برنامج Suricata، تُسجّل الأحداث في المسار المحدد بواسطة default-log-dir، والذي يكون عادةً /var/log/suricata . يستخدم ملف fast.log تنسيقًا نصيًا مضغوطًا يتضمن الطوابع الزمنية ومعرفات القواعد والتصنيفات والأولوية، مما يجعله مناسبًا للفحص السريع من خلال سطر الأوامر (tail -f).

على سبيل المثال، عند مواجهة حركة مرور تحتوي على مجاميع اختبار TCP غير صحيحة، قد نرى أسطرًا كهذه: طوابع زمنية تتضمن التاريخ والوقت، متبوعة بمعرف القاعدة (مثل 1:2200074:1)، والرسالة "SURICATA TCPv4 مجموع اختبار غير صالح"، والتصنيف، والأولوية، وزوج عنوان IP/المنفذ للمصدر والوجهة. تتيح هذه الأنواع من التنبيهات تحديد مشكلات سلامة الحزم أو محاولات التهرب بسرعة.

يحتوي ملف eve.json على نفس الأحداث بتنسيق JSON، مع حقول مثل الطابع الزمني، ونوع الحدث، وعنوان IP المصدر، وعنوان IP الوجهة، ومنفذ المصدر، ومنفذ الوجهة، والبروتوكول، بالإضافة إلى ملف فرعي للتنبيهات يحتوي على الإجراء، ومعرّف المجموعة، ومعرّف التوقيع، والمراجعة، والتوقيع، والفئة، ومستوى الخطورة. يمكن استيعاب هذا التنسيق بسهولة باستخدام Logstash أو Fluentd أو Filebeat أو أي وكيل سجلات آخر ، مما يتيح تحليلات أكثر شمولاً من مجرد استخدام نص عادي.

عند نشر Suricata على خادم متعدد النوى (مثلًا، 8 نوى)، يظهر ضغط الخيوط بوضوح في أدوات مثل htop في وضع الخيوط، حيث يُظهر خيطًا واحدًا أو أكثر لالتقاط البيانات (pcap أو AF_PACKET أو NFQ) وعددًا كبيرًا من خيوط الكشف موزعة على النوى. ويمكن أن يؤثر تعديل نسبة خيوط الكشف وتقارب وحدة المعالجة المركزية بشكل كبير على الإنتاجية وزمن الاستجابة عندما يقترب حجم حركة البيانات من حدود النظام الأساسي.

قبل نشر النظام في بيئة الإنتاج، يُنصح بتخصيص بعض الوقت لضبط مجموعات القواعد المُفعّلة بدقة لتجنب تدفق الإنذارات الكاذبة التي قد تحجب حركة المرور المشروعة أو تُسبب ازدحامًا في سجلات النظام. يتيح لك Suricata-update تعطيل فئات كاملة أو قواعد فردية لتحقيق توازن مناسب بين حساسية النظام وسهولة استخدامه.

تطبيقات خاصة: بروتوكول نقل الصوت عبر الإنترنت (VoIP)، وتحليلات الصوت، وقائمة انتظار إبداعية

إلى جانب الاستخدامات التقليدية (حماية خدمات الويب، واكتشاف البرامج الضارة، وتحليل هجمات DDoS)، يتيح برنامج Netfilter+NFQUEUE حلولًا مبتكرة في مجالات مثل VoIP. على سبيل المثال، يمكن إعداد فلتر لمكافحة البريد العشوائي عبر بروتوكول الإنترنت (SPIT) أو نظام لحجب الألفاظ النابية في تدفقات RTP.

الفكرة هي: تحديد حركة مرور RTP عن طريق المنافذ أو عن طريق التعرف على البروتوكول وإرسالها إلى NFQUEUE؛ من تطبيق المستخدم، إعادة بناء دفق RTP باستخدام مكتبة مثل librtp ، واستخراج الصوت بتنسيق WAV وتمريره إلى محرك التعرف على الكلمات الرئيسية (تحديد الكلمات)، مثل مكتبة توليف أو التعرف التي يقدمها طرف ثالث.

استنادًا إلى الكلمات المكتشفة، يمكن لعملية NFQUEUE أن تقرر السماح بالتشغيل أو حظره أو حتى تعديله عن طريق إدخال صوت تنبيه في البث، مع العلم أن هذا الأخير يتطلب تحكمًا دقيقًا للغاية في بروتوكول RTCP وتسلسل الحزم والتوقيتات - وهو ما يُشبه إلى حد كبير أسلوب اعتراض الاتصال. ليس الأمر بسيطًا، ولكنه نظريًا قابل للتحقيق تمامًا باستخدام نظام قائمة الانتظار ونظام الحكم نفسه.

صحيحٌ أنه يمكن تنفيذ بعض هذه العمليات باستخدام برنامج تحليل بسيط يُرسل البيانات إلى معالج خارجي، ثم يُنفذها بناءً على إشارات بروتوكول بدء الجلسة (SIP) أو عبر وحدة تحكم حدود الجلسة (SBC) (مثل Asterisk أو Kamailio). لكن الفرق في استخدام NFQUEUE يكمن في إمكانية تنفيذ الإجراءات على تدفق بروتوكول النقل في الوقت الحقيقي (RTP) بشكل فوري ومباشر ، دون الحاجة إلى تنسيق مكونات متعددة أو انتظار طبقة الإشارات لإتمام المكالمة.

توضح هذه السيناريوهات بوضوح إمكانات مزيج GNU/Linux + Netfilter + Suricata + مكتبات الطرف الثالث: الأمر لا يتعلق فقط بحظر المنافذ وعناوين IP، ولكن يتعلق بتنسيق قرارات حركة المرور المعقدة في الوقت الفعلي باستخدام نظام بيئي للبرمجيات الحرة بنسبة 100٪.

بالنظر إلى الرحلة بأكملها، بدءًا من برنامج C الصغير الذي يقبل الحزم دائمًا وصولًا إلى نشر Suricata متعدد العمليات المتكامل مع NFQUEUE وPfsense وقواعد البيانات وذاكرة التخزين المؤقت، يمكن للمرء أن يقدر المرونة التي توفرها هذه المجموعة التقنية لبناء كل شيء بدءًا من جدران الحماية الديناميكية البسيطة وحتى بنى IDS/IPS على نطاق مركز البيانات، مع إمكانيات فحص عميقة حقيقية واستجابة آلية للهجمات المعقدة بشكل متزايد.