我錯誤地設定了開放解析器 DNS 伺服器，該伺服器很快就被用於發起一系列源自/發送到俄羅斯的 DDoS 攻擊。出於這個原因，我完全阻止了除了受信任的 IP 之外的所有人的兩個 DNS 伺服器上的連接埠 53。它確實有效，因為我無法再連接到它們，但對我來說奇怪的是，當我在eth1（公共互聯網伺服器上的介面）上運行tcpdump 時，我看到大量從攻擊者到連接埠53 的傳入數據包。
即使 iptables 丟棄這些資料包，tcpdump 顯示這些資料包是否正常？或我的iptables配置錯誤？
另一方面，我沒有看到任何來自我的伺服器的傳出資料包，這是我之前所做的，所以我認為防火牆正在工作。讓我驚訝的是核心並沒有完全丟棄資料包？或者tcpdump以某種方式掛接到內核，甚至在資料包到達 iptables 之前就可以看到它們？
答案1
這是一個很好的問題。
事實上，tcp轉儲是在線路（和網卡，如果你願意的話）之後發現的第一個軟體在，以及路上的最後一輛出去。
Wire -> NIC -> tcpdump -> netfilter/iptables
iptables -> tcpdump -> NIC -> Wire
因此，它可以看到到達您的介面的所有資料包以及離開您的介面的所有資料包。由於傳送至連接埠 53 的封包沒有得到回應（如 tcpdump 所示），因此您已成功驗證 iptables 規則已正確設定。
編輯
也許我應該添加一些細節。tcp轉儲是基於libpcap，一個創建了封包套接字。當網路堆疊中收到常規資料包時，內核第一的檢查是否存在對新到達的資料包感興趣的資料包套接字，如果有，則將資料包轉送到該資料包套接字。如果選項ETH_P_ALL被選中，那麼全部協定透過資料包套接字。
libpcap實作一個這樣的資料包套接字，並啟動該選項，保留一份副本供自己使用，並將資料包複製回網路堆疊，由核心以通常的方式處理，包括首先將其傳遞給網路過濾器，內核空間對應的iptables。同樣的事情，以相反的順序（IE，首先是 netfilter，最後是通過資料包套接字的通道），在出去的路上。
這容易被駭客攻擊嗎？但當然。當然有使用概念驗證的 Rootkitlibpcap攔截發往 Rootkit 的通信前防火牆可以對他們下手。但即便如此，與簡單的谷歌查詢發現的事實相比，這還是相形見絀的。在職的程式碼甚至隱藏流量libpcap。儘管如此，大多數專業人士認為在調試網路封包過濾器時優點遠遠超過缺點。
答案2
今天我做了一些資料包分析的練習。我對 IPsec 和tcpdump.所以我找到了這個網頁，裡面講的是竊聽和封包流之間的關係。我認為這可能有助於解決您的困惑。
圖9：ICMP回顯請求h1→h2，r1遍歷，加密+封裝：
