WordPress Security: Which is more secure? A VPS or a VHost?

Posted on December 18, 2011 by mark

In web server admin parlance, a VPS is a Virtual Private Server and a VHost is a virtually hosted website. There were a few questions regarding security on VPS’s and VHosts in my previous post on “Seven ways I could hack into your WordPress website“, so I thought I’d clarify what the difference is between WordPress hosted on a Virtual Private Server (VPS) vs WordPress on a Virtual Host (VHost) and what the security implications are of each configuration.

A Virtually Hosted Website (VHost)

In the early days of the web, you would have a single physical machine running a single operating system running a single web server. That web server would serve up a single website.

HTTP 1.0 introduced the optional “Host:” header and HTTP 1.1 made it mandatory with any web request that a browser sends. The effect of this is that when a web browser sends a request to any web server, it lets the server know which website it wants to see. Because web servers know what website a browser expects, they can now host an unlimited number of websites. This is called virtual hosting.

When you have a virtually hosted website, you are sharing a single server and operating system with many other websites. Your files and the files of other websites are stored on the same operating system. You all share the same web server and the server chooses which of your websites it needs to serve based on what a web browser requests when it connects to that web server.

Usually on a virtually hosted website, you won’t have access to other website files and they won’t have access to yours. This is usually done by giving you a unique username that you use to sign in and your username only has permissions to view your files.

A Virtual Private Server (VPS)

A VPS is a little different. Normally when you install any operating system, you install it directly on a machine like a server or workstation. With a VPS, you first install a base operating system like Windows or Linux. Then you install a virtual machine hosting platform called a Hypervisor. Examples of Hypervisor’s are VMWare and Xen.

Within the Hypervisor you can then install multiple virtual machines. These pretend to be physical hardware and when you boot them up you get a BIOS message similar to when you boot up a physical machine.

Within these virtual machines you can then install an operating system like Linux or Windows. Using this config you can have potentially hundreds of virtual machines running on a single physical machine.

So to summarize, you have a physical machine running an operating which runs a hypervisor which runs multiple virtual machines and each virtual machine runs its own operating system. Within these operating systems you run your own web server, have the files for your website and do anything else you feel like doing. It’s impossible for someone on another virtual machine to access your virtual machine.

Linode is one of the most popular virtual machine hosting providers and they use the Xen Hypervisor to host Linux virtual machines.

So which is more secure?

By now you’ve probably already figured it out: Running your own virtual machine that is completely segmented from everyone else is usually the more secure option. Here are a few reasons why:

If your web host messed up the machine configuration or permissions, then other users may be able to access your files.
If another user’s WordPress installation gets hacked, it may be possible for the hacker to gain read or in rare cases read and write access to your files.

Another thing I like about having a VPS instead of a VHost is that you have your own IP address. On the Internet, IP addresses can get blacklisted, particularly if you’re sending email. If your web application sends email e.g. if you’re using the WordPress “Subscribe to Comments” plugin, then your emails may be flagged as spam if another user on the same server is sending a lot of spam.

With a VPS you have your own IP address, so as long as the IP address wasn’t already black-listed when you got it from your web host (I’ve seen it happen) then only you are responsible for how that IP address is perceived on the Net.

In conclusion: While VPS’s tend to cost slightly more (about $20/month from Linode), they are well worth the extra cost when it comes to protecting your website and your reputation. As always please post any questions in the comments and I’ll either answer them directly or in a future post.

Caveat: I have generalized greatly when it comes to VPS and VHost configurations. There are many variants including Type I and Type II Hypervisors, shared hosting where a single OS hosts one web server instance per website and many more. I’ve described two common VPS and VHost configs above for illustrative purposes, however the VPS config I describe is probably the most common configuration used by VPS providers.

Breaking: Google starts to block hacked WordPress blogs as attack widens

Posted on August 23, 2011 by mark

I’ve had two reports in the last 12 hours of WordPress blogs that were compromised via the Timthumb hack being listed as malware by Google. If you try to visit either site, you are confronted with the following:

These sites are listed with the warning that “This site may harm your computer” in Google’s search results and Google blocks access to the site with a warning forcing you to manually type the URL into your location bar if you really do want to visit the site:

One of the site owners sent me the detailed info that Google Webmaster Tools was giving her:

This malicious code is appearing intermittently on this author’s WordPress site. I’ve seen this same pattern recently in blogs I’ve repaired and the way it works is that the site is periodically downloading new PHP code from a remote site run by the attacker and re-injecting it into the wordpress code. That allows the attacker to add, remove and update whatever code he/she is executing on your blog. So they could for example update any spam links every few hours.

To prevent your site being listed as malware clean it as fast as possible

The fastest way to do this, although it doesn’t gaurantee a complete clean, is the following:

Remove all old plugins and themes you aren’t using.
Upgrade all your plugins and themes to the latest versions and make sure none of them use an old version of Timthumb.
Clean any Timthumb cache directories.
Upgrade your entire wordpress installation, even if it’s at the latest version. This overwrites all wordpress files.
Search your directory tree for any remaining suspicious files that contain base64_decode wrapped in an eval() statement or URL encoded data. More info on how to do this search here. Delete any files you find. NOTE: If you don’t find any additional infected files in this step, it’s highly likely that your site is not clean. Every attack that I’ve seen so far using Timthumb gets in by uploading a file into the cache directory and then uploads an additional file into a writeable directory on the blog to ensure continued access once the cache is cleaned. Make sure you find that additional file.
Make sure the only directory that is writeable in your wordpress installation is wp-content/. Directories like wp-admin and wp-includes should be read only by the web server.

If you are already listed as malware by Google, here is what to do

Clean your site using the above steps. You can find more suggestions on how to clean your site on this page.

The fastest way to get your site removed from Google’s malware list is to request a review through Google Webmaster Tools. You can find the help file on requesting a malware review on this page.

The process takes about 24 hours to get your site removed. You can find out more about Google’s Malware list and safe browsing report on this page.

Potential long term impact of this vulnerability

The fact that I’ve seen the same domain being used by attackers on multiple blogs suggests this attack may be partially or fully automated. The worst case scenario is that we end up with a WordPress botnet with thousands or tens of thousands of servers on high bandwidth links compromised and able to send spam emails or launch a huge DDoS attack.

Keep in mind that most botnets are compromised windows machines on relatively slow home broadband connections. Their uplink speeds are around 512kbps. These WordPress servers are on links that are a minimum of 10 Megabits per second each, so they have plenty of firepower for a coordinated attack. One WordPress server is equal to at least 20 infected PC’s in terms of pure bandwidth firepower.

Routers treat HTTPS and HTTP traffic differently

Posted on October 20, 2009 by mark

Well the title says it all. Internet routers live at Layer 3 [the Network Layer] of the OSI model which I’ve included to the left. HTTP and HTTPS live at Layer 7 (Application layer) of the OSI model, although some may argue HTTPS lives at Layer 6.

So how is it that Layer 3 devices like routers treat HTTPS traffic differently?

Because HTTPS servers set the DF or Do Not Fragment IP flag on packets and regular HTTP servers do not.

This matters because HTTP and HTTPS usually transfer a lot of data. That means that the packets are usually quite large and are often the maximum allowed size.

So if a server sends out a very big HTTP packet and it goes through a route on the network that does not allow packets that size, then the router in question simply breaks the packet up.

But if a server sends out a big HTTPS packet and it hits a route that doesn’t allow packets that size, the routers on that route can’t break the packet up. So they drop the packet and send back an ICMP message telling the machine that sent the big packet to adjust it’s MTU (maximum transfer unit) size and resend the packet. This is called Path MTU Discovery.

This can create some interesting problems that don’t exist with plain HTTP. For example, if your ops team has gotten a little overzealous with security and decided to filter out all ICMP traffic, your web server won’t receive any of those ICMP messages I’ve described above telling it to break up it’s packets and resend them. So large secure packets that usually are sent halfway through a secure HTTPS connection will just be dropped. So visitors to your website who are across network paths that need to have their packets broken up into smaller pieces will see half-loaded pages from the secure part of your site.

If you have the problem I’ve described above there are two solutions: If you’re a webmaster, make sure your web server can receive ICMP messages [You need to allow ICMP code 4 "Fragmentation needed and DF bit set"]. If you’re a web surfer (client) and are trying to access a secure site that has ICMP disabled, adjust your network card’s MTU to be smaller than the default (usually the default is 1500 for ethernet).

But the bottom line is that if everything else is working fine and you are having a problem sending or receiving HTTPS traffic, know that the big difference with HTTPS traffic over regular web traffic is that the packets can’t be broken up.

How to mirror someone elses web server with iptables

Posted on October 16, 2009 by mark

It took me a while to find this – I needed it for testing purposes, nothing malicious. If you’d like your web server somewhere on the web to pretend to be any other web server, even a secure one, you can do the following. x.x.x.x is your own server and y.y.y.y is the ip of the server you’re trying to mirror. I’m also assuming you only have one network card in the machine and it’s called eth0. The following will mirror a secure web server. If you’d like to mirror a regular web server, replace 443 with port 80.

iptables -t nat -A PREROUTING -p tcp -i eth0 -d x.x.x.x --dport 443 -j DNAT --to y.y.y.y
iptables -t nat -A POSTROUTING -p tcp -o eth0 -d y.y.y.y --dport 443 -j MASQUERADE

If this doesn’t work you probably have to enable packet forwarding like this:

echo 1 > /proc/sys/net/ipv4/ip_forward