Imagine the panic that ensues when you or your client gets an alert from the web hosting company that their site has been hacked… trust me, it is not pretty. Unfortunately, this kind of issue is on the rise and the chances of becoming a victim could be greater than you might think. And even worse? Once it happens, at least in my experience, it seems more likely to happen to the same site again!
How Does This Happen?
Well, of course the obvious answer is that someone maliciously attacks your web site and messes it up. Yes, this is true. But the more important part of this question is really “How do we let our sites become more vulnerable to hacking?”. The simple answer to this question is that we spend a ton of time, energy and money creating the initial build of a web site. Hours and hours can go in to even the most minute decisions regarding visual design, responsive coding, site architecture, imagery, content, landing pages, etc. That is fantastic. A site design or redesign absolutely should command this type of attention. It is what happens after this build has gone live that leads to vulnerabilities.
Many, many organizations of all types and sizes only pay attention to their web sites during the design or redesign process and not very much in between. I totally get why this happens – especially in organizations that don’t have an internal team dedicated to the upkeep of the web site. If the site is running fine and doing what it needs to do, it is easy to ignore it.
A Typical Scenario
A brand new web site is deployed in a content management system (CMS) like WordPress or Drupal. When it is built, the site is constructed with the latest versions of the CMS and any plugins or modules used in the site. The hosting package has the site on servers running the most up to date versions of the Linux operating system and the most up to date version of PHP. Awesome.
Time goes by and the site is updated – that is the content is updated. The CMS, modules and plugins often are not. The site sites blissfully on the web host’s server as the OS and versions of PHP are not updated. Nothing bad happens. The site functions just fine. Everyone involved is lulled into a sense of contented complacency.
Until… the site gets hacked.
The web host may or may not suspend the site until the files can be cleaned up. You may or may not even be able to access the site without spending a very long time on the phone with the hosting company to get permissions restored to even be able to connect in to your site’s files to clean them up. Depending on the availability of your site development resources, they might be able to drop everything and help resolve the situation ASAP or they might not. Regardless of exactly how it plays out, there is an awful lot of agida for all parties involved.
How To Prevent A Hacking
No strategy is going to be 100% foolproof, but there are some simple things you and your clients can to do make their sites much less likely to be hacked:
- Regularly backup the entire site
- Monitor the site regularly for anything that seems off
- Check the backend of the site for available updates for the CMS, modules and plugins and APPLY THE UPDATES
- Work with your hosting company to be sure that your site is hosted on a server that is also up to date
- Plan to upgrade your site to the latest version of your chosen CMS at an interval of no longer than 3 years
- Don’t let your site just keep going running CMS versions that are not actively supported for any significant period of time
- Consider a subscription to a web site monitoring service that also offers hack clean up (like Sucuri)
I understand how if a site is functioning well an organization will not be motivated to necessarily dump resources into it to bring it up to the latest versions of a CMS. I am also not a huge fan of being really early adopters of new versions of a CMS (or OS for that matter). I do like to let others find the inevitable bugs and have them fixed by a few update versions before I would be ready to advise a client to dive in. But, it is essential that all organizations budget funds for proper web site maintenance on an annual basis. To not do so is to flirt with disaster. And, having to reactively fix a hack is not cheap. Depending on your host, the effects could last even longer. Worse still? Your site could show up in search results with a warning that the site has been hacked/compromised. Yikes!
It might not be the sexiest of topics to broach with clients or your boss if you’re in charge or your organization’s web site, but it is so important! Don’t wait until you’re in a crisis to have a hacking prevention plan in place. As with most things, being proactive is a way better path to follow!
What about you – have any of your sites or your clients’ sites been hacked? How did you handle it? What were the consequences? As always, sound off in the comments or hit my up on Twitter (@NeptuneMoon).
NOTE: Yes, I do find it a bit ironic that I am writing a post about hacking two weeks in a row!