アカウント名:
パスワード:
もしもphpを入れていたり、perlのcgiを送り込まれていたら
<Directory /home/*/public_html/cgi-bin>Options ExecCGI</Directory>
みたいなことをしてました。 ユーザー個別の設定をしてると、ユーザーを増やした時に修正箇所が多くなって面倒なので上記のようなワイルドカード指定をしていたのですが、これだと、crackされた、httpアクセスを想定していないアカウントfooに対しても、~foo/public_html/cgi-bin 以下にCGIをアップロードされれば、CGIの実行が可能になってしまいます。 それ以来、面倒でも「ユーザー個別に設定する」ことを心がけるようにし
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
「誰にでもアップロードできる」のがヤバイと思う (スコア:5, 参考になる)
ファイルの受け渡し用に簡単なパスワードを使った半anonymousなftpアカウントに侵入されたことがあります。
(今ならうぷろだとか使うケースですかね)
・前提条件: ユーザー名foo(仮)のパスワードはユーザー名と同じ。ssh や telnet は不可でftpのみ可能。chrootしてるので、他のディレクトリは見えない。(実際には、アカウント名は英単語一つ)
侵入方法
1. cracker にブルートフォースでアカウントfooの存在およびパスワードがばれる
2. ftpでホームにphpファイルがアップロードされる
3. httpでhttp://example.com/~foo/bar.php にア
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:1, 参考になる)
phpがヤバイのは分かりますが、CGIはディレクトリ単位でOption ExecCGIが指定されてないと
有効にならないと思いますけど、そんな設定をされていたということですか？
あと、ftpdはモノによってsite chmodを禁止できるものもありますよね。
まぁ、設定は極力穴を塞いでセキュリティを高めておこうというのには同意です。
Re:「誰にでもアップロードできる」のがヤバイと思う (スコア:5, 興味深い)
みたいなことをしてました。
ユーザー個別の設定をしてると、ユーザーを増やした時に修正箇所が多くなって面倒なので
上記のようなワイルドカード指定をしていたのですが、
これだと、crackされた、httpアクセスを想定していないアカウントfooに対しても、
~foo/public_html/cgi-bin 以下にCGIをアップロードされれば、CGIの実行が可能になってしまいます。
それ以来、面倒でも「ユーザー個別に設定する」ことを心がけるようにし
incoming (スコア:4, 参考になる)
かく言う自分も2000年ごろ動かしていた自宅サーバーのincomingに怪しげなASPスクリプトを置かれたことがあります。内容は何だったか覚えていませんが、当時の常識として、ftpで見られる領域とWWWで見られる領域は分けるというのがあったので、攻撃者も自分が置いたものがないと首をひねったことでしょう。
その後、そもそもファイルを送ってもらう必然性というのがほとんど無かったのとDMZを作るときに面倒臭いことになったので、自宅サーバーマシンを入れ換えたときにFTPサービスはやめてしまいましたが。