Kill the Perimeter: Why "Zero Trust" is the Only Strategy for Norwegian Systems in 2013

Let’s be honest: the last few months have been a wake-up call for every systems administrator in Europe. The Snowden leaks confirmed what paranoid sysadmins have suspected for years—the network is hostile. If you are still designing your infrastructure based on the idea that "inside the firewall" means "safe," you are already compromised.

For years, the industry standard has been the "castle and moat" approach: build a hard outer shell with heavy firewalls and let everything inside run soft and unencrypted. That model is dead. In 2013, we must adopt a new paradigm that Forrester Research calls Zero Trust. The concept is simple but brutal: Never trust, always verify.

As a DevOps engineer managing infrastructure across Oslo and Frankfurt, I've seen too many companies rely on a single edge firewall while their internal database traffic flows in cleartext. Today, we are going to fix that. We will build a hardened environment where every single packet is treated with suspicion, using tools available right now on your Linux servers.

1. The Hard Truth About Virtualization and Isolation

Before we touch a single configuration file, we need to talk about the bedrock of your security: the hypervisor. In the budget hosting world, OpenVZ is popular because it allows providers to oversell resources. But from a security standpoint, OpenVZ is a nightmare because all guests share the host's kernel.

If a vulnerability is discovered in the kernel (and they are discovered), an attacker can potentially break out of their container and access your memory. This is why CoolVDS exclusively uses KVM (Kernel-based Virtual Machine). With KVM, your operating system is fully isolated. You have your own kernel. Even if a "noisy neighbor" gets compromised, your memory space remains encrypted and separate. In a Zero Trust model, you cannot trust the neighbors.

2. Host-Level Firewalls: IPTables is Mandatory

In a traditional setup, you might have a hardware firewall filtering traffic at the datacenter edge. In Zero Trust, we assume the attacker is already inside the datacenter. This means every single server must run its own strict firewall.

On a standard CentOS 6.4 or Debian 7 deployment, iptables is your first line of defense. We don't just block ports; we lock down traffic to specific internal IP addresses.

Here is a battle-tested configuration for a database server that should only accept connections from the web server (IP: 10.0.0.5) and your management VPN:

# Flush existing rules
iptables -F

# Set default policies to DROP (The most important step)
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 state --state ESTABLISHED,RELATED -j ACCEPT

# SSH: Only from Management VPN IP (e.g., 192.168.50.50)
iptables -A INPUT -p tcp -s 192.168.50.50 --dport 22 -j ACCEPT

# MySQL: Only from Web Server Private IP
iptables -A INPUT -p tcp -s 10.0.0.5 --dport 3306 -j ACCEPT

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

# Save rules
service iptables save
service iptables restart

Pro Tip: Never rely solely on IP whitelisting. IP spoofing is possible within local subnets if the switching infrastructure isn't secured. This is why strict VLAN segregation—standard in CoolVDS networking—is critical.

3. Kill Passwords: SSH Key Management

If you are still typing a password to log into your server, stop. Brute force attacks are currently saturating the NIX (Norwegian Internet Exchange) bandwidth. The only acceptable authentication method in 2013 is 2048-bit (or 4096-bit) RSA keys.

Edit your /etc/ssh/sshd_config to explicitly forbid password auth and root login. This is non-negotiable.

# /etc/ssh/sshd_config
Port 22
Protocol 2

# Disallow root login directly
PermitRootLogin no

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Restrict strict modes
StrictModes yes

# Allow only specific users
AllowUsers deploysysadmin

After a restart of the sshd service, any attempt to connect without the private key is immediately rejected. It doesn't matter if the attacker has a dictionary of a billion passwords; the door simply doesn't exist for them.

4. Encryption in Transit: SSL Everywhere

The "soft underbelly" of most networks is the communication between the web server and the application or database. We used to assume this traffic was safe because it was on a private LAN. Post-PRISM, we know that traffic interception can happen anywhere.

You must encrypt internal traffic. For MySQL, this means enabling SSL support in my.cnf. It adds overhead, yes. But unencrypted data is leaked data.

Generating Internal Certs with OpenSSL

# Create CA certificate
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca-cert.pem

# Create server certificate
openssl req -newkey rsa:2048 -days 3600 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Configure your MySQL server to require these certificates. If the handshake fails, the query fails. This ensures that even if someone plugs into your switch or spoofs an IP, they cannot read or inject data without the valid crypto keys.

5. Data Sovereignty and The "Datatilsynet" Factor

Technical controls are only half the battle. Legal jurisdiction is the other. If you are hosting your data on US-owned infrastructure (even if the server is physically in Europe), you are subject to the USA PATRIOT Act. The implications of this for Norwegian businesses are massive.

Under the Norwegian Personal Data Act (Personopplysningsloven), you are the data controller. You are responsible. Hosting with a provider like CoolVDS, which is headquartered and legally bound to Norwegian jurisdiction, simplifies your compliance drastically compared to navigating the murky waters of Safe Harbor agreements.

6. Performance vs. Security: The I/O Bottleneck

One valid criticism of heavy encryption (SSL everywhere, encrypted disks via LUKS) is the performance hit. Encryption requires CPU cycles. On older spinning rust (HDDs), the random I/O penalty of encrypted file systems can be noticeable.

This is where hardware choice becomes part of your security architecture. We equip CoolVDS instances with enterprise-grade SSDs (Solid State Drives) in RAID-10. The high IOPS capability of SSDs negates the latency introduced by encryption. You can run dm-crypt on your database partition without your web app crawling to a halt. Don't let legacy hardware force you into bad security practices.

Summary: Trust is Vulnerability

The era of trusting the local network is over. By moving to KVM-based virtualization, enforcing strict iptables rules on every node, and leveraging SSH keys and SSL encryption internally, you build a system that is resilient by design.

Security isn't a product you buy; it's a process you adhere to. But having the right foundation helps. If you need a host that understands the difference between "marketing security" and actual kernel-level isolation, we are ready for you.

Secure your infrastructure today. Deploy a KVM-based, SSD-accelerated instance on CoolVDS and keep your data under Norwegian law.