rsyslog 및 상호 TLS를 사용한 안전한 SLES Syslog 포워딩

SUSE Linux Enterprise Server(SLES) 시스템 로그를 안전하게 전달하려면 rsyslog가 TLS로 보호되는 TCP 포트 6514를 통해 메시지를 보내도록 구성하고, 수집기의 인증서 이름을 확인하고, 테스트 이벤트를 통해 전달을 확인해야 합니다. SLES 15 SP7은 2026년 3월 27일에 OpenSSL TLS 모듈을 추가하는 선택적 rsyslog 업데이트를 받았습니다. 아래 구성에서는 의도적으로 기존의 GnuTLS( gtls) 모듈을 사용합니다.

이 절차는 SLES 15 발신자(sender) sles01.example.net와 rsyslog 수집기(collect)를 다룹니다 logs.example.net. 두 이름과 모든 인증서 경로를 사용자 환경에 맞게 변경하십시오. 이 절차는 상호 TLS를 사용하므로 수집기가 발신자를 인증하고 발신자도 수집기를 인증합니다.

1. rsyslog와 SLES 로깅 경로를 확인하십시오.

두 호스트 모두에서 등록된 SUSE 저장소에서 rsyslog 데몬과 GnuTLS 모듈을 설치하십시오. 기존 설치에는 이미 첫 번째 패키지가 포함되어 있을 수 있습니다.

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에 도달하는지 확인하십시오. SUSE 문서 ForwardToSyslog=yes에는 /etc/systemd/journald.conf저널-syslog 전달에 대한 내용이 나와 있습니다. 변경하기 전에 배포 환경을 확인하십시오. 저널 판독기를 별도로 활성화하면 중복 이벤트가 발생할 수 있습니다. 이 절차는 rsyslog에서 이미 처리된 메시지만 전달하며, 모든 파일을 /var/log자동으로 전달하는 것은 아닙니다.

2. 신뢰할 수 있는 서버 및 클라이언트 인증서를 준비합니다.

logs.example.net조직에서 관리하는 인증 기관(CA)을 사용하여 수집기용 DNS 주체 대체 이름(SAN)이 포함된 인증서 와 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 서비스 ID에 대한 인증서 및 키 접근을 제한하십시오. 진단 정보, 셸 기록, 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승인된 인증서 ID가 없는 클라이언트는 거부합니다. 허용되는 이름이 하나뿐인 것은 의도적인 것이며, 다른 발신자를 추가할 때는 인증을 약화시키는 대신 승인된 피어 목록을 확장해야 합니다.

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. SLES에 TLS 포워딩 및 제한된 큐를 추가합니다.

rsyslog를 실행 하려면 sles01.example.netrsyslog 작업 디렉터리가 존재하고 서비스에서 쓰기 권한이 있는지 확인하십시오. 여기에 표시된 디렉터리는 예시일 뿐이며, 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 또는 인증서 오류: 인증서 SAN을 와 비교하고 PermittedPeer, StreamDriverPermittedPeersCA 체인, 만료일, 시스템 시계 및 개인 키 권한을 확인하십시오.
• 연결은 되었지만 이벤트가 없는 경우: 중복되거나 누락된 저널/시스템 로그 입력, 일시 중단된 전달 작업 및 디스크 큐 용량을 확인하십시오. journalctl -u rsyslog두 호스트 모두에서 검토하십시오.

이 방법은 공식 SLES 15 SP7 시스템 로깅 가이드 , rsyslog 인증서 인증 클라이언트 가이드 , imtcp 리스너 참조 및 omfwd 포워딩 참조를 따릅니다 . 2026년 3월 SUSE 업데이트 공지에는 선택적 OpenSSL 모듈 추가에 대한 내용이 포함되어 있습니다. 구성은 SLES 서비스 팩에 따라 다를 수 있으므로 프로덕션 환경에 변경 사항을 적용하기 전에 설치된 rsyslog 빌드에서 유효성을 검사하십시오.