誤ってオープン リゾルバ DNS サーバーを設定してしまったため、すぐにロシアを起点とする一連の DDoS 攻撃に使用されました。そのため、信頼できる IP を除くすべてのユーザーに対して両方の DNS サーバーでポート 53 を完全にブロックしました。これで接続できなくなりましたが、奇妙に思えるのは、tcpdump eth1(パブリック インターネットとのサーバー インターフェイス) を実行すると、攻撃者からポート 53 に大量のパケットが着信しているのが見られることです。
iptables がこれらのパケットをドロップしても、tcpdump がこれらのパケットを表示するのは正常ですか? それとも、iptables を間違って設定したのでしょうか?
一方、以前は見えていたサーバからの送信パケットが見当たらないので、ファイアウォールがうまく機能しているのだと思います。カーネルがパケットを完全にドロップしないのは驚きです。それとも、カーネルがパケットがtcpdumpiptables に到達する前にパケットを認識できるようにカーネルに接続されているのでしょうか。
答え1
これはいい質問ですね。
実際のところ、tcpダンプワイヤー（とNIC）の後に最初に見つかるソフトウェアですで、そして最後の1つ外。
Wire -> NIC -> tcpdump -> netfilter/iptables
iptables -> tcpdump -> NIC -> Wire
したがって、インターフェイスに到達するすべてのパケットと、インターフェイスから送信されるすべてのパケットが表示されます。tcpdump で確認すると、ポート 53 へのパケットは応答を受け取らないため、iptables ルールが正しく設定されていることが確認されました。
編集
おそらく、いくつかの詳細を追加する必要があります。tcpダンプに基づいていますlibpcap、ライブラリを作成するパケットソケット通常のパケットがネットワークスタックで受信されると、カーネルは初め新しく到着したパケットに興味を持つパケットソケットがあるかどうかを確認し、ある場合はそのパケットソケットにパケットを転送します。オプションETH_P_ALLが選択されると全てプロトコルはパケット ソケットを経由します。
libpcapオプションを有効にしてそのようなパケットソケットを1つ実装し、コピーを独自に使用し、パケットをネットワークスタックに複製して戻します。そこでは、最初にネットフィルター、カーネル空間版iptables同じことを逆の順序で（つまり（最初にネットフィルタ、最後にパケットソケットを通過）、出力時に行われます。
これはハッキングされやすいのでしょうか？もちろんです。確かに概念実証ルートキットは存在します。libpcapルートキット宛の通信を傍受する前にファイアウォールはそれらに手を出すことができます。しかし、これは、単純なGoogle検索で発見できる事実に比べれば見劣りします。働くトラフィックを隠すコードlibpcapそれでも、ほとんどの専門家は、ネットワーク パケット フィルターのデバッグにおいては、利点が欠点をはるかに上回ると考えています。
答え2
今日はパケット分析の練習をしました。特に IPsec に興味がありますtcpdump。そこで、盗聴とパケット フローの関係について説明しているこの Web ページを見つけました。あなたの混乱を解消するのに役立つと思います。
図9: ICMPエコー要求h1 → h2、r1トラバーサル、暗号化+カプセル化:
