Why I Use Read-Only Partitions on My Linux Servers (And You Should Too)

Intro

One of the most underrated Linux hardening techniques is also one of the simplest: read-only partitions. In a world of ransomware, misconfigurations, and stealthy rootkits, setting parts of your system to read-only is a powerful and low-effort win.

Here’s why I use it — and how you can start applying it today without breaking your setup.

🔒 What Is a Read-Only Partition?

A read-only partition is exactly what it sounds like: a part of your file system that can’t be modified — no writing, no deleting, no tampering.

You can mount directories like /boot, /usr, or even / with the ro (read-only) flag. The goal? Reduce the writable attack surface and prevent malicious or accidental changes.

💡 Why Bother Making It Read-Only?

✅ 1. Stops Persistence

Many malware and rootkits need to write to disk. A read-only mount blocks this — instantly breaking most persistence mechanisms.

✅ 2. Prevents Accidental Changes

Ever typo a command as root and nuked something important? A read-only setup makes critical directories tamper-proof.

✅ 3. Protects System Integrity

With /usr or /boot locked down, even if someone gets limited access, they can’t easily backdoor your binaries or kernel modules.

✅ 4. Survives Insider Mistakes

Even if a legit user (or script) messes up, damage is minimized. This is especially useful on multi-user or production environments.

🧪 How I Set It Up (Real Examples)

Let’s say I want to make /usr read-only:

Step 1: Backup and Test

Always test changes on a staging server or VM. Some applications may try to write into /usr (they shouldn't).

Step 2: Edit /etc/fstab

UUID=xxx-xxx-xxx /usr ext4 ro,defaults 0 2

Or if you’re using overlayfs for flexibility:

mount -o ro,remount /usr

This can be done for:

• /boot
• /usr
• /var (with exceptions — logs/cache need writes)
• Even / in containers

Step 3: Reboot and Verify

mount | grep ro

Check that your intended directories are mounted read-only.

🧠 Bonus: Use systemd for Service-Level Protection

You don’t need full partition changes. For individual services, use this in your .service file:

ProtectSystem=strict
ReadOnlyPaths=/etc /usr

This mounts parts of the system read-only just for that service. Easy win.

⚠️ What to Watch Out For

• Logging: Be sure /var/log or equivalent remains writable.
• Updates: You’ll need to remount partitions as rw (read-write) temporarily during patching.
• Docker: If using containers, enforce readOnlyRootFilesystem: true in Kubernetes or Docker Compose.

🚀 Final Thoughts

Security isn’t just about tools — it’s about defaults that work in your favor. By setting key parts of your system as read-only, you make it harder for attackers, users, and even root to do unintended damage.

Think of it as your invisible bodyguard — always watching silently in the background.

Try it. Break less. Sleep more.

💬 What’s your take? Do you use read-only mounts in production? Let’s discuss in the comments below.

🙏 Thank you for being a part of the community

👏 Before you go: Be sure to clap and follow me!

📲 Follow me on social media: 🔗 LinkedIn: https://www.linkedin.com/in/bornaly/ ✍️ Medium: https://medium.com/@bornaly/subscribe 💬 Discord: https://discord.gg/FkjR2WFs 📘 Facebook: https://www.facebook.com/profile.php?id=61578778563015