Introduction to Container Egress Risks on VPS

In the modern cloud-native landscape, securing Virtual Private Servers (VPS) hosting Docker containers requires looking beyond standard ingress controls. While traditional firewalls are effective at blocking unauthorized incoming requests, they often leave outbound traffic unmonitored. This asymmetric security posture introduces a severe vulnerability: data exfiltration (rò rỉ dữ liệu). If a container is compromised via an application vulnerability, a malicious actor can establish a reverse shell or stream sensitive data to a remote command-and-control (C2) server.

To mitigate this threat, implementing Egress Filtering is paramount. By enforcing strict zero-trust rules on what external IP addresses, domains, and protocols a container can access, you drastically minimize the blast radius of a security breach. This technical guide explores how to leverage Cilium—a cutting-edge, eBPF-powered networking plane—to enforce granular Cilium Network Policies (CNP) for Docker containers running on a standard VPS architecture.

Why Choose Cilium and eBPF over Traditional Firewalls?

Traditional Linux firewall solutions like iptables rely on routing traffic through sequential chains of netfilter rules. As the number of containers and rules grows, the linear evaluation of these chains introduces significant CPU overhead and latency. Furthermore, iptables operates entirely at the network layers (L3/L4), rendering it blind to container-specific metadata and application-layer (L7) contexts like domain names (DNS).

Cilium revolutionizes container networking by utilizing Extended Berkeley Packet Filter (eBPF) technology running directly within the Linux kernel. This approach offers several transformative advantages:

Line-rate Performance: eBPF bypasses the overhead of traditional iptables chains, routing packets via highly optimized kernel-space BPF maps.
Identity-Aware Security: Instead of relying on volatile container IP addresses, Cilium assigns cryptographic identities based on container labels and metadata.
Layer 7 Visibility: Cilium parses application protocols such as HTTP, gRPC, and DNS, enabling policies that restrict outbound traffic to specific subdomains rather than broad IP blocks.

Architectural Framework: Cilium with Docker

When running Cilium on a standalone VPS environment with Docker, Cilium typically acts as a plugin via the Docker libnetwork architecture or operates in a routing mode that manages container network interfaces directly. This setup ensures that every single packet originating from a Docker container must pass through an eBPF program before reaching the VPS host's physical network interface.

Step-by-Step Implementation Guide

To establish comprehensive egress filtering, we must transition from a default-allow state to a zero-trust architecture. Follow these steps to deploy and configure Cilium Network Policies on your VPS.

Step 1: Preparing the VPS Environment

Before installing Cilium, ensure your VPS kernel supports eBPF. Modern Linux distributions such as Ubuntu 22.04 LTS or 24.04 LTS come pre-configured with the required kernel subsystems. Verify your kernel version using the following command:

uname -r

Ensure your kernel version is 5.4 or higher. Next, configure the Docker daemon to utilize a bridge network compatible with Cilium, or install the Cilium CLI tool to manage network attachments directly. Once Cilium is active on your host, it will begin tracking container states using its internal agent.

Step 2: Defining a Default-Deny Egress Policy

The foundational principle of zero-trust network security is to block everything by default, then explicitly permit required paths. Without a default-deny rule, containers can freely reach the global internet. Create a file named default-deny-egress.yaml with the following policy definition:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "default-deny-egress"
  namespace: "production"
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/part-of: "my-docker-stack"
  egress:
  - {}

Applying this policy acts as an absolute firewall, severing all outbound connections from endpoints carrying the matching label. No data can leave these containers until explicit allow-rules are written.

Step 3: Allowing Essential Infrastructure Services (DNS)

Completely isolating a container renders most applications non-functional because they can no longer resolve domain names. We must explicitly permit DNS resolution, but restrict it strictly to trusted upstream DNS servers (e.g., CoreDNS inside the local cluster, or public resolvers like 1.1.1.1). Here is how to configure a policy that permits outward UDP traffic on port 53 for DNS lookups:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-dns-egress"
spec:
  endpointSelector:
    matchLabels:
      env: "production"
  egress:
  - toPorts:
    - ports:
      - port: "53"
        protocol: UDP
    rules:
      dns:
      - matchPattern: "*"

Step 4: Implementing Domain-Based Egress Filtering (L7)

One of Cilium's most powerful capabilities is filtering outbound traffic based on Full Qualified Domain Names (FQDNs). If your payment processing container only needs to communicate with Stripe, allowing broad outbound access to port 443 is an unacceptable risk, as an attacker could stream data to any external HTTPS server. Cilium intercepts the DNS response, learns the transient IP address of the permitted domain, and dynamically opens an eBPF map entry for that IP.

The following policy example demonstrates how to restrict a container's outbound HTTPS traffic exclusively to the official API endpoint of Stripe:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-stripe-api"
spec:
  endpointSelector:
    matchLabels:
      app: "payment-gateway"
  egress:
  - toFQDNs:
    - matchName: "api.stripe.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

With this configuration active, any attempt by the application to connect to an unauthorized domain (e.g., a malicious pastebin site) will be instantly dropped at the kernel layer, preventing data exfiltration entirely.

Auditing and Monitoring Dropped Traffic

Deploying restrictive security policies requires continuous observability to diagnose false positives without interrupting production systems. Cilium provides an exceptional toolset for this called Hubble. Hubble utilizes the data collected by eBPF to deliver real-time visibility into network flows.

To view real-time dropped packets and understand which policy blocked them, execute the following command in your VPS terminal:

hubble observe --type drop --follow

The output will clearly state the source container label, the destination IP/domain, and the specific Cilium Network Policy responsible for terminating the packet. This feedback loop allows DevOps teams to safely refine rules before deploying them to mission-critical infrastructure.

Conclusion and Best Practices

Securing Docker environments against data exfiltration demands shifting from passive observation to active enforcement. Implementing Cilium Network Policies for egress filtering on your VPS provides an ironclad layer of defense that operates with minimal performance overhead. To ensure success, adhere to these operational best practices:

Incorporate Labels Uniformly: Always use precise, deterministic key-value pairs for your Docker container labels, as Cilium relies completely on these for rule mappings.
Audit Phase First: Deploy policies in monitoring or lenient modes when available, tracking drops via Hubble before enforcing strict blocks to avoid accidental application downtime.
Incorporate into CI/CD: Treat your Cilium Network Policies as code (GitOps). Store them alongside your Docker Compose files or deployment manifests, ensuring security definitions evolve in tandem with application features.

Securing Docker Containers on VPS: Implementing Cilium Network Policies for Advanced Egress Filtering