Stop your firewall from leaking interface metadata via raw packet captures

Technical Briefing | 8/4/2026

You spend all weekend hardening your nftables ruleset, strictly isolating your internal services. Then you run a quick tcpdump to verify a handshake and realize you can see the interface names and bridge port indices leaking into the capture files even when traffic is dropped. It feels like you have a solid fence, but the gate is made of glass.

The kernel is being too helpful

When you capture traffic on a Linux host, libpcap grabs the packet before the firewall decides its fate. If you are sniffing on a bridge or a bonded interface, the meta-information attached to the frame usually ends up in the pcap header. This is a common oversight when you are running packet captures on production nodes to debug inter-service latency. Most people ignore the metadata block, but that is exactly what local attackers look for when they want to map your internal network topology.

tcpdump -i any -n -w capture.pcap 'not (port 22 or port 51820)'

• Avoid using the any interface for sensitive debugging as it aggregates noise from all internal bridges.
• Use drop-cap filters to ensure you aren’t logging internal MAC addresses or interface indices.
• Ensure your capture files are chmodded to 600 so other users on the box cannot peek at the headers.

Fixing the leak

If you really need to see what is happening without compromising the host architecture, pipe the capture directly to your local machine via SSH rather than writing to disk locally. It keeps the noise off your production storage and limits exposure. The next time you debug an interface leak, remember that tcpdump is effectively a kernel-level monitor; treat the output with the same level of paranoia you apply to your log files.