- 締切済み
RH Linux v.7.1 とwu-ftpdの問題
RedHat Linux v.7.1上でwu-ftp-2.6.1-16を使用しています。外部からsshやsftpでは問題なく入ることが出来ます。しかし以下の様に一般ユーザでftpを用いてサーバにアクセスしようとしたときに通常は 230 User xxxx logged in. Remote system type is UNIX Using binary mode to transfer file. ftp> ls とここで入力するとディレクトリの内容が表示されますが、 代わりに次のような結果となるのは何か原因が在りますでしょうか。 227 Entering Passib Mode ( 222,232,222,112,6,136)の状態で 停止状態になります。 この状態で問題のサーバの状態をps ax見てみますとftpは以下のよう な状態になっております。 1990 ? SN 0:00 ftpd: ns.gxxx.co.jp: myname: IDLE お心当たりの解決策がございましたら教えてください。
- みんなの回答 (3)
- 専門家の回答
みんなの回答
うわ~厄介そうですね。^ ^;) 端末側の問題ではない ということですよね? 例えば、WindowsのFFFTPで接続できたPCからコマンドベースのftpなら障害発生 ということですか? とりあえずtcpdumpして正常時と異常な時のパケットの応答状況を比較してみてはいかがですか? といいつつもtcpdumpは使ったことがありませんので詳しくないです。m(_ _)m (自分はLANアナライザを使ってしまうので...) 参考URLにtcpdumpの使用例のサイトをひとつあげておきます。
国内NG、国外OK となるとDNSがらみではないですか? といってもどこかどうあやしいかはちょっとわかりません。すみません。 よくあるのはログ書き出しの為の逆引き解決に時間がかかっているとかですが、 今回は正引きになるから関係ないかな...。 とりあえず逆引き設定あたりのDNS設定に問題がないかチェックしてみては。
補足
ご回答有り難うございました。ご指摘の点につきまして、DNSのファイルを調べ、正引きも逆引きも問題なく作動していることを確認しました。即ちnslookupで正逆ともに検索可能です。その後、wu-ftpdにセキュリティ上の脆弱性が発見されたとの報告が在りましたので、wu-ftpdを最新のものにしました。その結果serverの中でftp>commandが作動するようになりましたが、外部からftp>で入った後は矢張りコマンドがフリーズしておりました。またMacのFetch,WindowsのFFFTPから入れることが解りましたが、小生のlinuxからのアクセスでは正常に作動しません。たのftpサイトには問題なく入れます。不思議の一言なんですが、困っています。
- selenity
- ベストアンサー率41% (324/772)
RedHat7.1上でiptables/ipchainsによるパケットフィルタリングが稼動していませんか? FTPのPASVモードはクライアントのHighポート(1024以上)からサーバ側のHighポートへ接続しますのでサーバ側でHighポートを遮断していると、PASVモードでは接続できません。 その場合は、Activeモードで接続しましょう。 ftpのプロンプトから一度「PASV」と打てば、PASV<-->Activeでモードが切り替わるはずです。
補足
早速のご回答有り難うございました。 ipchains -F , ipchains -Xとしましてフィルタリングは全て解除した結果も同様でした。PASVコマンドをftp>PASVとして実行しましたところInvalid commandと言う表示になりました。どうもコマンドが実行されていないようです。 不思議なことに国内のいくつかの場所からのデータ転送は出来ていないのですが、国外からはftpでアクセスしてデータを転送したり、受信したり出来ています。国外から入った者のアカウントとパスワードを借りて入りましたが、データの転送のコマンドを打ったところでフリーズし、その後Connection time outとなります。ちなみに当方のマシーンから他のサーバには問題なくftpが可能です。Linux上のftpの機能をチェックするプログラムはないものでしょうか。
補足
有り難うございました。カーネルの再構築が必要ということが解りましたので、頂きました方法を試しておりませんが、確かにパケットの状況を見れば何か解るような気が致します。再構築をしないでftpを用いた場合のサーバ間での応答が解ればと思いますが、LANアナライザーはそれが可能と言うことですね。値段も高そうですが。 いずれにしましても接続要求がでて、受けたサーバから応答が出て、接続が完了した後コマンドが作動しない訳ですが、ipchainsですべてポートを解放しているのでポートの問題でもなさそうです。