web-dev-qa-db-ja.com

Iptables： "-p udp --state ESTABLISHED"

発信DNSを許可するためによく使用される次の2つのiptablesルールを見てみましょう。

iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53 
   -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -p udp --sport 53 --dport 1024:65535
   -m state --state ESTABLISHED -j ACCEPT

私の質問は、UDPのESTABLISHED状態をどの程度正確に理解する必要があるかです。 UDPはステートレスです。

これは私の直感です-これが間違っているかどうか、またはどこが間違っているか知りたいです：

Manページは私にこれを伝えます：

状態

このモジュールを接続追跡と組み合わせると、このパケットの
接続追跡状態にアクセスできます。
 
 --state ...

したがって、iptablesは基本的に、発信パケットに使用されたポート番号を記憶します（UDPパケット用に他に何を記憶できますか？）。次に、短い時間枠内に送り返される最初の着信パケット？攻撃者はポート番号を推測する必要があります（それは本当に難しいですか？）

競合の回避について：

カーネルはどのポートが（他のサービスまたは以前の発信UDPパケットによって）ブロックされているかを追跡しているため、これらのポートはタイムフレーム内の新しい発信DNSパケットに使用されませんか？ （時間枠内に誤ってそのポートでサービスを開始しようとすると、どうなりますか？その試みは拒否/ブロックされますか？）

上記のテキストですべてのエラーを見つけてください:-)ありがとうございます。

クリス

linuxdomain-name-systemiptablesudp
18
Chris Lercher

したがって、iptablesは基本的に、発信パケットに使用されたポート番号を記憶します（UDPパケットの場合、他に何を記憶できるでしょうか）。

UDPの場合は、送信元と宛先のポートとアドレスが保存されていると思います。

状態テーブルを検査する場合は、conntrackおよび/またはnetstat-natをインストールしてください。

（時間枠内に誤ってそのポートでサービスを開始しようとすると、どうなりますか？その試みは拒否/ブロックされますか？）

OUTPUTとINPUTを使用しているので、ローカルサービスについて話しています。そのポートはすでに使用されています。何かがすでにそのポートでリッスンしているため、システムで別のサービスを起動できるとは思いません。もし本当にやりたければ、最初のサービスを停止して別のサービスを開始することができると思います。その場合、応答はおそらくサービスに届きます。サービスがパケットで何をするかは、パケットの内容が何であるか、およびそれがどのサービスであるかによって異なります。

12
Zoredache

注意：この回答は編集されています。

Manページの内容にかかわらず、ESTABLISHEDは「ステートフル」を意味するようです。 UDPの場合、これは単に（お勧めのとおり）各送信UDPパケット（「src ip、src port dst ip、dst port」タプル）をしばらくの間覚えて、その応答を認識することを意味します。

FWIW、DNSトラフィックの通常のルールは次のようになります。

# permit any outbound DNS request (NB: TCP required too)
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53  -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024:65535 --dport 53  -j ACCEPT

# accept any packet that's a response to anything we sent
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

つまり、OUTPUTチェーン上のトラフィックを制御し、iptables状態モジュールにINPUTチェーン上のその他すべてを処理させます。

この関連質問 も参照してください。

8
Alnitak

Iptablesの開発者たちは、「確立された」状態は、2つのクライアント間のプロトコルが何であれ、パケットが両方向で見られたときの状況であると考えてきました。

状態拡張はconntrackの一部です。カーネルはテーブルから状態を理解します

/proc/net/nf_conntrack

送信者の観点から見た、テーブルnf_conntrackのUDPのiptable状態の例。 UDPでDNSクエリを送信するとしましょう

udp   17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
 [UNREPLIED] src=192.168.1.10 dst=192.168.1.2 sport=53 \
 dport=35237 use=1

パケットが送信されました。返答がないので、テーブルには見返りに期待されるデータ（DNS応答のパケット）が含まれています。

udp   17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
  src=192.168.1.10 dst=192.168.1.2 sport=53 \
 dport=35237 use=1

応答が到着し、未応答のフラグがなくなっています。これは、このUDP接続がシステムで定義されている少しの間ESTABLISHED状態であることを意味します。

1
Nicolas Guérinet