Prevent DNS (and other) Spoofing with Calico

AquaSec’s Daniel Sagi recently authored a blog post about DNS spoofing in Kubernetes. TLDR is that if you use default networking in Kubernetes you might be vulnerable to ARP spoofing which can allow pods to spoof (impersonate) the IP addresses of other pods. Since so much traffic is dialed via domain names rather than IPs, spoofing DNS can allow you to redirect lots of traffic inside the cluster for nefarious purposes.

So this is bad, right? Fortunately, Calico already prevents ARP spoofing out of the box. Furthermore, Calico’s design prevents other classes of spoofing attacks. In this post we’ll discuss how Calico keeps you safe from IP address spoofing, and how to go above and beyond for extra security.

ARP Spoofing

ARP spoofing is an attack that allows a malicious pod or network endpoint to receive IP traffic that isn’t meant for it. Sagi’s post already describes this well, so I won’t repeat the details here. An important thing to note, however, is that ARP spoofing only works if the malicious entity and the target share the same layer 2 segment (e.g. have direct Ethernet connectivity). In Calico, the network is fully routed at layer 3, meaning that each pod is on its own isolated layer 2 segment. ARP spoofing by pods is stopped dead in its tracks.

Calico directly programs the routing table that determines where IP packets are forwarded based on the known IP addresses of the pods, never basing the decision on a protocol like ARP which is partially under control of the potential attacker.

IP Spoofing

So Calico ensures that IP packets are delivered to the correct pods by avoiding ARP altogether within the node, but what about pods spoofing their source IPs?

The idea here is that if a pod is granted CAP_NET_ADMIN, it can just add an IP address to its network interface inside the pod. Or if it has CAP_NET_RAW it could construct IP packets with spoofed addresses and send them over the interface at the Ethernet layer.

Calico was designed from the get-go to stop this kind of spoofing. Regardless of what the malicious entity can do from within the pod, these packets are processed by the host kernel in the root network namespace where Calico has programmed it to be on the defensive against spoofing.

By using a kernel feature called reverse path filtering, IP packets with source addresses that are not the pod’s real address are dropped.  Reverse path filtering isn’t some fancy new kernel feature: it’s tried and true and hardened by years of operational experience. The idea is for every packet that is processed, look up how to route back to the source. If the packet came through a different interface than the one the kernel would use to forward to it, drop the packet. Since Calico programs the IP routes for each pod, this effectively stops them from sending packets as any address other than their real address.

CAP_NET_ADMIN and CAP_NET_RAW

While Calico automatically mitigates the most abusive uses of the NET_ADMIN and NET_RAW capabilities, Sagi is correct that you should ask yourself whether particular applications actually need these capabilities.

NET_RAW is used for the Internet Control and Management Protocol (ICMP), including the `ping` command. While useful for operators when diagnosing connectivity problems, applications typically don’t need it, and it can be exploited by attackers to do reconnaissance on your network. NET_RAW also allows the attacker to bypass the standard kernel TCP stack, potentially allowing them to more effectively launch denial of service attacks like SYN flooding.

NET_ADMIN allows reconfiguration of network interfaces and iptables rules inside the pod (it does not grant the ability to modify the way Calico uses this in the root network namespace). These capabilities could allow attackers to redirect traffic inside the pod, set up tunnels for data exfiltration, etc.

Beyond using Pod Security Policy to restrict the use of these capabilities, you can use Calico network policy to further police the use of the network. For example, you can allow pods to use ICMP in `ping` mode, but disallow other commands. You can also whitelist egress destinations to defend against attackers tunneling out of your cluster. You can also upgrade Calico to Tigera Secure to take advantage of network anomaly detection, which will warn you about unusual network activity automatically.

————————————————-

Free Online Training
Access Live and On-Demand Kubernetes Tutorials

Calico Enterprise – Free Trial
Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption