vps-security-hardening

# VPS Security Hardening Audit and harden VPS security with fail2ban (brute-force protection), SSH hardening, and optional firewall setup. ## When to Use - New VPS setup (initial hardening) - Security audit requested - SSH brute-force attacks detected - User wants to "secure VPS" or "protect server" ## Prerequisites: Establishing SSH Access **Before hardening, ensure you can SSH into the VPS.** ### If Password Auth is Disabled (PublicKey only) VPS providers often disable password auth by default. You need to add your SSH key first. #### Option 1: Via VPS Web Console (Recommended) 1. **Generate SSH key locally** (if not exists): ```bash ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N '' -C "user@machine" cat ~/.ssh/id_ed25519.pub ``` 2. **Login to VPS via web console** (provider dashboard → Console/Terminal) 3. **Add public key to VPS**: ```bash mkdir -p ~/.ssh echo "ssh-ed25519 AAAA... user@machine" >> ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys ``` 4. **Test from local machine**: ```bash ssh root@VPS_IP ``` #### Option 2: Via Provider Dashboard Most providers (DigitalOcean, Vultr, Biznet, etc.) have "Add SSH Key" in dashboard: - Copy public key (`cat ~/.ssh/id_ed25519.pub`) - Paste into provider's SSH key management - Rebuild/restart VPS (some providers require this) #### Option 3: Enable Password Auth Temporarily **Only if web console is unavailable:** 1. Login via web console 2. Edit SSH config: ```bash echo "PasswordAuthentication yes" >> /etc/ssh/sshd_config.d/99-temp-password.conf systemctl reload sshd ``` 3. SSH in with password, add your key 4. Remove temp config: ```bash rm /etc/ssh/sshd_config.d/99-temp-password.conf systemctl reload sshd ``` ### Common Pitfall: sshpass with PublicKey-Only VPS **Problem:** `sshpass -p 'password' ssh user@host` fails with "Permission denied (publickey)" even with correct password. **Why:** VPS has `PasswordAuthentication no` in sshd_config — password auth is disabled at server level. **Solution:** Use web console to add SSH key first (see Option 1 above). ## Workflow ### Phase 1: Security Audit 1. **Check running processes** ```bash ps aux --sort=-%mem | head -20 systemctl list-units --type=service --state=running ``` 2. **Check listening ports** ```bash sudo ss -tulpn sudo netstat -tulpn ``` 3. **Check for rootkits/malware** ```bash # Hidden processes ps aux | wc -l ls /proc | grep -E '^[0-9]+$' | wc -l # Recent failed logins sudo grep "Failed password" /var/log/auth.log | tail -20 ``` 4. **Check user accounts** ```bash cat /etc/passwd | grep -E '/bin/(bash|sh)$' sudo lastlog ``` 5. **Resource usage** ```bash free -h df -h uptime ``` ### Phase 2: Install fail2ban ```bash # Install sudo apt-get update sudo apt-get install -y fail2ban # Enable and start sudo systemctl enable fail2ban sudo systemctl start fail2ban ``` ### Phase 3: Configure fail2ban Create `/etc/fail2ban/jail.local`: ```ini [DEFAULT] bantime = 3600 # Ban for 1 hour findtime = 600 # Count failures in last 10 minutes maxretry = 5 # Ban after 5 failures [sshd] enabled = true port = 22 logpath = /var/log/auth.log maxretry = 5 ``` Restart: ```bash sudo systemctl restart fail2ban sudo fail2ban-client status sshd ``` ### Phase 4: SSH Hardening Create `/etc/ssh/sshd_config.d/99-hardening.conf`: ```conf # Disable root login PermitRootLogin no # Enable public key auth PubkeyAuthentication yes # Disable empty passwords PermitEmptyPasswords no # Limit auth attempts MaxAuthTries 3 # Disable X11 forwarding X11Forwarding no # Disable TCP forwarding AllowTcpForwarding no # Disable agent forwarding AllowAgentForwarding no # Set login grace time LoginGraceTime 30 # Limit sessions MaxSessions 2 # Strong ciphers only Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com # Strong MACs only MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com # Strong key exchange KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256 ``` Test and reload: ```bash sudo sshd -t sudo systemctl reload sshd ``` ### Phase 5: Verify ```bash # fail2ban status sudo fail2ban-client status sshd # SSH config sudo sshd -T | grep -E '(permitrootlogin|maxauthtries|x11forwarding)' # Check banned IPs sudo fail2ban-client get sshd banip ``` ## Important: Password vs SSH Key Decision **DO NOT automatically disable password authentication!** ### Check First ```bash # Check if user has SSH keys cat ~/.ssh/authorized_keys # Check how user is currently connected sudo grep "Accepted" /var/log/auth.log | tail -5 ``` ### Decision Logic **If user logs in with PASSWORD:** - ✅ Keep `PasswordAuthentication yes` - ✅ fail2ban provides brute-force protection - ⚠️ Disabling password = user gets locked out **If user logs in with SSH KEY:** - ✅ Can disable `PasswordAuthentication no` - ✅ Maximum security (impossible to brute-force) ### User Preference Handling **CRITICAL:** If user says "keep password" or "tanpa ssh key" or similar: - ✅ Accept their decision - ✅ Explain security is already good with fail2ban - ❌ DO NOT keep suggesting SSH keys - ❌ DO NOT say "but SSH keys are better" - ❌ DO NOT make them feel their choice is wrong **User knows their use case better than you:** - They might need portability (login from anywhere) - They might not want key file management - They might prefer convenience over maximum security - **Respect their decision and move on** ## Pitfalls ### 1. Disabling Password Auth Too Early **Problem:** User currently uses password, you disable it, user gets locked out. **Solution:** - Always check current connection method first - If password login, keep it enabled - Only disable if user has working SSH keys AND explicitly requests it ### 2. Not Testing SSH Config **Problem:** Invalid SSH config breaks SSH service, user locked out. **Solution:** - Always run `sudo sshd -t` before reload - Use `reload` not `restart` (preserves current connections) ### 3. fail2ban Banning User's Own IP **Problem:** User makes typo 5 times, gets banned. **Solution:** - Explain how to unban via VPS console: `sudo fail2ban-client unban --all` - Consider whitelist for user's known IPs (optional) ### 4. Over-Suggesting Security Improvements **Problem:** User made decision (e.g., keep password), you keep suggesting alternatives. **Solution:** - Present options ONCE with pros/cons - User decides - Accept decision and move on - Don't revisit unless user asks ### 5. Cloud Provider Default Users **Problem:** Deleting cloud provider system users (e.g., `lighthouse` on Tencent Cloud). **Solution:** - Check if user has sudo privileges: `sudo grep lighthouse /etc/sudoers.d/*` - If yes, it's emergency access mechanism - DO NOT delete (user might need it for recovery) ## Monitoring Commands ```bash # Check fail2ban status sudo fail2ban-client status sshd # Check banned IPs sudo fail2ban-client get sshd banip # Unban IP sudo fail2ban-client set sshd unbanip 1.2.3.4 # Watch SSH attacks live sudo journalctl -u ssh -f # Recent failed attempts sudo grep "Failed password" /var/log/auth.log | tail -20 ``` ## Optional: UFW Firewall Only enable if user requests or if no cloud-level firewall exists. ```bash # Allow SSH first (CRITICAL!) sudo ufw allow 22/tcp # Allow other services sudo ufw allow 1430/tcp # Example: API port # Enable sudo ufw enable # Check status sudo ufw status ``` ## Success Criteria - ✅ fail2ban running and banning attackers - ✅ SSH hardened (root disabled, limited attempts) - ✅ User can still login (not locked out) - ✅ Auto-updates enabled - ✅ User satisfied with security level ## References - `references/ssh-key-vs-password.md` — Detailed comparison and decision framework - fail2ban docs: https://www.fail2ban.org/ - SSH hardening guide: https://www.ssh.com/academy/ssh/sshd_config - Ubuntu security: https://ubuntu.com/security