Stop Trusting Your LAN: The Zero Trust Mandate

If the events of 2013 taught us anything—specifically the NSA leaks—it is that the concept of a "secure internal network" is a dangerous hallucination. For years, sysadmins have operated on a crunchy-shell, soft-center model: a heavy firewall at the edge, and a free-for-all LAN inside where database ports are open and authentication is lax. That era is over. If an attacker breaches your web server, they shouldn't own your infrastructure.

John Kindervag at Forrester calls this "Zero Trust." It sounds like marketing buzz, but the engineering reality is brutal and necessary: never trust, always verify. It doesn't matter if the packet comes from a Chinese IP or the server sitting next to you in the rack. Treat every interface as public.

In this guide, we are going to lock down a standard LAMP stack running on CoolVDS infrastructure in Oslo. We aren't just setting up a firewall; we are architecting an environment where even a compromised node cannot pivot to destroy your data. We will use tools available right now in CentOS 6.5 and Debian 7: iptables, OpenVPN, and strict SSH hardening.

1. The Foundation: KVM over OpenVZ

Security starts at the hypervisor. In the budget VPS market, OpenVZ is popular because it allows providers to oversell resources. But OpenVZ shares the host kernel. If there is a kernel exploit, container isolation can crumble. This is why for serious security work, we only deploy on KVM (Kernel-based Virtual Machine).

At CoolVDS, we use KVM to ensure your memory and kernel space are strictly isolated from the "noisy neighbors" next door. You cannot build a Zero Trust architecture if you can't even trust the separation between your OS and the hardware.

Pro Tip: Check your virtualization type. Run virt-what or check /proc/cpuinfo. If you don't see hardware virtualization flags, you aren't truly isolated.

2. The Death of "Allow All": Strict Iptables Strategy

Most default iptables configurations allow all traffic on the loopback and internal interfaces. In a Zero Trust model, we explicitly define every flow. We don't care that 192.168.1.5 is our database server; we still filter the traffic.

Here is a battle-tested iptables script for a web node. It drops everything by default and only opens what is strictly necessary. Note the logging—if packets are dropped, we want to know why.

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

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

# 2. Allow Loopback (Required for local services like PHP-FPM -> Nginx)
-A INPUT -i lo -j ACCEPT

# 3. SSH (Moved to non-standard port 2222 in sshd_config)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2222 -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 flood
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT

# 6. Log dropped packets (Crucial for forensics)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-dropped: " --log-level 7

COMMIT

Save this to /etc/sysconfig/iptables (CentOS) or use iptables-save (Debian). Do not rely on your hosting provider's external firewall alone. Defense in Depth requires host-based firewalls.

3. Encryption Inside the Perimeter

The old logic was: "SSL terminates at the load balancer; traffic to the app server is cleartext." This is unacceptable in 2014. If someone taps the switch or ARP poisons the segment, they capture your SQL queries. You must encrypt traffic between your Load Balancer (Nginx) and your App Servers, and between App Servers and the Database.

Is it a performance hit? Yes, SSL handshakes consume CPU. This is why CoolVDS emphasizes high-frequency CPUs in our Oslo datacenter. We need that raw compute to handle the crypto overhead without adding latency to the user experience.

MySQL over SSL

By default, MySQL sends data in cleartext. To enable SSL, first generate your certs (CA, server-cert, server-key), then add this to your my.cnf:

[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

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

Verify it works by logging in and running SHOW STATUS LIKE 'Ssl_cipher';. If it returns a value, your internal data pipe is encrypted.

4. Management Access: VPN or Die

Never expose your database (port 3306) or backend management ports to the public internet, even with strong passwords. Brute force attacks are getting smarter, and 0-day vulnerabilities in services are inevitable.

The solution is an OpenVPN bridge. We run a lightweight OpenVPN server on a hardened CoolVDS instance. Developers connect to the VPN, and only the VPN IP is whitelisted in the security groups of the critical infrastructure.

Here is a snippet for server.conf to push internal routes to clients:

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 to the private subnet
push "route 10.10.0.0 255.255.255.0"

# Security settings
cipher AES-256-CBC
auth SHA512
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

5. Compliance and Data Sovereignty in Norway

We are seeing increasing scrutiny from Datatilsynet (The Norwegian Data Protection Authority). While the EU Data Protection Directive (95/46/EC) sets the baseline, Norwegian implementation via Personopplysningsloven requires strict control over where personal data resides.

Hosting outside of Europe (like in the US) is becoming legally risky due to the Patriot Act. By keeping your data on CoolVDS servers physically located in Norway, you simplify compliance. Latency is just physics—serving Norwegian users from Oslo (approx. 5-10ms) versus Amsterdam (25ms) or Virginia (100ms+) makes a tangible difference in application responsiveness. But beyond speed, it's about legal jurisdiction. Your data stays here.

6. SSH Hardening: The Final Lock

Finally, we secure the front door. Passwords are dead. If you are still using password authentication for SSH in 2014, you are negligent. Use 4096-bit RSA keys.

Edit /etc/ssh/sshd_config:

Port 2222                   # Security through obscurity helps reduce log noise
Protocol 2
PermitRootLogin no          # Log in as user, then su/sudo
PasswordAuthentication no   # Keys only
UseDNS no                   # Faster logins
AllowUsers deploy master    # Whitelist specific users

For the paranoid (like us), implement Two-Factor Authentication (2FA) on SSH using libpam-google-authenticator. It requires you to enter a code from your phone after your SSH key is accepted.

Conclusion

Zero Trust is not a product you buy; it is a mindset of verified paranoia. It requires more work. It requires managing certificates, VPN configs, and complex firewall rules. But when the next major vulnerability hits the headlines—and it will—you won't be scrambling.

Don't build your fortress on sand. Start with a solid foundation. Deploy a KVM-based CoolVDS instance today, and build an architecture that assumes the worst so you can deliver the best.