セキュリティ推奨

作成中です - Mitsuhiro Yoshida (トーク)

すべてのウェブアプリケーションは非常に複雑なものであり、すべてのアプリケーションには時々発見されるセキュリティ問題が存在します。通常、それはプログラマーが予期しない入力の組み合わせに起因します。Moodleプロジェクトはセキュリティを深刻に捉えています。そして、私たちが発見したセキュリティホールを閉じるよう、継続的にMoodleを改良しています。

イントロダクション (Introduction)

このページにはあなたのMoodleインストレーションに関する重要なセキュリティ対策を含みます。
開発者が確認することができて、登録Moodleサイトに早急に対応されるよう知らせるため、あなたはセキュリティ問題をMoodle trackerに報告 (およびセキュリティ問題であるとマーク) する必要があります。
まだアップグレードされていないMoodle管理者を保護するため、あなたは実際のセキュリティ上の弱点をウェブ上のフォーラムまたは他の場所に投稿すべきではありません。

簡易セキュリティ対策 (Simple security measures)

最善のセキュリティ戦略は適切なバックアップです! しかし、リストアできない限り、あなたは良いバックアップをしているとは言えません! あなたのリストア手順を確認してください!
あなたが使用するソフトウェアおよびサービスのみをロードしてください。
定期的な更新を実行してください。
寒い冬の日の重ね着の考えをもとにして、あなたのセキュリティモデルを作成してください。

基本推奨 (Basic recommendations)

それぞれのバージョンのリリース時、定期的にMoodleをアップデートする

公開されたセキュリティホールはリリース後にクラッカーの注意を引くことになります。古いバージョンほど、脆弱性を含んでいる可能性があります。

「register_globals」を無効にしてください!

これはサードパーティスクリプトのXSS (cross site scripting - クロスサイトスクリプティング ) 問題を防ぐための助けとなります。

管理者および教師に強いパスワードを使用する

「難しい」パスワードを選択することは「強引な (brute force) 」アカウントのクラッキングに対する基本的なセキュリティの実践です。

信頼できるユーザにのみ教師アカウントを与える。実運用サーバ上にフリーの教師アカウントが利用できる公開サンドボックスの作成を避けるため。

教師アカウントには極めて自由なパーミッションがあるため、データを悪用および盗用できる状況を簡単に作ることができます。

あなたのシステムを可能な限り分ける

もうひとつの基本的なセキュリティテクニックは異なるシステムで異なるパスワードを使用すること、異なるサービスごとに異なるマシンを使用すること等です。これにより、1つのアカウントが不正使用または1つのサーバに侵入にされたとしても、ダメージが広範囲に広がることを防ぎます。

通常更新を実行する (Run regular updates)

自動更新システムを使用する
Windowsアップデート
Linux: up2date, yum, apt-get

cronのスケジュールスクリプトによる自動更新を考慮する

Mac OSX更新システム
php、apacheおよびmoodleを最新版にする

ファイアウォール (Firewalls)

セキュリティ専門家は2重のファイアーウォールを推奨しています。

ハードウェア/ソフトウェアの組み合わせを別にします。

多くの場合、未使用のサービスを無効にすることはファイアーウォールと同じく効果的です。

開いているネットワークポートを確認するには、netstat -a コマンドを使用してください。

セキュリティ保護の保証があるわけではありません。
許可されるポート

80, 443(ssl), 9111 (チャット用)

リモート管理: ssh 22, または rdp 3389

パスワードポリシー (Password policy)

パスワードポリシーは「設定 > サイト管理 > セキュリティ > サイトポリシー」で設定することができます。

パスワードの複雑さを強制するチェックボックスがあります。オプションは次のとおりです: パスワード長、数字、小文字、大文字、非英数字、連続した同一文字

これらの条件に合致しないパスワードをユーザが入力した場合、入力されたパスワードに関する問題を示したエラーメッセージが表示されます。

初期パスワードの変更とともに複雑なパスワードの使用を強制することにより、ユーザが「良いパスワード」を選択する役に立ちます。

しかし、チェックを面倒にすることにより、結果としてユーザがパスワードを書きとめることになりますので、現実的になる必要もあります。

最悪の事態に備える (Be prepared for the worst)

バックアップを準備してください。
事前にリカバリ処理を練習してください。
定期的にルートキット検出ツールを使用してください。
- Linux/MacOSX - http://www.chkrootkit.org/
- Windows - http://technet.microsoft.com/en-en/sysinternals/bb897445.aspx および http://technet.microsoft.com/de-de/sysinternals/bb897445.aspx

Moodleセキュリティ警告 (Moodle security alerts)

あなたのサイトをmoodle.orgに登録します。

登録ユーザにはメールアラートが送信されます。

セキュリティアラートは下記オンラインでも投稿されます:
ウェブ　- http://moodle.org/security
RSSフィード - http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

様々な検討事項 (Miscellaneous considerations)

以下、あなたのセキュリティ全体に関して影響のある考慮すべき内容です:

セキュアフォーム設定を使用してください。
常にMySQLのrootパスワードを設定してください。
MySQLネットワークアクセスを無効にしてください。
SSLを使用してください (httpslogins=yes)。
良いパスワードを使用してください - 「設定 > サイト管理 > セキュリティ > サイトポリシー」のパスワードポリシーを設定してください。
「設定 > サイト管理 > セキュリティ > サイトポリシー」の「opentogoogle」設定を有効にしないでください。
ゲストアクセスを無効にしてください。
すべてのコースに登録キーを設定するか、すべてのコースにおいて「コース登録可能 = No」に設定してください。
「管理 > サイト管理 > プラグイン > 受講登録 > 自己登録」で登録キーヒント (「ヒントを表示する」) が無効にされていることを確認してください。

最も安全なファイルパーミッション (Most secure/paranoid file permissions)

注意: MS Windowsのパーミッションシステムとは全く異なるため、以下の情報はLinux/Unixベースのインストーレーションのみに適用されます。

あなたのサーバのセットアップに応じて、以下2つの異なるシナリオがあります:

あなたは独自の専用サーバでMoodleを運用しています。
あなたは共有ホスティング環境でMoodleを運用しています。

以下のセクションでは、あなたにパーミッションを設定するためにウェブサービスユーザアカウントおよびグループが必要であることに留意してください。これはサーバによって異なりますが、この機能が無効にうされていない場合、あなたは管理者としてログインした上で http://your.moodle.site/admin/phpinfo.php にアクセスして、「apache」テーブル内にある「User/Group」の行を探してください。例えば、私はユーザアカウントに「www-data」、グループアカウントにも「www-data」を見つけることができました。

専用サーバでMoodleを運用する (Running Moodle on a dedicated server)

あなたが密閉されたサーバでMoodleを運用している、そしてMoodleコードおよびMoodle設定 (config.php) の両方を管理者 (root) が管理していると仮定します。以下、私が考える最も厳重なパーミッションです:

1. moodledataディレクトリおよびすべてのコンテンツ (およびsessionsを含むサブディレクトリ):

owner: apache user (apache, httpd, www-data, whatever; see above)
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 700 on directories, 600 on files

2. moodleディレクトリおよびすべてのコンテンツ (およびconfig.phpを含むサブディレクトリ):

owner: root
group: root
permissions: 755 on directories, 644 on files.

あなたが通常ユーザとしてログインできる場合、2. は下記のようになります:

owner: root
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 750 on directories, 640 on files.

これらのパーミッションは考えすぎのパーミッションであることをご理解ください。moodledataおよびmoodleディレクトリ (およびサブディレクトリ) のパーミッションの厳しさを緩くしたとしても、あなたは十分セキュアであることができます。

共有ホスティング環境でMoodleを運用する (Running Moodle on a shared hosting environment)

あなたが教養ホスティング環境でMoodleを運用している場合、恐らく、上記のパーミッションは正しくありません。ディレクトリに700 (およびファイルに600) のパーミッションを設定した場合、恐らく、あなたのディレクトリおよびファイルにウェブサービスユーザアカウントがアクセスできないようになります。

可能な限りパーミッションを厳しくしたい場合、あなたは以下の内容を把握する必要があります:

ユーザアカウントおよびグループの下でウェブサービスが動作している (上記をご覧ください)。
moodledataおよびmoodleディレクトリ両方のオーナー (通常、あなたのクライアントユーザアカウント) およびグループ。通常、あなたはこれらの情報をホスティングのコントロールパネルのマネージャから取得することができます。moodleフォルダに移動して、ディレクトリまたはファイルを選択した後、そのファイルのパーミッション、オーナーおよびグループを確認または変更してみてください。通常、これは現在のパーミッション、オーナーおよびグループを表示します。同じことをmoodledataディレクトリに対しても実施してください。That would normally show the current permissions, owner and group. Do the same for the moodledata directory.

Then, depending on the following scenarios you should use a different set of permissions (listed from more secure to less secure) for your moodledata directory:

if the web service account and the owner of the directories/files is the same, you should use 700 for directories and 600 for files.
if the web service group and the group of the directories/files is the same, you should use 770 for directories and 660 for the files.
if none of the above, you will need to use 777 for directories and 666 for files, which is less secure but it is your only option. 707 and 606 would be more secure, but it might or might not work, depending on your particular setup.

In fact, you just need to set moodledata the permissions specified above, as all the directories and files inside are created by the web service itself, and will have the right permissions.

Regarding the moodle directory, as long as the web service user account can read the files plus read and execute the directories, that should be enough. There is no need to grant write permission to the web service account/group on any of the files or subdirectories. The only drawback is that you will need to create the config.php by hand during the installation process, as Moodle will not be able to create it. But that should not be a big problem.

Documentation