Hacking any system requires effort, whether it’s a website or nuclear reactor facility. What makes targets attractive to hackers is often a mixture of prestige, accomplishment and financial motivation. When it comes to your open-source projects, the chances are you aren’t working on anything as prestigious as Facebook or something that would have the same financial rewards as hacking HSBC bank, but you would be considered a much easier target and therefore attractive on the basis that your foundation code is open-source. This in itself means that website developers and designers who rely on open-source systems like WordPress, Joomla and Drupal need to be more cautious and aware of security issues that may have otherwise gone unnoticed in closed-source and bespoke systems.
Attacking an open-source system is much easier than many would think. Many professional hackers specialise in targeting open-source systems, with many of these specialists in targeting just a handful of the more popular systems. Once an open-source project reaches a critical mass of users, it becomes viable for the more criminally inclined hackers with a financial motivation to develop specialised methods and tools to target websites based on a specific set of open-source code. The diagram to the right shows how a hacker may develop their malicious code:
The solution to the security problem is to take pre-emptive steps to stop any potential vulnerability from succeeding. This article shows the steps you can take to make your open-source systems more secure – regardless of whether you are a WordPress tinkerer with no programming skills or an experienced programmer developing open-source plug-ins of your own.
For the most part, the majority of security issues can be avoided or resolved with simple measures without the need for programming knowledge. With suggestions from Debs Williams, freelance Internet marketer at debbidoo (www.debbidoo.com) and a perfect example of how a non-developer can take measures to ensure security of WordPress websites, we look at what you can do to improve the security of your WordPress and other open-source systems without programming skills.
A GOOD WEB HOST
Whether you consider yourself to be an expert or are new to creating websites, having the support of your hosting company and their ability to get things right first time will avoid many security issues happening in the first place. Premium level support comes at a cost, so consider this carefully before opting for the cheapest web host you can find.
Williams tells how a previous host may have been a key contributing factor to a WordPress website that was repeatedly hacked. “I hadn’t used the host before and haven’t used them since. I tried to visit the website one day, and there was a browser message saying the website was dangerous and had been blocked. Although they identified and removed some dodgy files that were placed on the server, the same issue kept happening several times – what the cause was is unknown, but what I can say is that I’ve since hosted WordPress sites with at least three other hosts and have had no security issues whatsoever.” Although the cause of Williams’ issue could have been anything, the chances are it was down to an unsafe plug-in or theme used in the website – something that the right server settings can stop.
Another downside to cheaper web hosting is that they use shared servers with other websites. This is in order to reduce their individual hosting costs and can have some negative consequences for the security of your site. The majority of risks associated with shared hosting can be eliminated simply by ensuring you have the right setup, which is dependent on the technical skills and competency of your host’s server administration team. Issues relating to shared hosting that you need to make sure are addressed by the chosen host include:
- Ability of scripts to access hosting space outside of their own domain.
- This vulnerability would allow a malicious script or plug-in installed by another website owner using your server to affect your website, by simply finding your website location on the server and writing copies of its code to your hosting space – and even into your WordPress scripts.
- The same vulnerability would also allow a malicious user of the server to scan and access your web hosting files. This could allow them to steal anything you are hosting, including documents and code files that have access to details of your database.
- Access to your database.
- It could be a brute force attack or by using details stolen directly from your PHP scripts, but either way, other websites on your server can access your database if they are able to acquire the database username and password.
- Email access.
- A server that hasn’t been configured to stop users accessing areas they shouldn’t also means that malicious users and scripts can access emails stored on the server, which includes yours. You could eliminate this risk by using a third-party email service provider such as Google, who offer a much better interface and more email storage.
- Email sending.
- Another risk concerning email is that malicious scripts that have access to your site can send spam email. This could be as a result of code being installed onto your hosting space or another website on the server sending spam. Either way, because your website shares the same IP address, the chances are that your genuine emails will often get marked as spam by email providers such as Hotmail and Google, because the IP address of your server has been blacklisted. Before signing up to any shared hosting, this is a question you should put forward to your host.
CUSTOM TABLE PREFIXES
WordPress has a useful feature as part of its installation process that allows you to define prefixes for the database table names it uses. This feature is in WordPress to allow your installations to share a database with other apps and bespoke code you have developed, but is also very useful to use from a security perspective. As described at the start, your web apps become better protected against malicious code the more they are altered. Simply changing the default database table prefix from ‘wp_’ to something like ‘myBlog1701_’ means that it will be harder for malicious code designed to attack your WordPress database installation to succeed; although keep in mind that this will only make it harder for the hacker and will not stop well-written malicious code from succeeding.
For those of you considering using this for existing WordPress installations, you can manually update your database table names from PHP MyAdmin, and then update your WordPress configuration file (wp-config.php) from your WordPress installation directory. Search for the following in wp-config.php:
001 $table_prefix = ‘wp_’;
… and replace with:
001 $table_prefix = ‘[Your prefix here]_’;
Other open-source systems that have been coded to a good enough standard will have similar settings – whether it’s like WordPress, in which table prefixes can be defined by accessing the backend system settings, or where the system itself can define fully bespoke table names for everything it needs.
The default WordPress database table prefix is wp_. Changing the prefix to a custom option makes it harder to hack
SECURE YOUR PASSWORDS
A mistake that’s often made is the use of easy to guess passwords. Whether it’s for a database connection or access to your admin area, hackers can easily crack passwords by brute force in which they use a dictionary of the most commonly used passwords. This method of breaking into your
database or admin area can be fully automated, meaning that a hacker needs only to spend a minimal amount of time to activate their attack and wait to see the results.
For your admin area account login(s), use passwords that combine numbers that are unique to you and can’t be guessed, but at the same time are memorable to you. An example could be:
- Current Date + Pet Name + Last 3 Telephone digits = 230412Tigger389
For actual database connection accounts, you want to use something that’s even more secure than the above – this is the database access your code will use when accessing your database, so memorability for frequent use isn’t as important. For better security, use a hash generator to encrypt a chosen password, which will ensure that it can’t be guessed. Try www.md5hashgenerator.com to create a hashed version of the password we have created above:
- Original Password: 230412Tigger389
- Hashed Password: 82b78173308696c7141a972e4deb3641
To properly secure your password, an original password that is secure is still required to ensure hackers can’t guess your hashed password by using a database of weak passwords to generate their MD5 equivalent.