Trust No One: Architecting "Zero Trust" Infrastructure Post-PRISM

The era of the "trusted internal network" ended last month. If the recent PRISM leaks and the steady stream of revelations from Edward Snowden have taught us anything, it is that the perimeter is a lie. As a systems architect operating out of Oslo, I see too many companies relying on a crunchy outer shell (a corporate firewall) and a soft, chewy center where servers talk to each other without authentication. That architecture is obsolete.

In the hosting world, specifically here in Norway where we value our privacy under the Personopplysningsloven, we need to adopt a stance of Zero Trust. This concept, championed by Forrester, assumes that the network is always hostile. Whether the threat is a script kiddie, a disgruntled employee, or a state-level actor sniffing fiber taps, your defense strategy must remain the same: verify every packet.

Today, we are going to burn the old "trusted LAN" playbook and configure a CentOS 6 environment that trusts absolutely nothing.

The War Story: The "Internal" Breach

I recently audited a media agency that utilized a hybrid setup. They had a robust hardware firewall, but once inside, their database server accepted connections from 0.0.0.0/0 with a root password that was, frankly, embarrassing. They assumed their provider's private VLAN was a sanctuary.

It wasn't. A compromised web node on the same private subnet (due to an outdated WordPress plugin) allowed an attacker to pivot laterally. They dumped the entire user database in seconds. The lesson? Network proximity does not imply trust.

1. The Foundation: KVM Isolation

Before we touch a config file, we must talk about the metal. In 2013, virtualization creates its own risks. If you are running on OpenVZ or similar container-based technologies, you are sharing a kernel with every other customer on that host node. If there is a kernel panic or a privilege escalation vulnerability in the shared kernel, your "security" is theoretical.

This is why we strictly deploy on KVM (Kernel-based Virtual Machine) at CoolVDS. KVM provides full hardware virtualization. Each VPS runs its own isolated kernel. If a neighbor gets compromised, your memory space remains encrypted and distinct. In a Zero-Trust model, isolation is the first layer of defense.

2. Network Layer: Iptables is Your God

Forget passive firewalls. We need aggressive packet filtering on the host itself. The policy for INPUT must be DROP by default. We do not REJECT; we DROP. We want to be a black hole to scanners.

Here is a baseline iptables configuration for a web server that assumes the network is hostile:

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

# Allow loopback (essential for local services like php-fpm connecting to mysql)
-A INPUT -i lo -j ACCEPT

# Allow established connections (keep your SSH session alive!)
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# SSH - LIMIT RATE to prevent brute force
# If they hit port 22 more than 3 times in 60 seconds, ban them.
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
-A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP/HTTPS
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# ICMP - Allow ping but limit rate to prevent floods
-A INPUT -p icmp -m limit --limit 1/sec -j ACCEPT

COMMIT

Save this to /etc/sysconfig/iptables and restart the service. Note the SSH rate limiting. Even with keys, we don't want the logs filling up with noise.

3. Transport Layer: The Overlay Network

If you have a database server and a web server, they should not communicate over the public interface, nor should they trust the provider's "private network" blindly. We build our own tunnel.

OpenVPN is the standard here. By setting up a tunneled interface (tun0), we can encrypt traffic between your CoolVDS instances using 2048-bit RSA keys. Even if someone sniffs the switch traffic, they see garbage.

Server Config Snippet (server.conf):

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Once the tunnel is up, bind your MySQL or Redis services only to the 10.8.0.x IP address. This makes them completely invisible to the public internet.

Pro Tip: Generate your Diffie-Hellman parameters (dh2048.pem) on a local machine with high entropy, not on a fresh VPS that hasn't gathered enough random noise yet. It prevents weak key generation.

4. SSH Hardening: Keys or Death

Passwords are dead. Brute force attacks are constant. Edit your /etc/ssh/sshd_config to explicitly forbid password authentication. Furthermore, restrict which users can log in.

# /etc/ssh/sshd_config
Port 22
Protocol 2
# Disabling root login is mandatory
PermitRootLogin no
# Keys only
PasswordAuthentication no
UsePAM no
AllowUsers deployer_user
# Remove weak ciphers (ArCFour/RC4 is weak)
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Combined with the iptables rate limiting above, your management port becomes a fortress.

5. Data Location and Jurisdiction

Technology is only half the battle. The other half is legal. With the Datatilsynet keeping a close watch on data privacy in Norway, where your data physically sits matters.

Hosting on US-owned clouds subjects your data to the US Patriot Act. This is the core concern driving the current migration back to local infrastructure. CoolVDS infrastructure is physically located in Oslo data centers, operating under Norwegian jurisdiction. We use high-performance SSD RAID-10 arrays (the fastest I/O currently available on the market) to ensure that encryption overhead doesn't kill your throughput.

Conclusion

Zero Trust is not a product you buy; it is a mindset. It implies that you verify identity at every step: the network interface, the SSL handshake, and the SSH login.

The days of the soft internal network are over. You need isolation, encryption, and jurisdiction you can trust. If you are ready to build a fortress, start with a platform that respects hardware isolation.

Don't leave your data exposed to the open web. Deploy a secure, KVM-based instance on CoolVDS today and lock down your infrastructure properly.