كيفية تصدير سجلات نظام SLES إلى خادم Syslog بعيد بشكل آمن

الطريقة الأكثر أمانًا وعملية لتصدير سجلات نظام SUSE Linux Enterprise Server (SLES) إلى مُجمِّع سجلات النظام عن بُعد هي استخدام rsyslog عبر بروتوكول TCP مع TLS، والتحقق من صحة شهادة المُجمِّع بالاسم، وتخصيص قائمة انتظار منفصلة لعملية إعادة التوجيه. يُعدّ بروتوكول UDP البسيط لسجلات النظام سهل الاستخدام، ولكنه لا يوفر السرية أو مصادقة النظير. يُحسِّن بروتوكول TCP البسيط من سرعة التسليم، ولكنه لا يزال يُعرِّض محتويات السجلات للخطر أثناء النقل.

يستخدم هذا الدليل برنامج تشغيل تدفق الشبكة GnuTLS ( gtls) وصيغة إجراءات rsyslog الحديثة. هذه العملية مُصممة لأنظمة SLES 15 SP7، التي تم تحديث دليل إدارتها في 1 أكتوبر 2026. تأكد دائمًا من التحقق من الحزم وإصدار rsyslog المُثبت على جهازك قبل نسخ أي إعدادات حرفيًا. توصي وثائق rsyslog الأصلية باستخدام بروتوكول TCP مع TLS في عمليات النشر الحديثة، كما توصي باستخدام قائمة انتظار الإجراءات لإعادة توجيه TCP.

المراجع الموثوقة: وثائق SUSE Linux Enterprise Server 15 SP7 ، ووثائق rsyslog omfwd ، وإعداد عميل rsyslog TLS ، و RFC 5425: تعيين نقل TLS لـ Syslog .

مرجع سريع

قبل إعداد إعادة التوجيه

تحتاج إلى اسم النطاق المؤهل بالكامل للمُجمِّع البعيد، ومنفذ TCP الذي يستمع إليه، وشهادة مرجع التصديق (CA) التي تُوقِّع شهادة المُجمِّع. بالنسبة لبروتوكول TLS المتبادل، تحتاج أيضًا إلى شهادة عميل ومفتاح خاص لجهاز SLES. يجب أن تكون شهادة المُجمِّع صالحة لاسم المضيف الذي تُكوِّنه في rsyslog، ويُفضَّل أن يكون ذلك من خلال اسم بديل للموضوع (SAN). لا تُعالج عدم تطابق الاسم بتعطيل التحقق من الشهادة.

يجب أن يكون جامع البيانات البعيد مُهيأً مسبقًا لقبول سجلات النظام عبر بروتوكول TLS. تركز هذه المقالة على مُرسِل SLES لأن إعداد المُستقبِل يختلف بين rsyslog وsyslog-ng وأجهزة SIEM وخدمات التسجيل المُدارة. إذا كان جدار الحماية يفصل بين النظامين، فاسمح لمضيف SLES بإنشاء اتصالات TCP مع جامع البيانات على المنفذ المُهيأ. عادةً لا تتطلب سياسة جدار الحماية الافتراضي فتح منفذ وارد على مُرسِل SLES.

الخطوة 1: تأكد من تثبيت rsyslog وحدد الإصدار الحالي

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

rpm -q rsyslog
rsyslogd -v
systemctl status rsyslog --no-pager

إذا لم يكن برنامج rsyslog مثبتًا، فقم بتثبيته من مستودعات SLES المُفعّلة لديك. حافظ على تحديث النظام من خلال عملية تحديث SUSE المعتادة قبل إنشاء اتصال تسجيل طويل الأمد.

الخطوة الثانية: تثبيت وحدة GnuTLS rsyslog

في نظام SLES، يتم تضمين برنامج تشغيل شبكة TLS بشكل منفصل. قم بتثبيت وحدة GnuTLS مع الإبقاء على حزمة rsyslog الأساسية.

sudo zypper install rsyslog rsyslog-module-gtls

يمكنك التأكد من أن الملفات جاءت من الحزمة المتوقعة باستخدام الأمر التالي rpm -ql rsyslog-module-gtls. تختلف أسماء الحزم باختلاف التوزيعة، لذا لا تقم بنسخ أسماء الحزم من الأدلة الموجهة إلى دبيان أو ريد هات إن لينكس.

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

استخدم الشهادات الصادرة عن مؤسستك أو منصة تسجيل البيانات. بالنسبة لنظام الإنتاج، تجنب إنشاء مرجع مصدق خاص جديد على مضيف إرسال السجلات. يمكن للمختبر استخدام مرجع مصدق تجريبي، ولكن يجب أن تتبع مواد الثقة الخاصة بالإنتاج عملية البنية التحتية للمفاتيح العامة (PKI) المعتمدة في مؤسستك.

أنشئ مجلدًا مملوكًا للمستخدم الجذر، وانسخ الملفات إليه، وقيّد الوصول إلى المفتاح الخاص. استبدل أسماء الملفات المذكورة في المثال بالمسارات التي يوفرها فريق البنية التحتية للمفاتيح العامة (PKI) الخاص بك.

sudo install -d -m 0755 /etc/rsyslog.d/certs
sudo install -m 0644 ca.pem /etc/rsyslog.d/certs/ca.pem
sudo install -m 0644 sles-client.crt /etc/rsyslog.d/certs/sles-client.crt
sudo install -m 0600 sles-client.key /etc/rsyslog.d/certs/sles-client.key
sudo chown root:root /etc/rsyslog.d/certs/*

افحص شهادة المرجع المصدق وشهادة العميل بدلاً من الاعتماد على أسماء الملفات:

openssl x509 -in /etc/rsyslog.d/certs/ca.pem -noout -subject -issuer
openssl x509 -in /etc/rsyslog.d/certs/sles-client.crt -noout -subject -issuer -dates

يحذر دليل عميل rsyslog TLS صراحةً من ضرورة حماية المفتاح الخاص بالجهاز. فإذا تمكن مستخدم آخر من قراءة هذا المفتاح، فقد يتمكن من انتحال شخصية عميل التسجيل.

الخطوة 4: تكوين إعادة توجيه TLS مع التحقق من اسم الخادم

أنشئ نقطة وصول مخصصة مثل هذه /etc/rsyslog.d/60-remote-tls.conf. إن فصل إعادة التوجيه عن بُعد عن إعدادات المورّد يُسهّل عملية المراجعة والتراجع.

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/sles-client.crt"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/sles-client.key"
)

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
    queue.type="linkedList"
)

StreamDriverMode="1"من المهم ملاحظة أن اختيار برنامج تشغيل يدعم بروتوكول TLS وحده لا يكفي في الإعدادات التي يكون فيها الوضع الافتراضي هو TCP العادي. StreamDriverAuthMode="x509/name"ثم يتحقق من الشهادة البعيدة ويتأكد من تطابق هوية الخادم مع النظير المسموح به. استخدم اسم المُجمِّع الدقيق في الشهادة بدلاً من استخدام رمز عام كلما أمكن ذلك.

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

الخطوة 5: التحقق، إعادة التشغيل، إرسال حدث اختبار، والتحقق من التسليم

تحقق من صحة إعدادات rsyslog بالكامل قبل إعادة تشغيل الخدمة. هذه هي أسرع طريقة لاكتشاف أخطاء بناء الجملة ومراجع الوحدات المفقودة.

sudo rsyslogd -N1

في حال نجاح عملية التحقق، أعد تشغيل rsyslog وأرسل رسالة اختبار فريدة:

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
logger -t sles-tls-test "remote syslog TLS test $(date -Is)"
sudo journalctl -u rsyslog -n 50 --no-pager

ابحث في جهاز التجميع عن الوسم sles-tls-testواسم مضيف المرسل. يُثبت ظهور الرسالة بنجاح وصولها إلى جهاز التجميع، لكنه لا يُثبت وحده صحة إعدادات التحقق من الشهادة. وللتحقق الأقوى، يُنصح بإبقاء هذه الخاصية x509/nameمُفعّلة والتأكد من عدم وجود أخطاء في مصافحة TLS أو اسم النظير في سجل خدمة rsyslog.

في حال فشل الاتصال، اختبر تحليل اسم النطاق (DNS) لـ logs.example.com، وتأكد من إمكانية الوصول إلى منفذ TCP 6514، وتحقق من تواريخ صلاحية الشهادة، وتأكد من أن شهادة المُجمِّع تحتوي على اسم النطاق المتوقع. تأكد أيضًا من أن المُجمِّع يثق في جهة إصدار الشهادات (CA) التي أصدرت شهادة عميل SLES عند تفعيل بروتوكول TLS المتبادل.

قائمة التحقق من استكشاف الأخطاء وإصلاحها

• تم رفض الاتصال: لا يستمع جامع البيانات على العنوان/المنفذ المُكوّن أو أن جدار الحماية يرفض الاتصال.
• مهلة زمنية: التوجيه، أو قوائم التحكم بالوصول للشبكة، أو جدار الحماية يقوم بإسقاط حركة المرور بصمت.
• فشل التحقق من الشهادة: ملف المرجع المصدق خاطئ أو غير مكتمل أو منتهي الصلاحية أو سلسلة شهادات الخادم غير مكتملة.
• عدم تطابق اسم النظير: لا يتطابق الاسم / مع هوية شهادة المُجمِّع target.StreamDriverPermittedPeers
• تم رفض الإذن على المفتاح: مسار المفتاح أو الأذونات لا تسمح لعملية rsyslog بقراءة الملف ضمن تكوين خدمة SLES.
• تتوقف الرسائل أثناء انقطاع الخدمة: راجع تصميم قائمة انتظار الإجراءات وسعتها. توصي وثائق omfwd الأصلية تحديدًا باستخدام قائمة انتظار لإعادة توجيه TCP حتى لا يعيق عدم توفر الوجهة المعالجة العادية.

ملاحظات أمنية يسهل تفويتها

لا تستبدل التحقق من صحة الشهادة ببروتوكول TLS المجهول إلا إذا كنت تفهم تمامًا المفاضلة بينهما. فالتشفير دون مصادقة الخادم قد يُعرّض السجلات لمهاجمٍ نشطٍ من نوع "رجل في المنتصف". كذلك، لا تفتح منفذ TCP 6514 الوارد على مُرسِل SLES لمجرد أن الوجهة تستخدم هذا المنفذ؛ فالتوجيه هو اتصال عميل صادر.

احمِ مفاتيح العميل الخاصة كبيانات اعتماد، وقم بتدوير الشهادات قبل انتهاء صلاحيتها، واستخدم اسم مضيف جامع بيانات يظل ثابتًا بغض النظر عن تغييرات عنوان IP. إذا كنت بحاجة إلى ضمانات تسليم أقوى من إعادة توجيه TCP/TLS العادية، فإن وثائق rsyslog تشير إلى RELP كبديل مصمم لضمان التسليم المؤكد. هذا خيار تصميم منفصل عن تشفير النقل.

التحقق النهائي

يجب أن يستوفي النشر الصحيح أربعة شروط قابلة للملاحظة: نجاح عملية التحقق من صحة تكوين rsyslog، وبقاء الخدمة نشطة بعد إعادة التشغيل، واستلام المُجمِّع لحدث الاختبار الفريد، وعدم وجود أخطاء في سجل المُرسِل تتعلق بثقة TLS أو اسم النظير. بعد اجتياز هذه الفحوصات، وثِّق تواريخ انتهاء صلاحية الشهادة واعتمادية المُجمِّع البعيد حتى لا تتسبب عمليات الصيانة المستقبلية في تعطيل التسجيل المركزي دون علم المستخدم.