Stop Trusting Your LAN: A Sysadmin's Guide to Internal Hostility

There is a dangerous lie that hardware vendors have been selling us for the last decade: the idea of the "Trusted Network." They tell you to buy a massive Cisco ASA, configure a DMZ, and assume that everything inside your VLAN is safe. This is the "hard crunchy shell, soft chewy center" approach to security. And in 2013, it is effectively suicide for your infrastructure.

I recently audited a setup for a mid-sized e-commerce retailer here in Oslo. They had a fortress of a firewall at the edge. But once a developer's laptop—infected via a drive-by download—connected to the VPN, the malware scanned the internal subnet, found a MySQL server listening on port 3306 with a weak root password, and dumped the customer table. The firewall didn't fire a single alert because the traffic was internal.

This is why we need to look at the Zero Trust model, a concept popularized by Forrester Research. The premise is simple: Never trust, always verify. Even if a packet comes from `192.168.1.5` (your backup server), you treat it with the same suspicion as a packet from a botnet in Shenzhen.

Here is how you build a Zero Trust environment on CoolVDS KVM instances today, using tools available in standard repositories like IPTables, OpenSSH, and OpenVPN.

1. The Host-Based Firewall is Mandatory

If you are running `service iptables stop` because it's "too hard to configure," you are part of the problem. In a Zero Trust architecture, every single server is its own perimeter. We don't rely on the hosting provider's edge firewall alone.

On a standard CentOS 6 or Ubuntu 12.04 LTS instance, your default policy must be DROP. Not REJECT—DROP. We don't owe attackers a TCP RST packet. We want to be a black hole.

The "Paranoid" IPTables Config

Save this to a script, chmod +x, and run it. Warning: Ensure you allow your specific IP for SSH before applying, or you will lock yourself out of your VPS.

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

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

# Allow loopback (critical for local services like PHP-FPM talking to Nginx)
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (so you don't break your own SSH session)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH only from a specific management IP (VPN or Static Office IP)
# REPLACE 1.2.3.4 WITH YOUR IP
iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT

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

# Log dropped packets (Optional: Watch disk space!)
iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

On Debian/Ubuntu systems, make these persistent using `iptables-persistent`:

2. SSH: Keys are Not Enough

Password authentication for SSH should have been dead in 2010. By now, if you aren't using RSA keys (minimum 2048-bit), you are negligent. But in a Zero Trust environment, we go further. We bind SSH to a specific interface.

If your CoolVDS server has a public interface (`eth0`) and a private backend interface (`eth1`), typically SSH listens on `0.0.0.0` (all interfaces). Change this. Force administration traffic through a controlled path.

Edit `/etc/ssh/sshd_config`:

# Disable Protocol 1 completely
Protocol 2

# No root login. Log in as user, then su/sudo.
PermitRootLogin no

# Disable passwords strictly
PasswordAuthentication no

# Restrict to specific users
AllowUsers deployed_admin

# OPTIONAL: Bind to VPN IP only (if you have a management VPN)
# ListenAddress 10.8.0.5

Pro Tip: For extra security, implement Two-Factor Authentication (2FA) on SSH using `libpam-google-authenticator`. It works perfectly with the Google Authenticator app on iOS and Android. It adds a Time-based One-Time Password (TOTP) requirement even after the SSH key handshake.

3. Database Isolation: The MySQL Bind

A common mistake in multi-tier applications is opening MySQL to the world because the web server is on a different node. I often see `grant all privileges on *.* to 'root'@'%'` in audit logs. This is terrifying.

In our architecture, the database should never speak to the public internet. On your CoolVDS Database node, configure MySQL 5.5 to listen ONLY on the private network interface.

Edit `/etc/mysql/my.cnf` (Ubuntu) or `/etc/my.cnf` (CentOS):

[mysqld]
# Do NOT use 0.0.0.0
# Bind to the private network IP provided by CoolVDS
bind-address = 10.10.0.5

# Disabling symbolic links is recommended to prevent assorted security risks
symbolic-links=0

Furthermore, use SSL for replication. If you are replicating data between our Oslo data center and a secondary site, unencrypted replication traffic is readable in plain text by anyone performing a man-in-the-middle attack on the transit links. Generate SSL certs for your MySQL users.

4. The Management Plane: OpenVPN

How do you access these locked-down ports? You build a management tunnel. Don't expose your administration panels (phpMyAdmin, Webmin, Nagios) to the public web.

We deploy OpenVPN servers on a dedicated CoolVDS instance acting as a bastion host. This is the only entry point into the management network.

Server Config Snippet (`server.conf`):

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
push "route 10.10.0.0 255.255.255.0"
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Using UDP reduces latency overhead, which is crucial when you are SSHing over the VPN tunnel. The push "route..." command ensures that once connected, your laptop can route traffic to the private IPs of your backend servers.

Why Infrastructure Choice Matters

Implementing Zero Trust requires resources. Encryption (SSL/SSH/VPN) eats CPU cycles. Packet filtering (IPTables with complex rule sets) consumes kernel interrupts.

This is where the "noisy neighbor" problem of cheap hosting kills you. If you are on a standard container-based VPS (like OpenVZ) where the kernel is shared, a neighbor under DDoS attack will fill the connection tracking table (`nf_conntrack`), causing your firewall rules to fail or drop valid packets.

This is why at CoolVDS, we standardize on KVM (Kernel-based Virtual Machine). With KVM, you have your own kernel, your own memory space, and dedicated interrupt handling. You can tune your `sysctl.conf` parameters specifically for high-security networking without begging support to change a host-node setting.

Compliance in Norway (Datatilsynet)

Operating in Norway means adhering to the Personopplysningsloven. While we aren't lawyers, we know that the Data Inspectorate (Datatilsynet) looks favorably on organizations that take proactive measures to segregate data. By treating your internal network as hostile, you are building "Privacy by Design" into your infrastructure before it becomes a buzzword.

Summary

Security is not a product you buy; it is a process you adhere to. The era of the trusted LAN is over. Assume every packet is malicious until proven otherwise.

Ready to lock down your infrastructure? Deploy a KVM instance on CoolVDS today. Our Oslo facility offers sub-3ms latency to the Norwegian Internet Exchange (NIX), ensuring that your encryption overhead never feels like lag.

Configure Your Secure CoolVDS KVM Instance Now »