Learn Samba - Privilege & Ransomware Mitigation

#Introduction

Episode 14 made Samba "hard" against technical attacks. Episode 15 confronts a more vicious threat: ransomware — malware that encrypts every file it can write. The perspective you must hold: if malware gets into a user's computer, it will use that user's credentials to write to Samba shares. So the best defense isn't preventing malware (that's the endpoint's domain), but designing shares that can't be destroyed even by a compromised user. That's the philosophy of this whole episode.

#Protection: Layered Defense

#Immutable Snapshots: The Last Defense

Read-only snapshots (episode 12) are the most powerful weapon: ransomware can't delete a file it can't write, even with admin credentials. The key word is immutable: at the filesystem level, not merely Samba read-only. For Btrfs, -r (readonly) snapshots plus extra protection:

sudo btrfs subvolume snapshot -r /srv/data /srv/data/.snapshots/@GMT-2026.08.13-06.00.00
sudo btrfs property set /srv/data/.snapshots/@GMT-2026.08.13-06.00.00 ro true

The key thing to understand: ransomware running as a normal user has no admin access to the server — it can only encrypt what that user can write. The immutable server snapshot is untouched. This is why share separation (below) is so decisive: the narrower a user's write rights, the less there is to destroy.

#Read-Only Shares for Backup Targets

Backups must be written from a separate system, to a location unreachable by endpoints. One strong pattern: a share that is write-only for the backup server, read-only for everyone else:

[backup]
   path = /srv/backup
   read only = yes
   valid users = @LAB\backup-agent
   write list = backupsvc
   vfs objects = recycle

• read only = yes + write list = backupsvc: only the backup service (backupsvc) may write — normal users can only read (restore files).
• valid users = @LAB\backup-agent: even reading is restricted to a dedicated group.
• VFS recycle as an extra layer in case of accidents.

#Recycle: The First Safety Net

Recycle from episode 12 protects against deletion — many modern ransomware variants delete files first or wipe share contents before/alongside the encrypter. Recycle buys reaction time. But remember episode 12's emphasis: recycle is not the primary defense — it's the fastest layer; immutable snapshots and offsite backup are what actually win.

#Monitoring Suspicious Access

Ransomware patterns on a network: mass file writes in a short time, mass renames, or odd logins. Build simple detection:

du -sh /srv/data 2>/dev/null >> /var/log/share-growth.log

The script above records the share size at each interval; an extreme size spike (or mass ownership changes) is a red flag. Reinforce with episode 14's auth_audit log:

sudo grep -c "NT_STATUS_LOGON_FAILURE" /var/log/samba/log.*

And check for files that suddenly change extension — a typical encrypter pattern:

find /srv/data -mmin -30 -name "*.encrypted" 2>/dev/null

#Best Practices: Least Privilege and Segregation

#Least Privilege

The principle: every user gets the minimum capability to do their job. In practice with Samba:

• Don't set valid users = @domain users, which opens every share to everyone.
• Create per-department groups (@staf, @finance, @engineering) and map them to their respective shares.
• Use read only = yes + write list (episode 4) — write is the exception, not the default.
• Rotate and restrict admin accounts; don't use the Samba admin (root) for day-to-day access.

#Share Segregation

One giant data directory is a nightmare: one user's mistake affects everyone. Separate by function and sensitivity:

[data]     -> departemen (per group)
[archive]  -> read-only, jarang berubah
[backup]   -> write-only untuk service backup
[incoming] -> drop zone, write-only, dibersihkan berkala

[incoming] is worth emulating: a write-only drop-zone share (small valid users, no browse) is where users drop "raw" files before an admin moves them to a final location. This pattern narrows the writable surface — and every writable surface is what ransomware can destroy.

#Incident Response Checklist

When a red flag appears (an encrypter is detected), here's the recommended order of actions:

1. Isolate: cut share access (smbcontrol all pause) and pull the infected machine off the network.
2. Don't reboot the server: snapshots and logs are evidence; shut down services in a controlled way.
3. Identify the window: find the last clean snapshot before the infection (episode 12).
4. Recover: mount the immutable snapshot, copy clean files to a new location.
5. Audit accounts: find which credentials the attacker used (auth_audit logs), reset and restrict them.
6. Review the design: why did that user have write access? Fix it before coming back online.

sudo smbcontrol all pause
sudo smbcontrol all resume   # setelah yakin aman

#Closing

Key takeaways:

• Immutable snapshots are the primary defense — ransomware can't write what's read-only.
• Backup share: read only = yes + write list for the backup service only.
• Recycle protects against deletion; detection (logs, growth monitor) speeds up response.
• Least privilege and share segregation narrow what can be destroyed.
• Samba configuration doesn't stop ransomware with valid credentials — design and detection win.

In episode 16 next, we'll cover testing & troubleshooting — testparm, smbclient -L, smbstatus, net ads testjoin, samba-tool domain info, log level, plus common cases: DNS, time skew, permissions, and SELinux/AppArmor. When everything works, it's time to learn how to fix it when it doesn't!