「セキュリティ」の版間の差分

提供:MoodleDocs
移動先:案内検索
8行目: 8行目:
*同じ理由で、セキュリティ上の弱点 ( exploits ) をbugtrackerやフォーラムに投稿しないでください。
*同じ理由で、セキュリティ上の弱点 ( exploits ) をbugtrackerやフォーラムに投稿しないでください。


==Simple security measures==
==シンプルなセキュリティ対策==
*The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!
*最良のセキュリティ対策は、データのバックアップを適切に取ることです! しかし、バックアップデータをリストアできないようでしたら、適切なバックアップと呼ぶことができません。リストア処理をテストしてください!
*Load only software or services you will use
*あなたが使用するソフトウェアまたはサービスのみをロードするようにしてください。
*Perform regular updates
*定期的にMoodleのアップデートを行ってください。
*Model your security after the layers of clothing you wear on a cold winter day
*あなたが寒い冬の日に着る服の層にならって、セキュリティ対策を行ってください。


==Basic recommendations==
==Basic recommendations==

2006年7月12日 (水) 10:10時点における版

慎重に翻訳中です。 Mitsuhiro Yoshida 2006年7月11日 (火) 19:05 (WST)

すべてのウェブアプリケーションソフトウェアは、非常に複雑で、どのアップリケーションにも時々発見されるセキュリティの問題があります。通常、これらの問題は、プログラマが予期することのできない入力の組み合わせに関係しています。Moodleプロジェクトでは、セキュリティを重要な部分であると認識し、随時セキュリティホールに対応する等、継続した改善作業を行っています。

すべての前に

  • この記事には、あなたのインストール済みMoodleに関する重要なセキュリティ対策が記載されています。
  • セキュリティ問題は、直接 http://security.moodle.org に投稿してください - 他の場所でしたら開発者が見落とす可能性がありますし、( アタックを避けるため ) 問題が解決されるまで一般公衆にリリースされないからです。
  • 同じ理由で、セキュリティ上の弱点 ( exploits ) をbugtrackerやフォーラムに投稿しないでください。

シンプルなセキュリティ対策

  • 最良のセキュリティ対策は、データのバックアップを適切に取ることです! しかし、バックアップデータをリストアできないようでしたら、適切なバックアップと呼ぶことができません。リストア処理をテストしてください!
  • あなたが使用するソフトウェアまたはサービスのみをロードするようにしてください。
  • 定期的にMoodleのアップデートを行ってください。
  • あなたが寒い冬の日に着る服の層にならって、セキュリティ対策を行ってください。

Basic recommendations

  • Update Moodle regularly on each release
Published security holes draw crackers attention after release. The older the version, the more vulnerabilities it is likely to contain.
  • Disable register globals
This will help prevent against possible XSS problems in third-party scripts.
  • Use strong passwords for admin and teachers
Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
  • Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
Teacher accounts have much freer permissions and it is easier to create situations where data can be abused or stolen.
  • Separate your systems as much as possible
Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.

Run regular updates

  • Use auto update systems
  • Windows Update
  • Linux: up2date, yum, apt-get
Consider automating updates with a script scheduled via cron
  • Mac OSX update system
  • Stay current with php, apache, and moodle

Use mailing lists to stay updated

Firewalls

  • Security experts recommend a dual firewall
Differing hardware/software combinations
  • Disabling unused services is often as effective as a firewall
Use netstat -a to review open network ports
  • Not a guarantee of protection
  • Allow ports
80, 443(ssl), and 9111 (for chat),
Remote admin: ssh 22, or rpd 3389

Be prepared for the worst

Moodle security alerts

  • Register your site with Moodle.org
Registered users receive email alerts

Miscellaneous considerations

These are all things you might consider that impact your overall security:

  • Turn off opentogoogle, esp for K12 sites
  • Use SSL, httpslogins=yes
  • Disable guest access
  • Place enrollment keys on all courses
  • Use good passwords
  • Use the secure forms setting
  • Set the mysql root user password
  • Turn off mysql network access

Most secure/paranoid file permissions

Assuming you are running this 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 subdirs, includes sessions):

owner: apache user (apache, httpd, www-data, whatever)
group: apache group (apache, httpd, www-data, whatever)
perms: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirs (including config.php):

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

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

owner: root
group: apache group
perms: 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).

関連情報