Overly broad permissions can turn one compromised account into a much larger security problem. Learn how to reduce unnecessary access, review privileges, and apply least privilege across modern Linux systems. Review Linux Privileges×
When you’re digging through an incident, your logs are the only thing you can actually trust. The problem is, attackers know that too. If someone gets root on your server, their first move is almost always to delete the evidence and cover their tracks. . If you aren't actively protecting your logs, you're basically flying blind the second a breach happens. It’s a miserable feeling to realize you have no idea what an attacker did because they wiped the logs before you even got there. In this guide, I’m going to show you how to actually lock these things down. We’re going to build a setup that keeps your audit trail safe—even if the host itself is completely compromised. The Strategy: A Layered Defense A tamper-resistant logging strategy combines multiple defensive layers to make the cost of log destruction too high for an attacker: Centralized Logging: Preserves evidence off-host where an attacker cannot reach it. Service Resilience: Prevents the logging daemon from being easily stopped or killed. Immutable Local Storage: Adds "speed bumps" to local files to slow down tampering. Active Monitoring: Detects tampering attempts or "log silence" the moment they occur. 1. The Golden Rule: Centralized Remote Logging Local logs are a liability. By streaming logs to a dedicated centralized server—where even administrators cannot easily modify previously written logs—you ensure that if an attacker wipes the local disk, the evidence is already safely archived elsewhere. Action: Configure rsyslog for TLS forwarding Most modern systems use rsyslog or systemd-journald . For production, use TCP (@@) rather than UDP (@) to ensure packets aren't dropped. Edit /etc/rsyslog.conf : # Encrypted transport via TCP $ActionSendStreamDriver gtls $ActionSendStreamDriverMode 1 $ActionSendStreamDriverAuthMode x509/name *.* @@logserver.example.com:514 Stick with TCP for this. A lot of people use UDP because it’s easy, but it’s 'fireand forget'—meaning you’re going to lose packets the second your network gets busy. You can’t afford to lose audit logs. You should be running TCP, and frankly, you need to layer TLS on top of it. That’s the only way to stop someone from sniffing your traffic or spoofing the logs while they’re moving across the wire. Quick warning: Don’t try to wing the TLS setup. If your client and server aren't playing nice with the same Certificate Authority (CA) , it’s just not going to connect, period. Seriously, check your distro’s docs on how to handle the certs first—don't just force the connection and hope for the best. How to make sure it’s not broken: Once you’ve got the config saved, don't just hope for the best. Run this on your client: logger "Test log message" Then, jump over to your central server. Tail the logs—use journalctl , your SIEM, or whatever standard log file your distro uses (usually /var/log/syslog or /var/log/messages ). If you don’t see that test message pop up, your pipeline isn't working 2. Service Resilience: Making the Daemon Stick Attackers often try to kill the logging service to stop the flow of information. You can use systemd to make the service self-healing. While this example uses rsyslog , the same logic applies to systemd-journald if you are managing it directly. Action: Configure service overrides sudo systemctl edit rsyslog Add this block: Ini, TOML [Service] Restart=always RestartSec=1 StartLimitBurst=5 StartLimitIntervalSec=10 Why this matters: This forces the daemon to restart immediately if killed. While a root user can technically override this, it forces them to continuously fight the system, increasing the likelihood that your monitoring will catch the activity. Verification: Manually kill the process with sudo pkill rsyslog and immediately run systemctl status rsyslog to watch it restart. 3. Local "Speed Bumps": Immutable Attributes If you havesensitive logs that must reside locally, you can use the chattr command to add an "append-only" flag. Action: Set the attribute sudo chattr +a /var/log/auth.log That’s the only way to stop someone from sniffing your traffic or spoofing the logs while they’re moving across the wire. Quick warning: Don’t try to wing the TLS setup. If your client and server aren't playing nice with the same Certificate Authority (CA), it’s just not going to connect, period. Seriously, check your distro’s docs on how to handle the certs first—don't just force the connection and hope for the best. 4. Detecting "Log Silence" A sudden stop in log volume is often an early indicator of compromise. A sudden absence of logs is often just as suspicious as malicious entries. Action: Monitor the heartbeat If you aren't running a full SIEM, add a simple cron job to verify the service is running: pgrep -f rsyslog > /dev/null || logger -p crit "CRITICAL: Logging service is down!" Pro Tip: Hook this logger command into your alerting system (like Prometheus, Zabbix, or Slack notifications) so you know within seconds if your logging goes dark. 5. Auditd: Tracking the Tamperer auditd is one of the most effective tools for detecting unauthorized changes to log files. Action: Add a watch rule Add this to /etc/audit/rules.d/audit.rules : -w /var/log/auth.log -p wa -k log-tamper Verification: Run sudo ausearch -k log-tamper -i to see the results. It will show you exactly which user account or process touched that file. Best Practice: Hardening local logs is valuable, but remote logging should always be your first priority. Once an attacker has root access, no local protection is completely trustworthy. Common Mistakes to Avoid The UDP Trap: Using UDP for production logging leads to lost data. Always prefer TCP or RELP (Reliable Event Logging Protocol), which provides stronger delivery guarantees than traditional syslogover TCP. Ignoring Rotation: Making a file immutable without configuring logrotate will cause your system to fill up or services to crash. Assuming Local Safety: No local log is safe if the host is compromised. Centralization is your only true insurance. Final Implementation Checklist Remote Logging: Enabled TLS/TCP forwarding. Verification: Confirmed messages appear on the central server. Resiliency: Set systemd restart policies on the logging daemon. Monitoring: Set up an alert for "Log Silence." Auditd: Active watch rules on critical files. Next Steps: If you are using immutable log files ( chattr +a ), your next task should be integrating those protections with logrotate so your logs continue to manage themselves without manual intervention. Want more Linux security news, vulnerability analysis, and software supply chain updates? Subscribe to the LinuxSecurity Newsletter and get the latest threats, advisories, and expert insights delivered directly to your inbox. Related Reading Exploring Log Management Tools for Efficient Linux System Monitoring Practical Guide to Hardening Linux Servers for Enhanced Security How to Read Linux Audit Logs During an Intrusion Auditd vs eBPF: Modern Approaches to Linux System Monitoring Linux Features Enhancing Security for 2026: Predictability and Control . Explore strategies to build a tamper-resistant logging infrastructure in Linux to enhance incident response and logging security.. Linux logging security, tamper-resistant logs, incident response. . MaK Ulac
The Shoreline Firewall (Shorewall) is an iptables based firewall that can be used on a dedicated firewall system, a multi-function masquerade gateway/server or on a standalone Linux system.. . Delve into the Shorewall Framework, an iptables-centric tool designed specifically for Linux systems, delivering both strength and adaptability.. Shoreline Firewall, Iptables Security, Linux Firewall, Shorewall Tool, Network Protection. . Anthony Pell
A great document that explains security risks and ways to protect yourself.. . Java, a widely-used programming language, presents security vulnerabilities that threaten application integrity and data confidentiality with several risks to address. Java Security, Risk Management, Application Protection. . Anthony Pell
Get the latest Linux and open source security news straight to your inbox.