Комментарии 11
А есть где-нить полная база с описанием всех возможных уязвимостей по движкам?
А если еще и с версиями движков и лекарством — то совсем хорошо.
И чтобы ломала проверяла автоматически. «Введите URL и нажмите ОК».))
Если на exploit-db еще не заходили — можете попробовать посмотреть там.
Софтинки способные ломать сайт по урлу врят-ли в паблике есть, иначе школота уже давно бы все сайты на cms-ках положили. А вот знать где соломки себе подстелить, даже чисто теоретически, без активных действий по защите, было-бы неплохо.
Apache, конечно, хорошо, но как мне кажется — практичнее закрывать всё же со стороны фронтенда (в виде nginx). Об этом накидал небольшую заметку (не вставил её текст прямо сюда по причине обновлений время от времени).
И по поводу robots.txt — приведу как альтернативу следующий пример (где и когда он был найден — история умалчивает):

Disallow: /*/wp-*
Disallow: /*/feed/*
Disallow: /*/*?s=*
Disallow: /*/*.js$
Disallow: /*/*.inc$
Disallow: /*/trackback/*
Disallow: /*/xmlrpc.php

User-agent: ia_archiver
Disallow: /
Собственно, если у вас php5-fpm+nginx, то как минимум:
  1. закрываем несчастный xmlrpc.php
  2. вешаем на wp-admin auth от nginx'а или делаем блог «только для себя»(чтобы не было других писателей)
  3. отключает autoindex для папок
  4. вводим фильтрацию args снова в nginx
  5. делаем фильтр для wp-login.php только для ввода пароля, чтобы смотреть защищенные статьи.


По пунктам:
1)
location ~* ^/(\.htaccess|xmlrpc\.php)$ {
 return 404;
}

2)
location ~* ^/wp-admin/(.*(?<!(\.php)))$ {
   auth_basic            "protected by password";
   auth_basic_user_file users/somefile;
   #еще параметры
}

и/или во втором случае
location ~* (/wp-admin/|/wp-config\.php|/wp-config-sample\.php|/wp-mail\.php|/wp-settings\.php|/wp-signup\.php|/wp-trackback\.php|/wp-activate\.php|/wp-links-opml\.php|/wp-load\.php|/wp-comments-post\.php|/wp-blog-header\.php|/wp-login\.php|/wp-includes/.*?\.php|/wp-content/.*?\.php) {
   auth_basic            "protected by password";
   auth_basic_user_file users/somefile;
   #еще параметры
}


3) autoindex off;

4)
if ($args ~* "(attachment_id|media_category|attachment_category|select|eval|duplicate|base64|substring|preg_replace|create_function)") {
   #действия;
}



5) символическая ссылка на wp-login.php. К примеру, как «wp-postpass.php».
location ~* (/wp-postpass\.php) {
   if ($args ~ "^action=postpass$") {
      set $wppostpass 1;
   }
   if ($wppostpass ~ 0) {
      return 403;
   }
   #еще параметры
}

В итоге люди смогут ввести пароль к публикации, да и только.

Я когда себе ставил, опубликовал на хабре свои шаги.
Против подбора пароля ботами в админку существует великолепный плагин Brute Force Login Protection, который банит IP через .htaccess после заданного количества неуспешных попыток входа.
И есть еще одна хорошая альтернатива. У популярного плагина Jetpack есть опция блокировать попытки несанкционированного входа (модуль называется Protect). Для этого используется единая база данных и нагрузка при попытке брут-форса плавно переходит на сервера Jetpack-а. В том же модуле можно и жестко прописать нужные IP-адреса в список разрешенных адресов. Активировал его несколько месяцев назад и на моем не слишком посещаемом проекте было за это время детектировано около 7.000 попыток несанкционированного входа.
Я еще wordfence плагин ставлю. Он каждый день сканирует сайт на вредоносный код и шлет на емейл если кто то пытается подобрать пароль или запустить известные уязвимости.
После предложенного

RewriteCond %{QUERY_STRING} GLOBALS (=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST (=|\[|\%[0-9A-Z]{0,2})


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