The Castle Wall Has Fallen: Why Your Firewall Isn't Enough

If 2014 has taught systems administrators anything, it is that the "trusted internal network" is a myth. First, we dealt with Heartbleed in April. Then, just last month, Shellshock (CVE-2014-6271) ripped through the internet, allowing arbitrary code execution on servers that administrators thought were safely tucked behind corporate firewalls. The era of the perimeter defense—the "crunchy shell, soft center" model—is effectively over.

As we approach the end of the year, security architects operating in the Norwegian market must pivot. We need to adopt a model where trust is never assumed, regardless of where the traffic originates. In enterprise circles, Forrester is calling this "Zero Trust." In the trenches, we call it "locking down every damn packet."

This is not about buying expensive appliances. This is about rigorous configuration of the tools we already have: iptables, OpenSSH, and the Linux kernel itself. Here is how we build a fortress on a single node, optimized for the rigorous data privacy standards demanded by Datatilsynet (The Norwegian Data Protection Authority).

1. Identity is the New Perimeter: Hardening SSH

The first step in a Zero Trust model is ensuring that access to the control plane (your VPS) is cryptographically verified. Passwords are dead. If you are still allowing password authentication on port 22, your server is likely being brute-forced as you read this.

We need to implement a three-tiered authentication strategy: Keys, Passphrase, and Time-Based One-Time Password (TOTP). Even if a laptop is stolen and the private key is compromised, the attacker still needs the rotating code.

The Configuration

First, install the Google Authenticator PAM module (available in EPEL repo for CentOS 6/7 or standard Debian/Ubuntu repos).

# On CentOS 6/7
yum install google-authenticator

# Run the setup
google-authenticator

Next, we fundamentally alter /etc/ssh/sshd_config. We are disabling root login, disabling passwords, and mandating the authentication methods.

# /etc/ssh/sshd_config

# Change default port to reduce log noise (security through obscurity is not security, but it helps logs)
Port 4422

# Disallow root login strictly
PermitRootLogin no

# The Basics
Protocol 2
UsePrivilegeSeparation yes

# Authentication
LoginGraceTime 30
PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes

# Enforce specific users
AllowUsers sysadmin_deploy

Finally, update your PAM configuration in /etc/pam.d/sshd to require the code:

# Add to the bottom of /etc/pam.d/sshd
auth required pam_google_authenticator.so

Pro Tip: Always keep an active SSH session open in one terminal window while you restart the SSH service in another. If you messed up the config, you won't lock yourself out. On CoolVDS KVM instances, you can use our VNC console if you get locked out, but it's a walk of shame you want to avoid.

2. Micro-Segmentation with IPtables

In a Zero Trust environment, we do not trust the server sitting next to us in the rack. Even inside a private LAN or VLAN, lateral movement is the hacker's primary goal. The solution is rigid host-based firewalling.

We don't use ufw or high-level wrappers here. We write raw iptables rules to ensure we know exactly what the kernel is doing with every packet. The default policy for INPUT and FORWARD chains must always be DROP.

The "Paranoid" Ruleset

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

# 1. Allow loopback (essential for local services like MySQL connecting to localhost)
-A INPUT -i lo -j ACCEPT

# 2. Allow established and related connections (Stateful Inspection)
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 3. Allow SSH on our custom port, but rate limit it to prevent scanners from eating CPU
-A INPUT -p tcp -m state --state NEW -m tcp --dport 4422 -m recent --set --name SSH
-A INPUT -p tcp -m state --state NEW -m tcp --dport 4422 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
-A INPUT -p tcp -m state --state NEW -m tcp --dport 4422 -j ACCEPT

# 4. Web Traffic (HTTP/HTTPS)
-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

# 5. ICMP (Ping) - Rate limited to prevent floods
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT

# Log dropped packets (Optional: careful with disk I/O on high traffic)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

COMMIT

Save this to /etc/sysconfig/iptables (CentOS) or load it via iptables-restore.

3. Data Sovereignty and Encryption

Operating in Norway offers significant advantages regarding data protection laws compared to the US, but compliance with the Personal Data Act (Personopplysningsloven) requires vigilance. Physical security is our job (CoolVDS datacenters in Oslo utilize biometric access and 24/7 surveillance), but logical security is yours.

If you are handling sensitive customer data, disk encryption is not optional—it is a necessity. Since we provide KVM (Kernel-based Virtual Machine) virtualization, you have full access to the block device. You should be utilizing dm-crypt/LUKS for your data partitions.

Why KVM matters here: On older container technologies like OpenVZ (still common among budget hosts), you share the kernel with the host. You cannot encrypt your file system independently. With CoolVDS, your OS is isolated. You can encrypt /var/lib/mysql and mount it only when the keys are provided.

Check your I/O Scheduler

Encryption adds CPU overhead. To minimize latency impact, ensure your scheduler is optimized for our NVMe storage arrays. In 2014, deadline or noop are preferred over cfq for solid-state drives.

# Check current scheduler
cat /sys/block/vda/queue/scheduler
# [noop] deadline cfq

# If it's cfq, change it in grub.conf by adding:
elevator=noop

4. The Application Layer: SSL Perfect Forward Secrecy

Heartbleed exposed private keys across the web. If an attacker recorded your encrypted traffic from 2013 and stole your key in 2014, they could decrypt the past. Perfect Forward Secrecy (PFS) prevents this by using unique session keys.

Ensure your Nginx configuration explicitly defines the cipher suite. Do not rely on defaults.

server {
    listen 443 ssl;
    server_name secure.example.no;

    ssl_certificate /etc/nginx/ssl/bundle.crt;
    ssl_certificate_key /etc/nginx/ssl/secure.key;

    # The Critical 2014 Hardening Block
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # No SSLv3 (POODLE vulnerability)
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem; # Generate this with: openssl dhparam -out dhparam.pem 2048

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
    add_header X-Frame-Options DENY;
}

Why Infrastructure Choice Dictates Security

You can write the best iptables rules in the world, but if your hosting provider is noisy or oversubscribes resources, your security monitoring will be useless. Spike in CPU? Is it a DDoS attack, or just your neighbor running a heavy cron job?

At CoolVDS, we isolate resources strictly. When you see a load average of 0.00, it's 0.00. This clarity is essential for detecting anomalies that indicate a breach. Furthermore, our direct peering at NIX (Norwegian Internet Exchange) ensures that your traffic to Norwegian users stays within the country, reducing the hops where interception could theoretically occur.

Security in late 2014 is about removing variables. Remove the weak passwords. Remove the unnecessary open ports. Remove the "noisy neighbor" variable.

Ready to build your fortress? Deploy a high-performance KVM instance in our Oslo datacenter today. It takes 55 seconds to get root.