This is an obvious prevention, but generally overlooked by most people. A majority of customers we speak to that have been victim to a hack, previously have had no security products installed on their machines and those that do more often than not, are installed out of the box, barely configured, forgotten about and seldom updated.
If you don’t have a decent virus/malware product installed on your desktop. Make an informed purchase by discussing your specific needs with various vendors. Ensure that it’s set to automatically scan your machine each day. Ensure that at least each week it connects to the vendor’s site and updates itself with new libraries of virus and malware definitions.
If you want to get bonus points, install software that allows you to monitor your network traffic and where you see odd outgoing requests, investigate. Your machine should never be contacting the outside world without you either expressly taking an action, or setting up something like a regular download of new virus definitions. If your machine is randomly connecting to addresses or sites you know nothing about, then “Houston we have a problem!”
Step 2: Rotate FTP passwords:
File Transfer Protocol (FTP) provides full access to your files on the server. Like all passwords, you should not set these and forget about them. They should be updated regularly. We recommend monthly if you access your FTP regularly but if you access it less frequently it should be okay. If you’ve never changed passwords, we suggest that you update it now! You should also have a reasonable password policy.
• DO NOT use the same passwords for everything
• DO NOT use dictionary words, or people names
• DO NOT re-use the same passwords. Once used and rolled, discard!
• DO use a random password generator
• DO use minimum of 8 characters
• DO use a combination of uppercase, lowercase, numbers and symbols.
Step 3: Rotate database passwords:
Your database password is what allows your website to access your database. It’s not as critical as rolling the admin password for your application or FTP details, but it’s still an important part of a well-managed password policy. We recommend bi-monthly Password changes on this, though you may want to look more or less depending on specific circumstances.
The most likely scenario if database access is compromised, is that a bad guy could create a new admin user for your site, delete your database completely, or modify content that is stored and served from the database. If you do change this password via a management interface like the Webgyan Console or c Panel you need to remember that your website has to have the new password configured into it. Generally you’ll have an interface for this, or some applications require you to edit a text based Configuration file on the server. It sounds complicated, but once you know your way around, it’s a 5 minute task.
Step 4: Remove access details:
If you took your car to the mechanic and left the spare keys so they can work on it, you wouldn’t leave them the keys after you pick it up. Why would you leave full access to your site once work or changes are completed?
You should hand access details out strictly on a required use basis. Once the work is done go through Steps 2, 3 and 14. If you have given domain level console access, also go through Step 5.
Some of you don’t outsource your development work and have dedicated IT staff. Any time a staff member with a specific level of access leaves, you should reset those details immediately. Remember, you are doing this not because they may deliberately do something nasty, in fact that’s generally unlikely, but as a precaution in case at some point in the future their computer was exploited or compromised.
We backup data so that in the case of a disaster we are able to get all customers back online.
Step 5: Rotate ‘TheConsole’ (or cPanel) passwords:
This is a very easy step. Simply follow the instructions to reset your control panel passwords. Use the same common sense as described in Step 2 to set a more difficult password.
Step 6: Subscribe to external monitoring:
This is like an insurance policy. Companies like Secure do a Range of really neat things for you. They’ll scan your site each day, and immediately alert you if you’ve been compromised. They offer services where they will clean your site if you do get Compromised and you need immediate help. If you are using WordPress, they’ll do preventative monitoring for you, so you are alerted to updates in the application, plug-ins, themes and the like.
Step 7: Backup of web files:
There is a notion that your hosting provider will have backups ready and waiting for you to access and can immediately recover all your lost data, without any charge. Generally speaking hosting providers don’t do backups for the reason you think. We backup data so that in the case of a disaster we are able to get all customers back online. The backup sizes we deal with are in the many many Terra bytes. So I recommend in the strongest possible terms to BACKUP!
It’s a simple task, that will save you from a lot of headaches later. There are even applications available that are able to backup. Backing up doesn’t have to happen everyday, but with a busy site, weekly backups should be part of your strategy. For websites that are static and changes very rarely, monthly backups are more appropriate. No matter what schedule you decide to follow, if bad things happen, you will at least have a copy of your site and you can easily re-publish quickly, without hassle and at no charge. So what are you waiting for? If you’ve never backed up, do it now, then come back!
Step 8:Backup of database:
This is simply an extension of Step 7. If you have a site that signs up new users, for example an e-commerce website that requires shoppers to register before purchase; you most likely market to them, run a loyalty program or have some kind of reward scheme. What would happen if all that data was deleted? If you have a busy site, you may decide weekly is too infrequent and decide to archive a copy of your database daily.
Again there are many tools available that will do this for you automatically, especially if you are using very common database technology like MySQL. Restoring from a self-generated backup is a 5 minute job. Getting your hosting provider to trawl through archives and do a restoration for you will leave you off the air for multiple hours in a best-case scenario.
Step 9:Review software for patches:
You should pro-actively keep your website up to date as best as is possible. This one would seem self-explanatory but it’s probably the most common way for a site to get exploited and is largely ignored. It’s safe to say that most people tend to forget to update their website, with the usual process of having your website built be a developer, which they then handover to you and that would be the last time the site is updated. Ever.
We routinely see CMS or e-Commerce sites that have not been updated for 3+ years, and often 5 years. So by the time a piece of software is 3 years old, it’s generally ancient. If it’s then compromised, fixing it becomes 10x more complicated, as there isn’t a straight-forward upgrade path from the version you are on, to the latest. It is therefore, not just a simple patch install instead trying to re-engineer the whole thing, while your site
is offline, and you are losing money. This becomes a very bad thing. Most software companies have mailing lists that you can subscribe to and they notify you each time security vulnerabilities are discovered, new patches and new versions and the like are available.
Step 10:Review installed add-ons:
An extension of Step 10. Again a very common scenario we see, is a site owner or manager thinks they are doing everything right by updating the core site software. But they forget all about the add-on modules that have been installed. It’s a bit like leaving the house, and locking the doors, but leaving the windows wide open.
Step 11:Review any installed templates or themes:
Same as Step 11. Again very often over looked and another common way to exploit your site.
Step 12:Rotate site admin passwords:
It’s always important to change the admin password for your site regularly. Some hackers will create themselves a new admin account and use that to do harm to your website. Check regularly for any accounts that you haven’t created, especially those that have admin privileges.
Step 13:Review logs & scan for high traffic:
A common method for hackers gaining access to the admin section on your site is to write a program that tries to log in using a list of commonly used admin passwords. Many people don’t ever change the default install password, ‘password’, or ‘default’, or cunningly change it to something like ‘password123’. You can see where this is going.
Lets say your admin site is at the address, test.com. In your raw server logs, if you see large numbers of visitors to that page, especially from single IP addresses, then it is safe to assume that people have or are trying to do bad things.
The method used in Step 13, can assist here. As can putting your admin section of the site, if possible, into a directory that isn’t called ‘admin’. These little things can be very helpful.
Step 14:Review all file permissions:
Unix file permissions confuse even very technical people, so we won’t try and explain them in the context of this guide. If you are interested then the reference provided will give you a basic primer. In a nutshell file permissions dictate who is allowed to do what with individual files. The ‘what’ part is defined as being able to read the contents of a file, to write to the contents of a file, or to execute a file – computer lingo for make the file do something.
Very often if you are trying to build an application it’s easier to relax file permissions, instead of fix your code. Yes that makes it easier to get the code to run, it also opens up big security holes. If you have files and directories that are set to ‘777’, which is read by anyone, write by anyone and executed by anyone. This is mostly a very bad thing. Your files and folders should have file permissions in place that are just enough for the website to do what it needs. If they exceed those permissions, depending on the application, you or your developer should look at carefully restricting them.
If you got this far, well done! I hope this post has helped you. If it has or you feel there was more information that could be added, we’re always happy to take feedback.