Manual:Security/ru

From MediaWiki.org
Jump to: navigation, search
Если Вы считаете что нашли проблему безопасности в MediaWiki или в одном из сайтов Wikimedia's, пожалуйста свяжитесь напрямую с security@wikimedia.org, чтобы мы могли выпустить исправление.

Contents

Обновляйтесь [edit]

Самый главный шаг в обеспечении безопасности, который Вы можете предпринять, это поддерживать Ваше программное обеспечение в актуальном состоянии. И MediaWiki и программы от которых он зависит периодически получают новые версии исправляющие найденные бреши в безопасности, которые могут быть использованы против Вас.

Разработчики MediaWiki настоятельно рекомендуют каждому пользователю MediaWiki подписаться на рассылку mediawiki-announce mailing list. Сообщения этой рассылки имеют очень небольшой размер и информируют лишь о выходе новый версий.

В соотвествии с жизненным циклом MediaWiki, каждый релиз будет получать обновления безопасности в течение одного года. Старые релизы могут содержать известные, но не исправленные ошибки безопасности.

Также не забудьте поддерживать в обновленном состоянии Apache, PHP, MySQL и любое другое программное обеспечение запущенное на ваших серверах включая операционную систему и другие вэб-приложения. Некоторые пользовательские инсталяции MediaWiki 1.3.x были затронуты сетевым червем в феврале 2004-ого предназначенным для атаки на phpBB. Как только червь получил доступ через брешь в безопасности phpBB он добавил сообщение "you are hacked" к другим .php файлам к которым были права на запись, включая шаблоны MediaWiki 1.3.


Основные рекомендации для PHP [edit]

Эти небольшие рекомендации относятся к общему окружению PHP, а не только конкретно к MediaWiki.

Рекомендации к настройкам PHP в php.ini или расположенным в другом месте

  • Отключите register_globals.
    • Многие PHP атаки основаны на инъекциях в глобальные переменные, поэтому отключение таких переменных исключают возможность множества потенциальных атак.
    • Если Вам необходимо register_globals для других вэб-приложений, то включайте опцию выборочно, для виртуальных хостов и поддиректорий.
    • MediaWiki будет в безопасности и при включённой опции, однако отключение этой опции закроет возможность атаки на пока ещё неизвестные уязвимости.
  • Если это не необходимо отключите allow_url_fopen.
    • Уязвимости удалённого выполнения PHP кода зависят от возможности вставки URL в include() или require(). Если Вам не нужно использовать файлы с других сайтов в работе скрипта отключите эту возможность.
    • MediaWiki может потребоваться эта настройка для расширения Lucene search extension, для OAI harvester extension, и некторых действий связанных с Special:Import в версии 1.5. В случае типичной установки эта функция не нужна.
    • MediaWiki будет в безопасности и при включённой опции, однако отключение этой опции закроет возможность атаки на пока ещё неизвестные уязвимости.
  • Установите session.use_trans_sid в off.
    • Если включено, то идентификатор сессии может быть добвлен к URL в случае неработоспособности cookie. Это может привести к утечке информации о сессии на другие сайты через реферер или через ссылку копирование-вставка.
    • Вы должны выключить это в любом случае.


Ваш php.ini может быть найден в:

  • /etc/php.ini (Red Hat Linux, SuSE / Novell Linux)
  • /etc/php4/apache/php.ini (Debian woody and sarge, Ubuntu 6.10 с php4 и apache 1.3)
  • /etc/php5/apache2/php.ini (Ubuntu 6.10 с php5 и apache2, Debian etch)
  • /etc/httpd/php.ini (Trustix Secure Linux 3.0)
  • /usr/local/php/lib/php.ini (Mac OS X использующий пакет Marc Liyanage's PHP)
  • /etc/apache/php.ini (Slackware 10.x)
  • /var/www/conf/php.ini (OpenBSD)
  • /usr/local/etc/php.ini (FreeBSD)
  • /usr/pkg/etc/php.ini (NetBSD)
  • Gentoo Linux:
    • /etc/php/apache2-php4/php.ini
    • /etc/php/cli-php4/php.ini
    • /etc/apache2/php.ini
  • c:\windows\php.ini (Windows)

Если в Вашем экземпляре php.ini есть такая строка:

register_globals = On

Замените ее на:

register_globals = Off

В качестве альтернативы, Вы можете добавить такую директиву apache для отключения register_globals для директорий:

php_flag register_globals off

Затем перезагрузите настройки Apache (apachectl reload или другим способом (прим.переводчика)).


В многопользовательских системах где PHP установлен в виде модуля для Apache, все пользовательские скрипты запускаются от имени одного и того же пользователя с ограниченными правами. Это может дать такому пользователю возможность чтения Ваших конфигурационных файлов (включая пароли к базе данных), возможность чтения и изменения данных сессии, или возможность записи файлов в Вашу директорию для загрузки файлов (upload).

Для безопасности многопользовательских систем убедитесь в использовании конфигурации CGI/FastCGI в которых пользовательские скрипты запускаются под собственными учётными записями либо используется Safe Mode|Безопасный режим для ограничения доступа скрипта к пользовательским файлам. Напоминаем, что безопасный режим может конфликтовать с некоторыми функциями MediaWiki такими как загрузка файлов и дополнения.


Основные рекомендации к MySQL [edit]

Главное - это минимизировать доступ к базе в MySQL. Если база будет использоваться только на локлаьной машине, отключите поддержку сети или используйте локальный сетевой доступ (используя интерфейс "петля" - loopback, об этом ниже) так чтобы сервер мог соединяться с локальными клиентами через UNIX сокеты.

Если база данных будет использоваться через сеть с ограниченным количеством клиентских компьютеров, то используйте правила IP брандмауэра для ограничения доступа к TCP порту 3306 только с компьютеров Вашей локальной подсети и отказа в доступе из Интернет. Такие меры предотвратят случайный доступ к серверу через неизвестные, пока, ошибки в MySQL, данные по ошибке права GRANT или утечке пароля.

Если Вы создали нового пользователя для MySQL через инсталлятор MediaWiki, значит ему были даны слишком большие права для проверки хорошей работоспособности со второго сервера так же как с локального. Вы можете проверить вручную эти права или вручную создать пользователя со специфическими правами любым способом.

Напоминаем, что таблица user в базе данных MediaWiki содержит пароли пользователей и может содержать их e-mail адреса и должна рассматриваться как приватная информация.

Смотрите так же:

  • опции командной строки mysql --skip-networking.
  • Настройка bind-address=127.0.0.1 в Вашем my.ini (ниже секции [mysqld]) приведёт к тому, что MySQL будет работать только с loopback интерфейсом. Эта настройка сделана по умолчанию инсталляции EasyPHP для Windows. (Если используется MySQL на машине с Unix настройка может быть в виде skip-networking вмесето вышеуказанной в файле my.cnf.)
  • Синтаксис GRANT и REVOKE

Если произошла утечка базы данных [edit]

Если база данных стала доступна общественности или третьим лицам то внесите следующие изменения в LocalSettings.php:

  1. Замените $wgDBpassword если произошла и его утечка
  2. Замените несколько букв в $wgSecretKey

Установка вручную [edit]

Если Вы используете установку через вэб-браузер Вы подвергаетесь потенциальной атаке кем-то другим так-же запустившим инсталлятор на Вашем сервера в период между тем как вы открыли на запись вашу директорию config и тем временем когда файл LocalSettings.php был записан.

Usually this should not be a very large risk, but if it's unacceptable to you (or if you need to do a batch install of many wikis), consider doing an installation manually:

  • Create a database
  • Grant user permissions
  • Source maintenance/tables.sql to create the tables.
  • Create a LocalSettings.php based on a sample or the generation code in config/index.php, and AdminSettings.php based on AdminSettings.sample
  • cd maintenance && php update.php

If PHP is running as an Apache module, the LocalSettings.php generated by the web installer will usually be owned by the Apache user account. To ensure that it can't be changed again by another user (see notes above about multiuser systems) or by malicious code injected to a vulnerable web application, you should reassign it to another account. (If you have only limited access, consider copying instead of moving the file; the new copy will be under your other account.)

If LocalSettings.php has leaked [edit]

If LocalSettings.php has leaked to the public, reprotect it and:

  1. Change $wgDBpassword
  2. Change some letters in $wgSecretKey
  3. Possibly make a slightly different $wgSpamRegex

Database passwords [edit]

See Manual:Securing database passwords for some precautions you may wish to take to reduce the risk of MySQL or WikiSysop passwords being presented to the web.

Alternate file layout [edit]

MediaWiki is designed to run in-place after being extracted from the distribution archive, for ease of installation.

You can however manually consolidate or relocate various files, to avoid duplicates in a mass installation or to keep sensitive files out of the web root for safety.

(Moving the main includes and skin files may require carefully picking and choosing and altering the include_path set in your LocalSettings.php. Experiment with this as desired.)

Consider moving the database password or other potentially sensitive data from LocalSettings.php to another file located outside of the web document root, and include()ing that file from LocalSettings.php. This can help to ensure that your database password will not be compromised if a web server configuration error disables PHP execution and reveals the file's source text.

Similarly, editing LocalSettings.php with some text editors will leave a backup file in the same directory with an altered file extension, causing the copy to be served as plain text if someone requests, for example, LocalSettings.php~. If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.

User security [edit]

Anyone able to edit the user-interface system messages in the MediaWiki: namespace can introduce arbitrary HTML and JavaScript code into page output. This includes wiki users who have the editinterface permission, as well as anyone with direct write access to the text table in the database.

HTML is disabled on many system messages, particularly those displayed at the login screen, so the risk of password-snarfing JavaScript should be minimal. Malicious code could still attempt to exploit browser vulnerabilities (install spyware, etc), though, so, you should make sure that only trusted people can modify system messages.

Upload security [edit]

Here the question is, how to protect strangers from inserting garbage?

File uploads are an optional feature of MediaWiki and are disabled by default. If you enable them, you also need to provide a directory in the web root which is writable by the web server user.

This has several implications for security:

  • The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory (see multiuser notes above)
  • While PHP's configuration sets a filesize limit on individual uploads, MediaWiki doesn't set any limit on total uploads. A malicious (or overzealous) visitor could fill up a disk partition by shoving lots and lots of uploads at you.
  • Generated thumbnails and uploaded files held for overwrite confirmation may be kept in images/thumb and images/tmp without visible notice in the MediaWiki web interface. Keep an eye on their sizes as well.

The default configuration makes an attempt to limit the types of files which can be uploaded for safety:

  • By default, file extensions .png, .gif, .jpg, and .jpeg are whitelisted ($wgFileExtensions.
  • Various executable and script extensions are explicitly blacklisted ($wgFileBlacklist) even if you allow users to override the whitelist ($wgStrictFileExtensions).
  • Several known image file extensions have their types verified using PHP's getimagesize function.
  • Uploaded files are checked to see if they could trip filetype detection bugs in Internet Explorer and Safari which might cause them to display as HTML.

In case these checks turn out to be insufficient, you can gain further protection by explicitly disabling server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (by default, images).

For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:

<Directory "/Library/MediaWiki/web/images">
   # Ignore .htaccess files
   AllowOverride None
 
   # Serve HTML as plaintext, don't execute SHTML
   AddType text/plain .html .htm .shtml
 
   # Don't run arbitrary PHP code.
   php_admin_flag engine off
 
   # If you've other scripting languages, disable them too.
</Directory>

Your exact configuration may vary. In particular, the use of PHP's safe mode or open_basedir options may complicate handling of uploads.

External programs [edit]

  • /usr/bin/diff3 may be executed for edit conflict merging.
  • If ImageMagick support for thumbnails or SVG images is enabled, convert may be run on uploaded files.
  • If enabled, the texvc math extension will call texvc executable, which calls latex, dvips, and convert (which calls gs).

See also [edit]

Язык: English  • Deutsch • Bahasa Indonesia • 日本語 • русский