Stop Giving Script Kiddies Root Access: A 2010 Guide to Server Hardening

Let’s be honest. Most Virtual Private Servers (VPS) deployed today are compromised within 15 minutes of coming online. I’ve seen logs on a fresh CentOS 5 install lighting up with brute-force attempts from IPs in Eastern Europe and China before I even finished running yum update.

If you are managing infrastructure for Norwegian clients, the stakes are higher. The Personopplysningsloven (Personal Data Act) is not a suggestion; it is the law. If you leak customer data because you left port 22 open to the world with a password authentication enabled, Datatilsynet (The Norwegian Data Inspectorate) will not be amused, and neither will your boss.

Security isn't a product you buy; it's a process. Here is how we lock down servers at CoolVDS, and how you should configure yours to survive the hostile internet of 2010.

1. The SSH Fortress: Keys Only, No Root

The default configuration of OpenSSH on most distributions is too permissive. Passwords are the weak link. Ditch them.

First, generate a strong RSA key pair on your local workstation. Don't use DSA; 1024-bit limits are becoming questionable.

ssh-keygen -t rsa -b 4096

Once your public key is on the server (in ~/.ssh/authorized_keys), edit your daemon config. We need to disable root login and kill password authentication entirely.

# /etc/ssh/sshd_config

# Change the default port to reduce log noise (security by obscurity, but helps keep logs clean)
Port 2222 

# NO Root login. Log in as a user, then su/sudo up.
PermitRootLogin no

# Keys only. No passwords.
PasswordAuthentication no
UsePAM no

# Limit who can even talk to the daemon
AllowUsers sysadmin deploy

Restart the service. On RHEL/CentOS:

Pro Tip: Always keep a second terminal session open when restarting SSH. If you locked yourself out, that session is your lifeline. If you are on a CoolVDS KVM slice, you can use our VNC console to fix it, but let's try to avoid that panic.

2. IPTables: The First Line of Defense

Many sysadmins rely on external hardware firewalls. That is a mistake. You need host-level filtering. In 2010, iptables is the standard. Don't rely on wrappers; learn the raw chains.

Here is a baseline configuration for a web server. This policy drops everything by default—whitelisting only what is necessary.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow loopback
-A INPUT -i lo -j ACCEPT

# Allow established connections (so you don't cut yourself off)
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow SSH (Remember we changed the port to 2222)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT

# Web traffic
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

# Ping is useful for monitoring, but limit it to prevent floods
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT

COMMIT

Save this to /etc/sysconfig/iptables on CentOS or use `iptables-save` on Debian/Ubuntu.

3. Kernel Hardening with Sysctl

The Linux networking stack is tuned for compatibility, not security. We can tweak /etc/sysctl.conf to prevent common attacks like SYN floods and IP spoofing.

# /etc/sysctl.conf

# Ignore ICMP broadcasts (Smurf attack protection)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable Source Routed Packets
net.ipv4.conf.all.accept_source_route = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

# Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1

Apply these changes instantly with:

4. Services: If You Don't Use It, Kill It

A default installation of Red Hat or Debian often starts services you don't need. Sendmail? Portmap? NFS locks? If this is a standalone web server, these are just attack vectors.

Check what is listening:

If you see port 25 open and you aren't hosting a mail server, shut it down. On CentOS:

chkconfig sendmail off
service sendmail stop

5. The Norwegian Context: Latency and Law

Technical hardening is useless if the physical layer is compromised or non-compliant. Under the Norwegian Personal Data Act, you are responsible for where your data lives. Hosting sensitive Norwegian user data on a budget server in a basement in Texas is a compliance nightmare waiting to happen.

This is where infrastructure choice matters. At CoolVDS, our servers are located in Oslo datacenters connected directly to the NIX (Norwegian Internet Exchange). This ensures two things:

1. Compliance: Your data remains within the EEA/Norway legal jurisdiction, simplifying your audits with Datatilsynet.
2. Performance: Latency from Oslo to Oslo is often under 2ms. Compare that to 30ms+ for hosting in Frankfurt or London.

Virtualization: OpenVZ vs. KVM

Security also extends to neighbor isolation. Many budget providers use OpenVZ, which shares the host kernel. If a vulnerability is found in the kernel (like the recent heavy exploits in 2.6.x kernels), your container could be compromised from the outside.

We prioritize KVM (Kernel-based Virtual Machine) and Xen. These technologies provide hardware-level virtualization. Your RAM is your RAM. Your kernel is your kernel. This provides a much stricter security boundary, essential for enterprise workloads.

Conclusion

Hardening a server takes time, but the cost of a breach is infinite. By disabling passwords, configuring strict iptables rules, and ensuring your kernel is tuned against network attacks, you are already ahead of 90% of the internet.

Don't risk your uptime on oversold hardware or distant datacenters. For low latency and strict isolation compliant with Norwegian standards, you need a partner who understands the local landscape.

Ready to deploy? Spin up a hardened KVM instance on CoolVDS today. Our high-speed SSD storage ensures your secure configuration doesn't come at the cost of I/O performance.