วิธีการส่งออกบันทึกระบบ SLES ไปยังเซิร์ฟเวอร์ Syslog ระยะไกลอย่างปลอดภัย

วิธีที่ปลอดภัยและใช้งานได้จริงในการส่งออกบันทึกระบบของ SUSE Linux Enterprise Server (SLES) ไปยังตัวรวบรวม syslog ระยะไกล คือการใช้ rsyslog ผ่าน TCP ด้วย TLS ตรวจสอบความถูกต้องของใบรับรองตัวรวบรวมโดยใช้ชื่อ และกำหนดคิวเฉพาะสำหรับการส่งต่อ syslog ผ่าน 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 โดยควรใช้ Subject Alternative Name (SAN) อย่าแก้ปัญหาชื่อไม่ตรงกันโดยการปิดใช้งานการตรวจสอบใบรับรอง

ตัวเก็บรวบรวมข้อมูลระยะไกลจะต้องได้รับการกำหนดค่าให้ยอมรับ syslog ผ่าน TLS แล้ว บทความนี้เน้นที่ตัวส่ง SLES เนื่องจากวิธีการตั้งค่าตัวรับจะแตกต่างกันไปตาม rsyslog, syslog-ng, อุปกรณ์ SIEM และบริการบันทึกข้อมูลแบบจัดการ หากไฟร์วอลล์แยกระบบออกจากกัน ให้โฮสต์ SLES สามารถเริ่มต้นการเชื่อมต่อ TCP ไปยังตัวเก็บรวบรวมข้อมูลบนพอร์ตที่กำหนดค่าไว้ได้ โดยปกติแล้วนโยบายไฟร์วอลล์แบบมีสถานะเริ่มต้นจะไม่จำเป็นต้องเปิดพอร์ตขาเข้าบนตัวส่ง SLES

ขั้นตอนที่ 1: ตรวจสอบว่าได้ติดตั้ง rsyslog แล้ว และระบุเวอร์ชันปัจจุบัน

เริ่มต้นด้วยการตรวจสอบเวอร์ชันของแพ็กเกจและดีมอน เพื่อป้องกันความสับสนเมื่อตัวอย่างเก่าๆ ใช้คำสั่งที่ไม่รองรับโดยเวอร์ชันที่สร้างบนเซิร์ฟเวอร์ของคุณ

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

หากไม่ได้ติดตั้ง rsyslog ให้ติดตั้งจากที่เก็บซอฟต์แวร์ SLES ที่เปิดใช้งานไว้ หมั่นอัปเดตระบบผ่านกระบวนการอัปเดต SUSE ตามปกติก่อนที่จะเปิดใช้งานการเชื่อมต่อบันทึกข้อมูลระยะยาว

ขั้นตอนที่ 2: ติดตั้งโมดูล GnuTLS rsyslog

บน SLES ไดรเวอร์เครือข่าย TLS จะถูกบรรจุแยกต่างหาก ติดตั้งโมดูล GnuTLS และคงแพ็คเกจ rsyslog พื้นฐานไว้:

sudo zypper install rsyslog rsyslog-module-gtls

คุณสามารถยืนยันได้ว่าไฟล์มาจากแพ็กเกจที่คาดไว้โดยใช้คำสั่งrpm -ql rsyslog-module-gtls`package name` ชื่อแพ็กเกจจะแตกต่างกันไปตามแต่ละระบบปฏิบัติการ ดังนั้นอย่าคัดลอกชื่อแพ็กเกจจากคู่มือที่ใช้ Debian หรือ RHEL

ขั้นตอนที่ 3: เก็บรักษาข้อมูลประจำตัวของ CA และไคลเอ็นต์ไว้ในที่ปลอดภัย

ใช้ใบรับรองที่ออกโดยองค์กรหรือแพลตฟอร์มการบันทึกข้อมูลของคุณ สำหรับระบบใช้งานจริง ควรหลีกเลี่ยงการสร้าง CA ส่วนตัวใหม่บนโฮสต์ที่ส่งบันทึกข้อมูล ห้องปฏิบัติการสามารถใช้ CA สำหรับทดสอบได้ แต่สำหรับข้อมูลความน่าเชื่อถือในระบบใช้งานจริง ควรปฏิบัติตามกระบวนการ PKI ขององค์กรของคุณ

สร้างไดเร็กทอรีที่เป็นกรรมสิทธิ์ของ root คัดลอกไฟล์ และจำกัดการเข้าถึงคีย์ส่วนตัว แทนที่ชื่อไฟล์ตัวอย่างด้วยเส้นทางที่ทีม 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/*

ตรวจสอบใบรับรอง CA และใบรับรองไคลเอ็นต์ แทนที่จะเชื่อถือชื่อไฟล์:

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

เอกสารประกอบการใช้งานไคลเอ็นต์ TLS ของ rsyslog เตือนไว้อย่างชัดเจนว่าต้องปกป้องคีย์ส่วนตัวของเครื่อง หากผู้ใช้รายอื่นสามารถอ่านคีย์ส่วนตัวได้ ผู้ใช้นั้นอาจสามารถปลอมตัวเป็นไคลเอ็นต์การบันทึกข้อมูลได้

ขั้นตอนที่ 4: กำหนดค่าการส่งต่อ TLS พร้อมการตรวจสอบชื่อเซิร์ฟเวอร์

สร้าง drop-in เฉพาะ เช่น/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 ได้ ตรวจสอบวันหมดอายุของใบรับรอง และตรวจสอบว่าใบรับรองตัวเก็บรวบรวมข้อมูลมีชื่อ DNS ที่คาดหวังไว้ นอกจากนี้ ให้ตรวจสอบว่าตัวเก็บรวบรวมข้อมูลเชื่อถือ CA ที่ออกใบรับรองไคลเอ็นต์ SLES เมื่อเปิดใช้งาน Mutual TLS

รายการตรวจสอบการแก้ไขปัญหา

• การเชื่อมต่อถูกปฏิเสธ:ตัวเก็บข้อมูลไม่ได้กำลังรับฟังอยู่ที่ที่อยู่/พอร์ตที่กำหนดค่าไว้ หรือไฟร์วอลล์กำลังปฏิเสธการเชื่อมต่อ
• หมดเวลา:การกำหนดเส้นทาง, ACL ของเครือข่าย หรือไฟร์วอลล์กำลังบล็อกการรับส่งข้อมูลโดยไม่แจ้งให้ทราบ
• การตรวจสอบใบรับรองล้มเหลว:ไฟล์ CA ไม่ถูกต้อง ไม่สมบูรณ์ หมดอายุ หรือห่วงโซ่ใบรับรองของเซิร์ฟเวอร์ไม่สมบูรณ์
• ชื่อโหนดไม่ตรงกัน:ชื่อtarget/ StreamDriverPermittedPeersไม่ตรงกับข้อมูลประจำตัวในใบรับรองตัวเก็บรวบรวมข้อมูล
• ไม่ได้รับอนุญาตให้เข้าถึงคีย์:เส้นทางของคีย์หรือสิทธิ์การเข้าถึงไม่อนุญาตให้กระบวนการ rsyslog อ่านไฟล์ภายใต้การกำหนดค่าบริการ SLES
• การรับส่งข้อความจะหยุดลงระหว่างที่ระบบขัดข้อง:โปรดตรวจสอบการออกแบบและความจุของคิวการดำเนินการ เอกสาร omfwd ต้นทางแนะนำเป็นพิเศษให้ใช้คิวสำหรับการส่งต่อ TCP เพื่อป้องกันไม่ให้ปลายทางที่ไม่พร้อมใช้งานขัดขวางการประมวลผลตามปกติ

ข้อควรระวังด้านความปลอดภัยที่มักถูกมองข้าม

อย่าใช้ TLS แบบไม่ระบุตัวตนแทนการตรวจสอบความถูกต้องของใบรับรอง เว้นแต่คุณจะเข้าใจข้อดีข้อเสียอย่างถ่องแท้ การเข้ารหัสโดยไม่ตรวจสอบความถูกต้องของเซิร์ฟเวอร์ยังคงสามารถเปิดเผยบันทึกข้อมูลให้กับผู้โจมตีแบบ man-in-the-middle ได้ ในทำนองเดียวกัน อย่าเปิดพอร์ต TCP 6514 ขาเข้าบนฝั่งผู้ส่ง SLES เพียงเพราะปลายทางใช้พอร์ตนั้น การส่งต่อเป็นการเชื่อมต่อไคลเอ็นต์ขาออก

ปกป้องคีย์ส่วนตัวของไคลเอ็นต์ในฐานะข้อมูลประจำตัว หมุนเวียนใบรับรองก่อนหมดอายุ และใช้ชื่อโฮสต์ตัวเก็บรวบรวมที่คงที่แม้ว่าจะมีการเปลี่ยนแปลงที่อยู่ IP หากคุณต้องการการรับประกันการส่งมอบที่แข็งแกร่งกว่าการส่งต่อ TCP/TLS ปกติ เอกสารของ rsyslog ชี้ไปที่ RELP เป็นทางเลือกที่ออกแบบมาสำหรับการส่งมอบที่ได้รับการยืนยัน ซึ่งเป็นทางเลือกการออกแบบที่แตกต่างจากการเข้ารหัสการขนส่ง

การตรวจสอบขั้นสุดท้าย

การติดตั้งใช้งานที่ถูกต้องควรเป็นไปตามเงื่อนไขที่สังเกตได้สี่ประการ ได้แก่ การตรวจสอบความถูกต้องของการกำหนดค่า rsyslog สำเร็จ บริการยังคงทำงานอยู่หลังจากรีสตาร์ท ตัวเก็บรวบรวมได้รับเหตุการณ์ทดสอบที่ไม่ซ้ำกัน และบันทึกของผู้ส่งไม่แสดงข้อผิดพลาดเกี่ยวกับความเชื่อถือ TLS หรือชื่อของคู่ค้า เมื่อการตรวจสอบเหล่านี้ผ่านแล้ว ให้บันทึกวันหมดอายุของใบรับรองและการพึ่งพาของตัวเก็บรวบรวมระยะไกล เพื่อที่การบำรุงรักษาในอนาคตจะไม่ทำให้การบันทึกส่วนกลางเสียหายโดยไม่แจ้งให้ทราบล่วงหน้า