tcpdumpはiptablesをバイパスしますか？
私は誤ってオープンリゾルバーDNSサーバーをセットアップしました。これはすぐに、ロシアから/へのDDoS攻撃の多くに使用されました。そのため、信頼できるIP以外のすべてのDNSサーバーのポート53を完全にブロックしました。動作しますが、もう接続できませんが、eth1（パブリックインターネットとのサーバー上のインターフェイス）でtcpdumpを実行すると、攻撃者からの着信パケットが大量に表示されるので、奇妙に思われます。ポート53へ。
Iptablesがこれらのパケットをドロップしても、tcpdumpがこれらのパケットを表示するのは正常ですか？または、iptablesを間違って設定しましたか？
一方、以前に行ったように、サーバーからの発信パケットは表示されないので、ファイアウォールが機能していると思います。カーネルがパケットを完全に落とさないことに私を驚かせますか？または、tcpdumpがカーネルにフックされて、パケットがiptablesに到達する前でもパケットが認識されるようになっていますか？
これはいい質問です。
実際のところ、tcpdumpは、配線（およびNICであれば）の途中で最初に見つかったソフトウェアです[〜＃〜] in [〜＃〜]、そして途中の最後のもの[〜＃〜] out [〜＃〜]。
Wire -> NIC -> tcpdump -> netfilter/iptables
iptables -> tcpdump -> NIC -> Wire
したがって、すべてのパケットがインターフェースに到達し、すべてのパケットがインターフェースから出ます。 tcpdumpで確認できるように、ポート53へのパケットは応答を受信しないため、iptablesルールが正しく構成されていることを確認できました。
[〜＃〜]編集[〜＃〜]
おそらく私はいくつかの詳細を追加する必要があります。 tcpdumpはlibpcapパケットソケットを作成するライブラリに基づいています。通常のパケットがネットワークスタックで受信されると、カーネルfirstは、新しく到着したパケットに関心のあるパケットソケットがあるかどうかを確認し、ある場合は、そのパケットをそのパケットに転送します。ソケット。オプションETH_P_ALLが選択されている場合、allプロトコルはパケットソケットを通過します。
libpcapは、このようなパケットソケットを1つ実装してオプションをアクティブにし、コピーを独自に使用するために保持し、パケットをネットワークスタックに複製します。最初にnetfilter、つまりカーネル空間のiptablesに対応します。同じことを逆の順序で（i.e。、最初にnetfilter、次にパケットソケットを通る最後の通過）、途中で。
これはハッキングされやすいですか？しかし、もちろん。ルートキット宛ての通信を遮断するためにlibpcapを使用する概念実証のルートキットは確かにありますbeforeファイアウォールはそれらに手を置くことができます。しかし、これでも、単純なGoogleクエリがworkingからトラフィックを隠すlibpcapのコードを発掘するという事実と比較すると見劣りします。それでも、ほとんどの専門家は、ネットワークパケットフィルターのデバッグにおいて、利点が欠点をはるかに上回ると考えています。