セキュリティ推奨

作成中です - 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パスワードを設定してください。
Turn off mysql network access
Use SSL, httpslogins=yes
Use good passwords - set up a password policy in Settings > Site administration > Security > Site policies
Do not enable the opentogoogle setting (in Settings > Site administration > Security > Site policies)
Disable guest access
Place enrollment keys on all courses or set Course Enrollable = No for all courses
Ensure the enrolment key hint is disabled (which it is by default) in Administration > Site administration > Plugins > Enrolment > Self enrolment.

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

Note: The following information applies to Linux/Unix based installations only, as MS Windows permission system is quite different.

Depending on your server set-up there are two different scenarios:

You are running Moodle on your own dedicated server.
You are running Moodle on a shared hosting environment.

In the sections below, you are required to use the web service user account and group to set the permissions, so you need to know them. This can vary quite a bit from server to server but if this feature has not been disabled in your server, you can go to http://your.moodle.site/admin/phpinfo.php (logging in as admin), and then search for the line that reads 'User/Group', inside the 'apache' table. For example, I get 'www-data' for the user account and 'www-data' for the group too.

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

Assuming you are running Moodle on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirectories, includes 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 directory and all of its contents and subdirectories (including config.php):

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

If you allow local logins for regular users, then 2. should be:

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

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

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

If you are running Moodle on a shared hosting environment, then above permissions are probably wrong. If you set 700 as the permission for directories (and 600 for files), you are probably denying the web service user account access to your directories and files.

If you want to tighten your permissions as much as possible, you will need to know:

the user account and the group the web service is running under (see above).
the owner of the directories/files of both moodledata and the moodle directory (this should normally be your client user account), and the group of the directories/files. You can usually get this information from the file manager of your hosting control panel. Go to the moodle folder and pick any directory or file and try to view/change the permissions, owner and group of that file. 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