The Perimeter is Dead: Building a "Zero Trust" Infrastructure on Linux in 2015

Let’s be honest: your firewall isn’t enough. For the last decade, sysadmins have relied on the castle-and-moat strategy. We build a massive firewall (the castle walls) and assume everything inside the LAN is safe (the soft, chewy center). In 2015, this architecture is not just outdated; it is negligent.

Between the Snowden leaks confirming sophisticated internal snooping and the rise of BYOD (Bring Your Own Device), the concept of a "trusted network" is a myth. If an attacker breaches your web server, they shouldn't have an open highway to your database. This is where the Zero Trust model comes in. Popularized recently by Forrester and exemplified by Google's new "BeyondCorp" initiative, the philosophy is simple: Never trust, always verify.

I've spent the last week auditing a client's infrastructure that was supposedly "secure" behind a corporate VPN. It took me ten minutes to pivot from a compromised dev box to their production SQL server. Why? Because the internal network allowed all traffic. Here is how you lock that down, specifically for Norwegian businesses concerned with data sovereignty and latency.

1. Identity is the New Perimeter

In a Zero Trust environment, the network location implies nothing about authority. Access depends on who you are, not where you are. On a Linux VPS, this starts with SSH.

If you are still using password authentication, stop. Brute force botnets are scanning IP blocks in Oslo every second. You need key-based authentication combined with Two-Factor Authentication (2FA).

Edit your /etc/ssh/sshd_config to explicitly deny passwords and root login:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes

Then, install the libpam-google-authenticator package. This forces a Time-based One-Time Password (TOTP) prompt upon login. Even if someone steals your private RSA key, they can't get in without your phone.

2. Micro-segmentation with iptables

Many hosting providers drop you into a flat VLAN where you can ping your neighbors. That is a security nightmare. At CoolVDS, we isolate customer networks, but you must secure the traffic between your own servers.

Do not rely on a perimeter firewall alone. Every single server must run its own firewall. If you have a Web Node and a DB Node, the DB Node should accept traffic on port 3306 only from the Web Node's private IP. Drop everything else.

Here is a battle-tested iptables snippet for a database server:

# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

# Allow MySQL ONLY from the Web Server Private IP
iptables -A INPUT -p tcp -s 10.10.0.5 --dport 3306 -j ACCEPT

Pro Tip: Always verify your rules with iptables -L -v -n before saving. Nothing is more embarrassing than locking yourself out of a remote server and having to use the VNC console to fix it.

3. Encryption in Transit (Internal)

In the old model, we only used SSL/TLS for public traffic (HTTPS). Inside the datacenter, traffic often flows in plain text. In 2015, this is unacceptable. If an intruder sniffs the internal network, they capture SQL queries and session cookies.

You must encrypt traffic between your application and your database. MySQL supports SSL connections. Configure it in 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

Yes, there is a CPU overhead for encryption. This is where hardware selection matters. Cheap VPS providers oversell their CPU cores, leading to "steal time" that kills SSL performance. CoolVDS instances run on high-frequency cores with dedicated resource allocation, meaning that SSL handshake overhead is negligible.

4. The KVM Factor and Data Sovereignty

Software security means nothing if the virtualization layer is compromised. Many budget hosts use OpenVZ, a container-based technology where all VPS instances share the host kernel. If a kernel exploit is found, a neighbor could theoretically break out of their container and access your memory.

For a Zero Trust architecture, you need Kernel-based Virtual Machine (KVM). KVM provides hardware-level virtualization. Each CoolVDS instance runs its own isolated kernel. This is the closest you can get to a dedicated server without the dedicated price tag.

Furthermore, consider the physical location of your data. With the ongoing scrutiny of the Safe Harbor agreement and the aggressive reach of the US Patriot Act, hosting sensitive data outside of Norway is a liability. Datatilsynet (The Norwegian Data Protection Authority) is strict. Storing your data on CoolVDS servers in Oslo ensures you are protected by Norwegian privacy laws, not subject to foreign subpoenas.

Conclusion

Zero Trust isn't a product you buy; it's a mindset. It requires assuming that your network is already compromised and designing your systems to survive anyway. By hardening SSH, enforcing strict iptables rules, and encrypting internal traffic, you drastically reduce your attack surface.

Don't build your security architecture on a shared kernel or a flat network. Start with a solid foundation. Deploy a KVM-based instance on CoolVDS today and build a fortress, not a fence.