When I mention I have clients with WordPress on IIS7 at the local WordPress Meetup (definitely go, well worth it), I invariably get snickers and disparaging comments. Some of that, especially from the less technical people, is just “Apache/MySQL/WordPress are Open Source”, and “big bad Microsoft is not as good”; it’s like cheering for your home sports team.
But the more technical people who have hosted WordPress for many clients, give different quality of answers.
I have a client hosting about 300 sites for Realtors. They brought me in to install WordPress in Multi-Site mode, for them to switch from their old ASP system to WordPress, and to then help them keep it running smoothly. Their IIS7 administrator was good at IIS but didn’t know WordPress or PHP, certainly not at the diagnostic and troubleshooting level.
Here’s the actual problems I have run into, over a few years of being their WordPress troubleshooter.
Linux and Apache vs. Windows and IIS
Linux (by far the most common operating system for web site hosting computers) and Apache (by far the most common web site hosting software, comes with Linux) and MySQL (the database that comes with Linux) are supported widely on web sites. You ask your search engine about an error message you get, or the tool you want, or the problem you’re having, and 15 of the top 17 sites listed will have the correct answer.
On IIS, those answers aren’t listed on hundreds of web pages. You’re not supposed to need them. You’re supposed to have taken the expensive Microsoft certification classes, have the manuals on paper and DVD, have the official troubleshooting tools and know how to use them. If you’re still stuck, you contact your Microsoft troubleshooter that you’ve paid for.
As a hosting client, you will either need to call your technical support to make the change to your IIS configuration, or you will hunt for months for a solution you can apply yourself. For something that, on Apache, you can fix yourself with a little learning in a few minutes from free resources.
Getting Help On Apache is Much Easier
WordPress Security on IIS vs Apache
I’m sure there are IIS security experts. IIS is used mainly on corporate web sites; they require experts on their security.
WordPress isn’t often hosted on IIS. WordPress has security issues that you aren’t going to see on web sites that are done by the one company, using only Microsoft tools for development.
Most web sites hosted on IIS have to deal with security holes in the operating system (whether Windows or Linux), on the web server (whether IIS or Apache), on the database (whether MSSQL or MySQL), and on the vulnerabilities in the development tools (e.g. the file uploader or the JavaScript form checking). But the site itself is written in house.
WordPress sites are developed using themes and plugins, mostly available open source for free. These plugins and themes are written by programmers who have unknown attention on security; every vulnerability in every plugin and theme offered on the WordPress repository, and every other well-known plugin or theme store, is known by hackers.
IIS security people are not used to thinking about security holes where every site owner can be installing plugins and themes that could unwittingly contain malware or insecure code.
One of the most common routes for hackers to install malware on your WordPress site, is to access a plugin that has file uploading, for example to upload images to a scrolling image slider. But instead of uploading an image, they upload a PHP program, or they upload it with a file extension saying it is (should be) an image and then rename it to a PHP program. The hackers know the folder their new file will be stored in; they can execute it any time.
There is a simple block for this — disallow execution of any PHP files, and since this is an IIS 7 server, any ASP files or C# files, in the wp-content/uploads folder. Really easy to implement, at the server level for all installations of WordPress on the server, once.
An IIS security person who knows he is “good at security” emailed me he’s not going to do that, “We need not invest any time going after problems that don’t threaten us. For instance, while the server supports ASP, there may currently be no ASP scripts on it, but there might sometime be, and blocking calls to scripts that don’t even exists serves no other purpose except to possibly cause excessive troubleshooting in the future when someone tries to put an ASP script on the server. Such a change would have zero positive effects, and potentially create negative consequences.” Do you notice that he isn’t thinking of hackers uploading a file? Even though the hack he just got hit by, uploaded .php files but could have uploaded .asp files. He still hasn’t blocked execution of PHP files in the wp-content/uploads folder!
IIS Administrators “know security” and have trouble adjusting their thinking to WordPress open-source plugin and theme attacks.
Leave a Reply