Web Hosting - Improving security and redundancy
Once upon a time you’d never have to do anything to a website once it was created. With the advent of Web 2.0, websites grew to the point that they require constant maintenance and monitoring. The more traffic your website receives, the more it becomes interesting to malicious individuals. Here are few steps to improve security and redundancy.
Deactivating User Accounts
Not all of them, but at least the redundant ones. When you move out of a house, you forfeit your key. When you are no longer part of a group associated with access to a website your user account should be delete. Not everyone is malicious, but it only takes one. When an account’s usefulness expires so should the account. All accounts should be held to the same standard; website, CMS, database, FTP.
Prevent automatic submissions
CAPTCHA seems to be a bad word, but sometimes you gotta curse. Alternatives such as noCAPTCHA exist; by monitoring how a user navigates a website, noCAPTCHA determines if a BOT is attempting to submit a form. Successful form submissions by BOTs is a great way of broadcasting vulnerability. Darwin.
Monitor logs
More specifically monitor logged data. There are plenty of analytical tools available that can help. Know your peak usage times, this will help with scheduling service outage and backups. Know where people are connecting from, be weary of an influx of traffic from a suspicious location.
Block/Timeout consequitive unccesful logins
It’s pretty much a industry standard now. You get three attempts to provide the correct password/PIN, after that you gotta sit in timeout. Be sure that users get some feedback once they have failed to login three times. Show a message by itself; don’t have it accommodate the login controls, otherwise they’ll keep trying until you get a support call.
Patch your ‘S’
When a new version is available, install it! Although it’s not a bad idea to wait until developers have enough time to fix bugs associated with new releases and issue a new minor release. Either way keep things relatively up to date. As an extension of patching your ‘S’, remove unused assets. Not using a JavaScript library or a plugin? Get rid of it! Unused assets provide security holes that, literally, don’t need to exist. Unused assets are less likely to be kept up-to-date; yet another reason to trash them.
BAD. ssh root@myserver
Never, under any circumstances, allow SSH connections to a server as root. Always force users to connect and then escalate their privilege level, the reason for this should be fairly obvious. SSH BOTs will scan all ports to get access so moving SHH to another port isn’t enough. Look into port knocking. Even better, only allow remote connections from a single location.
Back ups
The song never changes, always create backups. Drives fail. How often you backup will be dictated by how frequently your users create/modify data. Sometimes you need to back up everyday or every month. Backups should be offsite this will ensure if you are compromised, your data will be safe from malice. Encrypted offsite backups are a dam fine idea. What’s better than backing up data? Setting up RAID is pretty good. Now RAID is a whole other thing completely. In a nut shell (and grossly oversimplified) the same data is wrote to multiple disks simultaneously. When a drive fails, swap it out and your done. Equally important, perform periodic restorations to another location. Don’t sit back and relax once you’ve got a RAID or backup policy in place. Set a reminder to perform a restore. It’s part of this new thing the kids are doing called “Disaster Recovery”.
SSL and HTTPS
If your users are logging into personal accounts which hold sensitive data you need SSL. It doesn’t matter that people have absolutely no idea what SSL is, or what it safe guards. When (hopefully, “If”) you get hacked you’ll certainly need a leg to stand on, enter SSL certificate.
Conclusion
Perform backups at the very least. Doing everything listed above is great but perform backups (preferably off site).