NameOne: Акция для пользователей MediaWiki.ru - Регистрация доменов по доступным ценам. RU и РФ от 95 рублей! →
Не нашли ответа на свой вопрос? Посетите наш форум, там обязательно помогут.

Защита Mediawiki от вандалов и спамеров

При развитии сайта часто приходится наталкиваться с проблемами вандализма. Иногда задаёшься вопросом: неужели людям больше заняться нечем? Некоторых нарушителей спокойствия легко отшить, а вот некоторые, используя прокси-серверы, создают сущий кошмар для владельцев сайта.

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

Рекомендация

Защищайте важные станицы от изменений. Медиавики позволяет защитить страницы индивидуально.

Шаг первый: автоподтверждённые участники

В медиавики можно задавать интервал времени, по истечении которого участник будет считаться автоподтверждённым. Этот интервал задаётся в секундах с помощью настнойки $wgAutoConfirmAge:

$wgAutoConfirmAge = 3600*24*2; // 2 дня

Конкретное значение переменной конфигурации необходимо выбирать в зависимости от типа и назначения конкретного вики-сайта.

После этого необходимо запретить некоторые права в группе «Участники»(user). И назначить некоторые из этих запрещённых прав группе «Автоподтверждённые участники»(autoconfirmed).

Шаг второй: защитить пространства имён

Определить какие пространства имён должны быть защищены от незарегистрированных участников, пространства имён которые должны быть защищены от конкретной группы участников. И задать требуемые права на редактирование этих пространств имён.

Имеет смысл запретить незарегистрированным и неподтверждённым пользователям редактировать шаблоны, страницы справки и проекта().

Следущий пример демонстрирует создание двух новых прав(edit-userpages и edit-additional)[4] и использование одного существующего(autoconfirmed):

$wgAvailableRights[] = 'edit-userpages';
$wgAvailableRights[] = 'edit-additional';
$wgNamespaceProtection[NS_USER] = $wgNamespaceProtection[NS_USER_TALK] =
    array('edit-userpages');
 
$wgNamespaceProtection[NS_PROJECT]       = $wgNamespaceProtection[NS_TEMPLATE] =
    $wgNamespaceProtection[NS_HELP]      = array('edit-additional');
 
$wgNamespaceProtection[NS_FILE] = array('autoconfirmed');

После чего остаётся задать эти права необходимым группам.

Шаг третий: распределить права участников между группами

Распределение прав довольно трудоёмкая задача из-за большого числа существующих прав. При распределении прав главное не бояться создавать новые группы . Подходить к распределению прав следует индивидуально.

Для задания прав используется двумерный массив $wgGroupPermissions, где первый индекс — группа, а второй флаг разрешения. Например следующий код позволяет создать новую группу и задать ей право на блокировку базы данных:

$wgGroupPermissions['developer']['siteadmin'] = true;

А здесь — запретить участникам перемещать страницы:

$wgGroupPermissions['user']['move'] = false;

Шаг четвёртый: установить капчу

Капча (CAPTCHA) — это тест который, с большой долей вероятности, отличает человека от компьютерного бота.

Для защиты можно посоветовать дополнение медиавики — ConfirmEdit.

На мой взгляд интерес представляют следующие варианты реализации:

  • ReCaptcha — со всеми возможностями и недостатками, используемого при этом, сервиса google;
  • QuestyCaptcha — идеально подходит для тематических энциклопедий, в этом режиме пользователю задаётся вопрос, составленный владельцами сайта. Ещё одно его преимущество для русскоязычных проектов усложнение ответа на вопрос для вандалов, разговаривающих на другом языке;
  • FancyCaptcha — если есть возможность его настроить.

Шаг пятый: Установить защиту от спам-ботов

В этом может помочь дополнение SimpleAntiSpam.

Шаг шестой: использовать чёрные списки прокси-серверов

Для решения этого в медиавики есть встроенное решение:

$wgEnableDnsBlacklist = true;

И всё. Можно задать дополнительные DNSBL сервисы:

$wgDnsBlacklistUrls[] = 'opm.tornevall.org.';

Хотя сервис по умолчанию http.dnsbl.sorbs.net мне не очень понравился - мне не удалось найти прокси, которые он знал, поэтому лучше переопределить список DNSBL, где на первых местах будут сервисы, лучше осведомлённые о прокси-серверах:

$wgDnsBlacklistUrls = array( # ! переопределение
    'opm.tornevall.org.',
    'http.dnsbl.sorbs.net.',
    );

Однако встроенное решение мне очень не понравилось — я не нашел как можно заблокировать правку участникам из чёрного списка. Ещё один нелостаток встроенного решения - излишние запросы на DNSBL сервис, запросы посылаются, а результат ответа не учитывается. Поэтому я написал простое дополнение SpamDnsblAlternative которое работает с сервисами DNSBL когда встроенная работа с ними отключена. Для его работы достаточно двух строчек:

require_once( "$IP/extensions/SpamDnsblAlternative/SpamDnsblAlternative.php" );
$wgEnableDnsBlacklist = false;


Также желательно настроить настройки конфигурации $wgDnsBlacklistUrls и $wgProxyWhitelist.

Заключение

Эти несложные действия позволят значительно улучшить ситуацию с безопасностью на вики-сайте. Лучше сделать эти настройки когда есть свободное время, вместо того, чтобы производить из в спешке после атаки на сайт.