การส่งต่อ Syslog ของ SLES อย่างปลอดภัยด้วย rsyslog และ Mutual TLS

เพื่อส่งต่อบันทึกระบบของ SUSE Linux Enterprise Server (SLES) อย่างปลอดภัย ให้กำหนดค่า rsyslog ให้ส่งข้อความผ่านพอร์ต TCP 6514 ที่ได้รับการป้องกันด้วย TLS ตรวจสอบชื่อใบรับรองของตัวเก็บรวบรวม และยืนยันการส่งด้วยเหตุการณ์ทดสอบ SLES 15 SP7 ได้รับการอัปเดต rsyslog เพิ่มเติมเมื่อวันที่ 27 มีนาคม 2026 ซึ่งเพิ่มโมดูล OpenSSL TLS เข้ามา การกำหนดค่าด้านล่างนี้จงใจใช้gtlsโมดูล GnuTLS ( ) ที่มีอยู่แล้วแทน

ขั้นตอนนี้นำเสนอการใช้งานกับ SLES 15 sender ที่ชื่อว่าsles01.example.netและ rsyslog collector ที่ชื่อว่าlogs.example.netแทนที่ชื่อทั้งสองและเส้นทางใบรับรองทั้งหมดด้วยค่าของคุณเอง ขั้นตอนนี้ใช้ TLS แบบสองทาง ดังนั้น collector จะตรวจสอบความถูกต้องของ sender และผู้ส่งก็จะตรวจสอบความถูกต้องของ collector ด้วยเช่นกัน

1. ตรวจสอบ rsyslog และเส้นทางการบันทึกข้อมูลของ SLES

บนเครื่องทั้งสองเครื่อง ให้ติดตั้ง daemon 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-journaldjournal สำหรับเหตุการณ์ต่างๆ ในขณะที่ rsyslog ประมวลผลข้อมูลเข้าจาก syslog ตรวจสอบให้แน่ใจว่าเหตุการณ์ที่คุณต้องการส่งไปถึง rsyslog ผ่านการกำหนดค่าข้อมูลเข้าที่มีอยู่แล้ว เอกสารของ SUSE ForwardToSyslog=yesเกี่ยว/etc/systemd/journald.confกับการส่งต่อ journal ไปยัง syslog โปรดตรวจสอบการใช้งานของคุณก่อนที่จะเปลี่ยนแปลง เนื่องจากหากเปิดใช้งานตัวอ่าน journal แยกต่างหาก อาจทำให้เกิดเหตุการณ์ซ้ำซ้อนได้ ขั้นตอนนี้จะส่งต่อข้อความที่ rsyslog ประมวลผลแล้ว ไม่ใช่ทุกไฟล์โดย/var/logอัตโนมัติ

หน้าต่างเทอร์มินัลแสดงผลการตรวจสอบแพ็กเกจ rsyslog และไฟล์ CA, ใบรับรองไคลเอ็นต์ และคีย์ส่วนตัวสำหรับผู้ส่ง SLES
ตรวจสอบการติดตั้ง rsyslog และยืนยันว่าผู้ส่งมี CA ใบรับรอง และไฟล์คีย์แยกต่างหากก่อนที่จะเปิดใช้งาน TLS

2. เตรียมใบรับรองเซิร์ฟเวอร์และไคลเอ็นต์ที่เชื่อถือได้

ใช้หน่วยงานออกใบรับรอง (CA) ที่องค์กรควบคุมเพื่อออกใบรับรองที่มีชื่อทางเลือกของหัวเรื่อง DNS logs.example.netสำหรับผู้เก็บรวบรวมข้อมูล และใบรับรองแยกต่างหากsles01.example.netสำหรับผู้ส่ง ตรวจสอบให้แน่ใจว่าใบรับรองนั้นถูกต้องสำหรับบทบาทเซิร์ฟเวอร์ TLS หรือไคลเอ็นต์ และเครื่องทั้งสองเชื่อถือ CA ที่ออกใบรับรองนั้น ปฏิบัติตามกระบวนการ 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 ขาเข้าให้เฉพาะเครือข่ายผู้ส่งที่รู้จักโดยใช้ไฟร์วอลล์ของโฮสต์หรือต้นทาง การเปิดพอร์ตไม่ได้ทดแทนการตรวจสอบสิทธิ์ด้วยใบรับรอง ตรวจสอบให้แน่ใจด้วยว่าไม่มีตัวรับฟังข้อความธรรมดาที่มีอยู่เดิมถูกเปิดเผยโดยไม่ได้ตั้งใจ

โปรแกรมแก้ไขการกำหนดค่าแสดงตัวรับฟัง rsyslog imtcp บนพอร์ต TCP 6514 พร้อม gtls และการตรวจสอบสิทธิ์ x509/name
ตัวรับฟัง TLS ของตัวเก็บรวบรวมข้อมูลใช้พอร์ต 6514 โหมด GnuTLS 1 และการตรวจสอบสิทธิ์ด้วยชื่อใบรับรอง บทความนี้ให้การกำหนดค่าตัวรับแบบเต็มรูปแบบ

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 อื่นๆ ตรวจสอบการดำเนินการขาออกอื่นๆ และใช้พารามิเตอร์ใบรับรองต่อการดำเนินการที่รองรับ หากต้องการข้อมูลรับรองที่แตกต่างกัน

ตัวแก้ไขการกำหนดค่าแสดงการดำเนินการ rsyslog omfwd ที่กำหนดเป้าหมายไปยัง logs.example.net บนพอร์ต 6514 พร้อมการตรวจสอบชื่อใบรับรอง TLS
ส่งต่อข้อความระบบไปยัง logs.example.net โดยใช้แอ็กชัน omfwd ที่เปิดใช้งาน 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 ล้มเหลว จากนั้นให้คืนค่าการกำหนดค่าเดิมทันที

หน้าจอเทอร์มินัลแสดงการตรวจสอบความถูกต้องของการกำหนดค่า rsyslog, โพรบตัวบันทึกที่มีแท็ก และคำสั่งสำหรับตรวจสอบไฟล์บันทึกตัวเก็บรวบรวมข้อมูล
ตรวจสอบความถูกต้องของ rsyslog และส่งข้อความทดสอบที่มีแท็กเฉพาะ จากนั้นตรวจสอบบันทึกของตัวเก็บรวบรวมเพื่อหาการตรวจสอบ แทนที่จะสันนิษฐานว่าข้อความถูกส่งถึงแล้ว

หากไม่พบเครื่องหมาย ให้ทำตามขั้นตอนต่อไปนี้เพื่อแก้ไขข้อผิดพลาด:

  • ไม่มีผู้รับฟังหรือการเชื่อมต่อถูกปฏิเสธ:ตรวจสอบsystemctl status rsyslogTCP/6514 และกฎไฟร์วอลล์ของตัวเก็บรวบรวมข้อมูล
  • ความล้มเหลวของ TLS หรือใบรับรอง:เปรียบเทียบ SAN ของใบรับรองกับPermittedPeerและStreamDriverPermittedPeersตรวจสอบห่วงโซ่ CA วันหมดอายุ นาฬิการะบบ และสิทธิ์การเข้าถึงคีย์ส่วนตัว
  • เชื่อมต่อแล้วแต่ไม่มีเหตุการณ์เกิดขึ้น:ตรวจสอบหาข้อมูลบันทึกเหตุการณ์/syslog ที่ซ้ำกันหรือขาดหายไป การดำเนินการส่งต่อที่ถูกระงับ และความจุของคิวดิสก์ ตรวจสอบjournalctl -u rsyslogทั้งสองโฮสต์

วิธีการนี้เป็นไปตามคู่มือการบันทึกข้อมูลระบบอย่างเป็นทางการของ SLES 15 SP7 , คู่มือไคลเอ็นต์ที่ตรวจสอบสิทธิ์ด้วยใบรับรองของ rsyslog , เอกสารอ้างอิงตัวรับฟัง imtcpและเอกสารอ้างอิงการส่งต่อ omfwd ประกาศการอัปเดตของ SUSE ในเดือนมีนาคม 2026 ได้บันทึกการเพิ่มโมดูล OpenSSL ที่เป็นตัวเลือก การกำหนดค่าจะแตกต่างกันไปในแต่ละ Service Pack ของ SLES ดังนั้นควรตรวจสอบความถูกต้องบน rsyslog ที่ติดตั้งไว้ก่อนที่จะนำการเปลี่ยนแปลงไปใช้ในสภาพแวดล้อมการใช้งานจริง

ฝากความเห็น

เมื่อ SLES Btrfs เข้าสู่โหมดอ่านอย่างเดียว: ตรวจสอบหาสาเหตุก่อนทำการเมานต์ใหม่

เมื่อ SLES Btrfs เข้าสู่โหมดอ่านอย่างเดียว: ตรวจสอบหาสาเหตุก่อนทำการเมานต์ใหม่

ตรวจสอบว่า Btrfs ถูกตั้งค่าเป็นโหมดอ่านอย่างเดียวโดยเจตนา พื้นที่เหลือน้อย หรือกำลังปกป้องข้อมูลหลังเกิดข้อผิดพลาด จากนั้นเลือกวิธีการกู้คืนที่เหมาะสมกับสาเหตุ

ลงทะเบียน SLES 15 กับ SUSE Manager ในเครือข่ายออฟไลน์

ลงทะเบียน SLES 15 กับ SUSE Manager ในเครือข่ายออฟไลน์

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

ทำให้การส่งต่อ X11 ของ YaST ใช้งานได้ผ่าน SSH

ทำให้การส่งต่อ X11 ของ YaST ใช้งานได้ผ่าน SSH

แก้ไขข้อผิดพลาดในการเปิดใช้งาน XIO ของ YaST ผ่าน SSH ตรวจสอบการส่งต่อ X11 และ xauth และสลับไปใช้ส่วนติดต่อ ncurses เมื่อไม่จำเป็นต้องใช้หน้าต่างระยะไกล

ย้อนกลับการอัปเดต SLES ที่ล้มเหลวอย่างปลอดภัยด้วย Snapper

ย้อนกลับการอัปเดต SLES ที่ล้มเหลวอย่างปลอดภัยด้วย Snapper

ค้นหาสแนปช็อต Btrfs ก่อนการอัปเดต ทดสอบในโหมดอ่านอย่างเดียว และทำให้การกู้คืนเป็นแบบถาวรด้วย Snapper พร้อมทั้งทำความเข้าใจว่าข้อมูลใดบ้างที่อยู่นอกเหนือการย้อนกลับแบบรูท

การส่งต่อ Syslog ของ SLES อย่างปลอดภัยด้วย rsyslog และ Mutual TLS

การส่งต่อ Syslog ของ SLES อย่างปลอดภัยด้วย rsyslog และ Mutual TLS

ส่งบันทึกระบบ SLES ไปยังตัวเก็บรวบรวม rsyslog ระยะไกลผ่าน TLS ที่มีการตรวจสอบสิทธิ์ พร้อมด้วยการตรวจสอบใบรับรอง การบัฟเฟอร์เมื่อระบบขัดข้อง และการทดสอบการส่งมอบ

ตรวจสอบข้อผิดพลาดเกี่ยวกับหน่วยความจำระหว่างการอัปเกรด SLES ก่อนลองใหม่อีกครั้ง

ตรวจสอบข้อผิดพลาดเกี่ยวกับหน่วยความจำระหว่างการอัปเกรด SLES ก่อนลองใหม่อีกครั้ง

ใช้บันทึก RAM, swap, kernel และ Zypper เพื่อระบุแรงดันหน่วยความจำที่แท้จริง ป้องกันสถานะของแพ็กเกจ และเลือกวิธีการลองอัปเกรด SLES ที่ปลอดภัยยิ่งขึ้น

รักษาการอัปเดตความปลอดภัยของ Debian 12 ให้ทำงานได้บนเซิร์ฟเวอร์แบบไม่มีหน้าจอแสดงผล

รักษาการอัปเดตความปลอดภัยของ Debian 12 ให้ทำงานได้บนเซิร์ฟเวอร์แบบไม่มีหน้าจอแสดงผล

เปิดใช้งานการอัปเดตความปลอดภัยอัตโนมัติของ Debian ผ่าน SSH รักษาแหล่งแพ็กเกจเริ่มต้น และตรวจสอบการทำงานตามกำหนดเวลาผ่านบันทึกของ systemd และ APT

รับการแจ้งเตือน SMART Disk ของ Ubuntu ทางอีเมลด้วย smartd

รับการแจ้งเตือน SMART Disk ของ Ubuntu ทางอีเมลด้วย smartd

เปรียบเทียบตัวเลือกการรับอีเมล ตั้งค่า smartd บน Ubuntu และตรวจสอบว่าคำเตือนเกี่ยวกับสถานะของดิสก์ส่งไปถึงกล่องจดหมายของคุณหรือไม่

ข้อผิดพลาดในการค้นหา DNS ของ Debian 12: ซ่อมแซม systemd-resolved

ข้อผิดพลาดในการค้นหา DNS ของ Debian 12: ซ่อมแซม systemd-resolved

กู้คืนการค้นหา DNS บน Debian 12 โดยตรวจสอบ systemd-resolved ซ่อมแซม resolv.conf เมื่อจำเป็น และตรวจสอบการแก้ไข DNS ต้นทางและการแก้ไขแอปพลิเคชัน

Ubuntu 24.04 ไม่แสดงเสียง HDMI ใช่ไหม? กู้คืนเอาต์พุต

Ubuntu 24.04 ไม่แสดงเสียง HDMI ใช่ไหม? กู้คืนเอาต์พุต

ตั้งค่า Ubuntu ให้ตรวจจับจอภาพหรือทีวีของคุณเป็นอุปกรณ์ส่งสัญญาณเสียง เลือกอุปกรณ์นั้นในการตั้งค่าเสียง และตรวจสอบการเชื่อมต่อหรือรายการอุปกรณ์ PipeWire หากไม่มี HDMI