アカウント名:
パスワード:
もしもphpを入れていたり、perlのcgiを送り込まれていたら
<Directory /home/*/public_html/cgi-bin>Options ExecCGI</Directory>
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
「誰にでもアップロードできる」のがヤバイと思う (スコア:5, 参考になる)
ファイルの受け渡し用に簡単なパスワードを使った半anonymousなftpアカウントに侵入されたことがあります。
(今ならうぷろだとか使うケースですかね)
・前提条件: ユーザー名foo(仮)のパスワードはユーザー名と同じ。ssh や telnet は不可でftpのみ可能。chrootしてるので、他のディレクトリは見えない。(実際には、アカウント名は英単語一つ)
侵入方法
1. cracker にブルートフォースでアカウントfooの存在およびパスワードがばれる
2. ftpでホームにphpファイルがアップロードされる
3. httpでhttp://example.com/~foo/bar.php にアクセスが来る→失敗
4. ftpでディレクトリ public_html が作られ、その下に php ファイルがアップロードされる
5. httpでhttp://example.com/~foo/bar.php にアクセス、スクリプトの内容が表示される
(Apacheで「UserDir public_html」は生きていたが、phpは入れてなかった)
ここで cracker は活動を断念、去っていきました。
php の中身は、引数で指定した任意のコマンドを実行可能というもの。
もしもphpを入れていたり、perlのcgiを送り込まれていたら(そのユーザーでもcgiは有効になってました)、とか背筋が寒くなりましたね。
あわてて、apache の設定で UserDir の記述を消し、
必要なユーザーそれそれについて「Alias /~foo/ /home/foo/public_html」などの記述を入れるようにしました。
それ以来、特定少数向けのファイル交換用にも、乱数で生成した推測しにくいパスワードをちゃんと付けてるようにしてます。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:2, すばらしい洞察)
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:1, おもしろおかしい)
何言ってるんですか、FTPでアップロードできなきゃサイバーノーガード戦法で不正アクセス禁止法違反を主張できないじゃないですか。むしろ積極的に開けるべきです。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:1, 参考になる)
phpがヤバイのは分かりますが、CGIはディレクトリ単位でOption ExecCGIが指定されてないと
有効にならないと思いますけど、そんな設定をされていたということですか？
あと、ftpdはモノによってsite chmodを禁止できるものもありますよね。
まぁ、設定は極力穴を塞いでセキュリティを高めておこうというのには同意です。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:5, 興味深い)
ユーザー個別の設定をしてると、ユーザーを増やした時に修正箇所が多くなって面倒なので
上記のようなワイルドカード指定をしていたのですが、
これだと、crackされた、httpアクセスを想定していないアカウントfooに対しても、
~foo/public_html/cgi-bin 以下にCGIをアップロードされれば、CGIの実行が可能になってしまいます。
それ以来、面倒でも「ユーザー個別に設定する」ことを心がけるようにしてます。
15年ぐらい?昔だと、公開サーバに anonymous ftp でアクセスできて、その中に
アップロード可能な「incoming」ディレクトリがあるのが当たり前でしたが、
その頃の慣習を引きずって
・anonymous だとWarez置き場にされてしまう→アカウント名をanonymous以外に。パスワードは空のまま
・パスワードが空だとブルートフォースアタックで一発でバれる→簡単な文字列のパスワードを付ける
・さらなるブルートフォースでばれる→ちゃんとパスワードを付ける
なんて流れで設定してきたので、あまりに場当たり的な対応をしてきたことに、ちょっと後悔しましたね。
incoming (スコア:4, 参考になる)
かく言う自分も2000年ごろ動かしていた自宅サーバーのincomingに怪しげなASPスクリプトを置かれたことがあります。内容は何だったか覚えていませんが、当時の常識として、ftpで見られる領域とWWWで見られる領域は分けるというのがあったので、攻撃者も自分が置いたものがないと首をひねったことでしょう。
その後、そもそもファイルを送ってもらう必然性というのがほとんど無かったのとDMZを作るときに面倒臭いことになったので、自宅サーバーマシンを入れ換えたときにFTPサービスはやめてしまいましたが。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:1)
# あと、攻撃と思しきアクセスを検出して攻撃元アドレスをしばらく無視るとか拒否るとか。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:2, 興味深い)
(生でもゴムでも)ftp putサービスが必要な状況は、昨今極めて稀と思っています。今時のファイル送信は、(俺オレ証明ででも使って)httpsでそれなりの認証を備えたinput type="file"なフォームのup専用URLを、ユーザ限定で(できればユーザ毎にURLも個別にして。そのURLにハイパーリンクが張ってある等は問題外。)使わせ、上がってきたファイルはwebサーバから見える範囲外に隔離して管理者の査閲に付す、くらいの防御をして然るべきと思います。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:2, 参考になる)
・ファイルの受け取りのために使用する。(受け取ったファイルをそのまま公開するつもりはない)
・アップロード者は特定少数
・ファイルサイズは数十MBから数GB
という状況なので、おそらく「極めて希」な例と言えると思います。
> input type="file"なフォームのup専用URL
これは、素人にもアップロードさせやすいというのは大きなメリットなのですが、
大きめのファイルをアップロードさせる場合、
・アップロードが進んでいるのかいないのかさっぱりわからない。いつ頃終わるかも読めない。
・途中で失敗しても再開できない
といった感じで実用性がありません。
あと、アップロード者は素人が多いので、sftp とかも不可。
「ftp って、FFFTPのことだんたんですかー?」なんて返事が来るレベルなので…
で、素のftpに落ち着きました。
> 上がってきたファイルはwebサーバから見える範囲外に隔離して
put途中で失敗して、appendで再開する、なんてこともあるので、自動で隔離などはせず、
完了の報告を受けてから、手動で移動させるようにしてます。
本当は、さらに、対象の個人ごとにアカウントを発行して使い捨てた方がいいのでしょうけど、
面倒なので、少人数のグループ単位でアカウントを作ってます。
http の .htaccess によるアクセス制限みたいに、通常のアカウントとは別な ftpd 専用の認証システムがあればいいんですけどねぇ…
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:0)
最近のftpdはたいてい仮想ユーザ使えます、ってのが答になってますか？
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:0)
Proftpd + LDAP認証を使ってます。
root directoryもローカルのアカウントから完全に切り離して自由に設定できるし便利。
まぁ、Proftpdは違う方でたまに穴が見つかったりしますけど。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:1)
有効なユーザー名が判明し、ftp を動かしていたら、後は辞書攻撃でパスワードを探す、といったパターンでしょうか。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:0)
うちは更に接続元のIPアドレスを逆引きしてドメイン名で接続切るようにしてる
apacheも入れてるけど、ソースからのコンパイルで不要なモジュールはさっくり切っているし(--disable-module=userdirとか)