UnderForge of Lack

知り合いから相談を受けたのでちょっと・・・

----------
FTP
File Transfer Protocol（ファイル・トランスファー・プロトコル、略称：FTP）
を知らない人はあまり居ないかもしれませんが、そのセキュア転送に関してはIT企業でも混乱している様子ですので・・・

----------
SFTP
SFTPは SSH File Transfer Protocolの略称で、実はFTPではありません。
例えば、SourceForgeには
Windows用SCP/SFTPクライアント「WinSCP」で安全なファイル転送
最近では、セキュリティ向上のためファイル転送にFTPではなく、SCPやSFTPを推奨しているサイトも多い。
と記述されていますが、ここに大きな陥穽が潜んでいます。

SSHを外部に開くということは、Windows リモートデスクトップを外部に開放するのと同じということを理解していますか？

SFTPは、要するに SSH -- Secure Shellの仕組みを使ったファイル転送であって、旧 rcpコマンドのセキュア版（別名 scp）です。Portは TCP/22を使用します。

逆に言えば、SFTP/SCPを使用したいということになれば、DMZからWANにPort22をピアスすることになり、これはSSH辞書攻撃などに晒されることになります。
もちろん、id_rsa/dsa の鍵＋パスフレーズをきちんと管理し、一般のshell modeを許可しない方法で開けるのであれば、セキュリティ的には問題がないレベルですが、往々にしてそうはなっていません。
※SCPの場合、認証鍵の作成の際に no-pty オプションを使用することにより、端末の割り当てを明示的に禁止することが可能・・・・かも
SSHD (8) -- AUTHORIZED_KEYS ファイルの形式(※注1)

また、SSHログインとFTPログインのユーザ情報(Credential)は同じになってしまうため、一部ユーザのためだけに FTP を許可したりすると、そこから SSHで侵入、完全に制御を奪われてしまうというケースが多々あるものと推測されています。

----------
FTPS (FTP over SSL/TLS) (※TLSは以降省略します)
FTPSは、従来のFTPで送受信するデータを SSLで暗号化するプロトコルで、SSHを使用する SFTP や SCP とは全く別のものです。 制御通信は Port21を使用し、実際のデータ送受信は、複数のポートをランダムに使用する PASVモードが一般的です。

FTPSには更に２つのモードがあります。
Explicit
　サーバ接続時は非SSLで接続し、ハンドシェイクが完了した後SSL通信に移行
Implicit
　最初からクライアントがSSLハンドシェイクを要求する

一見、Implicitのほうがセキュアに思えますが、Implicitの場合は、基本的にサーバ側のプロトコルに完全合致した設定を理解できる FTPS クライアントが必須となります。またTCP/990や989 を使用することもあるため、環境に依存することが多く、大抵すんなりとは動きません。ExplicitでもAUTHハンドシェイク完了後のID/PASS応答はSSLとなるため、どうしてもサーバ情報を秘匿したい場合以外は問題ないと考えています。

尚、PASVでの動作が前提となる場合、PASV用のポートに対してもケアが必要になります（特にNAT越えの場合）
※PORTモード(データ転送 : Port 20) はあまりお奨めしません。

----------
結論
いずれにせよ、現在FTP で何も考えずにデータ転送をしている環境が大きく変更されることは間違いありません。しかし、インシデントはたった１回で致命傷になります。

今回のGumblar、ガンブラー™の蔓延は、セキュリティを見直す又とないチャンスです。

これを他山の石とし、社内のセキュリティ・ポリシーを再度見直し、クライアントに対してFTP通信の危険性を説き、Web全体のセキュリティの向上を目指す一助になれば、これに勝る幸いはありません。

参考：
FTP, FTPS, SFTP -- 更新日：2005.05.07
FTPの暗号化の種類
FTPサーバ(vsftpd)の構築(RedHat系編)
Fedora/CentOS - FTPサーバの構築(vsFTPD)

※注1
ssh scp sftp の正しい自動実行方法
via:
_ ssh scp sftp の正しい自動実行方法
あと、これも時々目にする勘違いだけど、「no-pty」は仮想端末とれなくなるだけで、シェルが取れなくなるわけじゃないので、仮想端末取らないで「ssh remotehost '/bin/sh' < 悪のスクリプト」とかやるだけの話。
という感じで、実際にはカナリ頭痛のタネ系の問題が多いことも事実です。

------------------------------------------------------------
追記：
ah様より、
restricted shell for scp/sftpってのぢゃだめ？
と、教えていただきました。

ありがとうございます。

rsshは実は使ったことがなかったので、今回勉強のため VMに入れてみます。
特に chroot が可能なのは初めて知りましたので、うまくいけば FTPSよりも楽かもしれません。
が、
相談してきた人は、IIS だったことに気が付いたのは内緒にしておきます（爆）
※正確には、運用中のサーバの中に 2003/IISのものが混じってる

あと、
企業のセキュリティ・ポリシーとして 22番を外向きに開けるのはどうか？と思うぞ？
という意見も頂きました。
ま・・やっぱりそうですよね・・・

------------------------------------------------------------
rssh homepage(日本語訳)
RSSH.CONF
chrootpath

rssh (実際には補助プログラム)が chroot() システムコールを呼んで、指定されたディレクトリにファイルシステムのルートディレクトリを変更する。例えば、
chrootpath=/usr/chroot
は仮想的なファイルシステムのルートを /usr/chroot に変更し、ファイルシステムの /usr/chroot の下以外にユーザがアクセスできないようにし、 /usr/chroot がルートディレクトリとして見えるようにする。 chroot jail を適切に設定するように注意すること。どのようにしたらよいかのヒントについては、rssh ソースとともに配布される CHROOT ファイルを見ること。また chroot(2) の man ページも参照すること。
もし(/etc/password で指定される)ユーザのホームディレクトリが、このキーワードで示されるパス以下であれば、ユーザはホームディレクトリへと chdir される。そうでなければ、chroot jail の / へと chdir される。

rsshによるセキュアなファイル転送

This entry was posted on 日曜日, 1 月 17th, 2010 at 1:30 PM and is filed under RiskHedge, knowledge, security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.