Fortress Norway: The Definitive Linux Server Hardening Guide
Let’s be honest: default Linux installations are not secure. They are designed for compatibility, not for surviving the hostile environment of the public internet. If you launch a fresh VPS today and tail your /var/log/secure, you will see brute-force attempts from Chinese and Eastern European botnets starting within minutes. I have seen production servers compromised in less than an hour because an administrator thought a strong root password was enough.
It is not.
In the Nordic hosting market, we have an advantage: better infrastructure and stricter privacy laws. But the Norwegian Personal Data Act (Personopplysningsloven) won’t save you if your SSH port is wide open to the world. This guide details the exact methodology I use to harden servers for high-availability clients, moving beyond the basics into the specific configurations that separate a professional setup from a compromised box.
1. The SSH Gateway: Lock It Down
The first line of defense is your SSH daemon. By default, it listens on port 22 and allows password authentication. This is unacceptable. In 2011, rainbow tables and dictionary attacks are sophisticated enough to crack 8-character passwords in days. We need to switch to RSA key-based authentication immediately.
First, generate your keys locally and push them to the server. Once verified, edit /etc/ssh/sshd_config. We are disabling root login and password authentication entirely. This forces attackers to have your private key, which is mathematically infeasible to crack.
# /etc/ssh/sshd_config
port 2200 # Move away from standard port 22 to reduce log noise
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM yes
UseDNS no
AllowUsers admin_user
After saving, restart the service. On CentOS 6 or RHEL 6, use:
service sshd restart
Pro Tip: Never restart SSH without keeping a secondary terminal session open. If you messed up the config, you lock yourself out. I learned this the hard way during a migration for a client in Oslo—driving to the datacenter at 3 AM to get console access is not fun.
2. The Firewall: IPtables is Your Best Friend
Many sysadmins are intimidated by iptables, relying instead on high-level wrappers. Don't. You need to understand the packet flow. We want a 'Default Drop' policy. This means if traffic isn't explicitly allowed, it dies. This is far more secure than trying to blacklist bad IPs.
Here is a battle-tested configuration script I use for web servers. It allows HTTP/HTTPS, custom SSH, and established connections, but drops everything else.
# Flush existing rules
iptables -F
# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost traffic
iptables -A INPUT -i lo -j ACCEPT
# Allow established and related incoming connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH on our custom port
iptables -A INPUT -p tcp --dport 2200 -j ACCEPT
# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Allow Ping (ICMP) to help with diagnostics (optional, limit rate)
iptables -A INPUT -p icmp -m limit --limit 1/second -j ACCEPT
# Save rules
/sbin/service iptables save
This configuration creates a fortress. If you are running a database server, ensure port 3306 is only open to your specific web server IPs, not 0.0.0.0/0.
3. Filesystem & Network Stack Optimization
Security isn't just about blocking ports; it's about limiting the damage if an intruder gets in. One common vector is uploading a script to /tmp or /dev/shm and executing it. We can prevent this by mounting these directories with the noexec flag.
Edit your /etc/fstab:
tmpfs /dev/shm tmpfs defaults,noexec,nosuid 0 0
Additionally, we need to harden the network stack against SYN floods and spoofing. Add these to /etc/sysctl.conf:
# /etc/sysctl.conf
# Ignore ICMP broadcasts (Smurf attack protection)
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Protect against SYN floods
net.ipv4.tcp_syncookies = 1
# Log spoofed packets
net.ipv4.conf.all.log_martians = 1
# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
Apply these with sysctl -p.
4. The Norwegian Context: Data Integrity and Privacy
Why does geography matter in 2011? Because of the US Patriot Act. If your data resides on servers owned by US companies (even if the datacenter is in Europe), it is subject to US jurisdiction. For Norwegian businesses dealing with sensitive data, sticking to Datatilsynet guidelines is mandatory.
This is where infrastructure choice becomes a security feature. You need a provider that respects data sovereignty. Furthermore, latency matters. Routing traffic from Oslo to a datacenter in Frankfurt adds unnecessary milliseconds. Local peering at NIX (Norwegian Internet Exchange) ensures your SSH sessions are snappy and your customers see pages load instantly.
Virtualization: OpenVZ vs. KVM
A lot of budget hosts are overselling OpenVZ containers. The problem? You share the kernel. If a neighbor exploits a kernel vulnerability, they could theoretically access your memory. For serious hardening, I only deploy on KVM (Kernel-based Virtual Machine). It provides full hardware virtualization and isolation.
| Feature | OpenVZ (Common Budget VPS) | KVM (CoolVDS Standard) |
|---|---|---|
| Kernel Isolation | Shared | Isolated |
| Swap Management | Host-controlled (unreliable) | Dedicated |
| SELinux Support | Limited/Difficult | Full Support |
At CoolVDS, we standardized on KVM and high-performance SSD RAID arrays years ago because we refuse to compromise on isolation. When you are hardening a system, you need to know the foundation is solid.
5. Keep It Updated
It sounds simple, but yum update (or apt-get upgrade) is your lifeline. Subscribe to the mailing lists for CentOS or Debian. When a CVE is announced for Apache or OpenSSL, you usually have hours, not days, before exploits are in the wild. Automate your notifications, but never automate the updates on production—always test first.
Final Thoughts
Hardening is not a one-time task; it is a mindset. By implementing strict SSH keys, a whitelist-based firewall, and kernel-level hardening, you eliminate 99% of automated attacks. For the remaining 1%, you need robust hardware and a hosting partner that understands the landscape.
Don't wait for a breach to take security seriously. If you need a sandbox to test these configurations without risking your production environment, spin up a KVM instance on CoolVDS. Our local latency to NIX and enterprise SSD storage give you the responsiveness of bare metal with the flexibility of the cloud.