NAS Security Hardening: From SSH to Strict Permissions

April 10, 2026 • 10 min read

⚠️ Security Notice: This post documents security hardening steps for a home NAS. IP addresses and hostnames have been generalized for privacy. Adapt these steps to your own environment.

Background

When I first set up my NAS, I took shortcuts: default SSH configuration, password authentication, and loose file permissions. This post documents the journey from "it works" to "it's secure."

Phase 1: SSH Hardening

1.1 Disable Root Login

The first rule: never allow direct root SSH access.

# Edit SSH configuration
sudo nano /etc/ssh/sshd_config

# Change or add:
PermitRootLogin no

1.2 Enable Key-Based Authentication Only

Password authentication is vulnerable to brute force attacks. Switch to SSH keys:

# Generate SSH key (on your local machine)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Copy to NAS
ssh-copy-id user@<nas-ip>

# Test key login
ssh user@<nas-ip>

# Disable password auth (on NAS)
sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Restart SSH
sudo systemctl restart sshd

1.3 Restrict SSH to Local Network

Use firewall rules to only allow SSH from trusted IP ranges:

# Using UFW (Uncomplicated Firewall)
sudo apt install -y ufw

# Allow SSH from local network only (adjust subnet)
sudo ufw allow from 192.168.51.0/24 to any port 22

# Enable firewall
sudo ufw enable
sudo ufw status

1.4 Change SSH Port (Optional)

Security through obscurity isn't real security, but it reduces log noise from automated scanners:

# Edit SSH config
sudo nano /etc/ssh/sshd_config
Port 2222

# Update firewall
sudo ufw allow from 192.168.51.0/24 to any port 2222
sudo ufw delete allow 22

# Restart SSH
sudo systemctl restart sshd

# Test new port
ssh -p 2222 user@<nas-ip>

Phase 2: User and Permission Management

2.1 Create Dedicated Service Users

Each service should run under its own user account:

# Create users for different services
sudo useradd -r -s /usr/sbin/nologin media
sudo useradd -r -s /usr/sbin/nologin backup
sudo useradd -r -s /usr/sbin/nologin web

# Verify
getent passwd media
getent passwd backup
getent passwd web

2.2 Group-Based Access Control

Use groups to manage shared access to directories:

# Create groups
sudo groupadd mediausers
sudo groupadd backupusers

# Add your user to groups
sudo usermod -aG mediausers,backupusers henry

# Set directory ownership
sudo chown -R media:mediausers /srv/media
sudo chown -R backup:backupusers /srv/backups

# Set permissions (owner rwx, group rx, others none)
sudo chmod -R 750 /srv/media
sudo chmod -R 750 /srv/backups

2.3 ACL for Fine-Grained Control

For complex permission scenarios, use Access Control Lists:

# Install ACL tools
sudo apt install -y acl

# Set ACL: allow specific user read access
sudo setfacl -m u:username:rx /path/to/directory

# Set ACL: allow group read-write
sudo setfacl -m g:groupname:rwx /path/to/directory

# View ACLs
getfacl /path/to/directory

# Remove ACL
sudo setfacl -x u:username /path/to/directory

Phase 3: Network Segmentation

3.1 VLAN Configuration

If your router supports it, isolate IoT and server devices on separate VLANs:

VLAN 10: Trusted devices (laptops, phones)
VLAN 20: Servers (NAS, media servers)
VLAN 30: IoT devices (cameras, smart home)

3.2 Firewall Rules Between VLANs

# Example: Allow VLAN 10 to access VLAN 20, but not vice versa
# (Configure on your router/firewall)

# Allow trusted → servers
iptables -A FORWARD -i vlan10 -o vlan20 -j ACCEPT

# Block servers → trusted (except established)
iptables -A FORWARD -i vlan20 -o vlan10 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vlan20 -o vlan10 -j DROP

Phase 4: Monitoring and Auditing

4.1 SSH Login Monitoring

# View successful logins
last

# View failed login attempts
sudo grep "Failed password" /var/log/auth.log

# View all SSH activity
sudo journalctl -u ssh -f

4.2 File Integrity Monitoring

Use tools like AIDE or Tripwire to detect unauthorized file changes:

# Install AIDE
sudo apt install -y aide

# Initialize database (first run)
sudo aideinit

# Replace default database
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Run integrity check
sudo aide --check

4.3 Regular Security Audits

# Check for packages with security updates
sudo apt list --upgradable | grep security

# Review open ports
sudo ss -tlnp

# Check for world-writable files
sudo find / -type f -perm -0002 -ls 2>/dev/null

# Review user accounts
cat /etc/passwd | grep -v nologin | grep -v false

Phase 5: Backup Security

5.1 Encrypted Backups

Backups should be encrypted, especially if stored offsite:

# Using rsync with encryption
rsync -avz -e "ssh -i ~/.ssh/backup_key" /source user@backup-server:/dest

# Using restic (encrypted backup tool)
restic init --repo /srv/backups/restic
restic backup --repo /srv/backups/restic /home/henry

5.2 Backup Permissions

Backup directories should be even more restrictive than regular data:

sudo chown -R root:backupusers /srv/backups
sudo chmod -R 740 /srv/backups

Security Checklist

✅ SSH key-only authentication
✅ Root login disabled
✅ Firewall enabled with strict rules
✅ Services running as dedicated users
✅ Directory permissions set to 750 or stricter
✅ Regular security updates
✅ Login monitoring enabled
✅ Encrypted backups

Lessons Learned

Start secure from day one - It's much harder to lock things down after services are running and data is scattered.
Document everything - You will forget why you set something up a certain way. Write it down.
Test your backups - A backup you can't restore is not a backup.
Balance security and usability - Perfect security that prevents you from using your system is not useful.

References

CIS Debian Benchmark
Arch Wiki - Security
OpenSSH Hardening Guide