The email you entered is already receiving Daily Bits Emails!
Cloud servers have become a great way for businesses to get a server up and running quickly and inexpensively. But it can be easy to forget that since these servers are in the cloud, they are accessible to hackers all over the world and your business needs to take cloud security very seriously. Getting hacked can cost you anywhere from several thousand dollars worth of lost business and productivity to putting you out of business entirely. However, as long as you take the appropriate security measures the cloud can be worth the flexibility and savings. After all, even if you have an in-house server, it's likely that it needs to be accessible to the Internet so security should already be paramount to your business. Here are some things to consider when implementing security for a cloud server:
Hackers use automated scripts that monitor the IP ranges assigned to hosting companies. Shortly after you spin-up a cloud server hackers will be aware of it. At Xojo, we have found that you have just a few minutes to install all of your security measures before a hacker is inside your server. Once the hacker is inside, the server is compromised and you have to implement your recovery plan which I'll get to later.
Hackers use sophisticated algorithms to guess passwords. Your dog's name plus your birth year is not nearly secure enough. Every user account you create should have a unique password. Passwords should ideally be at least 16 characters long and should be nothing more than a random string of characters. If you can remember your server account password, it's probably not secure enough. There are many great password managers, such as 1Password, which will generate strong passwords and keep them secure. Get one and use it. Obviously the password you use to encrypt and thus unlock your password manager needs to be one you can remember. In that case, use a long sentence (without spaces) that is relatively obscure but also easy for you to remember. Change your server passwords once per quarter.
Most cloud servers are running Linux and by default there's a user named Root that has privileges to do anything and everything. If a hacker can login as Root, they can very quickly do A LOT of damage. Reconfigure your server to disallow logging in as Root. There are only a handful of things that require root access anyway. Instead, login from another account and then switch to Root when needed. This adds an extra layer of security in front of the Root user.
A firewall is essentially a set of rules. At its simplest, it indicates which ports can be used for incoming and outgoing traffic. Unfortunately, the default set of rules is rarely enough and hackers can easily bypass them. The more specific your rules are, the more secure you are. Beyond just which ports should be open, a rule can determine how often a connection is allowed from any given IP address. Such a rule can prevent a hacker from running a script that will try passwords very quickly and lock them out should they try it. The Xojo Cloud, our web app hosting service, has an incredibly sophisticated adaptive firewall with many complex rules that can watch for the telltale signs of a hacker and stop them before they get in.
Even with a good firewall, there are other measures that need to be taken. You should install some kind of intrusion detection software. IDS is designed to detect the hacker who has managed to get past your firewall. If they do, you'll want to know what they changed and there are software packages such as OSSEC that will do that for you. Hackers will often try to make low-level changes to the OS figuring that if you notice you have been hacked, you won't notice the changes they have buried deep within the OS. You should consider protecting the OS with Security-Enhanced Linux. There are entire books dedicated to SELinux and it's not for the faint of heart but it will provide OS protection. It tends to also get in your way when you are initially configuring it. When we were creating our security measures for Xojo Cloud, the system was frequently locking us out thinking we were hackers because the kinds of things you do when configuring a server can look at lot like someone hacking into it.
If this all sounds very time-consuming and outside your wheelhouse, there's another solution which I will get to in due course.
If your database contains valuable data, it needs yet another layer of protection. If the hacker gets to your main web or app server, you don't want your database sitting there ready to be stolen or deleted. Your database should be kept on a separate, private cloud server with an internal network link to your app/web server. That means hackers won't see your database server from the Internet at all. If they hack into your app/web server, they might be able to gain access to your database server but it's another layer they have to get through.
After you find out you've been hacked, you might think that simply changing passwords plugs the security holes and you are back in business. Nothing could be further from the truth. There's a very good chance the hacker has altered files or even replaced applications such as Apache, with a hacked version that will echo all your data to their server. You have to assume that everything on the server is tainted. You will need to restore the server from a backup. That means you will need multiple backups. If the hacker was already in when last night's backup was made, that backup is tainted. You'll need to restore from the last backup made before the hacker got in. That means you need daily backups for at least a week. If you can't be sure when the hacker got in, you may have to consider all of the backups tainted and rebuild the server by hand from scratch.
If your website or app provides a way for users to login to their account with you, don't store their passwords. Unfortunately, people tend to use the same username and password in multiple locations so if a hacker gets hold of those, it can be a gold mine for them and an epic disaster for you. Instead, when a user sets up their account or changes their password, create a hash of their password, salt it and then store that. A hash is one-way encryption. Salting makes decrypting a hash even more difficult. Salt is some additional, random characters you add to the password before you hash it. You then store these random characters with the user's account in your database. Hackers often have huge databases of hashed passwords. If they get a hold of your database, they can compare your user password hashes to their databases of millions of password hashes, if they find a match, they know the password. By adding salt, you make this kind of attack impractical.
When the user wants to login, you add the salt to what they entered and hash it then compare it (server-side) to the hash you have stored in your database. If they match, you don't know the user's password, but you know it matches what they entered when they created their account. If you use the right hashing and salt functions, decrypting a hash back to the original password is not practical.
If you are doing ecommerce, storing your customer's credit card numbers is a really bad idea. This is exactly the information hackers are looking for. Additionally, the PCI compliance measures necessary to store credit card numbers are onerous. Most payment processors like Paypal, have services where they will store a customer profile for you. This profile contains a piece of information that you use to identify the customer (such as your internal ID for that customer's record in your database) along with their credit card information. Your app can then call into the service to tell it to charge a customer a specific amount based upon their customer ID. You don't have the customer's credit card number so you don't have to worry about it being stolen from you and your payment processor can worry about the PCI compliance. If you want to avoid the most difficult parts of PCI compliance, avoid having ANY access to the customer's credit card number. This means not taking orders over the phone or by mail as well.
Your server will likely have software on it that you didn't create such as MySQL, Postgres, Apache, etc. From time to time, new security vulnerabilities are discovered and hackers will work to take immediate advantage of them. The creators of these packages have email lists to inform users when they find a security vulnerability in their software. You'll need to monitor these lists and be ready to install updates as soon as they are available.
Being hacked is terrible. You don't want to be figuring out how to respond to it when it has just happened. You need to have a documented recovery plan in place. This plan should clearly indicate who should do what and in what order. The more specific and detailed, the better so that important steps are not missed. If this server is critical to your business, be prepared for the possibility that it could be down for several days. If the server has customer data on it, you need to have a plan to notify your customers. Be honest. The sooner you can tell them what happened and what steps you have taken (and any steps they may need to take) the better. Trying to avoid this can seriously hurt your reputation. If it comes out later that you tried to cover it up, recovering your reputation could be difficult or impossible.
If you're not scared and overwhelmed yet, you may not be taking this seriously enough. Good cloud security can be time-consuming, require expertise and be expensive. Cloud servers are inexpensive but they generally don't come with much security. If you don't want to tackle this yourself, use a managed cloud service that handles the security and software maintenance for you. Many, but not all, cloud hosting companies provide this level of service as a more expensive option.
From the moment your server is up and running, hackers will be trying to get into it. That's a virtual guarantee. Being hacked can cost you thousands of dollars or even put you out of business- I speak from experience here. Before we created Xojo Cloud, a hacker got into one of our servers through a known vulnerability in one of the software packages we were using. We had planned to update it but hadn't done it fast enough. I'm quite sure we spent tens of thousands of dollars recovering from that. The more security you have, the more likely the hacker will move on to an easier target. Most people don't have the skills or time to deal with security on their own. If that's you, use a secure, managed service or pay an expert to provide that security for you. You'll sleep better at night.
