Jump to content

Featured Replies

Posted

You are reading Part 36 of the 57-part series: Harden and Secure Linux Servers. [Level 4]

This series covers progressive security measures, from fundamental hardening techniques to enterprise-grade defense strategies. Each article delves into a specific security practice, explaining its importance and providing step-by-step guidance for implementation.

To explore more security best practices, visit the main guide for a full breakdown of all levels and recommendations.

Remote logging allows you to store system logs on a separate server, ensuring:

Logs remain accessible even if a server is compromised or tampered with.
Easier centralized monitoring and analysis for multiple servers.
Compliance with security standards (PCI-DSS, ISO 27001, HIPAA).

By configuring remote logging, you enhance system visibility and improve incident response.

How to Configure Remote Logging with Rsyslog

1. Install Rsyslog on Both the Local and Remote Server

Most Linux distributions come with rsyslog pre-installed, but if not, install it:

For Debian/Ubuntu:

sudo apt update
sudo apt install rsyslog -y

For CentOS/RHEL:

sudo yum install rsyslog -y
2. Configure the Remote Log Server to Receive Logs

On the remote logging server (where logs will be stored), do the following:

  1. Edit the Rsyslog configuration file:

    sudo nano /etc/rsyslog.conf
    
  2. Uncomment or add the following lines to allow remote logging over TCP/UDP:

    module(load="imudp")
    input(type="imudp" port="514")
    
    module(load="imtcp")
    input(type="imtcp" port="514")
    

    (Enables logging over UDP (port 514) and TCP (port 514).)

  3. Enable log storage in a separate directory:
    Add a rule to store logs by hostname under /var/log/remote/:

    if $fromhost-ip != '127.0.0.1' then /var/log/remote/%HOSTNAME%/syslog.log
    & stop
    
  4. Save and close the file, then restart Rsyslog:

    sudo systemctl restart rsyslog
    
  5. Ensure the remote log server allows incoming logs on port 514:

    sudo ufw allow 514/tcp
    sudo ufw allow 514/udp
    
3. Configure the Local Server to Forward Logs

On the server sending logs, configure rsyslog to forward logs to the remote logging server.

  1. Edit the Rsyslog configuration file:

    sudo nano /etc/rsyslog.conf
    
  2. Add the following line at the end of the file:

    *.* @remote_log_server:514    # Use UDP (replace with @@ for TCP)
    
    • @remote_log_server:514 → Sends logs to the remote server over UDP.

    • @@remote_log_server:514 → Sends logs over TCP (more reliable).

  3. Restart Rsyslog to apply changes:

    sudo systemctl restart rsyslog
    
4. Verify Logs Are Being Sent and Stored
On the remote log server

Check if logs are arriving from the local server:

sudo tail -f /var/log/remote/your-server-ip/syslog.log
On the local server

Check if logs are being forwarded properly:

logger "Test log message to remote server"

Then verify if this message appears on the remote log server.

5. Automate Log Rotation and Retention

To prevent log files from consuming too much disk space, set up log rotation:

  1. Edit logrotate configuration on the remote log server:

    sudo nano /etc/logrotate.d/remote_logs
    
  2. Add the following configuration:

    /var/log/remote/*/*.log {
        rotate 14
        daily
        compress
        missingok
        notifempty
        create 0640 syslog adm
    }
    
    • Keeps logs for 14 days before deletion.

    • Compresses old logs to save space.

    • Skips rotation if logs are empty.

  3. Apply changes:

    sudo logrotate -f /etc/logrotate.d/remote_logs
    

Best Practices for Secure Remote Logging

Use TLS Encryption for Secure Log Transfer (replace TCP/UDP with imtcp_tls).
Restrict log access to authorized users (chmod 640 /var/log/remote/*).
Enable Fail2Ban to detect log-based attacks (sudo apt install fail2ban).
Regularly monitor logs for security events (sudo cat /var/log/auth.log | grep sshd).

By setting up remote logging, you ensure critical system logs remain available, even if the primary server is compromised, helping with forensic analysis, compliance, and security monitoring.

  • Views 91
  • Created
  • Last Reply

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

Important Information

Terms of Use Privacy Policy Guidelines We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.