Learn how to send logs from Linux to a centralized Syslog server or SIEM using Rsyslog — a complete cybersecurity tutorial covering Plain Text, TLS encryption, and certificate management on Rocky Linux.

Hello everyone! In this cybersecurity tutorial, I'll show you how to send logs from Linux to a centralized Syslog server or SIEM using Rsyslog — both in plain text and with TLS encryption.

Before we begin, let me introduce myself. I graduated with a degree in Computer Science, have 2 years of experience working in Cybersecurity, and hold a CompTIA Security+ certification. The operating system I'll be using to send logs is Rocky Linux 10.

First, let's take a look at the table of contents to see what we'll be covering:

01 — Why Logs Matter for Cybersecurity?

02 — What is Rsyslog?

03 — Who is this article for?

04 — Background knowledge you should know

05 — Sending logs with Rsyslog (Plain Text)

06 — Sending logs with Rsyslog (TLS)

07 — Sending logs Plain Text VS TLS

08 — Sending Log by Rsyslog

09 — Final Thoughts

Alright, let's get started with the first section!

Why Logs Matter for Cybersecurity?

When a cyberattack occurs, logs are what help us analyze the root cause of the attack, trace its origin, and — more importantly — detect and prevent threats before they cause damage.

Logs are an essential tool for monitoring security events, covering Device Logs, Firewall Logs, and Security Appliance Logs. All of these logs are forwarded to a SIEM (Security Information and Event Management) platform or a Centralized Logging System, where they are aggregated and analyzed to prevent attackers from reaching an organization's critical data.

What is Rsyslog?

Rsyslog is the default Syslog service on most Linux distributions, responsible for receiving, processing, and forwarding log messages — making it the backbone of centralized logging and SIEM integration in most cybersecurity architectures. It allows logs from various devices to be sent to a specified destination efficiently. Today, Rsyslog comes pre-installed on many Enterprise Linux distributions such as RHEL, Rocky Linux, CentOS, and Ubuntu Server. On minimal installations or distributions using systemd-journald, you may need to install it manually.

Who is this article for?

• Beginners who want to start learning how to send logs from Linux to a centralized Syslog server or SIEM platform
• Compliance teams that need to collect and retain logs to meet legal and regulatory compliance requirements such as PDPA, GDPR, ISO 27001, or PCI DSS.
• Security teams that need to forward logs to a SIEM (Security Information and Event Management) platform for security analysis.

Background knowledge you should know

What is the Syslog Protocol? Syslog Protocol is a standard for transmitting log messages from various devices — such as servers, routers, firewalls, and applications — to a log server for centralized logging, storage, and analysis.

RFC 3164 vs RFC 5424

RFC 3164 (The BSD Syslog Protocol)

RFC 3164 is the original Syslog standard, with the following characteristics:

• Simple message format with no clearly defined structure
• Limited message size of up to 1024 bytes
• No timezone support in timestamps
• No support for structured data
• Primarily uses UDP port 514

Example <34>Oct 11 22:14:15 server_1 app[1234]: User login successful

RFC 5424 (The Syslog Protocol)

RFC 5424 is the modernized Syslog standard, designed to improve upon RFC 3164. Here are its key characteristics:

• Well-defined structured format
• Supports ISO 8601 timestamps with timezone information
• Supports structured data (in key-value pairs)
• Larger, more flexible message size
• Can be used over both UDP and TCP/TLS

Example <34>1 2024–04–18T22:14:15.003Z server1 app 1234 ID47 [exampleSDID@32473 iut="3" eventSource="Application"] User login successful

Port 514 (UDP) vs 6514 (TCP/TLS)

Port 514 (UDP)

• The default port for traditional Syslog
• Uses UDP (User Datagram Protocol) — an unreliable delivery method
• Pros: Fast with low overhead
• Cons: Messages may be lost during network issues, and no encryption is provided

Port 6514 (TCP/TLS)

• The standard port for Syslog over TLS
• Uses TCP (Transmission Control Protocol) with TLS (Transport Layer Security) encryption
• Pros: Reliable delivery, encrypted traffic, and integrity checking
• Cons: Slightly slower than UDP with higher overhead

💡 Quick Note: Although port numbers are fully configurable in Rsyslog and other Syslog services, the ports shown below are the IANA-registered defaults most widely used in production. Port 514 was assigned for traditional Syslog (UDP), and port 6514 was assigned by IANA as "syslog-tls" for Syslog over TLS. Unless your organization has a specific policy, these defaults are recommended for compatibility with SIEM platforms and firewall rules.

What is a Protocol?

A protocol is a set of rules and standards that define how devices or systems communicate over a network. It allows devices from different vendors or systems to understand each other and exchange information seamlessly.

Common Protocols Used for Sending Logs

1. Syslog — The primary standard for transmitting log messages.
2. TCP/TLS — Used for secure and reliable Syslog transmission.
3. UDP — Used for fast, low-overhead Syslog transmission.
4. HTTP/HTTPS — Used to send logs via REST API (e.g., Elasticsearch, Splunk).
5. RELP (Reliable Event Logging Protocol) — A protocol for guaranteed log delivery.
6. Kafka Protocol — A distributed event streaming platform used as a scalable log transport for high-volume log ingestion pipelines
7. GELF (Graylog Extended Log Format) — A JSON-based format for sending logs to Graylog.
8. Fluentd Forward Protocol — Fluentd's native protocol for log forwarding.

Facility & Severity levels

What is a Facility?

Facility is an identifier that indicates which part of the system — or which service/subsystem on the machine — a log message comes from. It helps categorize logs for easier management and analysis.

What are Severity Levels?

Severity indicates the level of importance or urgency of each log message. It helps filter and prioritize logs based on how critical they are.

Think of Severity as a way to answer the question: "How serious is this log?" — ranging from a simple informational message to a critical system failure. This allows security and operations teams to focus on what truly matters first.

Severity Levels (0–7, from most to least severe):

Priority Value Calculation

Sending logs with Rsyslog (Plain Text)

Plain Text refers to sending logs without encryption during transmission. This method is best suited for use within an internal network, where both the client and server reside in the same private network and the network's security can be trusted.

• Data is not encrypted during transmission — if intercepted, it can be read immediately.
• Best for: Use within private, access-controlled networks, such as: Communication within the same data center, Transmission across a VLAN isolated from the main network and Between machines in a trusted network
• Pros: Fast processing and low overhead
• Cons: Vulnerable if intercepted — no data protection

Sending logs with Rsyslog (TLS)

TLS (Transport Layer Security) is the process of sending logs with encryption, which protects data while in transit. It's ideal for remote log forwarding — especially when logs need to travel across public networks or the internet, or when high-level protection against eavesdropping is required.

• Data is encrypted during transmission, preventing unauthorized reading or tampering.
• Best for: Transmission over public networks or the internet, Sending sensitive or confidential data, Site-to-site log forwarding, Environments with compliance requirements (e.g., PCI-DSS, HIPAA, GDPR)
• Pros: Secure, supports authentication, and maintains data integrity
• Cons: Slightly slower, higher overhead, and requires certificate management

Sending logs Plain Text VS TLS

💡 Recommendation: Even when sending logs within an internal network, if your log data contains sensitive information — such as credentials, personal data, or authentication events — you should always use TLS to ensure the highest level of security.

Sending Log by Rsyslog

Lab Setup

• 2 Virtual Machines (VMs): Client + Server (both running Rocky Linux 10)

Rsyslog usually comes pre-installed with Rocky Linux. However, if it's not installed on your system, you can install it by running the following command:

# Check if Rsyslog is already installed
rpm -qa | grep rsyslog

# If Rsyslog is not installed, run the following command:
sudo dnf install -y rsyslog

# Enable and start service
sudo systemctl enable rsyslog
sudo systemctl start rsyslog
sudo systemctl status rsyslog

Verify the Rsyslog Service on Both Client and Server

Method 1: Plain Text

Log flow:

Configure the Server

1. Open the Rsyslog configuration file

sudo nano /etc/rsyslog.conf

2. Enable log reception over UDP port 514

Find the following lines and uncomment them (remove the #):

# Provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

3. Add a template to organize logs by hostname

Append the following to the end of the file:

# Template for remote logs
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& stop

Save the file by pressing Ctrl + X, then Y, and finally Enter.

4. Create a directory to store the logs

sudo mkdir -p /var/log/remote 
sudo chmod 755 /var/log/remote

5. Configure the Firewall

On the server receiving the logs, I recommend using only one firewall (e.g., choose between Firewalld or iptables) to avoid confusion about which one to configure.

Firewalld (RHEL, Rocky Linux, CentOS, Fedora)

# Allow port 514/udp (for Plain Text transmission)
sudo firewall-cmd --permanent --add-port=514/udp

# Allow port 6514/tcp (for TLS transmission)
sudo firewall-cmd --permanent --add-port=6514/tcp

# Reload firewall to apply changes
sudo firewall-cmd --reload

# Verify the ports have been added
sudo firewall-cmd --list-ports

Expected output:

iptables (Legacy or Minimal Installations)

# Install iptables
sudo dnf install iptables-services

# Check current iptables rules
sudo iptables -L -n -v

# Add rules if the INPUT policy is set to DROP
# Allow port 514/udp (for Plain Text transmission)
sudo iptables -A INPUT -p udp --dport 514 -j ACCEPT

# Allow port 6514/tcp (for TLS transmission)
sudo iptables -A INPUT -p tcp --dport 6514 -j ACCEPT

# save rule iptables
sudo service iptables save

# Verify the rules
sudo iptables -L INPUT -n -v --line-numbers

Expected output:

UFW (Uncomplicated Firewall — Ubuntu, Debian)

# Check UFW status
sudo ufw status

# Enable UFW (if not already enabled)
sudo ufw enable

# Allow port 514/udp (for Plain Text transmission)
sudo ufw allow 514/udp

# Allow port 6514/tcp (for TLS transmission)
sudo ufw allow 6514/tcp

# Verify
sudo ufw status numbered

SELinux (Security-Enhanced Linux)

SELinux is not a firewall — it's a Mandatory Access Control (MAC) system that may block Rsyslog from functioning properly.

Managing SELinux:

# Check whether SELinux is enabled or disabled
getenforce

# The expected output should be: Enforcing

Expected output:

Output:

• ✅ Enforcing — SELinux policies are actively enforced. Any action violating the policy is blocked and logged. This is the recommended mode for production
• ⚠️ Permissive — SELinux policies are NOT enforced, but violations are logged (useful for policy development and troubleshooting). Actions are allowed even if they violate policy.
• ❌ Disabled — SELinux is completely turned off. No policy checks occur and no logs are generated. Not recommended for production systems handling sensitive data.

Set the correct SELinux context (recommended!):

For the Log Directory:

# 1. Define a rule that /var/log/remote and all files inside should have the SELinux type "var_log_t"
sudo semanage fcontext -a -t var_log_t "/var/log/remote(/.*)?"

# 2. Apply the rule to existing files (relabel)
sudo restorecon -Rv /var/log/remote

# Verify
sudo semanage fcontext -l | grep "/var/log/remote"

Expected output:

For the Rsyslog Ports:

# Allow Rsyslog to use port 514 (for Plain Text transmission)
sudo semanage port -a -t syslogd_port_t -p udp 514

# Allow Rsyslog to use port 6514 (for TLS transmission)
sudo semanage port -a -t syslogd_port_t -p tcp 6514

# Verify
sudo semanage port -l | grep syslogd

Expected output:

6. Restart rsyslog

sudo systemctl restart rsyslog
sudo systemctl status rsyslog

7. Verify the Server is Listening on Ports 514 and 6514

# For Plain Text transmission
sudo ss -ulnp | grep 514

# For TLS transmission
sudo ss -tlnp | grep 6514

Expected output:

Configure the Client

1. Open the Rsyslog configuration file

sudo nano /etc/rsyslog.conf

2. Configure log forwarding to the server

Append the following to the end of the file:

# Forward all logs to remote server via UDP
*.* @192.168.77.142:514

Notes: @ = UDP (single @) @@ = TCP (double @@) 192.168.77.142 = The server's IP address (replace with your actual server IP)

3. Restart rsyslog

sudo systemctl restart rsyslog
sudo systemctl status rsyslog

Testing Log Forwarding

On the Client: Send a test log

logger "Test message from client - Plain text - $(date)"

On the Server: Verify the log was received

sudo ls -la /var/log/remote/syslog-client

Expected output:

View the incoming log

sudo tail -f /var/log/remote/syslog-client/natthanan.log

Notes: Program name = "natthanan" (the username of the person running the logger command) Generated log file = natthanan.log

You should see output similar to:

Apr 18 06:00:15 syslog-client natthanan: Test message from client - Plain text - Fri 
Apr 18 06:00:15 AM UTC 2025

Verify with tcpdump

To capture and inspect the Syslog traffic in real time:

sudo tcpdump -i any -n port 514 -A

Then, on the client, send another log:

logger "Capture this with tcpdump"

On the server, you should see the captured packet:

Expected output:

Method 2: TLS Encryption

Log flow:

Understanding Encryption: Symmetric vs Asymmetric

When logs are sent over TLS (Transport Layer Security), the data is encrypted to prevent anyone from intercepting and reading it. But did you know there are different types of encryption? Let's explore the two main categories used in TLS.

🔐 Symmetric Encryption

Symmetric encryption uses the same key for both encrypting and decrypting data.

🔑 Asymmetric Encryption

Asymmetric encryption uses a key pair:

• Public Key — Can be shared openly with anyone
• Private Key — Must be kept secret and secure

🔐 Which Type of Encryption Does TLS Use?

Answer: Both! (Hybrid Encryption)

TLS is smart enough to leverage the strengths of both methods:

🔑 Asymmetric encryption is used during the TLS handshake to securely exchange a session key.

🔐 Symmetric encryption is then used to encrypt the actual data — because it's much faster.

How TLS Works in 6 Simple Steps

Think of TLS like two people agreeing on a secret code before talking — so no one eavesdropping can understand.

1. Client Hello: The client sends the TLS version, supported cipher suites, and a Client Random (random number) to the server. → Not yet encrypted
2. Server Hello + Certificate: The server responds with the selected cipher suite, a Server Random, and its Certificate (containing the Public Key). → Not yet encrypted
3. Session Key (encrypted with Public Key): The client generates a Session Key, encrypts it with the server's Public Key, and sends it to the server. → Uses asymmetric encryption
4. Server unlocks it with Private Key: Only the server can decrypt the Session Key using its Private Key. Now both sides share the same Session Key — without exposing it to eavesdroppers.
5. Send data locked with Session Key: The client encrypts log messages with the Session Key using symmetric encryption (AES-GCM) and sends them over port 6514. → tcpdump will only show unreadable ciphertext
6. Server unlocks data with Session Key: The server uses the same Session Key to decrypt and process the log messages.

💡 Note: This diagram shows the classic TLS 1.2 (RSA) handshake for simplicity. Modern TLS 1.3 uses ECDHE key exchange — both sides compute the Session Key together without sending it across the network, providing Perfect Forward Secrecy.

Part 1: Create TLS Certificates

On the Server: Install GnuTLS Tools

sudo dnf install -y gnutls-utils rsyslog-gnutls

Create a Directory for the Certificates

sudo mkdir -p /etc/rsyslog.d/certs
cd /etc/rsyslog.d/certs

1. Create the CA (Certificate Authority)

Generate the CA Private Key

sudo certtool --generate-privkey --outfile ca-key.pem --bits 2048

Create the CA Configuration File

sudo tee ca.info > /dev/null <<EOF
cn = Syslog Lab CA
ca
cert_signing_key
expiration_days = 3650
EOF

Generate the CA Certificate

sudo certtool --generate-self-signed \
 --load-privkey ca-key.pem \
 --template ca.info \
 --outfile ca.pem

2. Create the Server Certificate

Generate the Server Private Key

sudo certtool --generate-privkey --outfile server-key.pem --bits 2048

Create the Server Configuration File

sudo tee server.info > /dev/null <<EOF
organization = Syslog Lab
cn = syslog-server
tls_www_server
encryption_key
signing_key
expiration_days = 365
EOF

⚠️ Important: The cn = syslog-server value must match the server's hostname.

Generate the Server Certificate (Signed by the CA)

sudo certtool --generate-certificate \
  --load-privkey server-key.pem \
  --load-ca-certificate ca.pem \
  --load-ca-privkey ca-key.pem \
  --template server.info \
  --outfile server-cert.pem

3. Create the Client Certificate

Generate the Client Private Key

sudo certtool --generate-privkey --outfile client-key.pem --bits 2048

Create the Client Configuration File

sudo tee client.info > /dev/null <<EOF
country = TH
organization = Syslog Lab
cn = syslog-client
tls_www_client
encryption_key
signing_key
expiration_days = 365
EOF

⚠️ Important: The cn = syslog-client value must match the client's hostname.

Generate the Client Certificate

sudo certtool --generate-certificate \
  --load-privkey client-key.pem \
  --load-ca-certificate ca.pem \
  --load-ca-privkey ca-key.pem \
  --template client.info \
  --outfile client-cert.pem

4. Set the Correct Permissions for the Certificates

# Private keys must be 600 (accessible only by root)
sudo chmod 600 /etc/rsyslog.d/certs/*-key.pem

# Certificates can be 644 (readable by everyone)
sudo chmod 644 /etc/rsyslog.d/certs/*.pem

# Owner should be root
sudo chown -R root:root /etc/rsyslog.d/certs/

5. Verify All Generated Files

ls -lh /etc/rsyslog.d/certs/

Expected output:

6. Validate the Certificates

Check the CA Certificate

sudo openssl x509 -in /etc/rsyslog.d/certs/ca.pem -text -noout | grep -E "Subject:|Issuer:|Not"

Expected output:

Check the Server Certificate

sudo openssl x509 -in /etc/rsyslog.d/certs/server-cert.pem -text -noout | grep -A2 "Subject:"

Expected output:

Check the Client Certificate

sudo openssl x509 -in /etc/rsyslog.d/certs/client-cert.pem -text -noout | grep -E "Subject:|Issuer:|Not"

Expected output:

Part 2: Copy Certificates to the Client

On the Server: Transfer Files to the Client

sudo scp /etc/rsyslog.d/certs/ca.pem \
         /etc/rsyslog.d/certs/client-cert.pem \
         /etc/rsyslog.d/certs/client-key.pem \
         natthanan@192.168.77.143:/tmp/

Replace:

natthanan — the client's username

192.168.77.143 — the client's IP address

On the Client: Move the Files to the Correct Location

Install rsyslog-gnutls

sudo dnf install -y rsyslog-gnutls

Create the Certificates Directory

sudo mkdir -p /etc/rsyslog.d/certs

Move the Files

sudo mv /tmp/ca.pem \
        /tmp/client-cert.pem \
        /tmp/client-key.pem \
        /etc/rsyslog.d/certs/

Set the Correct Permissions

sudo chmod 644 /etc/rsyslog.d/certs/ca.pem
sudo chmod 644 /etc/rsyslog.d/certs/client-cert.pem
sudo chmod 600 /etc/rsyslog.d/certs/client-key.pem
sudo chown -R root:root /etc/rsyslog.d/certs/

Verify

ls -lh /etc/rsyslog.d/certs/

Expected output:

Part 3: Configure the Server (TLS)

1. Create the TLS Configuration File

sudo nano /etc/rsyslog.d/60-tls-server.conf

2. Add the Following Configuration

# ===== TLS Server Configuration =====

# Load TLS module
module(load="imtcp"
       StreamDriver.Name="gtls"
       StreamDriver.Mode="1"
       StreamDriver.AuthMode="x509/name")

# Global TLS Settings
global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/server-cert.pem"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/server-key.pem"
)

# Listen on TLS port 6514
input(type="imtcp" 
      port="6514"
      StreamDriver.Name="gtls"
      StreamDriver.Mode="1"
      StreamDriver.AuthMode="x509/name"
      PermittedPeer=["syslog-client"])

# Template for remote logs
template(name="RemoteLogs" type="string"
         string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")

# Store logs from remote clients
if $fromhost-ip != '127.0.0.1' then {
    action(type="omfile" dynaFile="RemoteLogs")
    stop
}

Save the file by pressing Ctrl + X, then Y, and finally Enter.

⚠️ Important: The value in PermittedPeer=["syslog-client"] must match the CN (Common Name) specified in the client certificate.

Examples:

• If the client cert has CN=syslog-client → use PermittedPeer=["syslog-client"]
• If the client cert has CN=web-server → use PermittedPeer=["web-server"]

3. Create the Log Directory

sudo mkdir -p /var/log/remote
sudo chmod 755 /var/log/remote

4. Don't Forget the Firewall and SELinux

Make sure TCP port 6514 is open in the firewall, and that SELinux allows Rsyslog to write log files to the server.

Additional SELinux configuration for certificates:

# Set the /etc/rsyslog.d/certs directory and its contents to SELinux type cert_t
sudo semanage fcontext -a -t cert_t "/etc/rsyslog.d/certs(/.*)?"

# Apply the rule to existing files (relabel)
sudo restorecon -Rv /etc/rsyslog.d/certs

# Verify 
ll -Z /etc/rsyslog.d/certs/

Expected output:

5. Restart Rsyslog

sudo systemctl restart rsyslog
sudo systemctl status rsyslog

6. Verify the Server is Listening on Port 6514

sudo ss -tlnp | grep 6514

Expected output:

Part 4: Configure the Client (TLS)

1. Create the TLS Configuration File

sudo nano /etc/rsyslog.d/60-tls-client.conf

2. Add the Following Configuration

# ===== TLS Client Configuration =====

# Load TLS driver
global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/client-cert.pem"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/client-key.pem"
)

# Send all logs to server via TLS
action(
    type="omfwd"
    target="192.168.77.142"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="syslog-server"
    
    # Disk-assisted queue - prevents log loss if server is down
    queue.type="LinkedList"
    queue.filename="fwdRule1"
    queue.maxdiskspace="1g"
    queue.saveonshutdown="on"
    action.resumeRetryCount="-1"
)

Replace:

• target="192.168.77.142" — with the server's IP address
• StreamDriverPermittedPeers="syslog-server"— with the CN of the server certificate

3. Set the Correct SELinux Context for the Client (Recommended!)

# Set the /etc/rsyslog.d/certs directory and its contents to SELinux type cert_t
sudo semanage fcontext -a -t cert_t "/etc/rsyslog.d/certs(/.*)?"

# Apply the rule to existing files (relabel)
sudo restorecon -Rv /etc/rsyslog.d/certs

# Verify
ll -Z /etc/rsyslog.d/certs/

Expected output:

4. Restart Rsyslog

sudo systemctl restart rsyslog
sudo systemctl status rsyslog

🧪 Part 5: Test Log Forwarding over TLS

On the Client: Send a Test Log

logger "TLS encrypted message - $(date)"

On the Server: Verify the Log

# Check files generated from forwarded logs
sudo ls /var/log/remote/syslog-client/

# View the log file
sudo tail -f /var/log/remote/syslog-client/natthanan.log

Expected output:

Part 6: Verify Encryption with tcpdump

On the Server: Capture Traffic on Port 6514

sudo tcpdump -i any -n port 6514 -X

On the Client: Send a Log

logger "This message should be encrypted"

On the server, you should see encrypted (unreadable) packets:

Expected output:

Troubleshooting

Common Issues

1. The Client's Logs Aren't Reaching the Server

Check the firewall:

# On the server
sudo firewall-cmd --list-ports

Verify that Rsyslog is listening:

sudo ss -ulnp | grep 514   # For UDP (Plain Text)
sudo ss -tlnp | grep 6514  # For TLS

Check for error logs:

sudo journalctl -u rsyslog -f

2. TLS: "error reading certificate file"

Check file permissions:

ls -la /etc/rsyslog.d/certs/

Fix the permissions:

sudo chmod 644 /etc/rsyslog.d/certs/ca.pem
sudo chmod 644 /etc/rsyslog.d/certs/*-cert.pem
sudo chmod 600 /etc/rsyslog.d/certs/*-key.pem

Check SELinux:

getenforce
sudo setenforce 0  # Temporarily disable for testing

3. TLS: "peer name not authorized"

Cause: The CN (Common Name) does not match the PermittedPeer setting.

Fix:

# Check the CN in the certificates
sudo openssl x509 -in /etc/rsyslog.d/certs/server-cert.pem -noout -subject
sudo openssl x509 -in /etc/rsyslog.d/certs/client-cert.pem -noout -subject

# The CN must match the configuration:
# Server: PermittedPeer=["syslog-client"]
# Client: StreamDriverPermittedPeers="syslog-server"

4. No Directory Appears in /var/log/remote/

Check the template configuration:

sudo grep -A5 "template.*Remote" /etc/rsyslog.d/*.conf

Create the directory manually:

sudo mkdir -p /var/log/remote
sudo chmod 755 /var/log/remote

🎯 Summary

Final Thoughts

Sending logs through Rsyslog on Linux (Rocky Linux 10) is a great starting point for beginners entering the world of cybersecurity and SIEM operations. Collecting logs from multiple systems into a single location — known as Centralized Logging — enables you to perform Incident Analysis and build Proactive Defense against cyber threats more effectively.

There are two primary ways to send logs: Plain Text and TLS Encryption. Choosing the right one depends on your data sensitivity and network environment.

If you found this article helpful, don't forget to 👏 Follow me for more Cybersecurity content in upcoming articles! 🚀