PetraSuper
Member
OP
network boot believer
- Joined:
- Jun 2024
- Posts:
- 127
- From:
- Bratislava, Slovakia
Celebration post, but also warning. Client on malý server at OVHcloud got full rootkit, injected into config after brute wp-admin. I spent 72 hours in forensic marathon. Found entry via plugin upload, pivot to user account, then on server as www-data. Cleaned manually, no restore from backup because backup was also compromised (hej, classic). Hardening applied: fail2ban tuned, wp file permissions locked, separate db user, removed xmlrpc, put wp-content outside web root. Client happy, paid invoice. No articles needed for good work.
Three weeks later same client emails: "into config again on new host". He reused same password from breach on Contabo account. No well.
boot anything, anywhere, anytime
SamAlvi
Member
Self-Host Everything
- Joined:
- Jun 2024
- Posts:
- 188
- From:
- Portland, US
I run twelve sites this way. Caddy handles automatic HTTPS, fail2ban in another container, and I snapshot the volumes before any update. The forensic marathon you describe is exactly what happens when you trust a provider to care about your security more than you do. Docker compose makes the whole stack reproducible. If a client of mine reused a password, I would rotate it automatically via my little ansible setup. Reverse proxy logs catch brute force before they reach the application. Just saying.
my cloud. my rules. my 3AM alerts.
kenji3
Member
- Joined:
- Jul 2024
- Posts:
- 138
- From:
- Osaka, JP
Separating wp-content from web root is excellent practice. I do similar setup in Singapore region with HostHatch, Asia-Pacific latency is good for my clients. Password reuse is common problem. I use Bitwarden for client credential sharing, though some resist. Your 72-hour effort deserves proper compensation.
conbini > datacenter snacks