CAP_NET_RAW

What CAP_NET_RAW Changes in a Linux Security Boundary

CAP_NET_RAW is one of the Linux capabilities that meaningfully weakens a container or process boundary because it allows raw packet creation and transmission. In practice, that shifts the workload from ordinary socket use into a mode where it can speak at the packet layer, which is why it is tightly controlled in hardened Linux and Kubernetes environments.

For defenders, the important point is not the capability name itself but the authority it grants. A process with CAP_NET_RAW may be able to craft traffic that bypasses higher-level application assumptions, interfere with local network trust, or impersonate adjacent systems on the same segment.

Why CAP_NET_RAW Is Dangerous in Containers

Inside a container, CAP_NET_RAW can be enough to support ARP spoofing, DNS spoofing, packet replay, or other low-level network abuse if the surrounding network path is reachable. That makes it materially different from benign networking permissions, because the process can influence how nearby hosts resolve or route traffic rather than only consuming network services.

The risk grows when containers share a flat network, have broad east-west reach, or are deployed where service discovery and trust assumptions depend on local packet behavior. In those environments, raw packet capability can become a stepping stone for interception, pivoting, or denial of service.

Granting the capability should therefore be treated as an exception, not a default. If a workload only needs standard outbound connections, raw packet authority is usually broader than the application’s actual function requires.

How to Assess Exposure to CAP_NET_RAW

Exposure review starts with workload inventory, pod specs, runtime profiles, and any inherited security context that adds capabilities at deploy time. The question is whether the workload is explicitly allowed to send raw packets, either directly or through a base image, sidecar, or policy exception.

It also helps to validate the network placement of the workload. A pod with CAP_NET_RAW is most concerning when it can reach sensitive internal services, shared L2 domains, or DNS infrastructure where spoofed traffic could affect other tenants or workloads.

In Kubernetes, this is often a policy review question as much as a runtime question. A cluster can look compliant at the node level while still allowing a namespace, DaemonSet, or privileged exception to reintroduce packet-level abuse risk.

Use the Linux Capabilities Guide to understand how capability sets, file capabilities, and container drops are used to keep Linux processes within least-privilege bounds.

Reducing the Need for CAP_NET_RAW

The preferred control is to remove the capability unless a workload has a clear, documented need for packet construction or other low-level networking functions. Most services do not need it, and the safer pattern is to design around ordinary sockets, proxies, or network APIs instead of packet crafting.

Where a temporary exception is unavoidable, scope it as narrowly as possible and pair it with network controls that reduce what the workload can reach. The goal is to prevent a privileged packet sender from having broad influence over internal resolution, routing, or lateral movement.

On Linux hosts, packet-level privilege decisions should be aligned with a default-deny mindset at the network layer as well. Host firewalls and restrictive cluster networking do not replace capability control, but they do limit what raw packet access can affect if it is misused.

Use the Linux Firewall Guide when you need the companion network-layer controls that reduce the blast radius of a workload granted low-level packet authority.

Detection and Review After CAP_NET_RAW Abuse

If CAP_NET_RAW is abused, the investigation usually focuses on abnormal packet behavior rather than ordinary application logs. Signs can include unexpected ARP traffic, DNS anomalies, unusual packet rates, or evidence that a container is emitting traffic patterns inconsistent with its declared role.

After suspected misuse, review whether the workload was allowed to retain the capability longer than necessary and whether any adjacent systems consumed spoofed responses or were exposed to interception. Even when the capability is removed later, prior abuse can leave behind session, routing, or trust impacts that need validation.

For persistent environments, review the workload’s security context, surrounding network policy, and any host or cluster telemetry that could show packet-level manipulation. The practical question is whether the process merely had the ability to send raw packets or actually used that ability to influence other systems.

Related resources from NHI Mgmt Group

• Why does CAP_NET_RAW create such a large attack surface in Kubernetes pods?
• How do you restrict Linux capabilities such as NET_RAW for Kubernetes containers?
• CAP_NET_ADMIN
• How should security teams choose authentication for a .NET application that may need enterprise customers later?