Read-only hosting: the simple rule that stops webshell attacks

Part 2 of 5 in Secure by Design, our series on how we build, host and maintain websites that stay stable and secure.

Ask most people how a website gets hacked and they'll say someone guessed the password. That does happen, but it's rarely what we find when we're called in to clean up a compromised WordPress, Drupal or Joomla site. What we usually find is a webshell: a small file the attacker slipped onto the server that lets them back in whenever they like, no password required.

This article covers how webshells get there, why they're so hard to remove, and why the hosting platform we run our clients' sites on doesn't give them anywhere to go.

Sometimes it's obvious. Google starts listing pages on your domain that you never created. A customer rings to say their browser flagged your site as dangerous. Your host emails to say your server is sending spam.

Sometimes there's nothing to see. The webshell sits there for months, copying whatever your customers type into your site: logins, enquiry forms, contact details. At that point it's not a clean-up job any more, it's a data breach. Depending on your organisation, it may also be reportable under Australia's Notifiable Data Breaches scheme.

Clean-up is rarely a matter of deleting one file. Attackers who get in usually leave several backdoors in different folders, so that removing the obvious one doesn't lock them out. Miss one and the site is reinfected within days.

The way in is usually a known flaw in open-source code the site depends on: a WordPress plugin or theme, a Drupal module, or a PHP library inside a custom build. Often it's one that has been waiting for an update for a while.

Open-source code is public, so attackers can read it looking for flaws, and one bug in a popular plugin can expose thousands of sites at once. Fixes tend to arrive quickly for the same reason. But a fix only helps the sites that install it.

When an attacker finds a site still running the vulnerable version, they use the flaw to write a webshell onto the server. After that they don't need the flaw any more. They have their own way in.

This works because most CMS hosting lets the website write files into its own code folders. That's how WordPress installs plugins and applies updates from the admin area. It's convenient, and it's exactly the access an attacker needs.

On a read-only filesystem, the website's code can't be changed while the site is running. Not by the CMS, not by a plugin, and not by an attacker who has found a flaw in either. The code that's running is the code we reviewed and deployed, and the only way to change it is to deploy a new version.

Your site still works as normal. Pages load, forms submit, and editors can upload images and PDFs. Uploads go into separate storage that's configured so the server won't execute anything in it. If someone does get a malicious PHP file into the uploads folder, it just sits there as an inert file.

So an attacker can find a flaw, and may even exploit it, but there's nowhere to write the webshell which could cause additional damage through the modification of your code.

Our hosting platform treats every deployment as fixed. Code is built and tested before it goes live, through the same reviewed process we use for Composer-pinned updates, and nothing can modify it after that.

This isn't a checkbox someone has to remember to tick on each project, or that gets switched off six months later when someone's in a hurry. The platform simply doesn't have a writable code folder.

• Uploads, forms and caching work as normal, using separate storage that can't run code
• A vulnerability that would normally lead to a webshell has nowhere to write one
• Every deployment replaces the code with a clean, reviewed copy
• No unexplained files turning up in your site's folders

Read-only hosting closes off file-based backdoors. It doesn't fix the vulnerability itself, and it doesn't cover everything an attacker might try.

Someone who exploits a flaw can still go after the database, for example by creating a rogue admin account or potentially even injecting a malicious script into content stored there. A read-only filesystem won't stop that, and redeploying the code won't undo it. That's why we still patch quickly, using the update process from our first article, and keep watch for newly disclosed vulnerabilities in the software our clients run. AI is shrinking the time between a flaw being found and being exploited, which we cover in our next article (coming soon).

Every site we host also sits behind Cloudflare, which blocks a lot of malicious traffic before it reaches the server. More on that in a later article (coming soon).

Every site on our Enterprise-grade hosting platform gets this protection as standard. Combined with pinned, reviewed updates, it's a very different setup from typical hosting, where the site can rewrite its own code at any time.

If you don't know what would stop someone planting a webshell on your current site, get in touch with our Brisbane team and we'll take a look.

What is a webshell?

A webshell is a small file an attacker places on a web server so they can keep controlling the site remotely. Once it's there, they don't need a password or the original vulnerability to get back in.

How do I know if my website has been hacked?

Look for pages in Google's results for your site that you didn't create, browser security warnings, admin accounts you don't recognise, or your host reporting spam from your server. Many compromised sites show none of these, which is why prevention matters more than detection.

What is read-only hosting?

Read-only hosting means the website's code can't be modified while it's running. Changes only arrive through a reviewed deployment, so an attacker who finds a flaw has nowhere to write a backdoor.

Can a website still accept uploads on read-only hosting?

Yes. Uploads go to separate storage that the server won't execute code from, so a malicious file uploaded there can't run.

Does read-only hosting stop every attack?

No. It stops file-based backdoors like webshells. Attacks on the database, or on a flaw before it's patched, still need fast updates and other layers such as a web application firewall.

Is shared hosting less secure?

Not always, but it usually lets the site write to its own code folders, which is what webshell attacks rely on. On that kind of hosting, security depends almost entirely on every plugin being patched before an attacker finds it.

Keep reading: Why AI-powered vulnerability scanning means open source updates can't wait (coming soon)