web-dev-qa-db-ja.com

Linuxサーバーでの奇妙なTCP / IP動作、およびポート21でのエンタープライズファイアウォール

これはトリッキーなものです。

TL; DR：

1）ファイアウォールがクライアントのSYNパケットに応答しない場合でも、クライアントはTCP（クローズ/使用不可）ポート21のファイアウォールとのハンドシェイクを確立します。

2）クライアントは1つのSYNパケットを送信し（再送信なし）、ファイアウォールはクライアントから3つのSYNパケットを確認します。

3）PREROUTINGチェーンにブロックルールがある別の大陸のLinuxサーバーでも同じことが起こります。

最近、Edgeエンタープライズファイアウォール（Gartnerランキングのトップ3）がポート21をそのWANポートで開いているポートとして表示していることに気付きました。

ファイアウォール自体がそのサービスにそのポートを使用しておらず、別のホスト/サーバーにリダイレクトするポリシー/ NAT/LBがない場合でも、NMAPまたはtelnet/NC出力で開いていると表示されます。

ファイアウォールのインターフェイスの下でセキュリティポリシーを介して明示的に拒否しても、違いはありませんでした。そのベンダーのドキュメントを検索しても、結果はまったく得られませんでした。

そのとき、ファイアウォールがポート21に応答するものであることを確認するために、システムでtcpdumpを実行し、ファイアウォールの「パケットフロー」ツールを実行して、何が起こっているかを確認しました。ポート21への接続が流れているのがわかります。ファイアウォールに、クライアントからのパケットがファイアウォール自体に到達することを証明する。

奇妙なことに、私のクライアントは1 SYNパケットを送信し、ファイアウォールはSYNパケット、私のクライアントに応答しません（SYN/ACKは送信されません）そしてまだどういうわけか接続は成功します。

事はTCPハンドシェイクが成功するクライアント側だけであり、クライアント端末でEnterキーを押すと、接続はすぐに閉じます。

これらのファイアウォールはコアがUNIXベースであるため、好奇心から、この動作を[〜＃〜] vps [〜＃〜]（Ubuntuを実行している）で複製できるかどうかを確認しようと試みました。サーバー19）私は別の大陸にいます。

IPTABLESを使用して、[〜＃〜] prerouting [〜＃〜]チェーンでDROPポリシーを作成し、ポート21宛てのトラフィックをブロックしました。テストを繰り返しましたが、結果はまったく同じです。クライアントが送信1つのSYNパケット、Ubuntuサーバーは3つのSYNパケットを確認し、ACKで応答しません、それでもどういうわけか、クライアントの接続が確立されます！クライアント端末でEnterキーを押すと、接続はすぐに閉じます。ファイアウォールでのまったく同じ動作。

以下は、私が実行したテストであり、サーバーとファイアウォールの両方で同一です。

ポート21のサーバーへのクライアントtelnet：

Client~# telnet Server-IP 21
Trying Server-IP...
Connected to Server-IP.
Escape character is '^]'.

Connection closed by foreign Host.

Telnetの実行時にクライアントでTCPDUMPを実行します。

Client~# tcpdump -ni any port 21

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:24:05.456477 IP Client-priv-IP.36284 > Server-IP.21: Flags [S], seq 3093982956, win 64240, options [mss 1460,sackOK,TS val 3370721563 ecr 0,nop,wscale 7], length 0
19:24:05.557556 IP Server-IP.21 > Client-priv-IP.36284: Flags [S.], seq 3130560876, ack 3093982957, win 4080, options [mss 1360,sackOK,TS val 1773913297 ecr 3370721563], length 0
19:24:05.557679 IP Client-priv-IP.36284 > Server-IP.21: Flags [.], ack 1, win 64240, options [nop,nop,TS val 3370721664 ecr 1773913297], length 0
19:24:17.740636 IP Server-IP.21 > Client-priv-IP.36284: Flags [R.], seq 1, ack 1, win 0, length 0

Telnetの実行時にサーバーでTCPDUMPを実行します。

Server~# tcpdump -ni any -Q in port 21

listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
19:25:05.001238 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773972678 ecr 0], length 0
19:25:08.000566 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773975678 ecr 0], length 0
19:25:10.999775 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773978678 ecr 0], length 0
19:25:16.999702 IP Client-pub-IP.36288 > Server-IP.21: Flags [R.], seq 2605288405, ack 0, win 0, length 0

IPTABLESは3つのSYNパケットをドロップします：

Server~# iptables -t raw -L -n -v
Chain PREROUTING (policy ACCEPT 36M packets, 26G bytes)
 pkts bytes target     prot opt in     out     source               destination         
   3  2468 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:21

さまざまなPCやISPからこれをテストして、奇妙なクライアントやインターネット接続の問題も除外しました。

秘密を守るために、IPアドレスとベンダー名を共有することはできませんでした。

誰かがこの振る舞いを説明できますか？最も不可解なのは、クライアントが1つのSYNを送信し、サーバー/ファイアウォールが3つを受信するという事実です。

前もって感謝します

firewallipftptcptraffic-filtering
1
PoJam

ポート21はFTPのよく知られたポートであり、NATに適したプロトコルではありません。クライアントからの編集済みtcpdumpは「Client-priv-IP」と表示されますが、サーバーからのtcpdumpは「Client-pub-IP」と表示されるため、クライアントはNATルーターの背後にあると見なします。 。ルーターがNATを介して動作させるために、FTPをインターセプトし、それ自体で3ウェイハンドシェイクを完了し、並行して宛先サーバーに到達するための3回の試行を実行していることは間違いありません。宛先サーバーが応答しない場合、ルーターは終了します。次の機会にクライアントからの接続。

0
Tilman Schmidt

Tilman Schmidtのおかげで、RFC 3234を検索して見つけることができました。これは、実際にはFTPトラフィックで機能するミドルボックスです。

TCPDUMP出力では、MSS値などの要素やSACKなどのいくつかのTCPオプションがクライアントごとに異なり、ミドルボックスの存在を示しています。

ミドルボックスは以下を操作する傾向があります。

  • いくつかのTCPオプション（SACK、NOPなど）
  • TTL値
  • MSS値
  • 場合によっては送信元ポート
  • シーケンス番号
  • パケットID

FTPのようなプロトコルは2つの異なるTCPチャネルで機能するため、これらのミドルボックスは（楽観的に）このように動作すると思います。FTP接続をプロキシするこの動作は、データチャネルを認識し、中断しないようにするためです。サーバーからクライアントへの流れ。

0
PoJam

これは予期された動作ではありませんか？ 「最初のTCPハンドシェイクがパケットのドロップのために失敗している場合、TCP SYNパケットは3回しか再送信されないことがわかります。」私はしません。 Microsoftがこの主題の権威であるかどうかはわかっていますが、私はこれを見つけました： docs Microsoft

0
Gerard H. Pille