Fortifying the Keep: Essential Linux Server Hardening for Nordic Deployments

It was 3:45 AM last Tuesday when the pager buzzed. Another generic hosting provider in Oslo had gone dark. The culprit? A distributed SYN flood targeting a poorly configured Apache cluster, combined with a brute-force SSH attack that cracked a weak password on a developer account. By the time the admins woke up, the botnet had already installed a rootkit.

This scenario is becoming all too common in 2010. As connectivity speeds in Norway increase—thanks to fiber rollouts and the robust NIX (Norwegian Internet Exchange) infrastructure—so does the bandwidth available for attacks. If you are running a default install of CentOS 5.4 or Debian Lenny, you are not an admin; you are a target.

Security isn't a product you buy; it's a process you adhere to. At CoolVDS, we see the aftermath of "default settings" every day. While we provide hardware-level DDoS protection and clean, minimal OS templates, the responsibility for the userland security rests on your shoulders. Here is how to lock down your Linux box before you even point a DNS record at it.

1. The SSH Fortress: Close the Gate

The vast majority of automated attacks target Port 22. If you leave it on default with password authentication enabled, it is simply a matter of time before a dictionary attack succeeds.

Disable Root & Switch to Keys

Never log in as root directly. Use a standard user and escalate privileges via sudo. Furthermore, passwords are a relic of the past for server access. RSA keys are the standard.

# Create a new user
useradd -m -s /bin/bash viking
passwd viking

# Add to sudoers (visudo)
viking ALL=(ALL) ALL

Once your keys are generated (use at least 2048-bit RSA) and copied to the server, edit your daemon config.

File: /etc/ssh/sshd_config

Port 4422  <-- Security through obscurity, but it reduces log noise
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers viking

Restart the service with service sshd restart. You have now eliminated 99% of automated script kiddies.

2. Iptables: The First Line of Defense

In 2010, we don't have fancy GUI firewalls on serious servers. We use iptables. Many sysadmins make the mistake of setting a default policy to ACCEPT and trying to block bad IPs. This is a losing battle. The only valid strategy is a default DROP policy.

Here is a battle-hardened ruleset for a web server. This assumes you are running Apache/Nginx (80) and SSH on our custom port (4422).

#!/bin/bash
# Flush existing rules
iptables -F

# Set Default Policy to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow localhost
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (Stateful inspection)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Custom Port)
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ICMP (Ping) - Limit to prevent flood
iptables -A INPUT -p icmp -m limit --limit 1/sec -j ACCEPT

# Log dropped packets (Optional, careful with disk I/O)
# iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

# Save rules
/sbin/service iptables save

Pro Tip: Always run iptables -L -n to verify before logging out. If you block yourself, you'll be submitting a ticket to CoolVDS support for a console reset. We answer fast, but the shame lasts forever.

3. Kernel Tuning via Sysctl

The Linux kernel (2.6.x) defaults are designed for compatibility, not security or high-load resilience. We need to tweak the network stack to handle SYN floods and invalid packets. This is crucial for maintaining uptime during those traffic spikes common in the European hosting market.

Edit /etc/sysctl.conf:

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

# Disable ICMP Broadcasting
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Enable IP Spoofing Protection
net.ipv4.conf.all.rp_filter = 1

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

# Ignore Bogus Error Responses
net.ipv4.icmp_ignore_bogus_error_responses = 1

Apply these changes instantly with sysctl -p. This hardens the TCP stack against common denial-of-service tactics without requiring external hardware.

4. Data Privacy & The "Personopplysningsloven"

Physical location matters. Under the Norwegian Personal Data Act (Personopplysningsloven) and EU Directive 95/46/EC, you are responsible for securing user data. This isn't just about hackers; it's about compliance.

If you are hosting sensitive data:

• Ensure partitions meant for sensitive storage are mounted with noexec,nodev,nosuid where possible.
• Use separate partitions for /tmp and /var/log to prevent a compromised script from filling your root partition and crashing the system.
• On CoolVDS, our datacenters in Oslo ensure that data stays within Norwegian jurisdiction, simplifying your compliance with local Datatilsynet requirements.

5. Automating Intrusion Detection

Even with a firewall, you need eyes on the logs. Fail2Ban is the standard tool here. It parses log files (like /var/log/secure or /var/log/httpd/error_log) and bans IPs that show malicious signs.

Install it via EPEL (CentOS) or Apt (Debian):

yum install fail2ban

Configure /etc/fail2ban/jail.conf to protect SSH:

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

This configuration automatically creates an iptables rule to block an IP for one hour after 3 failed login attempts. It is a simple, brutal, and effective way to stop brute-force attacks cold.

The CoolVDS Advantage: Clean Slate, High Performance

Hardening a server takes time, but starting with a compromised or bloated image makes it impossible. At CoolVDS, we provide minimal, optimized Linux templates. We don't pre-install junk. We give you raw access to KVM virtualization (kernel-based virtual machine), ensuring that your memory and CPU are yours alone—no noisy neighbors stealing cycles like you might find on older OpenVZ platforms.

Security is a trade-off between convenience and paranoia. The settings above lean towards paranoia because, in 2010, the internet is not a friendly place. Don't let a default config cost you your reputation.

Ready to deploy on infrastructure that respects your skills? Spin up a CoolVDS instance in Oslo today and experience true low-latency stability.