How to Respond to a Compromised Server
If you suspect your server has been hacked, act quickly and methodically.
Signs of Compromise
- Unfamiliar processes consuming CPU or network in
top/htop - Unknown outbound connections in
ss -tulpnornetstat -an - Unauthorized logins in
/var/log/auth.log - New unknown users in
cat /etc/passwd - Modified or new cron jobs:
crontab -l,ls /etc/cron.d/ - Files modified recently:
find / -mtime -1 -type f 2>/dev/null | head -50
Immediate Steps
- Isolate the server — add a UFW rule blocking all inbound except your IP:
ufw default deny incoming && ufw allow from YOUR_IP && ufw enable - Change all passwords immediately (SSH, control panel, databases, application accounts)
- Review running processes:
ps aux | sort -k3 -r | head -20 - Review recent logins:
last | head -30andgrep "Accepted" /var/log/auth.log | tail -30 - Check for unknown users:
cat /etc/passwd | grep -v nologin
Preserve Evidence (Optional)
tar -czf /tmp/evidence.tar.gz /var/log/ /etc/passwd /etc/cron.d/ /tmp/
scp root@server:/tmp/evidence.tar.gz ~/
Recovery
In most cases, the safest action is a full OS reinstall. You cannot fully trust a compromised system — the attacker may have installed kernel-level rootkits or backdoors you cannot see.
- Open a Technical Support ticket requesting an OS reinstall
- Restore your application from a clean backup made before the compromise
- Harden the server before going back online (SSH keys only, Fail2Ban, firewall rules)