私は誤ってオープンリゾルバDNSサーバーをセットアップしました。このサーバーは、ロシアから/ロシアへのどこかで発生する多数のDDoS攻撃にすぐに使用されました。そのため、信頼できるIPを除き、すべてのDNSサーバーのポート53を完全にブロックしました。それは機能しますが、もうそれらに接続することはできませんが、私にとって奇妙なのは、eth1（公開インターネットを備えたサーバー上のインターフェース）でtcpdumpを実行すると、攻撃者からポート53への多数の着信パケットが表示されることです。
iptablesがそれらをドロップしても、tcpdumpがこれらのパケットを表示するのは正常ですか？または、iptablesを間違って設定しましたか？
一方、以前に行ったサーバーからの送信パケットは表示されないため、ファイアウォールが機能していると思われます。カーネルがパケットを完全にドロップしないのは驚きですか？またはtcpdump、パケットがiptablesに到達する前であってもパケットを見るようにカーネルにフックされていますか？
回答:
これはいい質問です。
実際のところ、tcpdumpは、ウェイINのワイヤ（および、必要に応じてNIC）の後に見つかった最初のソフトウェアであり、ウェイOUTの最後のソフトウェアです。
Wire -> NIC -> tcpdump -> netfilter/iptables
iptables -> tcpdump -> NIC -> Wire
したがって、インターフェイスに到達するすべてのパケットと、インターフェイスを離れるすべてのパケットが表示されます。tcpdumpで見られるように、ポート53へのパケットは応答を受け取らないため、iptablesルールが正しく構成されていることを正常に確認できました。
編集
おそらく、いくつかの詳細を追加する必要があります。tcpdumpは、パケットソケットを作成するライブラリであるlibpcapに基づいています。ネットワークスタックで通常のパケットを受信すると、カーネルは最初に、新しく到着したパケットに関心のあるパケットソケットがあるかどうかを確認し、パケットソケットがある場合は、そのパケットソケットにパケットを転送します。オプションETH_P_ALLを選択すると、すべてのプロトコルがパケットソケットを通過します。
libpcapオプションを使用してそのようなパケットソケットはアクティブに実装、自身の使用のためにコピーを保持し、それは通常の方法でカーネルによって処理され、ネットワークスタック上にパケットの背中を複製、に最初にそれを渡すなど、netfilterのカーネルiptablesのスペース対応物。同じこと、逆順（つまり、最初のnetfilter、最後のパケットソケットの通過）、出口。
これはハッキングの傾向がありますか？しかし、もちろん。ファイアウォールがルートキットに手を出す前に、libpcapを使用してルートキット宛ての通信をインターセプトする概念実証ルートキットが確かにあります。しかし、これでさえ、単純なGoogleクエリがlibpcapからでもトラフィックを隠す作業コードを発見するという事実と比較すると見劣りします。それでも、ほとんどの専門家は、ネットワークパケットフィルターのデバッグにおいて、利点が欠点を大きく上回ると考えています。