web-dev-qa-db-ja.com

ネームサーバーをキャッシュするためのIptablesルール

BindをCaching-Nameserverとして実行しています。これらは、DNS機能を処理するためのセットアップの3つのルールです。

iptables -A INPUT -s $OUR_NETWORK -p udp --destination-port 53 -j ACCEPT
iptables -A INPUT -s $OUR_NETWORK -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -p udp --source-port 53 -m state --state ESTABLISHED,RELATED -j ACCEPT

最初の2つのルールはクライアント向けです。ゾーンをホストしていないため、ゾーン転送を許可していなくてもTCPを含めたことに注意してください（ただし、一部の正当なクライアントがTCP経由でクエリを実行していることに気づきました）。これが私が含めた理由です。それ。

私の質問は3行目に関するものです。この行は、アップストリームDNSサーバーからの応答（再帰クエリへの応答）用です。この行で十分だと思いましたが、ログ（ドロップしたパケットのうち、ALLOW行と一致しないパケット）で、送信元ポートUDP/53からのUDPパケットが数十個あることに気付きました。

私の最初の考えは次のとおりです。

1）これらは、私のシステムの接続追跡が「関連」として認識しなかった他のDNSサーバーからの正当な応答です。

2）これらは正当な応答ですが、「遅い応答」であるため、私のシステムはそれらを認識しませんでした。

ネームサーバーをキャッシュする際の応答にはどのルールを使用しますか？状態に関係なく、着信ソースポートudp/53のみを照合することで、ANYを許可する必要がありますか？ udpに接続追跡メカニズム（ESTABLISHED、RELATED）を使用していますか？

よろしくお願いします、JFA

linuxdomain-name-systemfirewalliptablesbind
3
JFA

IMHO、出力チェーン（もちろん、UDPとTCPの両方）で出力DNSクエリを明確に許可してから、ポートおよびプロトコル固有のフラグをRELATED入力ルールから削除する必要があります。例：

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

または、言い換えると、出力ポリシーを使用してプロトコルごとにアウトバウンドトラフィックを制御し、ステートフルマッチングを使用してインバウンド応答を制御します。

デフォルトのRHEL/CentOS iptablesルールはこのように機能しますが、デフォルトではすべてのOUTPUTパケットを許可します。

はい、ステートフルマッチングに一致するには遅すぎたため、拒否されたパケットが頻繁に表示されます。

3
Alnitak

接続追跡とUDPは意味がありません。 UDPはコネクションレス型プロトコルであるため、追跡する接続はありません。

RFCに完全に準拠するには、ポート53でtcpトラフィックとudpトラフィックの両方をリッスンする必要があります。

http://tools.ietf.org/html/rfc5966

1
dmourati

TCPは、クエリのサイズが512バイトを超える場合に使用されます。これは、通常、ゾーン転送などに使用されますが、正当なクライアントがこれを実行している場合もあります。

Udp/53からの接続が多いのは、ランダムなハイポートではなく、そのポートで応答するように多くのネームサーバーが構成されているためです。私があなたなら、アップストリームDNSサーバーからのudp/53を許可し、そのままにしておきます。

0
Andy Smith