The Death of the Perimeter: Implementing Zero-Trust Architecture in 2017

We used to trust the LAN. If a packet originated from 192.168.x.x, we assumed it was friendly. That assumption is now the single biggest liability in your infrastructure.

After the massive breaches we witnessed last year—Yahoo, LinkedIn, Dropbox—it has become painfully clear that the "castle-and-moat" security model is dead. Once an attacker breaches the outer firewall, the soft underbelly of your network is wide open for lateral movement. They jump from a compromised web server to the database, and then to the backup server, often undetected for months.

For those of us operating in Norway and the wider EEA, the stakes are even higher. The General Data Protection Regulation (GDPR) text was adopted last year and the clock is ticking toward the 2018 enforcement date. Datatilsynet will not care that you had a strong firewall if your internal data handling was negligent.

Enter the Zero-Trust model (popularized by Google's BeyondCorp initiative). The premise is simple: Never trust. Always verify. Every request, even if it comes from the server next to you in the rack, must be authenticated and encrypted.

1. Identity is the New Perimeter

In a Zero-Trust environment, IP addresses are meaningless indicators of trust. Access must be granted based on authenticated identity, not network location. Your first line of defense is hardening how you access your servers.

Passwords are dead. If you are still using password authentication for SSH in 2017, you are asking for a brute-force breach. We strictly enforce key-based authentication, and for critical entry points, Two-Factor Authentication (2FA) is mandatory.

Hardening SSH Configuration

Open /etc/ssh/sshd_config on your Ubuntu 16.04 or CentOS 7 server and ensure these directives are set. This prevents root login and disables password auth entirely.

# /etc/ssh/sshd_config

# Protocol 2 is standard, but verify it.
Protocol 2

# Disable root login. Use sudo instead.
PermitRootLogin no

# Disable password authentication. Keys only.
PasswordAuthentication no
ChallengeResponseAuthentication no

# Restrict users (optional but recommended)
AllowUsers deploymaster sysadmin

# usage of strong algorithms
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Restart the service with service sshd restart. Now, even if an attacker guesses your root password, they cannot get in without the private key.

2. Micro-Segmentation: The End of Flat Networks

Many VPS providers dump all customer instances into a massive shared subnet. This is a security nightmare. If your neighbor gets hacked, the attacker can sniff ARP traffic or launch spoofing attacks against you.

At CoolVDS, we advocate for strict isolation. We use KVM (Kernel-based Virtual Machine) virtualization which provides hardware-level isolation, unlike container-based solutions (like OpenVZ) where a kernel exploit could expose the host. Furthermore, you should utilize Private Networking to isolate your database from the public internet entirely.

Configuring the Host Firewall (IPTables)

Do not rely solely on your hosting provider's edge firewall. Every server needs its own host-based firewall. Here is a pragmatic iptables configuration that drops everything by default and only allows specific traffic. This script assumes your web server is 10.0.0.5 and DB is 10.0.0.6.

#!/bin/bash
# Flush existing rules
iptables -F

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

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

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

# Allow SSH from specific management IP only (Replace x.x.x.x)
iptables -A INPUT -p tcp --dport 22 -s x.x.x.x -j ACCEPT

# Web Server Rules (Run this on the Web Node)
# Allow HTTP/HTTPS from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Database Server Rules (Run this on the DB Node)
# ONLY allow traffic from the Web Server Private IP
iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.5 -j ACCEPT

# Save rules
/sbin/service iptables save

3. Encryption in Transit (Internal)

Historically, sysadmins didn't encrypt traffic between the Load Balancer and the Web Server, or the Web Server and the Database, because "it's on a private network" and "SSL is slow."

In 2017, these excuses are invalid. Modern CPUs with AES-NI instruction sets handle SSL encryption with negligible overhead. With the launch of Let's Encrypt leaving beta last year, certificates are free and automated.

If an attacker manages to tap your internal network, they should see nothing but garbled garbage. Configure your internal services to listen on localhost or private IPs only, and tunnel where necessary.

Pro Tip: For database connections, do not just open port 3306. Use an SSH tunnel for administration, or configure MySQL to require SSL. In my.cnf:

[mysqld]
require_secure_transport = ON
bind-address = 10.0.0.6

4. Data Sovereignty and The "Privacy Shield" Reality

Since the invalidation of the Safe Harbor agreement in 2015, reliance on US-based hosting providers has become a legal gray area for European companies. While the new "Privacy Shield" framework is currently in place, privacy advocates (including Max Schrems) are already challenging it. It is entirely possible it will face the same fate as Safe Harbor.

The safest bet for any Norwegian business is to ensure data residency within Norway or the EEA. Hosting on CoolVDS in our Oslo or European data centers ensures that your data falls under Norwegian jurisdiction, protecting you from foreign subpoenas and aligning strictly with the upcoming GDPR requirements.

5. Continuous Verification

Zero Trust is not a "set it and forget it" configuration. It requires active monitoring. You need to know when a file changes on your system.

We recommend installing AIDE (Advanced Intrusion Detection Environment). It creates a database of file hashes and alerts you if system binaries are modified—a classic sign of a rootkit.

# Install AIDE on Ubuntu/Debian
apt-get update
apt-get install aide

# Initialize the database
aideinit

# Move the database to the active location
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Run a check (add this to crontab)
aide --check

Summary: Trust No One, Encrypt Everything

The transition to a Zero-Trust architecture doesn't happen overnight. It requires a shift in mindset from "perimeter defense" to "resource defense."

1. Isolate: Use CoolVDS Private Networks to separate tiers.
2. Authenticate: Use SSH Keys and strict MySQL permissions.
3. Encrypt: SSL everywhere, even inside the LAN.
4. Locate: Keep data in Norway to avoid cross-border legal headaches.

Compliance is coming. Do not wait for May 2018 to start auditing your infrastructure. Start building a defensible network today.

Ready to lock down your infrastructure? Deploy a secure, KVM-based CoolVDS instance in Oslo today. We provide the raw NVMe performance; you provide the security policies.