Arp Spoofing on Docker

Arp Spoofing in Docker environments exploits the network bridge architecture that connects containers to host networks. When Docker creates a bridge network, it assigns IP addresses to containers and maintains ARP tables on the host to route traffic between containers and the outside world. Attackers can manipulate these ARP tables by sending forged ARP replies, causing the host to associate the attacker's MAC address with legitimate IP addresses.

In Docker, this attack often targets the docker0 bridge interface on Linux hosts. A malicious container can use tools like arpspoof or bettercap to send gratuitous ARP packets, claiming ownership of the gateway's IP address. Once successful, the attacker intercepts all traffic between containers and external networks, enabling man-in-the-middle attacks, session hijacking, and data exfiltration.

The Docker-specific vulnerability arises from the default network configuration. Docker's bridge networks use netfilter rules that, while providing basic isolation, don't prevent ARP spoofing within the same bridge. An attacker with access to one container can compromise the entire bridge network. This is particularly dangerous in multi-tenant environments where different applications share the same Docker host.

Real-world exploitation in Docker often involves mounting the host's network namespace or using privileged containers. With --privileged flag, containers gain access to all devices and can manipulate network interfaces directly. Attackers might also exploit misconfigured cap_net_admin capabilities to modify network settings. The attack surface expands when Docker networks use the default bridge driver instead of more secure options like macvlan or ipvlan.

Code paths vulnerable to ARP spoofing in Docker typically involve:

docker network create --driver bridge mynet
# Creates docker0 bridge with default settings

# Malicious container setup
docker run -it --cap-add=NET_ADMIN --network mynet alpine /bin/sh
# Inside container: arpspoof -i eth0 -t <target_ip> <gateway_ip>

The attack becomes more severe when combined with Docker's default iptables rules, which allow inter-container communication on the same network. An attacker who successfully spoofs ARP can then intercept traffic between legitimate containers, potentially stealing API keys, session tokens, or sensitive business data flowing between microservices.

Detecting ARP spoofing in Docker requires monitoring network traffic patterns and ARP table changes at the host level. The most effective approach combines host-based monitoring with container runtime inspection. On Linux hosts, you can use arpwatch to detect ARP flux—rapid changes in MAC addresses associated with IP addresses. Docker's integration with Linux network namespaces means these host-level tools can monitor all container network activity.

For Docker-specific detection, examine the network namespace of each container. Privileged containers or those with NET_ADMIN capabilities pose higher risk. Use docker inspect to check capabilities and network configurations:

docker inspect $(docker ps -q) | jq '.[].HostConfig.CapDrop'
docker inspect $(docker ps -q) | jq '.[].HostConfig.CapAdd'

Network traffic analysis can reveal ARP spoofing attempts. Monitor for unusual ARP request/response patterns using tcpdump on the docker0 interface:

tcpdump -i docker0 arp and port not 53
# Watch for unexpected ARP traffic on the bridge

middleBrick's Docker-specific scanning identifies ARP spoofing vulnerabilities by testing the network attack surface of your containerized applications. The scanner examines Docker network configurations, capability settings, and runtime network behavior without requiring credentials or internal access. It tests whether containers can manipulate ARP tables or intercept traffic between services.

Key detection indicators include:

• Containers with NET_ADMIN capabilities running in bridge networks
• Multiple containers attempting to claim the same IP address
• ARP table changes occurring faster than normal network churn
• Inter-container traffic that should be isolated but isn't
• Containers with privileged mode enabled in multi-tenant environments

middleBrick provides specific findings for Docker environments, mapping vulnerabilities to OWASP API Security Top 10 categories like A1: Broken Object Level Authorization when ARP spoofing enables privilege escalation attacks. The scanner's 12 parallel security checks include network layer analysis that identifies ARP spoofing risks unique to containerized architectures.

Remediating ARP spoofing in Docker requires architectural changes and network configuration hardening. The most effective approach is avoiding bridge networks for sensitive applications altogether. Instead, use Docker's macvlan or ipvlan drivers, which assign containers their own MAC addresses on the physical network, eliminating the shared bridge attack surface.

# More secure network configuration
docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  secure_net

For applications that must use bridge networks, implement network segmentation with user-defined bridges instead of the default docker0. Create isolated networks for different security levels:

# Create isolated networks for different security tiers
docker network create --driver bridge --internal secure_bridge
docker network create --driver bridge --internal trusted_bridge

Capability restrictions are critical. Drop all capabilities by default and add only what's necessary:

docker run -d \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --network secure_net \
  myapp

Network policies using Docker's built-in firewall can prevent ARP spoofing attempts. Configure iptables rules to restrict which containers can send certain types of network traffic:

# Restrict ARP traffic to specific containers
iptables -A DOCKER-USER -i docker0 -p arp -j DROP
iptables -A DOCKER-USER -i docker0 -p arp -s <trusted_container_ip> -j ACCEPT

Runtime security monitoring with tools like Falco can detect ARP spoofing in real-time. Falco rules can trigger alerts when containers attempt network manipulation:

- rule: ARP spoofing attempt
  desc: Detect potential ARP spoofing
  condition: >
    fd.type=eth and 
    syscall.type=sendto and 
    fd.name contains "arp" and 
    container.id != host
  output: ARP spoofing attempt from container (user=%user.name container=%container.name)
  priority: WARNING

For API security specifically, ensure your containerized applications use mutual TLS (mTLS) between services. Even if ARP spoofing occurs, encrypted traffic remains protected:

# Example service-to-service mTLS configuration
docker run -d \
  --network secure_net \
  -v /path/to/certs:/certs \
  -e TLS_CERT=/certs/service.crt \
  -e TLS_KEY=/certs/service.key \
  myapi

middleBrick's remediation guidance for Docker ARP spoofing includes specific configuration examples like these, prioritized by severity and mapped to compliance requirements. The tool identifies which containers need capability restrictions and provides exact Docker commands to implement the fixes.