Working With Sensitive Data: Securing Your Server

Picking the a reliable service provider

Avoid Free Offers and very cheap ones

Choosing too cheap will cost you more on the long term than buying 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. Cheaper servers also have questionable hardware most of the time. Your users might have a bad experience and your applications will be more vulnerable to attacks because it’s quite easy to DDoS these machines and extract sensitive data.

Check Their Security

When a provider’s website doesn’t tell you much about the security, contact them directly and ask them how do they secure your data and application? Some of the information should be confidential, so if they tell you the model of the firewall they use they might also tell that to the potential attacker. As you are a potential client, they will try to assure you they are doing the best to secure their clients’ data. Here are a few questions you should be asking:

How many people have access to the server?
What happens to the replaced disks. Do you recycle them or sell them?
Can I request tape backups of your data?
Who has access to those?

In case of hard drive failure, request the broken drive

When a hard drives fails and you had sensitive data on it, request the provider to send it to you. Some will send it for free so they don’t have to deal with recycling, some will sell it to you cheaper than the market price. It looks a bit weird to buy a broken hard drive, but informations about your users or your clients may leak somewhere if you don’t do it
Isolate the servers

Unplug the Internet connection from servers that don’t need them – if you don’t need it, disable it. Database server’s security will improve if you will only allow access to it over the LAN from your other machine(s), but only if your servers are in the same hosting center. Some of the providers will do it for you but If it’s not possible, don’t disable it yourself by changing the network interfaces. because their tools will detect that your machine does not have access to the Internet and they will “fix” it for you.

Update the Operating System

Operating systems are prone to bugs. Update your OS to avoid attacks that exploit bugs. Make sure you are running a stable long-term support (LTS) version of your OS.

Block ports and disable unused services

Everything enabled on your server is a possible security threat. Try and disable everything that you don’t need. Use sysv-rc-conf on Debian, manual stanza on Ubuntu or msconfig if you have to use Windows.
Do the same with ports. In most cases 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). That way, even if you install faulty software, it will not be exploited by a potential attacker. If you have multiple HTTP servers running on different ports (for example multiple Node.js apps), use nginx, Apache or Varnish to proxy the traffic from port 80 to the appropriate ports for all of your servers.

Change passwords often

This sounds obvious, but people tend to forget to do it. After someone successfully hacks into your system, they could wait and stay low-profile, silently downloading all of your data or waiting for the perfect moment to take an action. If you have users connecting to your server make them change their passwords periodically.

Use an antivirus software

For many, this is obvious. Sure, on Linux, compared to Windows, the number of malicious software is a very little number. But It exists and it can infect your machine. If you allow your users to upload anything on your server, you must use an antivirus software. If you are developing something and you test it on your server it may be reported to be a virus and you will have a hard time figuring out what happened. Also, you should exclude some directories from the scan to make it faster.

Accessing the server – 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. Using FTP to upload files to your server is not a good idea. The data is not encrypted, so if someone intercepts your communication, he could change what you are uploading. Always use SSH for shell access and SCP to transfer files. These protocols use strong encryption to avoid such incidents.

Use only verified software

Only use software from official sources. 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.

Related Blogs

Web developer
Symfony-PHP-Developer_02
Quick question?