Arp Spoofing on Kubernetes

Arp Spoofing in Kubernetes environments exploits the fundamental networking architecture where pods communicate over a flat network layer. Unlike traditional networks where ARP tables are managed at the host level, Kubernetes creates a complex overlay network where malicious actors can manipulate ARP responses to intercept traffic between pods.

The most common Kubernetes-specific Arp Spoofing attack occurs through compromised nodes. When an attacker gains access to a worker node, they can deploy a container with network capabilities that responds to ARP requests for other pods' IP addresses. This is particularly effective because Kubernetes' CNI (Container Network Interface) plugins often use bridge networking or VXLAN tunnels where ARP traffic flows freely between pods on the same node.

Consider this attack scenario: A malicious pod running on Node A responds to ARP requests for services running on Node B. Since Kubernetes pods often communicate directly with each other's IP addresses rather than through a centralized load balancer, the attacker can intercept all traffic between specific pods. The attack code might look like this:

#!/bin/bash
# arp-spoof-k8s.sh - Malicious ARP spoofing pod
# Requires NET_ADMIN capability and host networking

TARGET_IP="10.244.1.5"    # Victim pod IP
spoofed_mac="02:42:ac:11:00:02"
interface="eth0"

while true; do
    # Send ARP reply claiming to be the target
    arpspoof -i $interface -t $TARGET_IP $spoofed_mac
    sleep 1
done

This script, when deployed as a privileged container with host networking, can intercept traffic between any two pods on the cluster. The attack becomes even more potent when combined with Kubernetes' default flat networking model where all pods can communicate with each other by default.

Another Kubernetes-specific variant involves manipulating the kube-proxy component. Since kube-proxy manages service-to-pod communication using iptables or IPVS rules, an attacker who compromises kube-proxy can redirect traffic to malicious endpoints while maintaining the appearance of normal service operation. This creates a man-in-the-middle scenario where the attacker can inspect, modify, or drop API requests between services.

Service mesh implementations like Istio or Linkerd provide some protection against ARP spoofing through mutual TLS (mTLS) and sidecar proxies, but misconfigured service meshes can actually create new attack vectors. For instance, if mTLS is not properly enforced, an ARP spoofing attack can still intercept unencrypted traffic between sidecar proxies.

Detecting Arp Spoofing in Kubernetes requires a multi-layered approach that examines both network traffic patterns and pod behavior. The flat networking model of Kubernetes makes traditional ARP monitoring tools less effective, requiring specialized detection techniques.

Network-level detection involves monitoring ARP traffic across nodes using eBPF programs or CNI plugin instrumentation. Tools like Cilium can detect unusual ARP patterns, such as a single MAC address responding to ARP requests for multiple IP addresses that it shouldn't own. Here's a detection script using standard Linux tools:

#!/bin/bash
# arp-spoof-detector.sh - Detect ARP spoofing in Kubernetes

# Monitor ARP traffic for suspicious patterns
while true; do
    # Check for duplicate MAC addresses claiming multiple IPs
    duplicate_macs=$(arp -n | awk '{print $3}' | sort | uniq -d)
    
    if [ -n "$duplicate_macs" ]; then
        echo "ALERT: Duplicate MAC addresses detected: $duplicate_macs"
        # Log affected IPs
        for mac in $duplicate_macs; do
            echo "IPs using $mac:"
            arp -n | grep $mac
        done
    fi
    
    # Check for ARP traffic from unexpected sources
    unexpected_arp=$(tcpdump -i any -n arp | head -20)
    echo "ARP traffic: $unexpected_arp"
    
    sleep 10
done

Pod-level detection focuses on identifying containers with suspicious network capabilities. Kubernetes RBAC and Pod Security Standards can help prevent deployment of malicious ARP spoofing pods, but runtime detection is crucial. The middleBrick scanner specifically tests for ARP spoofing vulnerabilities by examining pod configurations and network policies.

middleBrick's Arp Spoofing detection includes:

• Checking for containers with NET_ADMIN capabilities that could perform ARP manipulation
• Verifying network policies that restrict pod-to-pod communication
• Analyzing service mesh configurations for proper mTLS enforcement
• Testing for exposed APIs that could be used to manipulate network routing

The scanner runs these checks automatically when you submit your Kubernetes API endpoint or service URL. It examines the unauthenticated attack surface to identify ARP spoofing risks without requiring credentials or agent installation.

Network policy analysis is particularly important for Arp Spoofing detection. Kubernetes Network Policies can restrict which pods can communicate with each other, but default policies often allow all pod-to-pod traffic. middleBrick evaluates your network policies and provides specific recommendations for tightening communication restrictions.

Log analysis complements network monitoring by identifying suspicious pod behavior. Look for pods that frequently change their network namespace, attempt to access host networking, or exhibit unusual traffic patterns. Kubernetes audit logs can reveal when pods with elevated privileges are deployed or when network policies are modified.

Remediating Arp Spoofing in Kubernetes requires a defense-in-depth approach that combines network segmentation, access controls, and runtime protection. The goal is to eliminate the conditions that make ARP spoofing possible while maintaining the flexibility of your Kubernetes deployment.

Network segmentation is the first line of defense. Implement Kubernetes Network Policies to restrict pod-to-pod communication to only what's necessary. Here's an example policy that prevents ARP spoofing by limiting which pods can communicate:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-pod-communication
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: authorized-frontend
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: authorized-backend
    ports:
    - protocol: TCP
      port: 8080
  - to: []
    ports:
    - protocol: TCP
      port: 443
    - protocol: TCP
      port: 53

This policy allows only specific pods to communicate, preventing an attacker from using ARP spoofing to intercept traffic between arbitrary pods. The empty to: [] rule ensures that egress traffic is explicitly controlled rather than allowing all outbound communication.

Pod Security Standards provide another layer of protection by preventing deployment of containers with dangerous capabilities. Enforce restrictive Pod Security Policies or use Pod Security Admission to block containers that require NET_ADMIN or host networking:

apiVersion: security.kubernetes.io/v1
kind: PodSecurityPolicy
metadata:
  name: restricted-networking
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - NET_ADMIN
    - SYS_ADMIN
  hostNetwork: false
  hostPID: false
  hostIPC: false
  runAsNonRoot: true
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny

Service mesh implementations provide runtime protection against ARP spoofing through mTLS and sidecar proxies. Istio configuration that enforces strict mTLS can prevent man-in-the-middle attacks even if ARP spoofing occurs:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default-strict-mtls
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: default-deny
spec:
  {}

This configuration enforces mutual TLS for all service-to-service communication, making it impossible for an ARP spoofing attacker to read the actual application data even if they intercept the traffic.

Runtime security monitoring with tools like Falco can detect ARP spoofing attempts in real-time. Falco rules can identify suspicious network activity, such as unexpected ARP responses or containers attempting to manipulate network interfaces:

apiVersion: falco.libsecurity.org/v1alpha1
kind: FalcoRule
metadata:
  name: suspicious-arp-activity
  description: Detect suspicious ARP spoofing attempts
condition: >
  (evt.type in (arp_send, arp_recv) and 
   (proc.name not in (kube-proxy, cilium-agent, calico-node)) and
   (container.id != host))
output: >
  Suspicious ARP activity detected (user=%user.name 
  command=%proc.cmdline container=%container.name)
priority: WARNING

Finally, implement network-level controls at the infrastructure layer. If using cloud providers, leverage their network security features like AWS VPC security groups or Azure Network Security Groups to control traffic between nodes. For on-premises deployments, consider using CNI plugins that provide built-in ARP spoofing protection, such as Calico with its default deny policies or Cilium with eBPF-based enforcement.