إعادة توجيه سجلات النظام الآمنة في SLES باستخدام rsyslog وبروتوكول TLS المتبادل

لإعادة توجيه سجلات نظام SUSE Linux Enterprise Server (SLES) بشكل آمن، قم بتهيئة rsyslog لإرسال الرسائل عبر منفذ TCP 6514 المحمي ببروتوكول TLS، وتحقق من اسم شهادة المُجمِّع، وأكِّد التسليم بحدث اختبار. تلقى SLES 15 SP7 تحديثًا اختياريًا لـ rsyslog في 27 مارس 2026 أضاف وحدة OpenSSL TLS؛ يستخدم التكوين أدناه gtlsوحدة GnuTLS المُثبتة بدلاً من ذلك.

يشمل هذا الإجراء مُرسِل SLES 15 باسم sles01.example.netوجامع rsyslog باسم logs.example.net. استبدل كلا الاسمين وجميع مسارات الشهادات بقيمك الخاصة. يستخدم هذا الإجراء بروتوكول TLS المتبادل، لذا يقوم الجامع بالتحقق من هوية المُرسِل، كما يقوم المُرسِل بالتحقق من هوية الجامع.

1. تحقق من rsyslog ومسار تسجيل SLES

قم بتثبيت برنامج rsyslog ووحدة GnuTLS الخاصة به على كلا الجهازين من مستودعات SUSE المسجلة لديك. قد تحتوي عمليات التثبيت الحالية بالفعل على الحزمة الأولى.

sudo zypper install rsyslog rsyslog-module-gtls
rpm -q rsyslog rsyslog-module-gtls
sudo systemctl enable --now rsyslog
rsyslogd -v

راجع /etc/rsyslog.confالمقتطفات الموجودة /etc/rsyslog.d/قبل إضافة القواعد. على وجه الخصوص، عطّل أي قاعدة إعادة توجيه قديمة غير مشفرة *.* @@hostلنفس الوجهة؛ وإلا فقد تسلك الرسائل مسارين، أحدهما بدون بروتوكول TLS.

يستخدم SLES systemd-journaldأحداث السجل بينما يعالج rsyslog مدخلات syslog. تأكد من وصول الأحداث المطلوبة إلى rsyslog عبر إعدادات الإدخال الحالية. ForwardToSyslog=yesتوفر SUSE وثائق /etc/systemd/journald.confلإعادة توجيه السجل إلى syslog؛ تحقق من بيئة النشر قبل تغييرها، لأن تفعيل قارئات السجل بشكل منفصل قد يؤدي إلى إنشاء أحداث مكررة. تعيد هذه العملية توجيه الرسائل التي تمت معالجتها بالفعل بواسطة rsyslog، وليس كل ملف /var/logتلقائيًا.

2. إعداد شهادات الخادم والعميل الموثوقة

استخدم جهة إصدار شهادات (CA) تابعة للمؤسسة لإصدار شهادة باسم بديل لموضوع نظام أسماء النطاقات (DNS) logs.example.netللمُجمِّع، وشهادة منفصلة تُعرِّف sles01.example.netالمُرسِل. تأكد من صلاحية الشهادات لأدوار خادم أو عميل TLS، وأن كلا الجهازين يثقان بجهة إصدار الشهادات. اتبع إجراءات البنية التحتية للمفاتيح العامة (PKI) الخاصة بك لإنشاء الشهادات وتجديدها؛ ولا تُعِد استخدام مفتاح خاص واحد عبر أجهزة مختلفة.

انسخ الملفات المناسبة عبر قناة آمنة معتمدة من قِبل المسؤول. في هذا المثال، يستخدم كلا الجهازين /etc/rsyslog.d/tls/ca.pem. يمتلك المُجمِّع أيضًا server-cert.pemو server-key.pem؛ بينما يمتلك المُرسِل client-cert.pemو client-key.pem.

sudo install -d -m 0750 /etc/rsyslog.d/tls
sudo chmod 0600 /etc/rsyslog.d/tls/*-key.pem
sudo chmod 0644 /etc/rsyslog.d/tls/ca.pem

قم بتقييد الوصول إلى الشهادة والمفتاح لهوية خدمة rsyslog عند الضرورة. لا تكشف المفاتيح الخاصة في التشخيصات، أو سجل الأوامر، أو مستودعات Git، أو دفق السجل المُصدَّر. تأكد من أن عملية rsyslog قادرة على قراءة مفتاحها قبل إعادة تشغيل الخدمة.

3. قم بتمكين مستقبل TLS مصادق عليه على جهاز التجميع

أضف logs.example.netما يلي كـ /etc/rsyslog.d/30-tls-listener.conf. إذا imtcpكانت الوحدة النمطية محملة مسبقًا في مكان آخر، فاحتفظ بعبارة تحميل وحدة نمطية واحدة فقط. تضع مجموعة القواعد المخصصة الرسائل المستلمة عن بُعد في ملف منفصل بدلاً من دمجها مع رسائل النظام المحلي.

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem"
)
module(load="imtcp")
ruleset(name="remote_tls") {
  action(type="omfile" file="/var/log/remote-tls.log")
}
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer="sles01.example.net"
  ruleset="remote_tls"
)

StreamDriver.Mode="1"يُفعّل بروتوكول TLS، x509/nameويرفض PermittedPeerالعملاء الذين لا يملكون هوية شهادة مقبولة. إن اقتصار الأمر على اسم واحد مُحدد هوية مقصود؛ إذ يُفضّل توسيع قائمة النظراء المعتمدين عند إضافة مُرسلين آخرين بدلاً من إضعاف المصادقة.

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload
sudo ss -ltn | grep ':6514'

نفّذ أوامر جدار الحماية فقط إذا كان المُجمِّع يستخدم firewalld. قيّد حركة مرور TCP/6514 الواردة إلى شبكات المُرسِلين المعروفة باستخدام جدار الحماية الخاص بمضيفك أو جدار الحماية الرئيسي؛ فتح المنفذ لا يُغني عن مصادقة الشهادة. تأكد أيضًا من عدم وجود أي مُستمع نص عادي مُعرَّض عن غير قصد.

4. أضف خاصية إعادة توجيه TLS وقائمة انتظار محدودة إلى SLES

تأكد من sles01.example.netوجود دليل عمل rsyslog وأن الخدمة قادرة على الكتابة إليه. الدليل الموضح هنا هو دليل توضيحي فقط؛ احتفظ بالدليل المُهيأ مسبقًا workDirectoryإذا كان مُثبّت الحزمة لديك يوفر واحدًا. أضف هذا المقتطف البرمجي كالتالي /etc/rsyslog.d/60-tls-forward.conf:

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client-key.pem"
)
*.* action(
  type="omfwd"
  target="logs.example.net"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  queue.type="LinkedList"
  queue.filename="tls_forward"
  queue.size="10000"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

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

تحقق من صحة المرسل وأعد تشغيله:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

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

5. التحقق من الاستلام والتحقيق في حالة فشل المصافحة

تأكد أولاً من أن جهاز التجميع يستمع على منفذ TCP/6514 وأن جهاز الإرسال قادر على الوصول إلى المضيف عبر جدار الحماية. ثم نفّذ الأمر التالي على جهاز إرسال SLES:

logger -t sles-tls-check "TLS forwarding probe"

على جهاز التجميع، ابحث عن ملف السجل البعيد المُكوّن:

sudo grep 'TLS forwarding probe' /var/log/remote-tls.log
sudo journalctl -u rsyslog -n 50 --no-pager

يؤكد العثور على العلامة /var/log/remote-tls.logأن مسار إعادة التوجيه على مستوى التطبيق قد نجح في هذا الاختبار. لكن هذا لا يثبت جمع جميع ملفات سجلات التطبيق. لاختبار المصادقة بشكل مستقل، استخدم مؤقتًا شهادة مختلفة غير موثوقة أو اسم نظير غير متطابق خلال فترة صيانة محددة، وتأكد من فشل اتصال TLS؛ ثم استعد الإعدادات الأصلية فورًا.

إذا لم يظهر المؤشر، فاتبع خطوات حل المشكلة بالترتيب التالي:

• لا يوجد مستمع أو تم رفض الاتصال: تحقق systemctl status rsyslogمن TCP/6514 وقواعد جدار الحماية الخاصة بالمجمع.
• فشل TLS أو الشهادة: قارن أسماء النطاقات البديلة للشهادة مع PermittedPeerو StreamDriverPermittedPeers؛ تحقق من سلسلة CA وتواريخ انتهاء الصلاحية وساعات النظام وأذونات المفتاح الخاص.
• متصل ولكن لا توجد أحداث: ابحث عن مدخلات سجلات النظام/المذكرات المكررة أو المفقودة، وإجراءات إعادة التوجيه المعلقة، وسعة قائمة انتظار القرص. راجع ذلك journalctl -u rsyslogعلى كلا المضيفين.

تتبع هذه الطريقة دليل تسجيل النظام الرسمي لنظام SLES 15 SP7 ، ودليل عميل rsyslog المُصادق عليه بالشهادة ، ومرجع مستمع imtcp ، ومرجع إعادة توجيه omfwd . ويوثق إشعار تحديث SUSE الصادر في مارس 2026 إضافة وحدة OpenSSL الاختيارية. تختلف الإعدادات بين حزم خدمة SLES، لذا يُرجى التحقق من صحة الإعدادات على إصدار rsyslog المُثبّت لديك قبل تطبيق التغييرات على بيئة الإنتاج.