Perimeter Security is Dead: Implementing Zero-Trust on Linux in the Wake of Shellshock

If the last six months have taught us anything, it is that the "soft chewy center" of our infrastructure is a liability. First, we scrambled to patch OpenSSL against Heartbleed. Then, just weeks ago, Shellshock (CVE-2014-6271) ripped through our Bash terminals, proving that even internal services are vulnerable if a single vector is compromised.

The era of the "Castle and Moat"—where you trust everything inside your firewall and fear everything outside—is over. If an attacker breaches your perimeter via a web app vulnerability, and your database trusts the web server implicitly, game over. It is time to adopt a Zero-Trust model. Trust no one. Not even localhost.

In this guide, we are going to tear down the assumption of the "trusted LAN" and build a hardened environment where every packet is verified. We will look at practical implementations using CentOS 6/7, iptables, and proper KVM isolation, specifically tailored for infrastructure hosted here in Norway.

The Hardware Reality: Why Virtualization Matters

Before touching a config file, we must address the substrate. Zero-Trust requires absolute isolation. In the budget hosting market, many providers push OpenVZ containers. While efficient, OpenVZ shares a kernel. If a kernel-level exploit hits, the isolation between tenants dissolves.

For a true Zero-Trust architecture, you need Hardware Virtualization (HVM). We use KVM (Kernel-based Virtual Machine) at CoolVDS because it acts like a dedicated server. Your memory is yours. Your kernel is yours. If a neighbor gets hit by a DDoS or runs a fork bomb, your latency remains stable.

Pro Tip: When selecting a VPS in Oslo or elsewhere in Europe, verify the virtualization type. If `uname -a` shows a kernel version ending in `stab` (e.g., `2.6.32-042stab...`), you are in a container. Get out if security is your priority.

Phase 1: Death to Passwords

The first rule of Zero Trust is identity verification. Passwords are leak-prone and susceptible to brute-force attacks. We are moving strictly to SSH Keys with Two-Factor Authentication (2FA).

First, generate a 4096-bit RSA key on your local machine. Do not settle for 2048-bit in 2014.

ssh-keygen -t rsa -b 4096 -f ~/.ssh/coolvds_admin

Upload this to your server. Next, we edit /etc/ssh/sshd_config to forbid password entry entirely. This stops botnets cold.

# /etc/ssh/sshd_config
Port 2222  # Move away from standard ports to reduce log noise
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers admin_user

Adding the Second Factor (Google Authenticator)

Even if someone steals your private key, they shouldn't get in. We will use the Google Authenticator PAM module. It is robust and free.

yum install google-authenticator
# Run the setup as your user
google-authenticator

Then, modify your PAM configuration at /etc/pam.d/sshd:

# Add to the end of the file
auth required pam_google_authenticator.so

Now, access requires Something You Have (Private Key) + Something You Know (Passphrase) + Something You Generate (Token).

Phase 2: Micro-Segmentation with IPTables

In a traditional setup, the database accepts connections from any IP in the 192.168.x.x range. In Zero Trust, we whitelist explicitly. We assume the internal network is hostile.

Here is a strict iptables configuration for a web server that communicates with a database server. Note the use of the `conntrack` module to allow established connections, preventing lockouts.

# Flush existing rules
iptables -F

# Default Policy: DROP EVERYTHING
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

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

# Allow established connections (so the server can reply)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (on our custom port)
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

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

# LOG and DROP everything else
iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

For the database server, do not just open port 3306 to the subnet. Bind it to the specific private IP of the web server:

iptables -A INPUT -p tcp -s 10.0.0.5 --dport 3306 -j ACCEPT

Phase 3: Encryption in Transit (Internal)

Many sysadmins terminate SSL at the load balancer (Nginx/HAProxy) and talk to the backend over plain HTTP. This allows an intruder with `tcpdump` on the network to sniff user data.

You must encrypt internal traffic. For MySQL, this means enforcing SSL in `my.cnf`. Yes, there is a slight CPU overhead, but modern CPUs (like the Xeons we use at CoolVDS) handle AES instructions natively.

Configuring MySQL for SSL

First, generate your CA, server, and client certs using OpenSSL. Then configure the database:

[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

On the application side (e.g., PHP), ensure your PDO connection references the client certificates. Do not rely on the network to be secure.

Data Sovereignty and The "Snowden Effect"

Technical security is useless if legal security is compromised. Since the 2013 leaks regarding NSA surveillance, data sovereignty has moved from a legal footnote to a CTO-level priority. Hosting data within the US jurisdiction (or with US-owned providers subject to the Patriot Act) introduces a risk vector that cannot be patched with code.

Hosting in Norway offers a distinct advantage. We are outside the US jurisdiction and operate under the Personal Data Act (Personopplysningsloven). For Norwegian businesses, keeping latency low (often sub-5ms via NIX—the Norwegian Internet Exchange) is a performance bonus; keeping data strictly under Norwegian law is a compliance necessity.

Summary: The CoolVDS Standard

Zero Trust is not a product you buy; it is a mindset. It requires diligence, configuration management (Puppet or Chef helps here), and a refusal to accept defaults.

Do not wait for the next "Heartbleed" to audit your infrastructure. If you are running legacy systems or shared hosting, the clock is ticking.

Ready to lock down your infrastructure? Deploy a KVM instance on CoolVDS today and build your fortress on Norwegian soil.