Home Lab Security
A practical guide for reviewing and improving home lab security.
A home lab is useful for learning, hosting services, testing Linux, running containers, and building projects.
But if it is reachable from the internet, it needs extra care.
Why home lab security matters
A home lab can contain:
- personal files
- photos
- password manager data
- databases
- Docker volumes
- configuration files
- API tokens
- SSH keys
- admin panels
- backups
- public services
A small mistake can expose more than expected.
The goal is not to make everything perfect.
The goal is to know what is running, what is exposed, and what must stay private.
Main goal
The goal is:
- Know what services are running.
- Know what ports are open.
- Keep admin tools private.
- Use SSH keys.
- Use Tailscale for private access.
- Keep backups tested.
- Reduce unnecessary exposure.
List running services
Start by knowing what runs on the server.
Useful commands:
docker ps
- ```bash
- ss -tulpn
```bash
systemctl --failed
- ```bash
- systemctl list-units --type=service --state=running
Questions:
- What is running?
- Do I still use it?
- Is it public or private?
- Does it need login?
- Does it have backups?
---
## Public vs private services
Separate services into two groups.
Public services:
- services meant to be reachable by others
- websites
- public wiki
- public social instance
- public blog
Private services:
- admin panels
- password manager admin page
- photo management
- server dashboards
- databases
- SSH
- Portainer
- backup tools
- internal calendars
Private services should usually be reachable only through Tailscale or local network.
---
## Admin panels
Admin panels should not be public unless there is a very strong reason.
Examples:
- Portainer
- database admin tools
- server dashboards
- monitoring admin pages
- router admin page
- Cloudflare tunnel dashboard endpoints
- application admin panels
Questions:
- Can this change server settings?
- Can this see private data?
- Can this delete data?
- Can this expose tokens?
- Can this create users?
If yes, keep it private.
---
## SSH
SSH should be treated as a high-value access point.
Recommended:
- use SSH keys
- disable direct root login
- disable password login only after key login works
- keep SSH on port 22
- use Tailscale for remote SSH
- do not expose SSH directly if not needed
Useful check:
```bash
sudo sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin|port'
- Expected clean result:
text
port 22
pubkeyauthentication yes
passwordauthentication no
permitrootlogin no
- Before changing SSH settings:
text
test key login
open a second session
keep one working session open
restart SSH only after syntax check
test again before closing old session
- ---
- ## Docker ports
- Docker can expose services to the host or internet.
- Check:
bash
docker ps
- Look at the `PORTS` column.
- Examples:
text
127.0.0.1:8080->80/tcp
0.0.0.0:8080->80/tcp
- Meaning:
text
127.0.0.1 = local host only
0.0.0.0 = all network interfaces
- If a service uses `0.0.0.0`, ask:
text
Should this really be reachable from outside?
Should it be local only?
Should it be behind Tailscale?
Should it be behind Cloudflare?
- ---
- ## Docker Compose review
- Check Docker Compose files.
- Look for:
text
ports
volumes
environment
restart policy
networks
.env files
admin tokens
database passwords
- Good habits:
text
do not expose unnecessary ports
keep secrets in .env files
do not publish .env files
use Docker networks
document what each service does
remove old containers
- ---
- ## Cloudflare
- Cloudflare is useful, but review what it exposes.
- Check:
text
DNS records
tunnel routes
public hostnames
access policies
API tokens
old unused records
SSL/TLS settings
- Questions:
text
Which services are public on purpose?
Are any admin tools public?
Are there old DNS records?
Are there old tunnel routes?
Are API tokens still needed?
- ---
- ## Tailscale
- Tailscale is useful for private access.
- Good uses:
text
SSH access
admin panels
private dashboards
password manager admin access
photo management
internal services
- Good habits:
text
remove old devices
review device names
enable device approval if useful
review ACLs if used
keep clients updated
- ---
- ## Backups
- Security also means being able to recover.
- Backups protect against:
text
disk failure
bad updates
accidental deletion
ransomware
broken containers
database corruption
user mistake
- Basic backup questions:
text
What is backed up?
Where is it backed up?
How often?
How long is it kept?
Can I restore it?
Have I tested restore?
- Important items:
text
Docker Compose files
.env files
databases
uploaded files
photos
wiki data
password manager data
calendar/contact data
configuration files
- ---
- ## Updates
- Keep the server and containers updated.
- Review:
text
operating system updates
Docker updates
container image updates
application updates
security advisories
- Do not update blindly if the service is important.
- Better:
text
read release notes
backup first
update one service at a time
test after update
keep rollback plan
- ---
- ## Logs
- Logs help find problems.
- Useful checks:
bash
journalctl -xe
- ```bash
- docker logs CONTAINER_NAME
```bash
sudo tail -n 100 /var/log/auth.log
- On RHEL-like systems:
bash
sudo tail -n 100 /var/log/secure
- Look for:
text
failed logins
unknown users
repeated errors
crashes
permission problems
strange IPs
unexpected restarts
Home lab review checklist
- List running containers
- List listening ports
- Identify public services
- Identify private services
- Keep admin panels private
- Review Docker Compose ports
- Review Cloudflare routes
- Review Tailscale devices
- Confirm SSH key login
- Disable root SSH login
- Disable password SSH login after testing keys
- Check backups
- Test at least one restore
- Review logs
- Remove old unused services
Simple rule
A home lab should be useful, not mysterious.
Know what runs, know what is exposed, and keep private tools private.