The Perimeter is a Lie: Why You Need Zero Trust in 2013

For the last decade, we have built our infrastructures like medieval castles. We dig a deep moat (the firewall), pull up the drawbridge (VPN), and assume that everyone inside the walls is a loyal subject. But in an era of BYOD, mobile access, and increasingly sophisticated persistent threats, this model is fundamentally broken.

If you are still operating on the assumption that your internal LAN is a "trusted zone," you are already compromised. The new paradigm, championed effectively by Forrester Research, is Zero Trust. The concept is brutally simple: Never trust, always verify. Packet source means nothing. Inside or outside the perimeter—it does not matter.

As a Systems Architect working with high-compliance data in Norway, I have seen the damage a "soft center" network can do. Once an attacker breaches the edge—perhaps via a SQL injection on a forgotten marketing microsite—they have free rein to scan, pivot, and attack your core database because your internal iptables policies were set to ACCEPT for local subnets.

Today, we are going to tear down the trusted LAN and build a verified network on top of CoolVDS infrastructure, using tools available to us right now in 2013: CentOS 6, iptables, and OpenSSL.

The Core Principle: Micro-Segmentation

In a traditional VPS setup, you might have a Web Server and a Database Server connected via a private backend network (e.g., 10.0.0.x). Most sysadmins simply allow all traffic on eth1. This is negligent.

Zero Trust demands that the Database Server treats the Web Server with the same suspicion it treats a random IP from the internet. It should only accept traffic on port 3306, only from the specific Web Server IP, and ideally, only over an encrypted channel.

1. Host-Based Firewalls are Mandatory

Do not rely solely on the perimeter firewall provided by your datacenter or the CoolVDS panel. You need aggressive local firewalling. On a standard CentOS 6 node, this means mastering iptables.

Here is a configuration snippet for a Database node that implements a "default drop" policy even for the private interface:

# Flush existing rules
iptables -F

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

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

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

# SSH - ONLY from your specific Management IP (Verify identity!)
# Replace 1.2.3.4 with your office static IP
iptables -A INPUT -p tcp --dport 22 -s 1.2.3.4 -j ACCEPT

# MySQL - ONLY from the specific Web Server Private IP
# Replace 10.0.0.5 with your Web Node IP
iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.5 -j ACCEPT

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

# Save rules
service iptables save
service iptables restart

This configuration ensures that if a neighbor on the private network gets compromised (a "noisy neighbor" scenario, which is mitigated by CoolVDS's strict KVM isolation but still a risk on shared LANs), they cannot touch your database.

2. Encryption Everywhere (Even on the LAN)

Cleartext HTTP and Telnet are dead. But many admins still run cleartext SQL or HTTP between their load balancer and web servers because "it's a private network" and "encryption adds latency."

In 2013, with the CPU power available on modern Xeon E5 processors (standard on CoolVDS), the latency argument is weak. The risk of packet sniffing on the wire—even a virtual wire—is real. Zero Trust mandates encryption for data in transit, regardless of the network location.

Securing MySQL Replication with SSL

If you are replicating data between your primary node in Oslo and a backup node in, say, Frankfurt, you must use SSL. Here is how to enforce it in my.cnf:

[mysqld]
# Enforce SSL for all connections
ssl-ca=/etc/mysql/cacert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

# Force clients to use SSL
# (Requires MySQL 5.6 or strictly configured grants in 5.5)

When creating the replication user, force the requirement:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.%' IDENTIFIED BY 'SolidPassword123' REQUIRE SSL;

3. Identity Management: Death to Passwords

Passwords are the weakest link. For SSH access, password authentication should be disabled globally. We rely on 2048-bit (or 4096-bit if you are paranoid) RSA keys.

Pro Tip: Data sovereignty is a major concern here in Norway. The Personal Data Act (Personopplysningsloven) puts strict requirements on how we handle personal data. By ensuring that only keys stored on authorized devices can access your servers, you create a robust audit trail that satisfies Datatilsynet requirements.

Modify your /etc/ssh/sshd_config to explicitly reject the old ways:

# Disable Protocol 1 (Ancient, insecure)
Protocol 2

# Disable Root Login (Audit trail requires individual users)
PermitRootLogin no

# Disable Passwords completely
PasswordAuthentication no
PermitEmptyPasswords no

# Use Keys
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit users
AllowUsers admin_johan deploy_bot

Why Infrastructure Choice Matters

You cannot build a secure house on quicksand. While you can implement software firewalls anywhere, the underlying hypervisor matters. This is why I deploy critical workloads on CoolVDS.

Many providers in the budget segment use OpenVZ. In OpenVZ, you share the kernel with every other container on the host. A kernel exploit (like the recent ones affecting 2.6.32 kernels) can potentially allow a container escape, rendering your internal Zero Trust policies moot.

CoolVDS uses KVM (Kernel-based Virtual Machine). Each instance runs its own kernel. This hardware-assisted virtualization provides the isolation of a dedicated server with the flexibility of the cloud. Furthermore, their datacenters in Oslo connect directly to NIX (Norwegian Internet Exchange), ensuring your data doesn't unnecessarily route through foreign jurisdictions—a key component of legal compliance.

Performance vs. Security?

The common counter-argument to Zero Trust is performance. "Checking iptables and decrypting SSL for every packet is slow."

Let's look at the reality. We ran a benchmark on a CoolVDS SSD-backed instance comparing raw HTTP vs HTTPS (using Nginx 1.2.6 and OpenSSL 1.0.1). The latency difference was measurable but negligible for business logic:

Is losing 6ms worth preventing a total data breach? Absolutely.

The Verification Imperative

Zero Trust is not a product you buy; it is a mindset. It requires you to look at your architecture and assume breach. If the web server is compromised, can it read the entire database? Or only the rows it needs?

Start small. Audit your iptables. Generate SSH keys. Turn on SSL for your internal services. And verify your hosting partner respects data sovereignty as much as you do.

Ready to harden your infrastructure? Don't risk your data on oversold, insecure containers. Deploy a KVM-based, SSD-accelerated instance on CoolVDS today and build your fortress correctly from day one.