Does tcpdump bypass iptables?

Question

I mistakenly setup open resolver DNS server, which was soon used for a 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, in that 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 displays these packets even if iptables drops them? Or did I configure iptables wrongly?

On other hand I don't see any outgoing packets from my server, which I did before, so I suppose that the firewall is kind of working. It just surprises me that the kernel doesn't drop packets entirely? Or is tcpdump hooked to the 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.

Answer 2

Today I did some practice for packet analysis. I am especially interested IPsec and tcpdump. So I found this webpage which talked about the relationship between tapping and the packet flow. I think it might be useful to resolve your confusion.

Figure 9: ICMP echo-request h1 → h2, r1 traversal, encrypt+encapsulate:

Source: Nftables - Netfilter and VPN/IPsec packet flow