Брутфорсят админку WordPress

Судя по логам сервера, да и по новостям, бушует очередная эпидемия заражения сайтов на WordPress — причём, в этот раз брутфорсят админки. Что делать?

  • Всегда обновляйтесь. И движок и плагины, особенно кэширующие. Самые замечательные дыры обнаружены как раз во всех популярных кеширующих плагинах.
  • Перенесите wp-config.php на уровень выше из папки блога. WordPress его найдёт.
  • Установите плагин с капчей для входа в админку.
  • Если ваш хостинг поддерживает SSL (ну или у вас свой сервер) в файле wp-config.php определите константу «DEFINE (‘FORCE_SSL_ADMIN’, true);», таким образом, вход в админку будет защищён.
  • Если совсем включить параною, можно вынести все скрипты WordPress за пределы видимости из инета.
  • Избавьтесь от ненужных плагинов.
Брутфорсят админку WordPress

Проверочные списки

Для рутинных операций весьма полезно, кроме использования скриптов и планировщиков использовать проверочные списки. Всегда можно забыть какую-нибудь мелочь, а из-за этого результат окажется непредсказуемым. В итоге у меня скопилась целая библиотека из десятков списков. Например, некоторые действия для установки блога на wordpress:

  1. Зарегистрировать домен на reg.ru
  2. Установить WordPress
    1. Создать базу данных
    2. Скопировать файлы на хостинг
    3. Создать .httacess
    4. Создать robots.txt
    5. Установить права на каталоги
    6. Скопировать плагины
    7. Настроить WordPress
    8. Установить (сверстать) шаблон
    9. Перевести шаблон на русский язык
    10. Нарисовать favicon.ico
  3. Настроить трансляции
    1. RSS – FeedBurner
    2. LiveJournal
    3. Twitter
  4. Установить счётчики
    1. Яндекс.Метрика
    2. Google Analytics
    3. LiveInternet

Советую взять на вооружение, действительно экономит время.

Проверочные списки

Мультивордпрессинг

Условия задачи:

  • Создать несколько однотипных блогов.
  • Блоги должны поддерживать удалённую публикацию.

Решение:

От весьма заманчивой идеи расплодить на площадке MaxSite CMS пришлось отказаться сразу, из за отсутствия пока что в нём возможностей удалённой публикации. Точнее, она уже присутствует, но разработанная по стандартам автора и с его же собственным клиентом под Windows.

Следующим простым решением было расплодить WordPress. Так как одна из главнейших вещей, которую впитывает любой нормальный программист с первыми байтами — это повторное использование кода, от этой идеи тоже отказался. Представьте себе — тридцать инсталляций WP, следить за обновлениями каждой из них, править темы в разных каталогах, следить за обновлениями каждого плагина каждого блога. Всё это выльется в итоге к написанию автоматизированной системы обновления с общим усложнением всей системы в целом и недопустимыми затратами времени.

Таким образом я пришёл к Movable Type. Платформа написана на perl и является законодателем моды: именно в ней впервые появиласись технологии OpenID, Trackback и многие другие. Одно из главных преимуществ Movable Type — статическая публикация контента. То есть, страницы не генерируются для пользователя скриптами в момент обращения к серверу, а создаются как старые добрые html-файлы. Одна установка системы теоретически способна обслуживать тысячи блогов на разных доменах, поддоменах, подкаталогах — везде в пределах файловой системы сервера. Так как страницы будут статическими — Digg эффект сервер переживёт.

Из главного достоинства вытекают и главные недостатки. При публикации блога или полной перепубликации в случае смены дизайна вы будете обречены часами смотреть на сообщения вроде: «Публикация записи 2 из 7890».

Админка работает медленно. Крайне медленно. На виртуальном хостинге пользоваться оказалось крайне затруднительно. Сложности возникли и с комментариями – так как хостер не давал доступ к  httpd.conf, алиасы для скриптов прописать не удалось.

Стал экспериментировать с WordPress MU — многопользовательской редакцией. Проблем при установке возникло не меньше, чем с Movable Type. Дело в том, что MU расчитан на блоги либо в подкаталогах, либо в субдоменах. А вот с работой на отдельных доменах опять же возникает проблема. Найденные пути решения при помощи плагинов оказались не без проблем. Другое решение тоже предполагало правку httpd.conf…Финальное решение, как всегда, было простым и изящным.

Установить один раз обычный WordPress на один из доменов, а остальные домены сделать его алиасами. В конфиге изменить жёсткий префикс имён таблиц MySql c ‘wp_’ на динамический, создаваемый на основе $_SERVER[‘HTTP_HOST’]. Найденный кусок кода выглядел так:

$prefix = $_SERVER[«HTTP_HOST»];
$prefix = str_replace(«www.», «», $prefix);
$prefix = str_replace(«-«, «», $prefix);
$prefix = str_replace(«.», «», $prefix);
$table_prefix = $prefix.»_» ; //»wp_»;

Я только заменил str_replace на ereg_replace(“www\.|\-|\.”,””,$prefix).

В паранояльном варианте можно задавать префиксы вида md5($_SERVER[‘HTTP_HOST’].$salt) или вовсе по условиям.

Ещё одна подсказка. При интеграции существующего блога в эту сборку обязательно возникнут проблемы с доступом в админку. В этом случае переименуйте в таблице prefix_options название опции “wp_user_roles” на “prefix_user_roles”, и в таблице “prefix_usermeta” аналогичным образом переименуйте все опции, начинающиеся со старого префикса “wp_”.

Условия задачи:

Имеем один домен, на который установлен WordPress и несколько доменов-алиасов(синонимов) к нему. Ну например, domain.ru как основной домен и alias.ru как его алиас. Так вот, пройдя по ссылке http://domain.ru/wp-admin попадаем в админку первого блога. Соответственно, пройдя по ссылке http://alias.ru/wp-admin попадаем в админку второго блога? Ничего подобного, почему то мы вновь оказываемся в админке первого блога. Разобраться, в чём дело.

Решение:

Продолжить чтение «Мультивордпрессинг»

Мультивордпрессинг