Does tcpdump bypass iptables?

Question

I mistakenly setup open resolver DNS server, which was soon used for bunch of DDoS attacks originating somewhere from / to Russia. For that reason I completely blocked port 53 on both DNS servers for everyone except for trusted IP's. It does work, I am not able to connect to them anymore, but what seems weird to me is that when I run tcpdump on eth1 (which is interface on server with public Internet) I see lots of incoming packets from attacker to port 53.

Is it normal that tcpdump display these packets even if iptables drop them? Or did I configure iptables wrong?

On other hand I don't see any outgoing packets from my server, which I did before, so I suppose that firewall is kind of working. It just surprise me that kernel doesn't drop packets entirely? Or is tcpdump hooked to kernel in a way that it sees the packets even before they get to iptables?

Answer 1

This is a nice question.

As a matter of fact, tcpdump is the first software found after the wire (and the NIC, if you will) on the way IN, and the last one on the way OUT.

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Thus it sees all packets reaching your interface, and all packets leaving your interface. Since packets to port 53 do not get a reply, as seen by tcpdump, you have successfully verified that your iptables rules have been correctly configured.

EDIT

Perhaps I should add a few details. tcpdump is based on libpcap, a library which creates a packet socket. When a regular packet is received in the network stack, the kernel first checks to see whether there is a packet socket interested in the newly arrived packet and, if there is one, it forwards the packet to that packet socket. If the option ETH_P_ALL is chosen, then all protocols go thru the packet socket.

libpcap implements one such packet socket with the option activated, keeps a copy for its own use, and duplicates the packet back onto the network stack, where it is processed by the kernel in the usual way, including passing it first to netfilter, the kernel-space counterpart of iptables. Same thing, in reverse order (i.e., first netfilter then last the passage thru the packet socket), on the way out.

Is this prone to hacking? But of course. There are certainly proof-of-concept rootkits using libpcap to intercept communications destined to the rootkit before the firewall can lay its hand on them. But even this pales in comparison with the fact that a simple Google query unearths working code hiding traffic even from libpcap. Still, most professionals think the advantages vastly outweigh the disadvantages, in debugging network packet filters.