It feels like the world’s on your shoulders when you are responsible for setting up and managing a large community portal or a website. Being the administrator of the website you have access to user’s data including credentials and full control of their accounts even if the user master records are encrypted. Always remember, You are responsible if your website ever get’s hacked, So better do something before your website get’s hacked.
I am the administrator of ietBugs.com and the owner of almost a dozen other websites, My objective is to always keep the data secure and maintain a high standard of anti hacking policies making the best use of the technology. I care for the private data like user account credentials associated with the registered users, that is why I learned how to be a Hacker to Hackers. Before you think about how to safeguard your website or applications from hackers you need to think like a wildest hacker. So here are a few things that am going to share with you.
First off, store an entire set of working files locally. This should be a set of files that has never been off your computer so that you know that they have not been tampered with. Edit them locally, when you need to, and then upload them to your webspace, either through the file manager in your cpanel or with ftp, sftp, ssh, or something similar. You don’t have to upload the entire set each time, just the modified files.
Some people edit their files live on the server. If you do this you will not have a current local copy. If you download the file(s) from your server, you do not know for certain that they have not been modified by a hacker. ALWAYS edit your local files and upload them to the server, not the other way around.
It wouldn’t be a bad idea to get XAMPP (from Apache Friends) and develop locally as well but that’s beyond the scope of this post.
Before installing a new mod, make a copy of the entire local directory and datestamp it (rename the directory copy to indicate the date). That way if anything goes wrong, you can revert to the old copy. It is a good idea to keep a couple of these snapshots (backups taken at different times) around just to be safe.
Now, if your site ever gets hacked it is easy to fix. Go to your webspace and delete all the files associated with your site. Use some common sense though. There may be other folders such as for cgi, logs, statistics, etc that you might want to keep. (They should not be in a web accessible location anyway but that’s another issue). Once you have deleted your website from the server, upload the entire fileset from your local computer. Now, your website should be back to where it was before you got hacked. That should be a fairly quick and painless recovery process.Do not upload your files over the existing files. You must delete everything first. Otherwise you will not remove any new files or folders that were added by the hacker.
That is step one: Preparing to recover from an attack.
Step two is protecting against an attack in the first place.
Most important.. Set the permissions correctly! The documentation states that you should set the permissions on a few folders to 777. That is fine if you want to be hacked. If you follow those instructions, you WILL be hacked, it’s just a matter of time.
Set the permissions on ALL folders to 755. If your host has PHP installed as CGI through phpSuExec (the proper method), then your site will run fine this way. If they have PHP installed as a module, you will get a warning from oscommerce saying that it is unable to write to the images folder. Setting permissions back to 777 will make the message go away but it will leave you open to an attack. Contact your host and ask them if they could change the way in which they install PHP. If they will not, you should immediately get a new host. This isn’t an arbitrary statement. By installing PHP the wrong way, they have created a security vulnerability that you will not be unable to resolve. A partial work-around is to upload images via file manager in cpanel or through ftp. A less secure method is to set the permissions on the images folder to 777 just long enough to add your new products and then set it back to 755. This work-around does not, however, deal with the permissions issues on a couple of other folders. Loading PHP in the correct manner is the only fix.
Set the permissions on all files to 644, with two exceptions. There are two configure.php files. One is located in /catalog/includes/ the other is in /catalog/admin/includes/. The permissions on these two files should be 400, 444, or 644 dependent on your server configuration. Use the lowest setting that will still allow your store to function and that your host’s setup allows you to set.
If you have trouble setting permissions on files or folders through ftp, try the file manager in cpanel instead. Some hosts don’t allow ftp to change permissions.
The admin folder requires a password (in the latest version of osc). This method of password protection is not secure. A hacker could run a password cracker program against it and try thousands of passwords a second until they get in. Use the feature in cpanel to password protect your admin directory. When a hacker runs a password cracker program against this, the system will be notified after a set number of attempts and the hacker’s IP will be automatically banned from the system (on a properly configured server. It wouldn’t hurt to check this with your host).
Renaming your admin folder to something obscure (a 12+ character long string of random letters and numbers would be best) makes it even more difficult for hackers since they won’t even know where your admin folder is now. You will have to modify your configure.php files to point to the newly renamed admin directory. Be sure that you do not list the new name in any other files (like robots.txt) as this will give the name away.
Lastly, install the following security mods:
Security Pro
Sitemonitor
IP Trap
.htaccess Protection
Anti-XSS
With all of those changes made, it is very unlikely that you will be hacked. There are always other methods of attack and some can only be prevented by making changes to the server configuration (which is out of your control). Keep in mind that shared-host accounts have more security issues than dedicated accounts and that “cheap” accounts are just that; don’t expect that a cheap account is managed by competent or conscientious people.
Lastly, make sure that your admin settings for file-based sessions and cache (if you use either), do not use the /tmp folder if you are on a shared-host account. On most systems, the /tmp folder is a symlink to a shared system folder that all the other accounts on that shared-host also use. Not only can this potentially cause problems but it can be a security leak, sharing customer data through this shared folderHope that helps.
Good luck!
Recent Comments