The Death of the Perimeter: Implementing Zero Trust Architecture on Linux in 2014

If the last few months have taught us anything, between Heartbleed in April and the absolute disaster that was Shellshock in September, it is this: your internal network is a war zone. The old philosophy of "hard shell, soft center"—the Castle and Moat approach—is officially obsolete. If an attacker breaches your firewall via a Bash vulnerability, and your internal network trusts every private IP, you are finished.

As a sysadmin operating in the Nordic region, you are likely dealing with strict compliance requirements under the Personal Data Act (Personopplysningsloven). The Datatilsynet (Norwegian Data Protection Authority) does not care if your firewall was expensive if your customer database was exfiltrated by a script kiddie pivoting from a compromised web server.

It is time to adopt the Zero Trust model. The concept, championed by Forrester Research, is simple: Never Trust, Always Verify. Treat your internal VLANs as if they were the public internet.

1. The Foundation: Host-Based Firewalls (Because VLANs Leak)

Too many administrators rely solely on the edge firewall. In a Zero Trust environment, every single node must defend itself. We are not just talking about blocking port 80; we are talking about strict egress filtering.

If your database server initiates a connection to an IRC server in Russia, that is a problem. Yet, default iptables policies often allow all outgoing traffic. Stop that immediately.

The Configuration

Here is a battle-tested iptables script for a standard web node running on Ubuntu 14.04 LTS. This drops everything by default—including outgoing traffic—and only whitelists what is necessary.

# Flush existing rules
iptables -F

# Set Default Policies to DROP (The Zero Trust Standard)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Allow loopback (critical for local processes)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Limit to your Management VPN IP if possible)
iptables -A INPUT -p tcp --dport 22 -s 192.168.10.5 -j ACCEPT

# Allow HTTP/HTTPS (Public)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow Outgoing DNS (UDP/TCP) - Specific DNS resolvers only
iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -d 8.8.8.8 -j ACCEPT

# Allow Outgoing NTP
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT

# Log dropped packets (for auditing)
iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

Pro Tip: On CoolVDS KVM instances, we provide VNC console access. This is your lifeline. If you botch the firewall rules and lock yourself out of SSH (we've all been there), use the VNC console in the client portal to reset the rules. Do not try this on a bare-metal server without IPMI unless you enjoy driving to the data center at 3 AM.

2. Kill Passwords: SSH Keys and 2FA

If you are still using password authentication for SSH, you are wrong. Brute force bots scanning the Norwegian IP ranges are relentless. In 2014, there is no excuse for not using 2048-bit RSA keys (or ECDSA if you're feeling modern).

However, keys can be stolen. To truly implement Zero Trust, you need Multi-Factor Authentication (MFA) at the shell level. We can use the libpam-google-authenticator package to enforce a Time-based One-Time Password (TOTP) upon login.

Implementation Guide

First, install the PAM module:

sudo apt-get install libpam-google-authenticator

Run the initialization tool and follow the prompts to generate your QR code:

google-authenticator

Now, edit /etc/pam.d/sshd and add this line at the bottom:

auth required pam_google_authenticator.so

Finally, tell SSH to use it. Edit /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
PasswordAuthentication no
UsePAM yes

Restart SSH. Now, even if an attacker scrapes your private key from a developer's laptop, they cannot access your CoolVDS instance without the physical token.

3. Encryption Inside the Wire

A core tenant of Zero Trust is assuming the network is tapped. If you are running a MySQL database and your web server connects to it over unencrypted TCP, you are leaking data. "But it's on a private LAN!" implies trust. We do not trust the LAN.

You must enable SSL for internal services. Yes, there is a CPU overhead, but with the AES-NI instruction set found in the modern Intel Xeon processors we use at CoolVDS, this overhead is negligible.

MySQL SSL Configuration

Generate your CA, server, and client certificates using OpenSSL. Then, configure your my.cnf to force SSL:

[mysqld]
ssl-ca=/etc/mysql/certs/ca-cert.pem
ssl-cert=/etc/mysql/certs/server-cert.pem
ssl-key=/etc/mysql/certs/server-key.pem
bind-address = 0.0.0.0
require_secure_transport = ON

This ensures that no connection can occur without encryption. This is vital for complying with Norwegian privacy standards regarding sensitive user data.

4. Isolation Technology: KVM vs. Containers

This brings us to the infrastructure layer. There is a lot of buzz around containers (Docker 1.0 was just released in June), and OpenVZ has been around for ages. But from a security standpoint, shared kernels are a risk vector. A kernel panic or exploit in one container can theoretically impact neighbors.

This is why CoolVDS strictly uses KVM (Kernel-based Virtual Machine) virtualization. KVM provides hardware-level virtualization.

With KVM, you can run your own custom kernel with Grsecurity patches if you are truly paranoid (which you should be). You cannot do that on a budget OpenVZ VPS.

5. The Management Plane: OpenVPN

Never expose your administrative ports (22, 3306, 8080) to the public internet, even with 2FA. The cleanest approach is to deploy an OpenVPN Access Server. Your team connects to the VPN, and your iptables rules allow access only from the VPN's virtual IP range (e.g., 10.8.0.0/24).

This creates a software-defined perimeter. The only port visible to the world is UDP 1194.

Conclusion

The threat landscape in late 2014 is aggressive. Between state-sponsored actors and automated botnets, assuming your internal network is safe is professional negligence. By implementing strict egress filtering, internal encryption, and utilizing robust virtualization like KVM, you build a fortress that doesn't rely on a moat.

Security requires stable, predictable infrastructure. If you need a hosting partner that understands the difference between "cheap hosting" and "secure infrastructure," check out our KVM-based NVMe-cached instances.

Secure your stack today. Deploy a CoolVDS instance in Oslo and start building your Zero Trust architecture.