I remember it like it was yesterday. I had taken my business from a couch on a Saturday afternoon with zero clients to a thriving business with over 150 monthly recurring accounts and growing. Life was good; business was thriving; and then it happened. There was a vulnerable plugin on one of my client’s sites and that was all that it took to have over half the sites on my dedicated server defaced with some elementary pixel art from Turkey.
The truth is that we are all vulnerable. The beauty of open source content management systems is that they are—how can I say this?—Free! Oh yeah, and the other benefit is that you don’t have to custom develop a feature for your client when they throw an “out of scope” request your way. You can go right over to the WordPress plugins repository, Joomla repo, or wherever your favorite CMS collects their library of community uploaded add-ons, and boom you have a feature for your client without any development sweat equity at all. Sure you may have to do a few minor CSS tweaks here and there, but you can have something that would have taken days or weeks to develop for free or a very low cost. Your client is happy and you look like a genius. That is until “D-Day” comes. “What is “D-Day” for us?” you ask. It is that day you wanted to take your kid to the park, had the whole day planned out, then you get the news from one client after another that they don’t speak Turkish so why is there weird music and links on their page? Ugh! Seriously?
If you have been in this business long enough and you do development on open source content management systems you have probably at one point or another dealt with a hack or like me in my beginning years a lot of hacks all at once. This brings us to the point of this post. I want to briefly look at the what, where, and how of a hack. Hopefully this will give you some insight on the before and after effects of a hack, and what you can do to put yourself in a better position as a website entrepreneur or as I have coined it, a “websitepreneur”.
What did these people from a far-away land do to my site in the first place?
The best thing you can do as a “websitepreneur” is to get familiar with the core code of your CMS. WordPress does not have nearly the amount of core files that you would see in Joomla, Drupal, or the heavyweight Magento, but no matter what your CMS choice is you need to get familiar with the core files. Every time I have had a hack I have logged in through SSH or even the file browser to look at the core files. Time stamps will be off, weird folders with either very close names to the original or ridiculously dumb names like “escorts-from-new-zealand”, or “pickles” will appear in the folder structure of your client’s teddy bear website. I mean why would teddy bears need escorts from New Zealand, right? These kinds of hacks are easy to find but can be a quite a challenge with the more file heavy CMS’s with folder structures that dive into dozens of layers deep.
There are some key indicators that I have found that are sure tell signs that you have been hacked. Most hackers do not deface your website. That is too obvious. The more popular hack is to hide somewhere in your site for years. They like to hijack your traffic and redirect them for profit. Here are some signs that you can look for that most likely point to hack activity.
If you are experiencing any of the symptoms above there is a good chance you have been hacked. Don’t ignore symptoms as they are pre cursors of uglier things to come if left ignored. A hacker if left in a shared un-protected environment (aka cheap hosting) can actually gain control of more than just one website. They can affect multiple sites or even the DB which can be catastrophic. (I have actually had to rebuild dozens of sites) Hint: Cheap hosting is not really cheaper in the long run.
Where is the vulnerability so I can close this dang thing?
You have determined that you have been hacked. Your client’s site is jacked and you have cleaned up the weird files that did not belong. You are not finished yet. Leave that baby unchanged for another day or two and your one friend from Turkey will bring some friends from countries you have never heard of before. There are actually websites out there that tell their peers when there is a vulnerability and your site or your whole server can be posted for all the hackers to use as a playground for all kinds of not so fun activities at your expense. Here are some ways you can pinpoint a hacker’s penetration point so that you can fix the hole they are coming in at.
How do I protect my sweat equity from getting jacked, I mean hacked, in the future?
There are really 2 things that contribute to most hacks. One is that your CMS is not keep up to date. The other is that you have an extension or plugin that is not up to date or that is not coded to spec for a secure environment. This means there are two things you can do to prevent a hack.
In some cases you inherit a website and are going to be the webmaster for a website that is not able to be upgraded. This hopefully is a temporary problem while you redesign something new and up to date but none the less you will at some point probably inherit an older CMS website that cannot be patched. I have found one thing that will save a world of hurt in this scenario and it is called Cloud Linux. You can cage each site separately so that one site does not drain all of your server’s resources. It may make the hacked site go down or perform poorly but it will not affect your other websites. Cloud Linux also prohibits hackers from gaining access to other sites on the same server all at once with root privileges.
Whenever I inherit old PHP driven CMS sites that cannot be updated right away I always place them on a box with Cloud Linux. After doing this for over 15 years I have found it to be the best tool against mass hacking out there for vulnerable un-patchable sites.
Not everyone enjoys confrontation. I certainly don’t. Even if you’re fine with confrontation you ideally don’t want to confront your client about the number of revisions they’re making or the additional work they’re adding to the scope of the project. Excessive revisions and scope creep can sometimes cause a little friction. Revisions If you’re working […]
