Securing Your Server

Getting your own dedicated server to host your site is fast becoming the norm. As these servers are situated remotely from the users, they think that security is not an issue. After all, the hosting company will help you handle that part, right? Wrong. When you get your own dedicated server, all responsibilities will naturally be passed to your side.

With full server access, remote or otherwise, means that hosting companies can’t touch your server, unless given the permission to do so. And you will usually pay for it. So, unless you get someone to manage the servers, you will have to manage it yourself. Be prepared to defend your server to the teeth from hackers, phishers and crackers.

Front Door: Wall it up

Firewalls are the front gate of your server. This is the first line of defense in blocking would be attacks and malicious worms. If you keep your front gate of your house unlocked, you are inviting people to rob you. Same goes with your firewall. Always keep it “locked” and keep trouble off your “property”. A firewall with egress and ingress protection can stop both incoming and outgoing attacks even when you're not aware of it.

Update your Kernels

Make sure your server is using current, updated software. Use the stable version which has been tested more than any beta and update as soon as possible. An old kernel can lead to an easy target for your server. If you're not sure then ask your provider for the latest update.

Upgrade your technical Skills every now and then

Ensure that you are properly trained in system administration and security procedures. If you have administration staff, train them too. Have backup procedures in place, as well as incident handling roles defined and filled. Try not to overload administrators with too many systems to manage or too many tasks to perform. This will inevitably lead to things being missed and intruders finding (and compromising) vulnerable systems before they are patched.

Use separate servers for internal and external applications

Given that organizations typically have two, separate classes of Web applications, those serving internal users and those serving external users, it's prudent to place those applications on different servers. Doing so reduces the risk of a malicious user penetrating the external server to gain access to sensitive internal information. If you don't have the resources to implement this at your disposal, you should at least consider using technical controls (such as process isolation) to keep internal and external applications from interacting with each other.

Monitor Logs

Keep a list of logging records of all the activities that goes on in the server. You will not be able to monitor your server 24/7, so logging it is the best way in helping you trace errors and malicious activities that your server encounters.

Make copies

Backup your server regularly. Even with all the firewalls and loggings, it is still never 100% secure, and backup is the best way of restoring your data just in case you are hit with a malicious attack.

Limit Access to a Minimum

Do not give users more access than the absolute minimum they require. Never give them shell access, restrict file access to a bare minimum and leave other services turned off by default until specifically requested and you determine that it’s safe to do so.

Intrusion Detection System

If firewalls are your front gate, Intrusion Detection System (IDS) is your security guard. IDS helps to monitor, detect and isolate potentially malicious activities before they even strike your server. This will include attacks coming from the internet as well as from the inside. Snort, TripWire and AIDE are a few of the IDS software available in the market for a reasonable cost.

Sudden Spike in Server Activity

When there is a sudden spike in server activity that is out of the norm, it usually means someone is trying to gain access to your server or could have already gained the access. Bandwidth, Server performances, all those are clues to unusual activities. Be quick to response. It maybe a false alarm, but it’s better to be safe than sorry.

Use a separate development server for testing and debugging apps.

Testing applications on a stand-alone Web server sounds like common sense -- and it is! Unfortunately, many organizations don't follow this basic principle and, instead, allow developers to "tweak" code or even develop new applications on a production server. This is a horrible idea for both reliability and security reasons. Testing code on production systems could cause users to experience malfunctions (possibly, a complete outage) and could also introduce security vulnerabilities as developers post untested code that might be vulnerable to attack. Most modern version control systems (such as Microsoft's Visual SourceSafe) can help automate the coding/testing/debugging process.

Know yourself, know your enemy. Be always a step or two ahead of your attackers and you would already have kill off their chances of attacking you on the blind side. Many other ways of securing your web server is still available, all depending on the situation and severity of it. Being aware of it is the all important first step.