Studies show that, 26.4% of the internet is powered by WordPress. Now, that’s a big number, and a welcome news to many WordPress design and hosting companies. However, this popularity has given rise to a steep increase in attacks on WordPress websites. Are WordPress hosting companies prepared to defend attacks on such a large scale?
A case for secure WordPress hosting
In a previous post, we covered how to secure WordPress websites and hosting servers. A key take away from that post was to keep WordPress Core and plugins updated at all times. But, in real life, this seldom happens.
Webmasters often maintain multiple websites, some rarely used, and some actively used. Updates are usually applied on the actively used sites, while others are left un-patched. This opens a window for attackers to upload malware into the server.
In our server management services, malware infections are considered a tier 1 threat to server security. In many WordPress hosting servers, websites share the same network IP. If one site is infected, the malware can send out spam, or initiate outbound attacks, thereby disrupting business in all other sites. To prevent such business downtime, we scan the servers daily for vulnerable sites, apply patches, and keep the anti-malware firewalls updated.
Blessen Cherian
Member of Executive Group, Bobcares
Custom configured anti-malware firewalls (such as ModSecurity and NAXSI) can block almost all malware infections. But, it is not 100% fool proof. An attacker who has access to the webmaster’s login details (through phishing, drive-by-downloads, etc.), can easily access the website, and inject malicious code in it.
So, it is important to have another layer of defense to protect websites from the ill effects of malware infection in a single account. This is where a security concept called “security by isolation” is useful.
Using account isolation for security
In a shared server, all customers share the same resources, network services, web server, mail server and database server. So, a malware infection in one account can potentially disrupt the business in all other accounts.
Now, what if we can put each account into its own individual silos? What if there’s no sharing of resources or services among multiple accounts? – That is what’s meant by “security by isolation“. The damage in one account is contained to only that account. Others will be safe.
There are a couple of ways to achieve account isolation for WordPress hosting:
- Using Virtual Machines such as Xen, KVM, etc.
- Using container virtualization solutions such as OpenVZ, Docker, etc.
Account isolation using Virtual Machines
Getting a physical server for each customer would probably be the best way to ensure isolation, but that is a costly proposition. The next best way is to use Virtual Machines like Xen, KVM, or VMWare. Each customer is given a fully isolated server environment, with independent IP, services and operating system. There’s no way that a malware in one account can affect the operations in another.
However, even this solution is still a bit too costly for an average WordPress webmaster. Virtual Machines are resource intensive, and only about 20 customers can be accommodated in a server with 16 GB RAM, Quad core processor and 250 GB HDD. This is a pretty low account density for 1 physical server.
For a WordPress hosting solution to be viable, servers should have better account density.
Isolation through container virtualization
In Virtual Machine systems such as Xen or KVM, the resources are hard limited to each customer, and a full operating system runs out of a disk image. This severely limits how many VMs can run out of a single physical server.
An alternate solution is to use container virtualization (aka OS virutalization) systems like OpenVZ or Docker. These systems use a single operating system to serve all the customers, but file system restrictions are used to effectively isolate each customer. Since there’s no heavy virtualization overhead, up to 5 times more server density can be achieved in comparison to Xen or KVM.
For all practical purposes of regular WordPress hosting, a container virtualization system will work fine. But if security is a prime concern for your hosting service, there’s a weakness you need to be aware of:
In container virutalization, all accounts share the same kernel. So if an attacker can run a kernel exploit, data in the whole server can be accessed.
So, it begets the question – Is there a better way?
A better way – OS virtualization + Access control
In an OS virtualization solution, each customer gets “root” access to their “containers” (aka server instances). The issue with that is, customers tend to install packages without considering security aspects of it. Case in point, a security researcher was able to break out of a Docker container by installing a specially crafted app to run a kernel exploit. This could happen in any container system, if it is not properly secured.
The solution to this problem is to use Mandatory Access Control systems like SELinux or AppArmor.
Most container systems are not secure by default. An important part of our server management services is to periodically audit system permissions and restrict access where it is not needed. For this purpose, we use Access Control systems like SELinux and AppArmor. For eg. Docker containers can be made hack proof using custom SELinux rules.
Rai Dhaman
Sr. Systems Engineer, Bobcares
Setting up SELinux or AppArmor can be tricky in a virtualization system. Rigorous testing is needed when a new Access Control rule is added, or a new virtualization feature is released. For eg., a security rule written to prevent file modification by an external program can possibly block plugin updates via FTP.
To avoid such un-intended consequences, we rely on SELinux rules that’s tested by thousands of open source community developers. By customizing well tested rules, we minimize the risk of un-intended functionality restrictions.
Some virtualization solutions come with pre-packaged, well tested SELinux/AppArmor rule sets. One of them is OpenShift Origin.
Secure WordPress hosting using OpenShift Origin
OpenShift Origin is an open source virutalization system created by RedHat. It uses Docker as its virtualization platform, and employs SELinux to provide fool proof isolation. More importantly, the SELinux rules are rigorously tested by the open source community to not break any apps.
Built as a PaaS platform, OpenShift can be used as a secure WordPress hosting solution. However, the security settings in the default installation is not setup to accommodate every possible use case. The authorization configuration and package security still need to be taken care of, to keep the system safe.
WordPress hosting can include many hosting scenarios. There could be designers who must give access to different customers on multiple projects. A hosting provider should be able to accommodate this need. In our server management services, we setup special cluster policy rules, and local policy rules to prevent one user accessing another’s data.
Reeshma Mathews
Sr. Systems Engineer, Bobcares
Added to this, it is important to keep the packages up-to-date and patched to make sure the underlying system is secure in itself. Once all these security points are taken care of, OpenShift Origin can be a reliable platform to deliver secure WordPress hosting services.
In short..
The popularity of WordPress is growing by leaps and bounds. While it is music to the ears of WordPress service providers, it is important to note that exploit attempts against WordPress are also on the rise. Account isolation is an effective way in which WordPress hosting providers can deliver fool proof security to customers. Today we’ve covered how OpenShift Origin can be used as an account isolation solution, by virtue of its Docker virtualization and SELinux access control systems.
Bobcares helps web hosting companies deliver industry leading hosting features using tried and tested server architectures. If you’d like to know how to make your server infrastructure and technical support more efficient, we’d be happy to talk to you.
0 Comments