Tag: archive

Dissection of a WordPress hack.

Dissection of a WordPress hack.

Today on episode 17 of Web Hosting Podcast, Megan and I, dissect a website hack we have been working on. We discuss the how, the what and ways to prevent future hacks. We also discuss the defacement of webhostingpodcast.com and how I recovered the site so quickly. And remember those quick tips I use to run? They are coming back in a new way!

Podcast phone line 971 249 2359 is manned by me on Thursdays 9AM PST – 12PM PST. Feel free to call in and press (2) to reach me directly during those hours. If you want to just leave me a message anytime, press (1) and it will send you directly to a voicemail box.

Dissection of a WordPress hack we have been dealing with, the topics we cover are.

How we think it happened.
How we cleaned it up.
What could have prevented it.

Info on what we found from sucuri, regarding this specific website hack.

You will find the plugin I used to find that the wordpress core files had been modified. This plugin is since abandoned by automattic (the makers of wordpress, woocommerce and jetpack to name a few) but it can still be used. You need to download the hash file for the version of wordpress you are using. I would just like to point out that other external and filesystem based scans did NOT find this hack. Only by careful examination of the output of the exploit scanner were we able to find the source of this hack. It is no longer enough to just scan with one tool and think the site is clean. I recommend that you scan with multiple sources if you think you have been hacked, or if a hack keeps coming back after being cleaned. I also, and I can not stress this enough, recommend a daily backup of your website. There are many tools out there that will help you obtain a regular backup to a external location, such as dropbox, s3, ftp, or google drive. There is no reason to not have this setup for your site.

This is the plugin linkĀ 
And this is the location of the hash file on github.

Disaster plan or success planning your website.

Disaster plan or success planning your website.

Do you have a web site disaster plan in order?
I am betting you likely don’t.

Why is a disaster plan important?

The unknown is ever present in the world of technology. With the rise of malware and CPU defects, the chances of your site going down by unseen forces is getting higher every day. You literally could wake up one morning and your site is no longer online, or worse it is being held for ransom. Add into the mix the number of web hosting companies that go out of business or are sold to another company. If you don’t have a worse case disaster plan in place, it is my opinion you are not doing yourself any favors. It is very easy to put together and can be accomplished by anyone. This would be like having an emergency go bag if you live in a earthquake zone.

What are some key things you need to have on your disaster plan?

Login details for your Domain and where it is registered (username, password, phone number and support email address).
It may or may not be registered with the same company that hosts your website. I would make a document that includes your login details, contact phone number and support email address. Put this along with the others we will be covering into a envelope and seal it, then put that in a safe place.

Login details for your hosting account (username, password, phone number and support email address).
This is the location where your website is actually being served from. Put this information in the same envelope as the rest of the ones we are covering. It is also important to have a phone number and support email address along with your login details.

A current backup or archive.
We have discussed this several times on this podcast. You should have a current backup or archive you can work with of at least your website, and possibly of your whole hosting account. If you have been backing up externally or manually copying to a local disk drive, put this information and location of the backup in the envelope with the other information.

Now that you have your login details sorted out, you need to have some basic DNS information. I personally like to have a complete zone listing of all of my DNS entries. These are things like;

  • What are my nameservers and where are they pointing? Nameservers are vital to knowing where your zone record is being kept. If your nameservers vanish, your domain vanishes from the internet.
  • Where does www and yourdomain.com point to?
  • What are my MX records?
  • Do I have a custom record that is used for connecting to my mail server? For example, do you use mail.yourdomain.com and if so where is it pointing too?
  • Are there any other records I need for my site to be online? Custom records for a cdn, custom txt records that have been added, SPF records? There are many types of records that can be added to DNS. Some of them are for email, some are for proving you own a domain (google validation comes to mind). All records should be tracked and kept with your disaster plan records. You never know when you may need to recreate a zone entry.

 

Success plan not unlike the disaster plan.

What happens if your site starts getting a large amount of traffic. Good for you, bad for your hosting company if your on shared hosting. I have seen this type of thing happen time and time again. A article you may have written, or a product you are offering gets picked up by national news or celebrity likes your product. This is great news for you, but this can often result in your site going down or even being taken offline by your hosting company. How do you deal with a “scuccess” hit often involves the same things as a disaster plan. You may find yourself needing to move to a new host rather rapidly. Have those contact information and login details at the ready in your disaster plan packet. Lets just call this the “What if” packet.

If you are just experiencing some temporary increased traffic, meaning you don’t think it will last for very long as the hype dies down. There are a few steps you can do to help with the site traffic increase, which will likely help with server load.

  1. Use a caching service like cloudflare. We have discussed this in the past. Basic cloudflare services are free and it only takes a minute to setup. This will act as a buffer between your host and the people trying to access your site.
  2. Make sure you use expires and headers so files are cached. Another topic we have discussed in the first episode.
  3. Make sure you are compressing the site files with mod_deflate. See episode 1 for more details. Or listen to the end of this episode for the quick tip.
  4. Enable a caching plugin in your framework. Something like wp super cache or w3 total cache for wordpress will save you a lot of headaches with a sudden spike in site traffic. This will also lower server load by reducing the mysql queries required to load your site by making some of the site pages almost static in nature. This will in turn keep your host happy. This is not the same as cloudflare caching service.
  5. Serve a static site during the increase in traffic. This one is a little more tricky, but it is definitely possible. By removing the need to have mysql and php render pages, your site will load faster and have almost zero load on the server. This requires planning ahead however and having static pages ready to go.
  6. Work with your hosting provider to see if you can to keep your site online. If they are less than helpful, then reach out to the world and get a recommendation for a new host. A good host will want you to grow and be a part of your growth process. If they just suspend your account because you are successful suddenly, then they are impeding your growth and should be removed from the equation. If the host offers some suggestions to you, no matter if they sound complicated, and want to work with you in providing even a temporary solution to the situation, then you should listen and see if they can help.

Things to NOT do. Do not allow your host to move you to a tiny VPS of your own. This is the number one thing I see and it will kill your site, but save your hosts butt. If your site is already creating a problem on a very large shared servers with possibly many CPU cores and many Gigs of ram, what good is moving you to a 1 core and 1 gig of ram VPS going to do. They just want you off their shared server as fast as they can, they are not offering a solution but passing the buck to you and making a few bucks in the process. You site will never stay online in a small VPS unless you have someone that you can call on to make massive tweaks to the VPS itself, install specific software and configure it, this often requires a system administrator/engineer to do.

Do NOT try and block the inbound traffic that is being generated, this includes changing the URL, blocking IPs in .htaccess or server firewall. You want that traffic to come in, if there are elements on that page that require external resources, like a facebook or twitter feed, remove that code during the spike in traffic. These can potentially slow down your page speed.

The biggest take away I want to share with everyone is to be proactive and not reactive. Whether it is a disaster plan or a success plan, the “what if” scenario should be on the minds of everyone. And if you are not ready for it, it can be devastating to your site, your finances and even your emotional state. Like any other disaster preparedness scenario, regaining control of the situation as fast as possible will allow you to continue on with your life. It will remove stress and worry. If you get an email from your hosting provider saying, “your site has been shutdown because….” you will know how to proceed because of your planning. Take some time out of your busy week and determine the best way to handle your “what if” scenario, it will make your life a lot better. If you have already put together a “what if” packet, then please share your experience and tips you may have with me. I would love to hear about them.

Quick tip today is gzip compression in cPanel, you can also see a video I did on this here.

Backup and Archive your website in preparation of the New Year.

Backup and Archive your website in preparation of the New Year.

Backup and Archive your website in preparation of the New Year.

What is the difference between a Backup and a Archive?

A backup is for short term recovery. This means a backup is likely a more current snapshot in time. Often a backup will be done daily/weekly/monthly. You should be able to restore your site from any of these backups. But what happens if the backup is corrupt, or your site is hacked and has been hacked for a while? This is where a Archive comes in. A archive, to me, is a snapshot in time of your site that you are comfortable and capable of starting from.

Example: You have a site or a blog, you do a weekly and monthly backup. You find out that it has been hacked and has hundreds of files that contain malicious code. You can spend all of your time, and possibly a large amount of money cleaning the site up. Or you could restore from a backup, but what if your backup also contains the hacked code? Maybe your site has been hacked for more than a month. Now those backups will likely not do you much good or save you time and ultimately money. A archive is what you will need to restore from. A snapshot in time, where you know your site is clean and functional and can also be rebuilt from. It is a starting point that you are comfortable with. it may not be a ideal situation to have to do, but at least you know you can do it. The alternative is to possibly spend hundreds of hours and maybe thousands of dollars with a developer or systems administrator cleaning up your now hacked site. It is possible that starting from the archive will be the quickest and safest path. If you do decide to restore from a archive, and it is because of a hack, be sure that you update everything and if possible determine how the hack originated. It would not hurt to change passwords and follow standard procedures for dealing with a hack, see episode 7 Web Hosting Podcast.

Backups in cPanel are created using a .tar.gz file format.

What is a .tar.gz file?
The .tar in the filename stands for Tape Archive. The .gz is a compression method known as GZIP. These can be opened with standard Windows, Mac and Linux applications. The first thing it will do is unzip the file, or decompress it. This will then leave a .tar file. This can then be extracted to get the contents of the full archive.

Generating a full backup through cPanel will generate a .tar.gz file in your chosen destination. To do this, login to cPanel and search for backup. This will show you either, backup or backup wizard. If you want a step by step process, use the wizard. If you want specific files then choose backup. They both will ultimately give you the same thing. If you choose to create your backup file in your home directory, be aware that this could take your account over quota and start breaking things rather quickly. Other options for backup destinations are FTP and SCP. You can also choose to download a current near line backup, which will download to the Downloads folder set by your web browser. If you plan to make a archive, be sure to generate a new full backup of your entire home directory. This will include mysql databases, email and your website directories.

Other things that are good to do at the start or end of a year?

Verify your whois data is current. This should be done regularly and is required by domain owners. Whois data is maintained through the company you registered the domain with.

Determine if there are domains that you no longer wish to keep before they are renewed. I find myself over the year purchasing domains for ideas I may have. Some of these ideas never see the light of day and become abandoned. This is a good time to determine if you wish to proceed with keeping these domains and websites going. This can save you a bit of money if you no longer wish to keep them going.

Do you have specific things you do to bring in the New Year for your website? I would love to hear what they are and discuss them on a future podcast episode. Contact me through the contact form.

In our quick tip, autoresponders for email.