投稿日:2004年10月06日 作成鷹の巣

No.17432 SSH/Port Forwardingを用いたFTP転送で、UDP137番ポートの通信を試みていた形跡がある。



SSH/Port Forwardingを用いたFTP転送で、UDP137番ポートの通信を試みていた形跡がある。

No.17432 投稿時間:2004年10月06日(Wed) 22:08 投稿者名:まんじゅう URL:

こんにちは.

SSH/Port Forwarding を用いた FTP 転送
(例えば,http://www.hc.keio.ac.jp/itc/manual/outside-net/port_forwarding/)
についてお伺いします.

私は上記URL先で説明されている通り,sshで自宅サーバの21番ポートを
外出先(会社)に飛ばしてftp接続を試みました.
ところが,上記URL先で紹介されているようにはいかず,次のようになりました.
・とりあえずユーザー,パスワードを入力し接続はできる.
・しかしながら,サーバ側のファイル取得に失敗してしまう.
もちろん説明の通りに設定されていることは確認しています.

そこで理由はなぜかといろいろ調べていると,
ftp接続した際に,自宅サーバからUDPの137番ポートを介してクライアント側に通信を試みていた形跡があり,
それがルータのフィルタでせき止められていました.
137番といえばあちらこちらで閉じておくべきだとの指摘を目にすることもあり,うちでも閉じております.
ポートフォワーディングを行わない通常のftp通信の際には上のようなエラーは出ません.
そこで,以下2点についてご教授いただきたいのです.

1.なぜssh PortForwardingを用いたときにファイル取得が失敗してしまうのか
2.ftp接続の際にUDP137番ポートはどのような目的で使われようとしていたのか

どうぞよろしくお願いいたします.


FTPサーバ(およびOS)が取得したIPアドレスの名前解決をnet-biosでする仕様なのかもしれません。

No.17435 投稿時間:2004年10月07日(Thu) 11:31 投稿者名:walbys URL:http://kolinahr.net/

昔、同じようなことをやってみました。

FTPは2つのポートを使います
・ftp-制御 (21)
・ftp-データ

・とりあえずユーザー,パスワードを入力し接続はできる.
・しかしながら,サーバ側のファイル取得に失敗してしまう.

21番ポートが正常に設定されていると、ユーザー/パスワードをSSHを通して接続できますが、データ用のポートの転送はなんら設定されていない状態なので通りません。現状にあっていますね。しかし、PASVモードは使用ポートが決まっていないのでどのポートを飛ばして良いのかもわかりません。

(2)は、137はftpと関係ないので推測になりますが、FTPサーバ(およびOS)が取得したIPの名前解決(net-bios)をする仕様なのかもしれません。

p.s.
もし、このページの説明どおりに接続した場合でも、ftp-データは 暗号化されていない ような気もします。


sftpを使う方向で考えています。

No.17441 投稿時間:2004年10月08日(Fri) 08:20 投稿者名:饅頭 URL:

walbysさま

> 昔、同じようなことをやってみました。
>
> FTPは2つのポートを使います
> ・ftp-制御 (21)
> ・ftp-データ
>
> ・とりあえずユーザー,パスワードを入力し接続はできる.
> ・しかしながら,サーバ側のファイル取得に失敗してしまう.
>
> 21番ポートが正常に設定されていると、ユーザー/パスワードをSSHを通して接続できますが、データ用のポートの転送はなんら設定されていない状態なので通りません。現状にあっていますね。しかし、PASVモードは使用ポートが決まっていないのでどのポートを飛ばして良いのかもわかりません。

確かにそういわれると,データ用のポートがつながっていないのにファイルのやり取りができるわけないですね・・・.
ではなぜ
http://www.hc.keio.ac.jp/itc/manual/outside-net/port_forwarding/
こちらのサイトではできているのかがわからなくなってしまいます・・・(大学内のネットワークだからでしょうか?)

> (2)は、137はftpと関係ないので推測になりますが、FTPサーバ(およびOS)が取得したIPの名前解決(net-bios)をする仕様なのかもしれません。

私が使っているサーバはWAR FTPで,これがそのような使用になっているのかちょっと調べてみようと思います.

> p.s.
> もし、このページの説明どおりに接続した場合でも、ftp-データは 暗号化されていない ような気もします。

たしかにそのとおりですね.
その後いろいろ調べてみたのですが,今のcygwinでsshを立てている私の環境では
WAR FTPとffftpを使ってsshのポートフォワーディングで通信を暗号化しようとしなくても
WinSCPだけで事足りるんじゃないかということに気づき,sftpを使う方向で考えています.

walbysさん,ありがとうございました.
今後もよろしくお願いいたします.


問題は、「接続できてしまう」ことで、「すべて暗号化されている」と誤解するということ。

No.17442 投稿時間:2004年10月08日(Fri) 11:09 投稿者名:walbys URL:http://kolinahr.net/


> ではなぜ
> http://www.hc.keio.ac.jp/itc/manual/outside-net/port_forwarding/
> こちらのサイトではできているのかがわからなくなってしまいます・・・(大学内のネットワークだからでしょうか?)

ftp-制御で接続を確立したら、ftp-データをサーバ/クライアント間で話し合って決めるので、21がsshされている以外は普通のftpと同じ。流れているデータも暗号化されていないポートでの通信。
(グローバルIP、ルータ無しならftp-データの転送までできる)

問題は、この方法で「接続できてしまう」ことで、「すべて暗号化されている」と誤解してしまう人がいるのでは?ということ。
ftpのsshポート転送のページでこの危険性に関して書いてあるページがあまりないのが不思議です。気づいていないのか、気にしていないのか、私が間違っているのか・・、原理は合っていると思うのですが・・。

> 私が使っているサーバはWAR FTPで,これがそのような使用になっているのかちょっと調べてみようと思います.

137に関しては、sshポート転送はローカルゾーンからの接続に見えるので、OSがローカルゾーンからの接続があったらそのnetbios名を取得しようとしている のではないかと思っています。(ftpでnetbios名の必要性が思いつかない)

私もssh、WinSCPを使用しています。cygwinを使っているのならrsyncも便利ですね。


ご参考まで。

No.17446 投稿時間:2004年10月08日(Fri) 22:59 投稿者名:おやじ URL:http://www.aconus.com/~oyaji/

> > ではなぜ
> > http://www.hc.keio.ac.jp/itc/manual/outside-net/port_forwarding/
> > こちらのサイトではできているのかがわからなくなってしまいます・・・(大学内のネットワークだからでしょうか?)
>
> ftp-制御で接続を確立したら、ftp-データをサーバ/クライアント間で話し合って決めるので、21がsshされている以外は普通のftpと同じ。流れているデータも暗号化されていないポートでの通信。
> (グローバルIP、ルータ無しならftp-データの転送までできる)
>
> 問題は、この方法で「接続できてしまう」ことで、「すべて暗号化されている」と誤解してしまう人がいるのでは?ということ。
> ftpのsshポート転送のページでこの危険性に関して書いてあるページがあまりないのが不思議です。気づいていないのか、気にしていないのか、私が間違っているのか・・、原理は合っていると思うのですが・・。

これは、walbysさんがおっしゃっているのが正解で、ftp-dataは完全にアウトバンド通信ですから暗号化されていません。
饅頭さんがうまくいかないのは、NATルータ環境下での自宅FTPサーバのPASV対応ができていないからだと思います。大学内は、トランスペアレント通信ができているでしょうから、PASVで問題が起きないので、気が付いていないだけでしょう。
言い換えると、walbysさんがおっしゃっていることも、チャント対策すればftp-dataもSSHポートで暗号化して飛ばせるということです。
warftpdならnat.confでlocalhostからきた時の、PASVのhost addressを127.0.0.1とし、port rangeを適当な値(4000-4001。レンジを多くとるとその全てをTeraTermで設定しなくてはならなくなるので、適当に。)に設定します。
TeraTermでは、ftpに加え、前述したport range指定した全てのポートを同様にポート転送します。
後は、PASVでFFFTPでつないであげれば、ftp-dataもSSHのトンネルで暗号化通信できます。ftp-dataの全てのポートをTeraTermで設定するわずらわしさがありますが、できないわけではありません。
おやじは、proftpdでssl対応してますので普通の感覚でsftpできてますが、WindowsだとRaidenですかね。


今問題になっていることもおやじさまのサイトに説明がありましたね。

No.17485 投稿時間:2004年10月09日(Sat) 21:44 投稿者名:饅頭 URL:

walbysさま,おやじさま

> 饅頭さんがうまくいかないのは、NATルータ環境下での自宅FTPサーバのPASV対応ができていないからだと思います。大学内は、トランスペアレント通信ができているでしょうから、PASVで問題が起きないので、気が付いていないだけでしょう。

おやじさまのサイトを参考にさせていただいて,(以前と比べると)だいぶ理解できるようになって来ました.
ちょうど今問題になっていることもおやじさまのサイトに説明がありましたね.
今後,おやじさまのサイトにおいてもたくさん勉強させていただきます.

> warftpdならnat.confでlocalhostからきた時の、PASVのhost addressを127.0.0.1とし、port rangeを適当な値(4000-4001。レンジを多くとるとその全てをTeraTermで設定しなくてはならなくなるので、適当に。)に設定します。
> TeraTermでは、ftpに加え、前述したport range指定した全てのポートを同様にポート転送します。
> 後は、PASVでFFFTPでつないであげれば、ftp-dataもSSHのトンネルで暗号化通信できます。ftp-dataの全てのポートをTeraTermで設定するわずらわしさがありますが、できないわけではありません。

nai.confの設定で上のとおり設定したらできました!
ですが・・・,けちな私はprot rangeを4000-4000としていました.
その場合,最初はログインしてすぐのファイル取得のみしかできず,
ディレクトリの移動時にファイル取得失敗のエラーが出てしまいました.
(ほんとはその質問をしようと思っていたのですが)いろいろ試しているうちに,
WarFtpDaemonの設定でftpd_PASVRANDTRIESという変数を0にするか,rangeを一つ増やして4000-4001とすれば
二回目以降のディレクトリ移動時も問題なくできました.
以上,私のようなずぼらな人がいた場合のために,ご報告しておきます.

> おやじは、proftpdでssl対応してますので普通の感覚でsftpできてますが、WindowsだとRaidenですかね。

現在はネットワーク関連事項の理解を進めている段階ですが,もう少し理解できるようになればいろんなソフトも
試してみようと思います.

今後もよろしくお願いいたします.


おやじのテストでは少し状況が違いました。

No.17487 投稿時間:2004年10月09日(Sat) 23:36 投稿者名:おやじ URL:http://www.aconus.com/~oyaji/

> > warftpdならnat.confでlocalhostからきた時の、PASVのhost addressを127.0.0.1とし、port rangeを適当な値(4000-4001。レンジを多くとるとその全てをTeraTermで設定しなくてはならなくなるので、適当に。)に設定します。
> > TeraTermでは、ftpに加え、前述したport range指定した全てのポートを同様にポート転送します。
> > 後は、PASVでFFFTPでつないであげれば、ftp-dataもSSHのトンネルで暗号化通信できます。ftp-dataの全てのポートをTeraTermで設定するわずらわしさがありますが、できないわけではありません。
>
> nai.confの設定で上のとおり設定したらできました!

Linuxではproftpdで確認はしていたのですが、Windowsも論理的にはいけるはずですが、未確認だったので、書いた手前、本当にそうなのか確認しました。
おやじの環境は、サーバ機は、Windows XP Pro SP2 でCygwin SSH + WarFTPDで、クライアントは、Windows XP Home SP2 + Teraterm + TTSSH + FFFTP でしたが、サーバ機でlocalhostでクライアントも動かすと、確かに先に書いた方法でもOKでしたが、違うクライアントからですと、Cygwin SSH からは、サーバ機のプライベートアドレスでWarFTPDに接続してきるので、nat.confに下記を127.0.0.1の行の次に書くことで、正常に動作しました。192.168.1.2は、サーバ機のプライベートアドレスです。

192.168.1.2 0 127.0.0.1 4000-4001

> ですが・・・,けちな私はprot rangeを4000-4000としていました.
> その場合,最初はログインしてすぐのファイル取得のみしかできず,
> ディレクトリの移動時にファイル取得失敗のエラーが出てしまいました.
> (ほんとはその質問をしようと思っていたのですが)いろいろ試しているうちに,
> WarFtpDaemonの設定でftpd_PASVRANDTRIESという変数を0にするか,rangeを一つ増やして4000-4001とすれば
> 二回目以降のディレクトリ移動時も問題なくできました.
> 以上,私のようなずぼらな人がいた場合のために,ご報告しておきます.

ftpd_PASVRANDTRIESは、見てませんでしたね。おやじは、知りませんでした。おやじはオッチョコチョイなので、よく1セッション張ったままもう1セッション張ろうとして失敗して、あれ? なんて無駄な時間を使うことが多いので、最低2セッションは設定することが多いので気が付きませんでした。


rsync の場合は?

No.17513 投稿時間:2004年10月15日(Fri) 09:15 投稿者名:スギマツ URL:

rsync の場合はどうなのでしょうか?

rsync -e ssh
とSSH指定しすれば暗号化されて通信されるような事がかかれているのですが
本当にデーター含めすべて暗号化されているのでしょうか。


暗号化されています。

No.17516 投稿時間:2004年10月15日(Fri) 22:03 投稿者名:おやじ URL:http://www.aconus.com/~oyaji/

etherealあたりでパケットキャプチャすれば、すぐに分かります。
上記のケースではsshで暗号化されています。速度もそこそこ出ますね。
一度整理しようと思ってますが、Windows で cygwin ssh + warftpd の組み合わせは、何故か非常に重いですね。
FTPのみやSCPのみでは確かにLinuxに比べれば遅いですが十分使える範囲ですが、組み合わせてしまうと15KB/sぐらいしかでません。原因が良く分かりません。因みに、WindowsXP SP2 (Pen4 2.6G HT, 1G mem )ですから、ハード要因ではないですし、CPUもほとんど使われていません。
LinuxでSSH + proftpdなら700~1MB/sぐらいでます。(cel 1.4G、512M mem)


|目次|掲示板|過去ログ目次|▲頁先頭|