DNS サーバーに対する DNS 増幅攻撃中に、一部の DNS 要求に のような IP/ポートの組み合わせがあることに気付きました104.49.96.196:80。これは偽装 IP であることは理解していますが、DNS 要求のポートをフィルタリングすることを検討してもよいでしょうか? 1023 を超えるポートは想定しない方がよいと思います。これは安全な想定でしょうか? その場合、これは簡単に見分けることができ、DNS 増幅攻撃に応答しないで済むと思います (パケットが DNS サーバーに到達し、WAF によってドロップされない場合)。
答え1
いいえ、それは安全な仮定ではありません。ポートをフィルタリングしようとしないでください。これは有益な結果をもたらさないでしょう。クライアントがローカル ポートをどのように処理するかはクライアント自身の問題であり、したがってサーバーとしてはすべてのポートからトラフィックを受け取ることが予想されます。Unix が 1024 で分割されるのは過去の時代遅れの遺産であり、今日では基本的に何の意味もありません。
DNS 増幅に対抗したい場合、「標準的な」対策 (受信するすべてのトラフィックを本当に処理する必要があるか、つまり完全にオープンになっていないかを確認するなど) の他に、現在最もよく使用される方法の 1 つは、RRL、つまり基本的にレート制限です。
見るhttps://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/このテーマについての紹介とhttps://www.isc.org/docs/DNS-RRL-LISA14.pdfより技術的なプレゼンテーションについてはこちらをご覧ください。
答え2
DNS クライアントの送信元ポートは 1023 より大きい必要があります。
1024 未満の場合、他の DNS サーバーからのものである場合は送信元ポート 53 のみになりますが、その可能性は低いです。
確認するtcpdump port 53
見ることでRFC6056そしていくつかのサンプルによる簡略化さらに言えば、正常に動作する IP スタックは、送信元ポートが 49152 (最初の一時ポート) より小さいはずがないと言えます。ただし、セクション 3.2 はこれに矛盾しており、サンプルも同様です。
しかし、RFC6056 を再定義する RFC への参照を誰かが提供できるようになるまでは、 sport <= 1023 は有効ではないと言っても過言ではありません。
何らかの理由でリクエストが失敗した場合、クライアントは再試行し、リクエストが成功することを望みます。(たとえ失敗したとしても、私はそれらの実装を無視します)