How to Export SLES System Logs to a Remote Syslog Server Securely

The safest practical way to export SUSE Linux Enterprise Server (SLES) system logs to a remote syslog collector is to use rsyslog over TCP with TLS, validate the collector certificate by name, and give the forwarding action its own queue. Plain UDP syslog is simple, but it does not provide confidentiality or peer authentication. Plain TCP improves delivery behavior but still leaves log contents exposed in transit.

This guide uses the GnuTLS network stream driver (gtls) and modern rsyslog action syntax. The procedure is aimed at SLES 15 SP7 systems, whose Administration Guide was updated on October 1, 2026. Always check the exact packages and rsyslog version on your host before copying a configuration verbatim. The upstream rsyslog documentation recommends TCP with TLS for modern deployments and recommends an action queue for TCP forwarding.

Authoritative references: SUSE Linux Enterprise Server 15 SP7 documentation, rsyslog omfwd documentation, rsyslog TLS client setup, and RFC 5425: TLS Transport Mapping for Syslog.

Quick reference

Before you configure forwarding

You need the fully qualified domain name of the remote collector, the TCP port it listens on, and the certificate authority (CA) certificate that signs the collector certificate. For mutual TLS, you also need a client certificate and private key for the SLES machine. The collector certificate must be valid for the hostname you configure in rsyslog, preferably through a Subject Alternative Name (SAN). Do not solve a name mismatch by disabling certificate verification.

The remote collector must already be configured to accept TLS syslog. This article focuses on the SLES sender because receiver setup varies between rsyslog, syslog-ng, SIEM appliances, and managed logging services. If a firewall separates the systems, allow the SLES host to initiate TCP connections to the collector on the configured port. A default stateful firewalld policy usually does not require opening an inbound port on the SLES sender.

Step 1: Confirm rsyslog is installed and identify the current build

먼저 패키지 및 데몬 버전을 확인하세요. 이렇게 하면 이전 예제에서 서버의 빌드에서 지원되지 않는 지시문을 사용하는 경우 발생할 수 있는 혼란을 방지할 수 있습니다.

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. 패키지 이름은 배포판마다 다르므로 Debian 또는 RHEL 관련 가이드에서 패키지 이름을 복사하지 마세요.

3단계: CA 및 클라이언트 자격 증명을 안전한 곳에 보관하십시오.

조직 또는 로깅 플랫폼에서 발급한 인증서를 사용하십시오. 운영 시스템의 경우 로그 전송 호스트에 새 개인 CA를 생성하지 마십시오. 테스트 환경에서는 테스트 CA를 사용할 수 있지만, 운영 환경의 신뢰 자료는 조직의 PKI 프로세스를 따라야 합니다.

루트 소유의 디렉터리를 생성하고 파일을 복사한 다음 개인 키에 대한 접근을 제한하십시오. 예시 파일 이름은 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

rsyslog TLS 클라이언트 설명서에는 시스템 개인 키를 보호해야 한다는 내용이 명시적으로 경고되어 있습니다. 다른 사용자가 개인 키를 읽을 수 있는 경우, 해당 사용자가 로깅 클라이언트를 사칭할 수 있습니다.

4단계: 서버 이름 확인을 포함한 TLS 포워딩 구성

예를 들어, 와 같은 전용 드롭인 경로를 생성하세요 /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인 구성에서는 TLS 지원 드라이버 선택만으로는 충분하지 않습니다. StreamDriverAuthMode="x509/name"그런 다음 원격 인증서를 확인하고 서버 ID가 허용된 피어와 일치하는지 검사합니다. 가능하면 광범위한 와일드카드 대신 인증서에 정확한 수집기 이름을 사용하십시오.

위의 작업은 해당 호스트에 도달하는 모든 메시지를 전달합니다. 특정 기능이나 우선순위에 따른 메시지만 전달하려면 작업 앞에 필터를 추가하세요. 예를 들어 보안에 중점을 둔 환경에서는 인증 및 데몬 이벤트는 전달하고 대용량 애플리케이션 디버그 로그는 로컬에 보관할 수 있습니다. 필터링은 모든 메시지를 호스트에서 내보내야 한다는 일반적인 가정보다는 보존, 사고 대응 및 규정 준수 요구 사항에 따라 이루어져야 합니다.

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활성화한 상태로 유지하고 rsyslog 서비스 로그에 TLS 핸드셰이크 또는 피어 이름 오류가 없는지 확인하는 것입니다.

연결에 실패하면 DNS 확인을 테스트하고 logs.example.com, TCP 6514 포트에 연결할 수 있는지 확인하고, 인증서 유효 기간을 확인하고, 수집기 인증서에 예상 DNS 이름이 포함되어 있는지 확인하십시오. 또한 상호 TLS가 활성화된 경우 수집기가 SLES 클라이언트 인증서를 발급한 CA를 신뢰하는지 확인하십시오.

문제 해결 체크리스트

• 연결 거부됨: 수집기가 구성된 주소/포트에서 수신 대기 중이 아니거나 방화벽이 연결을 차단하고 있습니다.
• 타임아웃: 라우팅, 네트워크 ACL 또는 방화벽이 트래픽을 조용히 차단하고 있습니다.
• 인증서 확인에 실패했습니다. CA 파일이 잘못되었거나, 불완전하거나, 만료되었거나, 서버 인증서 체인이 불완전합니다.
• 피어 이름 불일치: ' target/' StreamDriverPermittedPeers이름이 수집기 인증서 ID와 일치하지 않습니다.
• 키에 대한 권한이 거부되었습니다. 키 경로 또는 권한으로 인해 rsyslog 프로세스가 SLES 서비스 구성에 있는 파일을 읽을 수 없습니다.
• 장애 발생 시 메시지 전송이 중단될 수 있습니다. 액션 큐 설계 및 용량을 검토하십시오. 상위 omfwd 문서에서는 TCP 포워딩을 위한 큐 사용을 명시적으로 권장하고 있으므로, 대상 서버를 사용할 수 없는 경우 정상적인 처리가 차단되지 않도록 해야 합니다.

간과하기 쉬운 보안 참고 사항

인증서 유효성 검사를 익명 TLS로 대체하기 전에 그 장단점을 충분히 이해해야 합니다. 서버 인증 없이 암호화를 수행하더라도 중간자 공격자가 로그를 노출할 수 있습니다. 마찬가지로, 수신측에서 TCP 6514 포트를 사용한다는 이유만으로 SLES 발신측에서 수신 포트를 열지 마십시오. 포트 포워딩은 발신 클라이언트 연결입니다.

클라이언트 개인 키는 자격 증명으로 보호하고, 인증서는 만료 전에 교체하며, IP 주소 변경 시에도 안정적인 수집기 호스트 이름을 사용하십시오. 일반 TCP/TLS 포워딩보다 더 강력한 전달 보장이 필요한 경우, rsyslog 설명서에서는 확인 응답 전달을 위해 설계된 RELP를 대안으로 제시하고 있습니다. 이는 전송 암호화와는 별개의 설계 선택 사항입니다.

최종 확인

올바른 배포는 다음 네 가지 관찰 가능한 조건을 충족해야 합니다. rsyslog 구성 유효성 검사가 성공적으로 완료되고, 서비스가 재시작 후에도 활성 상태를 유지하며, 컬렉터가 고유한 테스트 이벤트를 수신하고, 발신자 로그에 TLS 신뢰 또는 피어 이름 오류가 표시되지 않아야 합니다. 이러한 검사를 통과하면 인증서 만료일과 원격 컬렉터 종속성을 문서화하여 향후 유지 관리 시 중앙 집중식 로깅이 예기치 않게 중단되는 것을 방지해야 합니다.