Securing MediaWiki

Securing a MediaWiki-based Website

Please refer to the official MediaWiki documentation linked below - I'm not a security expert!

MediaWiki is an application written in php which runs on Linux/Unix servers, stores data in databases like MySql and MariaDB, and content is presented to users by web servers, typically Apache or Ngiinx.

This used to be referred to by an acronym LAMP - Linux, Apache, MySQL, and PHP.

It can also be used to visualize a stack where each of the above is a layer and data is transferred from the layer below and transferred to a layer above. This concept fits with the layers in the TCP/IP model, and theoretically also the OSI Model.

These models, and the layer concept, are also useful from the perspective of Security.

For hosted websites, physical security is obviously a responsibility of the hosting provider, and the advantage of using a hosting service is that we do not need to maintain and secure the operating system, or the web server application. So, to a great extent, two layers in the LAMP stack are secured by the hosting provider - Linux and Apache, or the operating system and web server.

However:-

The web server will allow anonymous users to view the contents of MediaWiki directories, unless prevented.
Anonymous users can create new user accounts, unless prevented.
Anonymous users, or those with self-created accounts, can add, alter or delete website content, unless prevented.
Anonymous users, or those with self-created accounts, can view website content which should be restricted, unless prevented.
A MediaWiki-based website could be used by malevolent actors to send spam and as a vehicle for other dangerous actions, unless prevented.

Responsibility for preventing these actions is our responsibility.

A Spam Example

One evening (a long time ago) I installed MediaWiki through a hosting service but didn't finish configuring it because it was late but didn't think that would matter.

The next day I received a phone call from the service provider to say that they had to shut my sites down because there was too much traffic.

I had made a simple mistake: the following lines should have been in LocalSettings.php:-

$wgGroupPermissions["*"]["createaccount"] = false;
$wgGroupPermissions["*"]["edit"] = false;

Bots obviously scan the Internet looking for vulnerabilities. My incomplete installation was found and probed. The absence of the above settings meant that anonymous users could create accounts. Lots of accounts were created, perhaps by a script. Those accounts were then used to send email. The emails were spam. The traffic volume grew to a level where it was noticed by the hosting service systems administrators. All within 12 hours!

Recent versions of MediaWiki may include the above settings in LocalSettings.php by default. But now it is the first thing I check when creating a new installation or implementing an upgrade.

Security Tools

Some of the tools available to us which can be used to secure a MediaWiki-based website include:-

The .htaccess file in the root directory. This provides instructions to the web server. There is another .htaccess file in the /w/images directory to prevent direct access.
Configuration in LocalSettings.php, such as defining user rights, access levels for user groups, and namespace permissions.
The extension Lockdown which provides more security than available using MediaWiki settings.
Securing the database settings and passwords.
Using strong passwords for access to the hosting service account, and the MediaWiki installation.

Security and the mh370wiki.net website

To my knowledge security on this website has not been compromised, but people try.

The most common attempts are visible by reviewing logs and the statistics pages provided within cPanel.

It is well known that administrative access to Wordpress sites is the URL domain name/wp-admin. A common search, which results in a 404 message, is the potential login page at the MH370 site/wp-admin. If successful this probe would inevitably lead to attempts to bypass the administrator password. These probes, and attempts to probe the site logins directly, are undoubtedly automated and malevolent, but not successful. See article HTTP Code 404

Backup

If the site security was breached, what is the worst that could happen? Beyond the spam example above, it would lead to a loss of trust in the integrity of the site content or database. I couldn't check every page. MediaWiki does allow for some changes to be rolled back. But my preferred option would be to delete the potentially corrupted database and connect to a previous version. For that, one would need a suitable backup. And therefore it makes sense to create regular database backups, and test them, so there is always a fall-back option.