The Perimeter is a Lie: Implementing Zero Trust Before GDPR Hits

I still see it every day. A Senior Sysadmin logs into a jump box, tunnels into a production database, and assumes everything is fine because the firewall port 3306 is blocked from the public internet. They trust the LAN. They trust the private IP range.

Stop doing that.

The concept of a "trusted internal network" is the biggest liability in modern hosting. Google realized this years ago with BeyondCorp. Now, with the EU General Data Protection Regulation (GDPR) enforcement date set for next year (May 2018), relying on a castle-and-moat architecture isn't just bad practice; it's a regulatory time bomb waiting to explode in your face.

If an attacker compromises your web node, they shouldn't have free reign to talk to your database just because they are on the same subnet. In this guide, we are going to implement a basic Zero-Trust model using tools available right now on CentOS 7 and Ubuntu 16.04.

1. The Philosophy: Never Trust 192.168.x.x

Zero Trust is simple: Authenticate every packet. It doesn't matter if the request comes from a laptop in a coffee shop in Oslo or a server in the same rack in our CoolVDS datacenter. Treat every interface as public.

When I deploy high-performance infrastructure, I assume the network is hostile. This reduces the blast radius of a breach from "total company liquidation" to "one compromised container."

2. Hardening the Host with iptables

Most VPS providers give you a template and wish you luck. That’s lazy. On a raw KVM instance, your first line of defense is the kernel's packet filter. We aren't using UFW wrapper scripts here; we want precise control.

Here is a battle-tested iptables configuration for a web node. It drops everything by default—including outbound traffic you didn't explicitly authorize.

# Flush existing rules
iptables -F

# Set default policies to DROP. 
# If you don't allow it, it doesn't happen.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT # strict outbound filtering is complex, start here

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

# Allow established connections (don't break your own SSH session)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (limit this to your specific management IP later)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

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

# ICMP (Ping) - Rate limit to prevent flooding
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

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

Pro Tip: On CoolVDS, we provide VNC console access. This is your safety net. If you apply a rule that locks you out of SSH, use the out-of-band console to revert it. Never apply firewall rules remotely without a backup access method.

3. Mutual Authentication for Internal Services

If you have a Web Server talking to a Database Server, the Database should not just check the IP address. It should check an identity key. Since we can't easily do mutual TLS (mTLS) on everything without high overhead (and Istio isn't quite ready for prime time yet), we use SSH tunnels or SSL client certificates.

For a MySQL setup, force SSL. In your my.cnf on the server:

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

On the client (Web Node), do not connect to port 3306 without the certs. This ensures that even if someone spoofs an IP on the private network (ARP spoofing), they can't query your data without the private key.

4. SSH: The Front Door

Passwords are dead. If you are still using passwords for root access, you are failing your audit. Here is the standard /etc/ssh/sshd_config block I deploy on every CoolVDS instance immediately after provisioning:

Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
AllowUsers deploy_user

Combine this with Google Authenticator for MFA on SSH login. It takes 5 minutes to set up and eliminates 99% of brute force risks.

5. The Norwegian Context: Data Sovereignty

We are seeing a massive shift in 2017. The fallout from the Safe Harbor invalidation is still settling, and Privacy Shield is... shaky at best. Clients in Oslo are demanding to know exactly where their bits live.

This is why physical location matters. Latency is one thing—pinging an NVMe drive in Oslo from Bergen takes milliseconds—but legal jurisdiction is another. Hosting on CoolVDS ensures your data physically resides in Norway, under Norwegian law and Datatilsynet guidelines, not on a cloud replated across three continents subject to the US Patriot Act.

Performance vs. Security Trade-off

You might notice a CPU overhead with encryption. This is where hardware matters. We utilize KVM virtualization on CoolVDS because it exposes CPU instructions (AES-NI) directly to the guest OS. This hardware acceleration makes SSL offloading negligible on modern processors. Containers (OpenVZ) often struggle here due to shared kernel resources.

Conclusion

Zero Trust isn't a product you buy; it's a mindset that assumes breach is inevitable. By locking down iptables, enforcing SSL internally, and ensuring your data residency is legally sound in Norway, you are doing more than just "sysadmin work." You are protecting the business.

Next Step: Don't test firewall rules in production. Spin up a sandbox instance on CoolVDS—our NVMe storage means you can provision, break, and re-provision a CentOS 7 node in under 55 seconds.