# Best Practices When Working With Sensitive Data: Securing Your Server

When it comes to sensitive data like credit card numbers, user addresses or social security numbers, you can never be too careful. You have to ensure to your users that the information they provided to you is safe on your servers. In this article, I will show you how you can make your sensitive data secure. This part will focus on the lower levels of security, like network and the server.

## Picking the Right Service Provider

The first thing to consider is your service provider. It does not matter whether you are only using hosting, VPS or even have a dedicated server, the rules are the same.

### Avoid Supercheap or Free Offers

This rule applies to almost every buy that you make, but there are few reasons why you should avoid these kind of offers when choosing your provider. In this business, going too cheap will cost you more in the long run than the more expensive options will. Or, in terms of hosting, your app could land on an overpopulated server with too much traffic on it.

If it's VPS, the situation is similar - you will share the machine with too many people. On the other hand, cheaper dedicated servers will usually have questionable hardware. Not only does this mean that your users will have a bad experience, but that your applications will also be more vulnerable to attacks. When going the cheaper route, it's much easier to DDoS such machines and extract the sensitive data.

### Check Their Security

If the provider's website tells too little about the security, try to contact them directly (calling them is the best option) and ask them, how do they secure your application and data? Of course some of the information may be confidential, so they will probably not tell you what model of the firewall they use (if they do, run away - it means they will also tell that to the potential attacker), but as you are their potential client, they will try to assure you that they do what they can to secure their clients' data. Here are a few questions that you should consider asking:

• How many people besides you, will have access to the server?
• What happens to the disks that are replaced (do they recycle them or sell to someone)?
• Is it possible to request tape backups of your data?

## In Case of Disk Failure, Request the Broken One

These things just happen from time to time. But when one of your hard drives fails and there was some sensitive data on it, request the provider to send it to you. Some of them will send it for free, as they are happy they don't have to deal with recycling. Some will sell it to you, usually much cheaper than the market price since it's broken. It may seem weird to buy a broken hard drive, but when you realise that the informations about your users or clients may leak somewhere because of that drive, you will realize that it's worth the cost.

It's a good practice to unplug the Internet connection from servers that don't need them (a golden rule to server security - if you don't need it, disable it). For example, your database server's security will greatly improve if you will only allow access to it over the LAN from your other machine(s). Of course this is an option, only if your servers are in the same hosting center. Some of the providers will do it for you if you ask them to (I've even seen such options in one or two web-based admin panels, so it's really easy to switch back to development mode later). If it's not possible, don't try to disable it yourself by messing up the network interfaces. From my experience, their tools will detect that your machine does not have access to the Internet and they will try to "fix" it for you.

As with all software, operating systems are prone to bugs. You should update your operating system when it's possible to avoid attacks that exploit such defects. Also make sure you are running a stable (avoid experimental builds at all costs) long-term support (LTS) version of your favorite operating system. You don't want to wake up some day and see that the version you installed a few months ago, just died and is replaced by something entirely new.

## Block Ports & Disable Unused Services

Everything that is enabled on your server is a possible security threat. So to minimize the risk of some of the services failing and exposing you to attacks, you should disable everything that you don't need. Depending on your operating system, there are plenty of tools available to accomplish this task. For example, sysv-rc-conf on Debian, manual stanza on Ubuntu (and everything using upstart) and msconfig if you have to use Windows.

The situation is pretty much the same with the ports. In most cases (HTTP(S) server plus SSH access), you should deny access on all ports but 80 (for HTTP traffic), 443 (for HTTPS) and 22 (or any other port of your choice for SSH). This will make sure that even if you install some faulty software, it will not be exploited by a potential attacker - more likely it will fail by itself and cause a lot of trouble, so make sure you check what you are installing. Believe me, you really don't want to guess the names of directories after the flawed file manager goes berzerk and renames them to random strings (and that is one of the less painful accidents that may happen).

If you have multiple HTTP servers running on different ports (for example multiple Node.js apps), you should use nginx, Apache or Varnish to proxy the traffic from port 80 to the appropriate ports for all of your servers.

This may seem obvious, but many people forget to do it. The reason for this practice is that after someone successfully hacks into your system, they may hold back from wreaking havoc over your machine and just stay low-profile, silently downloading all of your data or waiting for the right moment to strike. Changing the passwords frequently makes his work harder. If you have other users connecting to your server, you should force them to change their passwords periodically. On Linux systems, this can be done with the passwd command. Use this syntax to make the user's password expire in 14 days, warning them about it seven days before that date:

Where >username< is the name of the user that will have to change their password in 14 days. There is an article about password policy in Windows Server on Microsoft Technet.

## Disable Root Access

You should never allow someone to log in as "root" using SSH - this is a major security threat. If someone cracks your password using a bruteforce attack, it's game over.

### Linux

If you don't have any other user yet, create one using the useradd command (if you just type it and hit enter there will be a nice wizard that will help you creating the new user). Now make sure you have sudo installed on your system and type:

If you don't have it, install it using apt-get install sudo. Then you can enable it for the user you have just created:

Where >username< is the name of the user you just created. Now edit the /etc/ssh/sshd_config file. Find this line:

And change it to:

Now restart the SSH service and you are good to go:

### Windows

Disabling the Administrator account on Windows is described on Microsoft Technet. Generally it will be disabled by default, but you should check yourself, to be sure that is the case.

## Use an Antivirus

For some, this is obvious, but there are people who think they don't need an antivirus (AV) software on their server. So many time I've heard ,"Hey, I'm running Linux, I don't need any AV - there is no malware for Linux!". Sure, compared to Windows the number of malicious software is a very little number. But why would you compare? It exists, it's a fact. And it can infect your machine.

Of course AV is not always needed and in some cases it may do more damage than it's worth. For example, if you allow your users to upload anything on your server, you must use such software. But if you are in progress of developing something and you test it on your server with AV on, it may be reported to be a virus and you may have a hard time figuring out what happened.

### Exclusions

To make your system perform better with antivirus software, you should exclude some directories from the scan. This is a tradeoff between complete security and maximum performance. There is a great article on what you should do with your AV on Windows Technet. There is also a good one for Linux on Symantec Connect Community.

The way you access your server is also important. Here are few tips on how to access your server securely:

### Never Connect From Public Hotspots

This is a common mistake. Never use a public wi-fi hotspot to access your server. You don't know who is running it - it may be someone who is just spying on everyone who is connected to the access point. Even if the owner of the hotspot is not such a person (for example in a very popular coffee shop), if it's not secured, someone else may be sniffing on everyone using it (man in the middle attack). If you really have to use a public hotspot to access your server (for example your ultra-important application went down), be cautious - if you were accessing your server using SSH before and now it has a different fingerprint (your SSH client should notify you about it) abort the connection and try to find another access point. Different fingerprint means someone who is connected to your network intercepted your communication and is trying to trick you into sending him your password.

### Use Secure Connection Channels

Using FTP to upload files to your server is not a good idea. The data is not encrypted, so if someone can intercept your communication, he could change what you are uploading so instead of some patch to your app you will get malicious software on your machine. Always use SSH for shell access and SCP to transfer files (it's based on SSH). These protocols use strong encryption to avoid such incidents.

### Use Verified Software

Use software from official sources like your operating system's package repository or trusted software provider. Never download any software you use to connect to your server from suspicious websites - it may be infected and communication between you and your server may be sent to the attacker. For example, if your favorite software is provided by the author only as source code, don't try to find precompiled packages for your system - it's safer to compile it yourself or look for an alternative.

## In Conclusion

Hopefully this article has helped you in protecting your server from attacks and malicious software. In the next part of this article, we'll focus completely on the third layer of security - your application itself. So stay tuned where I will show you techniques that you can use to protect your application from attacks and intrusions.