Quite a few of our clients run their websites on WordPress. Some we built ourselves years ago, others we took over. They sat with different hosting companies, on different versions, with dozens of plugins, some of which nobody had updated in years.
Then we brought them all in-house: one shared hosting setup on a more stable platform that we run ourselves.
The new hosting
- Code in git. Every website lives in a repository, and every deployment overwrites it completely. A file someone slipped in doesn’t survive the next deployment.
- No changes through the admin. Plugins and themes can’t be installed or updated from the website. Every change is a reviewed change to the code.
- Media on a CDN, and emails that don’t land in spam. Messages from contact forms are sent so that mail servers don’t treat them as forgeries.
Keeping websites from changing without review was meant to bring stability. The day after the move, a vulnerability showed us what it costs.
What went wrong
In the same few days the websites were moving to the new hosting, a critical vulnerability turned up in the core of WordPress itself. It let an attacker create an administrator account without a password. The WordPress team released a fix and pushed it to websites automatically.
It never reached ours. We had switched automatic updates off, because we didn’t want websites changing without review. That meant we had to deploy the fix ourselves, and we didn’t do it in time. Two websites were hacked, thousands of spam articles appeared on them, and it took us almost three weeks to notice.
- day 1Websites move to the new hosting1 day
- day 2Critical WordPress vulnerability published2 days
- day 4First attackalmost three weeks unnoticed
- day 23Hack discovered1 day
- day 24Fix on every website
We cleaned up both websites and restored them from backups to their original state. We deployed the fix to every website and checked that the attack no longer gets through.
All along, WordPress was reporting that a security fix was available. Nobody was reading it.
What we changed
The security these websites have today was only built after the hack was discovered. Because of it.
Updates as routine work. We prepare core security fixes every week, and plugin updates once a month, two weeks after their release. Always as a change somebody reviews.
The websites report in. Every website watches whether its core or plugins are out of date. A new account or an attempt to gain higher privileges is reported immediately. Everything else arrives once a week in one summary, not in ten emails a day that nobody reads.
Logins under lock and key. After repeated wrong passwords, login closes for half an hour. Anyone who can publish has to confirm their login with a code sent by email. A new administrator can’t be created through the website.
One website can’t endanger the rest. Each website has its own access to the database, so an attack on one can’t reach the other clients’ databases.
Less third-party code. We replaced the big plugins for SEO, security and media management with a little code of our own that does only what the websites actually used. The less third-party code, the fewer ways in.
A check from the outside. We have a tool that looks at the websites the way a visitor and a search engine do, and checks for spam, hidden links, or a page that shows Google something different from what people see.
What we took away
A website nobody looks at isn’t safe, even when it’s locked. A locked door is no use if even the fix can’t get through it. That’s why, for us, website maintenance doesn’t just mean hosting. Above all, it means somebody regularly looks at the websites.
We’re being upfront about this. The mistake was ours, not our clients’.