Zero-Trust Infrastructure: Why Your Firewall is Lying to You

There is a dangerous misconception in our industry: the belief that once a packet passes your edge firewall, it is "safe." We treat our internal networks like a cozy living room, assuming that the server sitting at 192.168.1.10 would never attack the database at 192.168.1.11. This "hard shell, soft center" approach is exactly how massive data breaches happen.

With the recent invalidation of the Safe Harbor agreement by the ECJ just two months ago, the legal landscape for data residency has shifted under our feet. But the technical landscape is even more treacherous. If you are running critical workloads—whether it's a high-traffic Magento store or a proprietary API—you need to adopt a Zero-Trust mindset. Trust no one. Verify everything. Even inside your own VPC.

At CoolVDS, we see the aftermath of "implicit trust" configurations weekly. A compromised web node becomes a launchpad for scanning the entire private subnet. Here is how a battle-hardened sysadmin locks down a Linux environment using tools available right now, in late 2015.

1. The Foundation: Isolation is Non-Negotiable

Before we touch a single config file, we must address virtualization. Many budget providers pack users onto OpenVZ containers. This is a security nightmare for a Zero-Trust model because you are sharing a kernel with potentially hostile neighbors. If a kernel exploit drops, isolation vanishes.

This is why CoolVDS strictly utilizes KVM (Kernel-based Virtual Machine). You get your own kernel, your own memory space, and true hardware virtualization. It is the only way to ensure that "Zero Trust" starts at the hardware level. Do not build a fortress on a foundation of sand.

2. Death to the Password

In 2015, SSH brute-force attacks are generating terabytes of noise across the internet. If you are still allowing root login with a password, you have already failed. We implement a two-tiered authentication gate: 4096-bit RSA keys combined with Time-based One-Time Passwords (TOTP).

First, generate a robust key pair on your local machine:

ssh-keygen -t rsa -b 4096 -o -a 100 -f ~/.ssh/id_rsa_coolvds_admin

Next, we configure the server. Install libpam-google-authenticator (available in standard repositories for Debian 8/CentOS 7) and configure SSH to require both the key and the code.

Edit /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
port 2222  # Security through obscurity helps reduce log noise, though not a real defense
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
UsePAM yes
AllowUsers deploy_admin

Restart the service. Now, even if a laptop with the private key is stolen, the attacker cannot breach your server without the rotating code on your phone.

3. Micro-Segmentation with iptables

In a Zero-Trust network, every interface is treated as hostile. Do not use default "ALLOW" policies. We want to explicitly whitelist only the necessary traffic. While tools like ufw are friendly, they obscure what is actually happening. For granular control, we use raw iptables.

Below is a baseline configuration for a web node. Note that we DROP everything by default, including outgoing traffic that isn't essential. This prevents a compromised server from easily downloading malware or phoning home to a C&C server.

# Flush existing rules
iptables -F

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

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

# Allow established connections (stateful inspection)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow Outbound DNS and Repo updates (be specific!)
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -d security.debian.org -j ACCEPT

# LOG dropped packets (crucial for auditing)
iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

Pro Tip: Be extremely careful applying the OUTPUT DROP policy over SSH. If you make a typo, you will lock yourself out. Always have the CoolVDS VNC console open in your browser as a backup access method during network configuration.

4. Encryption Inside the Perimeter

The days of terminating SSL at the load balancer and sending unencrypted HTTP to the backend are over. If an attacker breaches the load balancer, they can sniff all internal traffic, capturing session cookies and customer data.

With the Let's Encrypt Public Beta launching just days ago, there is no longer a financial excuse for lacking SSL. However, for internal node-to-node communication (e.g., Web to Database), you should use a self-signed CA or verify certificates strictly.

Ensure your Nginx configuration uses strong Diffie-Hellman groups to prevent Logjam attacks (a major issue this year). Do not use the default 1024-bit parameters.

# Generate strong DH params (this takes time)
openssl dhparam -out /etc/nginx/dhparam.pem 4096

Then, in your Nginx block:

ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:kEDH+AES128-SHA:kEDH+AES128-GCM-SHA256:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2';
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;

5. The Database: Bind is not Enough

Simply binding MySQL to 127.0.0.1 or a private IP is insufficient. We need to ensure that the user accessing the database is restricted by IP address at the application level.

In your MySQL/MariaDB console, never create a user with % host wildcard. Be explicit.

CREATE USER 'app_user'@'10.0.0.5' IDENTIFIED BY 'ComplexPasswordHere';
GRANT SELECT, INSERT, UPDATE, DELETE ON production_db.* TO 'app_user'@'10.0.0.5';
FLUSH PRIVILEGES;

This ensures that even if an attacker steals the database credentials, they cannot use them from an external node or a different internal server.

The Norwegian Advantage

Implementing Zero-Trust is technical, but it also touches on compliance. With the Datatilsynet keeping a close watch on data privacy, hosting your infrastructure outside of Norway adds a layer of legal risk. Latency matters too. A round trip from Oslo to a generic European datacenter might be 30ms. From Oslo to our facility? It's often sub-millisecond.

When you combine the low latency of CoolVDS's local network with the raw I/O power of our new NVMe storage arrays, the overhead of encryption and complex firewall rules becomes negligible. You don't have to sacrifice speed for security.

Final Thoughts

Zero Trust is not a product you buy; it is a discipline you practice. It requires assuming that failure is inevitable and that the network is hostile. By leveraging KVM isolation, enforcing strict ingress/egress filtering, and encrypting traffic deep within your stack, you harden your infrastructure against the threats of 2016 and beyond.

Security starts with the right foundation. Deploy a KVM instance on CoolVDS today and build an architecture that actually respects your data.