DDoS Detection for
Proxmox LXC Containers

Back to Blog

The LXC DDoS Problem

LXC containers on Proxmox share the host's network stack. Unlike KVM virtual machines, which have their own virtual NICs and can be somewhat isolated, LXC containers are connected via veth pairs to a Linux bridge on the host. An attack targeting one container's IP floods the host's physical NIC, and every other container on that bridge suffers.

This is particularly painful for hosting providers selling LXC-based VPS. One customer's unprotected web server gets DDoS'd, and 20 other customers on the same node experience packet loss. Without per-container monitoring, you do not know which container is the target until you manually inspect traffic on the bridge.

Two Deployment Approaches

Option A: Install ftagent on the Proxmox host (recommended)

Install ftagent on the Proxmox hypervisor itself. The agent monitors all traffic on the physical NIC and can identify which container is being targeted by correlating attack traffic with container IP addresses.

ssh root@proxmox-node
pip install ftagent
sudo ftagent --setup

Configure each container's IP as a service port mapping so the agent knows which IPs belong to which containers. This gives you per-container incident reporting from a single agent.

Option B: Install ftagent inside each LXC container

For providers who want per-container isolation and want each container to have its own Flowtriq node, install ftagent inside the LXC container:

# Enter the container
pct enter 101

# Install inside the container
pip install ftagent
sudo ftagent --setup

This approach gives each container its own detection baseline, its own incident history, and its own alert configuration. If you sell DDoS protection per-VPS, this is the right model because each customer's container maps to their own Flowtriq node.

LXC containers share the host kernel. ftagent inside an LXC container reads network counters for that container's network namespace, which is what you want for per-container detection.

Host-Level Setup

For the host-level approach, configure the agent to monitor the physical interface (usually vmbr0) and register each container's IP:

FTAGENT_INTERFACE=vmbr0
FTAGENT_SERVICE_PORTS=80/tcp,443/tcp,22/tcp

# Container IP mappings (via dashboard or API)
CT 101: 203.0.113.10 - "customer-web-01"
CT 102: 203.0.113.11 - "customer-game-01"
CT 103: 203.0.113.12 - "customer-mail-01"

When an attack targets 203.0.113.11, the agent identifies it as CT 102 ("customer-game-01") and creates an incident tagged to that container. You can then apply mitigation specifically for that IP without affecting the other containers.

Mitigation for LXC

Mitigation on Proxmox works at the host level because that is where iptables controls the bridge:

# ftagent deploys rules on the host's FORWARD chain
# targeting the specific container's IP
iptables -I FORWARD -d 203.0.113.11 -p udp \
  -m hashlimit --hashlimit-above 50000/sec \
  --hashlimit-mode srcip --hashlimit-name ct102_udp \
  -j DROP

Rules are applied per-container IP, so legitimate traffic to other containers is unaffected. When the attack ends, rules are removed automatically.

For severe attacks that saturate the host's uplink, configure upstream escalation to BGP FlowSpec or cloud scrubbing to filter traffic before it reaches the node.

Proxmox Network Considerations

• Bridge interface: Most Proxmox setups use vmbr0 as the Linux bridge. The agent monitors this interface to see all container traffic.
• VLAN tagging: If you use VLANs to separate container traffic, the agent still sees all traffic on the bridge. VLAN tags are preserved in the kernel counters.
• OVS bridges: If you use Open vSwitch instead of Linux bridge, ftagent works the same way. It reads kernel-level counters, not bridge-specific APIs.
• NAT vs routed: For NAT'd containers (sharing the host IP), the agent sees the post-NAT traffic. For routed containers (own public IP), the agent sees the pre-NAT traffic with the container's real IP.

FAQ

Does ftagent work inside unprivileged LXC containers?

Yes, with NET_ADMIN capability. Add lxc.cap.keep: net_admin to the container config, or install on the host instead.

Can I protect KVM VMs the same way?

For KVM VMs, install ftagent inside the VM (it has its own kernel). Or install on the Proxmox host and monitor the bridge like you would for LXC. The host-level approach works for both LXC and KVM.

How many containers can one agent monitor?

When installed on the host, a single agent monitors all traffic on the physical interface regardless of how many containers exist. CPU usage is under 1% because the agent reads aggregate kernel counters, not per-packet data.

Back to Blog

Related Articles