セキュリティに関する推奨事項

すべてのWebアプリケーションソフトウェアは非常に複雑であり、すべてのアプリケーションには、プログラマーが予期していなかった入力の組み合わせを伴う、時々見られるセキュリティの問題があります。 Moodleプロジェクトはセキュリティを真剣に受け止めており、Moodleを継続的に改善して、見つかった穴を塞いでいます。

はじめに

このページには、Moodleインストールの重要なセキュリティ対策が含まれています。
セキュリティの問題をMoodleトラッカーに報告して（そしてセキュリティの問題としてマークしてください!）、開発者がそれを見て登録済みのMoodleサイトにできるだけ早く修正について通知できるようにする必要があります。
実際のエクスプロイトをフォーラムやウェブ上の他の場所に投稿しないでください（まだアップグレードしていないMoodle管理者を保護するため）。

簡単なセキュリティ対策

最善のセキュリティ戦略は優れたバックアップです!ただし、リストアできない限り、適切なバックアップはありません。リストア手順をテストしてください!
使用するソフトウェアまたはサービスのみをロードします
定期的な更新を実行します
寒い冬の日に着る服の層をモデルにしてセキュリティをモデル化する

基本的な推奨事項

リリースごとに定期的にMoodleを更新する: 公開されたセキュリティホールは、リリース後にクラッカーの注目を集めます。バージョンが古いほど、含まれる可能性のある脆弱性が多くなります。
httpsを使用して、（ログインページだけでなく）すべてのページを保護します: https経由でのみすべてのページにアクセスできるようにすることで、Moodleインスタンスとユーザからのすべてのトラフィックを保護します。これにより、ログイン時にパスワードが保護されるだけでなく、ユーザのプライバシーが保護されるため、WLANプロバイダーなどのサードパーティからすべてのユーザデータが傍受または操作（広告インジェクション）されることはありません。無料のhttps証明書は https://letsencrypt.org/ から入手できます。さらに、moodle設定でhttpslogin=yesを設定して、ログイン認証情報を送信するための保護レイヤーを追加します。
グローバルの登録 MUST を無効にする: これは、サードパーティのスクリプトで発生する可能性のあるXSSの問題を防ぐのに役立ちます。
管理者と教師には強力なパスワードを使用してください: 難しい パスワードの選択は、アカウントの ブルートフォース クラッキングから保護するための基本的なセキュリティ慣行です。
信頼できるユーザにのみ教師アカウントを付与します。本番サーバで無料の教師アカウントを使用してパブリックサンドボックスを作成することは避けてください。: 教師のアカウントにははるかに自由なパーミッションがあり、データが悪用されたり盗まれたりする可能性のある状況を簡単に作成できます。
システムを可能な限り分離する: 別の基本的なセキュリティ手法は、システムごとに異なるパスワードを使用したり、サービスごとに異なるマシンを使用したりすることです。これにより、1つのアカウントまたは1つのサーバが侵害された場合でも、被害が広範囲に及ぶのを防ぐことができます。

定期的な更新を実行する

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

cron経由でスケジュールされたスクリプトを使用して更新を自動化することを検討してください

MacOSXアップデートシステム
php、apache、moodleを最新の状態に保つ

メーリングリストを使用して最新情報を入手してください

CERT - http://www.us-cert.gov/cas/signup.html
PHP - http://www.php.net/mailing-lists.php - アナウンスリストにサインアップ
MySQL - http://lists.mysql.com - MySQLアナウンスにサインアップ

ファイアウォール

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

ハードウェア/ソフトウェアの組み合わせの違い

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

netstat -aを使用して、開いているネットワークポートを確認します

保護を保証するものではありません
ポートを許可する

80、443（ssl）、および9111（チャット用）、

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

パスワードポリシー

パスワードポリシーは、 設定 > サイト管理 > セキュリティ > サイトポリシー で設定できます。

パスワードの複雑さを強制するかどうかを決定するチェックボックス、パスワードの最小長、最小桁数、最小小文字数、最小大文字数、および非英数字の最小数を設定するオプションがあります。

ユーザがこれらの要件を満たさないパスワードを入力すると、入力したパスワードの問題の性質を示すエラーメッセージが表示されます。

ユーザに初期パスワードの変更を要求するとともにパスワードの複雑さを強制することは、ユーザが 適切なパスワード を選択し、実際に使用していることを確認するのに大いに役立ちます。

ただし、チェックを面倒にすると、書き留めてしまうだけなので、現実的にしてください。

最悪の事態に備える

バックアップを用意してください
事前に回復手順を練習してください
定期的にルートキット検出器を使用してください
- 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.orgにあなたのサイトを登録してください

登録ユーザは電子メールアラートを受信します

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

その他の考慮事項

これらはすべて、全体的なセキュリティに影響を与えると考える可能性のあるものです。

セキュアフォーム設定を使用してください
常にmysql rootユーザパスワードを設定してください
mysqlネットワークアクセスをオフにします
SSLを使用、httpslogins=yes
適切なパスワードを使用する - 設定 > サイト管理 > セキュリティ > サイトポリシー でパスワードポリシーを設定します
opentogoogle 設定を有効にしないでください（ 設定 > サイト管理 > セキュリティ > サイトポリシー ）
ゲストアクセスを無効にする
すべてのコースに登録キーを配置するか、すべてのコースでコース登録可能=いいえに設定します
管理 > サイト管理 > プラグイン > 登録 > 自己登録 で、登録キーのヒントが無効になっていることを確認します（デフォルトでは無効になっています）。
サイト管理者がシステム管理者でもない場合は、Webインターフェイスを介してプラグイン（サーバ上で実行可能なコードを含めることができる）をインストールしないようにすることができます。この機能を無効にするには、内からのプラグインのインストールの防止のドキュメントを参照してください。

最も安全な/妄想的なファイルのアクセス許可

注 : MS Windowsのアクセス許可システムはまったく異なるため、以下の情報はLinux / Unixベースのインストールにのみ適用されます。

サーバの設定に応じて、2つの異なるシナリオがあります。

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

以下のセクションでは、Webサービスのユーザアカウントとグループを使用してアクセス許可を設定する必要があるため、それらを知っておく必要があります。これはサーバーごとにかなり異なる可能性がありますが、この機能がサーバーで無効になっていない場合は、 http://your.moodle.site/admin/phpinfo.phpにアクセスできます。（adminとしてログイン）、'apache' テーブル内で 'User/Group' と表示されている行を検索します。たとえば、ユーザーアカウントの 'www-data' とグループの 'www-data' も取得します。

専用サーバでMoodleを実行する

封印されたサーバでMoodleを実行していて（つまり、マシンでユーザログインが許可されていない）、rootがmoodleコードとmoodle構成（config.php）の両方の変更を処理すると仮定すると、これは私が考えることができる最も厳しいパーミッションです:

1. moodledataディレクトリとそのすべてのコンテンツ（およびサブディレクトリ、セッションを含む）: 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を実行する

共有ホスティング環境でMoodleを実行している場合、上記のパーミッションはおそらく間違っています。ディレクトリのアクセス許可として700（およびファイルのアクセス許可）として600を設定した場合、ディレクトリとファイルへのWebサービスユーザアカウントのアクセスを拒否している可能性があります。

パーミッションを可能な限り厳しくしたい場合は、次のことを知っておく必要があります。

ユーザアカウントとWebサービスが実行されているグループ（上記を参照）。
moodledataとmoodleディレクトリの両方のディレクトリ/ファイルの所有者（これは通常、クライアントユーザアカウントである必要があります）、およびディレクトリ/ファイルのグループ。通常、この情報はホスティングコントロールパネルのファイルマネージャから取得できます。 moodleフォルダに移動し、任意のディレクトリまたはファイルを選択して、そのファイルのパーミッション、所有者、およびグループを表示/変更してみてください。これは通常、現在の権限、所有者、およびグループを示します。 moodledataディレクトリについても同じようにします。

次に、次のシナリオに応じて、moodledataディレクトリに異なる権限のセット（安全性の高いものから安全性の低いものへとリストされている）を使用する必要があります。

Webサービスアカウントとディレクトリ/ファイルの所有者が同じ場合は、ディレクトリに700を使用し、ファイルに600を使用する必要があります。
Webサービスグループとディレクトリ/ファイルのグループが同じである場合は、ディレクトリに770を使用し、ファイルに660を使用する必要があります。
上記のいずれでもない場合は、ディレクトリに777を使用し、ファイルに666を使用する必要があります。これは安全性が低くなりますが、これが唯一のオプションです。 707と606の方が安全ですが、特定の設定に応じて、機能する場合と機能しない場合があります。

実際、内部のすべてのディレクトリとファイルはWebサービス自体によって作成され、適切なアクセス許可を持つため、moodledataに上記で指定したアクセス許可を設定する必要があります。

moodleディレクトリに関しては、Webサービスのユーザアカウントがファイルを読み取り、ディレクトリを読み取って実行できる限り、それで十分です。ファイルまたはサブディレクトリのWebサービスアカウント/グループに書き込みパーミッションを付与する必要はありません。唯一の欠点は、Moodleがconfig.phpを作成できないため、インストールプロセス中に手動でconfig.phpを作成する必要があることです。しかし、それは大きな問題ではないはずです。

Documentation