เพื่อส่งต่อบันทึกระบบของ 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 ใบรับรอง และไฟล์คีย์แยกต่างหากก่อนที่จะเปิดใช้งาน 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 ขาเข้าให้เฉพาะเครือข่ายผู้ส่งที่รู้จักโดยใช้ไฟร์วอลล์ของโฮสต์หรือต้นทาง การเปิดพอร์ตไม่ได้ทดแทนการตรวจสอบสิทธิ์ด้วยใบรับรอง ตรวจสอบให้แน่ใจด้วยว่าไม่มีตัวรับฟังข้อความธรรมดาที่มีอยู่เดิมถูกเปิดเผยโดยไม่ได้ตั้งใจ
ตัวรับฟัง 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 อื่นๆ ตรวจสอบการดำเนินการขาออกอื่นๆ และใช้พารามิเตอร์ใบรับรองต่อการดำเนินการที่รองรับ หากต้องการข้อมูลรับรองที่แตกต่างกัน
ส่งต่อข้อความระบบไปยัง 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 และส่งข้อความทดสอบที่มีแท็กเฉพาะ จากนั้นตรวจสอบบันทึกของตัวเก็บรวบรวมเพื่อหาการตรวจสอบ แทนที่จะสันนิษฐานว่าข้อความถูกส่งถึงแล้ว
หากไม่พบเครื่องหมาย ให้ทำตามขั้นตอนต่อไปนี้เพื่อแก้ไขข้อผิดพลาด:
ไม่มีผู้รับฟังหรือการเชื่อมต่อถูกปฏิเสธ: ตรวจสอบ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 ที่ติดตั้งไว้ก่อนที่จะนำการเปลี่ยนแปลงไปใช้ในสภาพแวดล้อมการใช้งานจริง