Securing the Cage: Hardening LXC and OpenVZ for High-Performance Hosting

Let’s be honest: virtual machines are heavy. If you are running a high-traffic Nginx cluster or a massive MySQL shard, the overhead of full hardware virtualization (HVM) can eat into your margins. That is why we love containers—specifically LXC (Linux Containers) and OpenVZ. They offer near-native performance because there is no hypervisor layer translating instructions. You get raw metal speed.

But here is the ugly truth that many hosting providers in Oslo and across Europe won't tell you: Containers share the host kernel.

If a bad actor triggers a kernel panic inside their container, the whole physical server goes down. If there is an unpatched privilege escalation vulnerability in the Linux 3.x kernel, a user inside a container might break out and gain root access to the host node. I have seen it happen. I have seen a sloppy chmod 4755 inside a chroot environment turn a production server into a playground for script kiddies.

In this guide, we are going to look at how to secure these environments. We aren't talking about the experimental "Docker" project that was just announced at PyCon this week—we are talking about battle-tested, production-ready LXC and OpenVZ configurations.

The First Line of Defense: Dropping Capabilities

By default, root inside a container has too much power. The Linux kernel divides privileges into units called "capabilities." To secure a container, you must strip away everything the guest OS doesn't strictly need.

For an LXC container running a simple web server, there is absolutely no reason for it to have CAP_SYS_MODULE (loading kernel modules) or CAP_SYS_TIME (changing the system clock). If a hacker gets in, you don't want them loading a rootkit module into your host kernel.

Here is how we configure a hardened lxc.conf for a web node:

# /var/lib/lxc/web01/config

# Network configuration
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0

# Drop dangerous capabilities
lxc.cap.drop = sys_module
lxc.cap.drop = sys_time
lxc.cap.drop = sys_boot
lxc.cap.drop = audit_control
lxc.cap.drop = mac_admin

# Prevent container from re-mounting /proc or /sys as read-write
lxc.mount.auto = proc:mixed sys:ro

Pro Tip: Always use proc:mixed. This mounts /proc as read-write for the container's own processes but masks the sensitive host-level directories. If you leave /proc fully writable, you are begging for a security breach.

Resource Isolation with Cgroups

One of the biggest risks in a shared environment is the "Noisy Neighbor" effect. If one container decides to compile a massive C++ project or gets hit by a DDoS attack, it can starve the CPU for everyone else.

We use Control Groups (cgroups) to enforce strict limits. This isn't just about fairness; it's about availability. If a process goes rogue and eats all RAM, the OOM (Out of Memory) killer might strike the wrong process if you haven't set fences.

Limiting Memory and Swap

You can set these limits on the fly without rebooting the container:

# Limit container to 512MB RAM
cgset -r memory.limit_in_bytes=536870912 web01

# Limit memory + swap to 1GB
cgset -r memory.memsw.limit_in_bytes=1073741824 web01

For CPU, we prefer assigning "shares" rather than hard limits, which ensures high utilization when the system is idle but enforces fairness under load.

# Give this container half the priority of others (default is 1024)
cgset -r cpu.shares=512 web01

Network Filtering: The Iptables Wall

Never rely on the firewall inside the container. If the attacker compromises the container, they can flush those rules. You must enforce security on the host using iptables.

When we provision VPS Norway based infrastructure, we often use a bridge interface (br0). Here is a snippet to ensure a container can only send traffic out, but cannot spoof IP addresses or sniff traffic across the bridge:

# HOST NODE CONFIGURATION
# Force traffic from the container's veth interface to go through the FORWARD chain
iptables -A FORWARD -m physdev --physdev-in veth1234 -j ACCEPT

# Prevent IP Spoofing
iptables -t raw -A PREROUTING -i veth1234 -s ! 192.168.1.50 -j DROP

# Block access to local management subnet (10.0.0.0/8)
iptables -A FORWARD -i veth1234 -d 10.0.0.0/8 -j DROP

The Storage Bottleneck: I/O Priority

Disk I/O is the single biggest bottleneck in virtualization. Mechanical hard drives (HDDs) are terrible at random I/O, which is exactly what fifty containers generate simultaneously. While standard SATA SSDs are becoming common, the real game-changer is high-performance PCIe flash storage (often called Enterprise SSDs).

However, even with fast disks, you need to prioritize I/O using blkio cgroup controller. This prevents a database container from being choked by a log-heavy backup job in another container.

# Set weight for block I/O (10-1000)
# Give the database container high priority
echo 1000 > /cgroup/blkio/lxc/db01/blkio.weight

# Give the backup container low priority
echo 100 > /cgroup/blkio/lxc/backup01/blkio.weight

Data Privacy in 2013: The Norwegian Context

Here in Norway, we take data privacy seriously. The Personopplysningsloven (Personal Data Act) and the directives from Datatilsynet require strict control over where data resides. Using US-based cloud providers can be legally risky due to the Patriot Act.

When you host on a container, you must ensure that the physical host resides in a jurisdiction you trust. At CoolVDS, our racks are located in Oslo. This guarantees two things:

1. Low Latency: You are pinging 2ms to NIX (Norwegian Internet Exchange), not 30ms to Frankfurt.
2. Legal Compliance: Your data remains under Norwegian law, protected from foreign surveillance overreach.

Why We Still Use KVM at CoolVDS

While this guide focuses on securing containers, there is a limit to how safe a shared kernel can be. For mission-critical applications where security is paramount, or for kernels that require custom modules (like specific VPN configurations), we recommend KVM (Kernel-based Virtual Machine).

KVM provides full hardware virtualization. Each VPS has its own kernel, its own memory space, and total isolation. It is slightly heavier than OpenVZ, but with modern hardware and Intel VT-x extensions, the difference is negligible for most applications.

Comparison: Container vs. KVM

Final Thoughts

Security is not a product; it is a process. If you are managing your own LXC nodes, you need to be vigilant about kernel updates and cgroup configurations. A single misconfiguration in sudoers or a weak root password can compromise the entire node.

If you prefer to focus on your code rather than kernel patching, managed hosting is the answer. We configure the ddos protection, the firewalls, and the I/O schedulers so you don't have to.

Ready for a stable environment? Stop fighting with noisy neighbors. Deploy a high-performance KVM instance with pure SSD storage on CoolVDS today and experience the stability of Norwegian infrastructure.