Bulletproof Your Box: The Definitive Linux Server Hardening Guide for 2013

Let’s be honest: default Linux installations are not designed for the hostile environment of the public internet. If you spin up a fresh CentOS 6 or Ubuntu 12.04 instance and leave it running with default settings on port 22, you aren't an admin; you're a victim waiting to happen. I’ve seen production servers compromised in less than 15 minutes by automated botnets scanning for weak root passwords. It’s messy, it’s expensive to clean up, and it kills your reputation.

In the Nordic hosting market, we pride ourselves on stability and trust. But low latency to NIX (Norwegian Internet Exchange) works both ways—your server responds just as fast to an attacker in Eastern Europe as it does to a client in Oslo. Security isn't a product you buy; it's a process you execute.

This guide is for the serious systems administrator. We are going to lock down a fresh VPS using industry-standard tools available right now. No fluff, just config.

1. The First 5 Minutes: SSH Lockdown

The moment your IP is announced via BGP, the brute-force attacks begin. The absolute first step is securing the SSH daemon. Passwords are dead to us. If you aren't using RSA key pairs, you're doing it wrong.

First, generate your keys locally if you haven't already:

Once your public key is on the server (in ~/.ssh/authorized_keys), we need to edit the daemon config. Open /etc/ssh/sshd_config and ruthlessly disable the legacy options.

# /etc/ssh/sshd_config

# Change the default port to reduce log noise (security through obscurity, but helpful)
Port 22022

# ABSOLUTELY CRITICAL: Disable root login
PermitRootLogin no

# Disable password auth. Keys only.
PasswordAuthentication no
UsePAM no

# Restrict to specific users
AllowUsers deploy_admin

# Turn off DNS lookups to speed up login
UseDNS no

Restart the service. Congratulations, you just eliminated 99% of automated drive-by attacks.

Pro Tip: If you are managing servers for Norwegian enterprise clients, you must adhere to the Personopplysningsloven (Personal Data Act). Datatilsynet (The Norwegian Data Protection Authority) takes a dim view of unauthorized access due to weak authentication. Audit your /var/log/secure (CentOS) or /var/log/auth.log (Ubuntu) regularly.

2. The Firewall: Learning to Love iptables

Many devs are scared of iptables because the syntax is unforgiving. Get over it. It is the kernel-level packet filter that stands between your application and the abyss. We want a "Default Drop" policy. This means if traffic isn't explicitly allowed, it dies.

Here is a battle-tested stateful firewall script suitable for a web server. Save this as /etc/iptables.firewall.rules.

*filter

# 1. Set default policies to DROP. 
# If we mess up, we lock ourselves out, so be careful.
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# 2. Allow localhost traffic (essential for local services like MySQL)
-A INPUT -i lo -j ACCEPT

# 3. Allow traffic associated with established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 4. Allow SSH on our custom port
-A INPUT -p tcp --dport 22022 -j ACCEPT

# 5. Allow HTTP and HTTPS
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# 6. Allow ICMP (Ping) but rate limit it to prevent floods
-A INPUT -p icmp -m limit --limit 1/second -j ACCEPT

# 7. Log dropped packets (optional, can fill logs quickly)
# -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

COMMIT

Apply it:

If you are on CentOS 6, save it permanently:

3. Kernel Hardening via sysctl

The Linux kernel defaults are designed for compatibility, not security. We need to tweak the TCP/IP stack to resist SYN floods and spoofing attacks. This is done in /etc/sysctl.conf.

In a high-performance environment—like the Pure SSD KVM instances we run at CoolVDS—we also tune these for network throughput, but today we focus on security.

# /etc/sysctl.conf

# 1. Enable SYN Cookies (mitigates SYN flood attacks)
net.ipv4.tcp_syncookies = 1

# 2. Log Martians (packets with impossible addresses)
net.ipv4.conf.all.log_martians = 1

# 3. Disable ICMP Redirects (prevents routing table tampering)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# 4. Ignore ICMP broadcast echoes (Smurf attack protection)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# 5. Disable IP forwarding (unless you are a router/VPN)
net.ipv4.ip_forward = 0

# 6. Enable source address verification (prevents IP spoofing)
net.ipv4.conf.all.rp_filter = 1

Reload the changes immediately without rebooting:

4. Brute Force Protection: Fail2Ban

Even with SSH hardened, services like FTP, SMTP, or even HTTP forms can be brute-forced. Fail2Ban is mandatory software. It scans log files for malicious patterns (like repeated password failures) and updates iptables to ban the offender's IP.

Install it (requires EPEL repo on CentOS):

Configure a local jail in /etc/fail2ban/jail.local. Do not edit `jail.conf` directly as updates will overwrite it.

[DEFAULT]
# Ban hosts for one hour
bantime  = 3600

# Override the default backend
backend = polling

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=22022, protocol=tcp]
logpath  = /var/log/secure
maxretry = 3

The Hardware Factor: Isolation Matters

Software hardening effectively becomes useless if your underlying architecture is flawed. In the current market, many providers are still pushing OpenVZ containers. The problem? You share the kernel. If a neighbor on the node triggers a kernel panic or exploits a kernel vulnerability, your hardened server goes down with them.

This is why, at CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine) virtualization. It provides true hardware virtualization. Your memory is yours. Your kernel is yours. Combined with our RAID-10 Enterprise SSD storage (which provides the IOPS needed to handle log writing during a DDoS attack without choking), you have a foundation that is physically capable of staying up when others fold.

Final Thoughts

Security is a race. As we head into 2013, the attacks are getting smarter. Automated scripts are now testing for vulnerabilities in web apps (SQLi, XSS) just as often as they hammer port 22. By implementing these four steps—Keys, Firewalls, Sysctl tuning, and Fail2Ban—you put yourself ahead of 90% of the targets out there.

Don't build your fortress on a swamp. Start with a solid foundation.

Ready to deploy? Spin up a secured KVM instance on CoolVDS in Oslo today. Experience the difference of pure SSD performance.