Paranoia as a Policy: Implementing Zero-Trust Networking on Linux

The Castle is Burning: Why Perimeter Security Fails

If you are still relying solely on a hardware firewall to protect your infrastructure, you are already breached; you just don't know it yet. The old school mentality—the "crunchy shell, soft center" approach—is dangerous. We saw this with the DigiNotar breach in 2011 and the LinkedIn leak last year. Once an attacker breaches the perimeter, the internal network (LAN) is usually wide open. In the hosting world, this is suicide.

Enter the Zero Trust model. Coined by Forrester, the concept is simple: Never Trust, Always Verify.

As a sysadmin managing servers, I treat every packet hitting my eth0 interface as hostile, even if it comes from the database server sitting right next to it in the rack. In Norway, where data privacy under the Personopplysningsloven (Personal Data Act) is strictly enforced by Datatilsynet, we cannot afford to be lax. Here is how to lock down your CoolVDS instance using tools available right now in 2013: CentOS 6, IPTables, and OpenVPN.

1. Kill the Shared Kernel (Why KVM Matters)

Before we touch a single config file, we must talk about virtualization. Many budget hosts in Europe are still pushing OpenVZ. OpenVZ uses a shared kernel. If a vulnerability is found in the host kernel, every container is potentially compromised. You cannot build a secure fortress on a foundation of sand.

This is why strict isolation is non-negotiable. At CoolVDS, we strictly use KVM (Kernel-based Virtual Machine). You get your own kernel. You can load your own SELinux modules. If your neighbor gets hacked, your memory space remains encrypted and isolated. Do not run mission-critical databases on container-based virtualization.

2. IPTables: Default DROP is Your Best Friend

Most sysadmins configure iptables to ACCEPT everything and then block bad guys. That is backward. In a Zero Trust model, we DROP everything and only whitelist specific IPs and ports. Even internal traffic between your Web Node and your DB Node must be explicitly allowed.

Here is a standard "Paranoid" configuration for a Web Node on CentOS 6.4:

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

# 1. Allow loopback (essential for local services)
-A INPUT -i lo -j ACCEPT

# 2. Allow established connections (stateful inspection)
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# 3. Allow SSH only from your VPN or Office Static IP
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -s 85.x.x.x -j ACCEPT

# 4. Allow HTTP/HTTPS from the world
-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. LOG everything else before dropping (crucial for forensics)
-A INPUT -j LOG --log-prefix "IPTables-Dropped: "
COMMIT

This configuration ensures that even if someone plugs a laptop into the switch at the datacenter, they cannot talk to your SSH port unless they spoof your specific IP.

Pro Tip: Save your rules. On RHEL/CentOS systems, running service iptables save is mandatory. I've seen seasoned admins lose their firewall rules after a reboot. Don't be that guy.

3. Encryption Inside the Wire

In 2013, computing power is cheap enough that we don't need to offload SSL at the load balancer. We can afford end-to-end encryption. If you are running MySQL, traffic usually flows over port 3306 in cleartext. If an attacker runs tcpdump on the switch, they have your customer data.

Force MySQL to use SSL. Generate your certs using OpenSSL and configure my.cnf:

[mysqld]
ssl-ca=/etc/mysql-ssl/ca-cert.pem
ssl-cert=/etc/mysql-ssl/server-cert.pem
ssl-key=/etc/mysql-ssl/server-key.pem

# Force SSL for specific users
# GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'10.0.0.5' REQUIRE SSL;

Does this add latency? Yes. On a standard HDD VPS, the handshake might cost you a few milliseconds. But CoolVDS leverages high-performance storage arrays that mitigate the I/O wait often associated with logging encrypted traffic. The trade-off is negligible compared to the security gain.

4. Management via VPN Only

Exposing SSH (Port 22) to the public internet is inviting a brute-force attack. Even with Fail2Ban, you are relying on reactive security. The Zero Trust way is to hide the door entirely.

Deploy an OpenVPN server on a dedicated small instance (a "Jump Box"). Configure your backend servers to only accept SSH connections from the VPN's internal IP range (e.g., 10.8.0.0/24).

OpenVPN 2.0 Server Config Snippet:

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
push "route 192.168.10.0 255.255.255.0"
cipher AES-256-CBC
auth SHA256
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Note the use of AES-256-CBC. Blowfish is the default in many tutorials, but in 2013, with the rise of stronger cryptanalysis, AES is the requisite standard for compliant hosting in Europe.

Performance vs. Security: The CoolVDS Balance

Security adds overhead. Encryption eats CPU cycles. Firewall inspection adds micro-latency. This is why hardware matters. If you try to run a fully encrypted, Zero Trust architecture on a generic VPS oversold by 300%, your application will crawl.

Our infrastructure is located in Oslo with direct peering to NIX. This low latency offsets the overhead introduced by your encryption layers. You get the security of a bank vault with the speed of a startup.

Final Thoughts

The Personal Data Act in Norway puts the responsibility on you, the data controller, to secure client information. "I didn't know" is not a legal defense. By moving to KVM-based virtualization, enforcing strict IPTables policies, and encrypting internal traffic, you move from a "Soft Center" architecture to a Zero Trust stronghold.

Don't wait for the next major exploit to patch your systems. Provision a KVM instance on CoolVDS today and build your architecture correctly from packet one.