Определение безопасности блога — плагин WP Security Scan
Сегодня хочу поговорить о безопасности блогов на WordPress и плагине, который делает ее более прочной. Это — WP Security Scan. Главной задачей модуля есть сканирование установленной версии системы и проверка ее на возможные прорехи в безопасности. После скана, плагин предлагает выполнить корректировку для уменьшения рисков взлома вашего сайта.
Чтобы установить модуль просто скопируйте его установочные файлы (целиком всю директорию wp-security-scan) туда, где располагаются остальные ваши плагины — wp-content/plugins/. После этого заходите в меню Plugins и активируете его — появится новый раздел Security.
Рассмотрим все нюансы безопасности, которые анализирует данный модуль.
Своевременное обновление. Запомните, установка последней версии системы — первый и самый основной ключ к обеспечению безопасной работы всего сайта. Разработчики постоянно трудятся над устранением багов и дыр, поэтому каждый новый релиз содержит исправления львиной доли прорех в защите. Последняя доступная на данный момент версия системы — WordPress 2.5.1. Обновитесь, кто еще не успел! Стыд мне и позор, но я принадлежу именно к таким людям, о чем свидетельствует предупреждение WP Security Scan.
Таблицы в базе данных. Все таблицы в базе данных имеют префикс wp_ — wp_comments, wp_posts и т.д. Дабы обезопасить себя от SQL инъекций лучше его сменить. Чем меньше злоумышленник знает о настройках вашей системы — тем сложнее ему будет навредить. Для данного дела в разделе Security имеется специальная закладка — Database.
Внимание! Перед сменой префикса очень рекомендуется сделать бэкап (резервную копию) базы. Для успешного завершение процесса требуется чтобы файл настроек wp-config.php имел права на запись, а пользователь БД — возможность выполнять команду ALTER.
Если все эти условия у вас выполняются, то в форме на странице указываем префикс, на который мы хотим заменить стандартный, и нажимаем кнопку Start Renaming.
Теперь, зайдя в phpmyadmin, вы обнаружите новые названия таблиц. Кстати, разработчики плагина говорят, что бывали случаи, когда WP Security Scan на срабатывал, поэтому в документации (на англ.) описаны действия для ручного изменения префикса.
Отображение версии системы. Опять же, меньше информации — лучше защита. Если злоумышленник узнает версию системы, то сможет понять какие прорехи у вас есть. Зачем давать каждому понять, что вы еще не обновились. Версию системы убрать очень просто — в файле шаблона header.php (где содержится информация из блока HEAD) убираем META тэг generator или указываем в нем, например, номер последней версии.
Другие. К сожалению, не совсем понял на что влияют указанные элементы защиты «WordPress DB Errors turned off.» и «WP ID META tag removed form WordPress core» — у меня они сразу были «в норме». Первый параметр WordPress DB Errors по идее можно поискать в настройках системы (Options), а второй в исходном коде.
Имя пользователя. По умолчанию имя пользователя устанавливается в Admin. Если рассуждать логически, то это просто громадный «подарок» для злоумышленника — ему не придется тратить время на подбор логина, останется разузнать только пароль. Для изменения пароля потребуется какой-то инструмент для работы с MySQL на вашем сервере, скорее всего это будет phpmyadmin. Итак, заходите в базу данных, открываете таблицу wp_users (или подобную ей, если вы уже сменили префикс), находите запись admin в поле (колонке) user_login. Изменяете его значение и сохраняете новое.
Защита директории wp-admin. С помощью .htaccess файла можно запретить вход в админку всем неизвестным ip адресам, чтобы заходить могли только вы со своего домашнего и (или) рабочего компьютера. Считаю, это действительно очень хороший способ себя обезопасить, дабы ни у кого и в мыслях не было угадывать пароли. Чтобы реализовать данный метод создаете файл .htaccess, где пишете следующий текст:
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName «Access Control»
AuthType Basic
order deny,allow
deny from all
allow from 91.250.120.20
В принципе, можно работать и без первых 4-х строк, но в некоторых примерах видел именно такую комбинацию. Что конкретно означают эти команды не разбирался, но информацию о них в Интернете я встречал. Строка deny from all запрещает любой доступ к директории wp-admin, а следующая как бы задает исключение для вашего ip адреса. Кстати, если у вас динамический айпишник, то запись в примере выглядела бы так:
allow from 91.250.120. (в конце строки должна быть точка, что символизирует «пустой» последний параметр).
После создания файла не забудьте записать его на фтп в директорию wp-admin!
Кроме того, в плагине WP Security Scan есть еще 2 опции: сканер и механизм проверки прочности паролей. Находятся они в соответствующих пунктах меню раздела Security. Если по второму пункту все понятно, то скажу немного слов о сканере. Он проверяет права пользователя, установленные на разные директории вашего сайта, и сравнивает их с требуемыми значениями. Когда все ок, то получится такая приятная картинка:
На достигнутом разработчики не останавливаются, и уже в следующих версиях плагина планируют добавить ряд нововведений, среди которых: изменение прав файлов/директорий одним кликом, тест на XSS уязвимость, отслеживание неверных попыток входа в систему, проверка .htaccess файла и многое другое.
В общем, плагин мне здоров пригодился, я практически могу спать спокойно. В принципе, после прочтения этой статьи можно его и не устанавливать, все основные моменты я рассмотрел, а также привел способы нейтрализации прорех безопасности. Советую использовать вместе все пункты, описанные выше — это сведет риск взлома блога к минимуму.
P.S. Открыл для себя еще одну систему продажи ссылок на сайтах — Setlinks. С сапой тягаться, конечно, пока рано, по попробовать поработать с ней будет интересно. Пользователей, кстати, там 23 тыс.
При поддержке:
- Социальная сеть для блоггеров — стань заметнее!
- Софт для сбора email адресов и рассылки.
Большое спасибо за ссылку, давно слышал, что есть плагин от защиты и проверки, но никак не мог найти, воспользуюсь!
Спасибо за обзор. Действительно очень интересный плагин — пробывал его ставить, у знал много нового о безопасности блога. Правда тогда не разобрался, как вручную сменить префиксы и как изменить юзера — так что спасибо за объяснения.
Пожалуйста, пользуйтесь на здоровье:) Чем больше безопасных блогов в рунете — тем лучше.
Очень хороший обзор, спасибо. Ты мне открыл глаза на безопасность блогов)
пожалуй самый полный и четкий обхор по безопасности WP в рунете, который я видел.
Спасибо, Евгений, я старался. Написал по сути то, как я для себя проверял безопасность. Практические рассуждения всегда более наглядны.
Очень и очень полезная информация. Спасибо.
про префикс в самую точку. чем больше нестандартностей, тем больше проблем
интересно, хотя и немного стрёмно копатсьяя в базах, можно испортить по глупости.
vVv, делай бэкап и ничего стремного не будет)
Во-первых, с 2.5 такое не проходит — meta name=»generator» добавляется хуком.
Во-вторых, существует очень много способов узнать версию WordPress косвенно — например, по версии JavaScript редактора TinyMCE.
Кстати, если у админа кривые руки, смена префикса не спасёт — если спровоцировать ошибку в запросе (см. ссылку выше), получишь всю необходимую информацию.
А в версиях, начиная с 2.5(?), в wp-config.php есть такой параметр, называется SECRET_KEY — не поверите, но на 90% блогов он одинаков. По сути дела, это означает, что SECRET_KEY не используется. Зная статистические характеристики псевдослучайного генератора (который Mersenne Twister), можно успешно ломать пароли, сгенерированные wp_generate_password().
Счастливый Вы человек… От себя добавлю, что основные дыры в безопасности — это сторонние плагины, а не WordPress… Отсюда делайте выводы, что нужно сканировать :-)
Vladimir, спасибо за такой развернутый комментарий! Я обязательно ознакомлюсь с вашими замечаниями и дополню пост соответствующей информацией!
По сторонним плагинам — на все 100% согласен, поэтому стараюсь использовать их по минимуму.
Ребят, а у меня такой вопрос — не проще ли использовать «чистый» ВП? Зачем заморочки ненужные, разве не хватает функционала? Лично я пользую чистяк и не парюсь.
Не совсем понятно что такое «чистый ВП», расшифруй:)
вот какие ошибки вызвал у меня этот плагин, хотя другие активируются без проблем.
Warning: main(/home/httpd/vhosts/site.ru/httpdocs/wp-content/plugins/wp-security-scan/support.php) [function.main]: failed to open stream: No such file or directory in /home/httpd/vhosts/dewux.ru/httpdocs/wp-content/plugins/wp-security-scan-ru/securityscan.php on line 10
Fatal error: main() [function.require]: Failed opening required ‘/home/httpd/vhosts/site.ru/httpdocs/wp-content/plugins/wp-security-scan/support.php’ (include_path=’.:/usr/share/pear’) in /home/httpd/vhosts/dewux.ru/httpdocs/wp-content/plugins/wp-security-scan-ru/securityscan.php on line 10
выставлял права на паку и на указанные файлы 777 и 666 — не помогло
statistic, плагин недавно обновился до версии 2.3 — ты использовал ее? И еще интересно узнать какая у тебя версия WordPress. В любом случае можешь следовать рекомендациям, описанным в посте. Я рассмотрел большую часть требуемых для проверки нюансов.
Версия WP 2.51, а версия плагина 2.2.64, щас поставил версию 2.3., спасибо за подсказку, — всё заработало, удачи!
Vladimir, как и обещал, глянул ваш комментарий более подробно. За ссылку на пост с удалением 13 ненужных тэгов спасибо, только вот узнать косвенно версию WordPress это не поможет. Возможно, вы просто ошиблись ссылкой:)
Кстати, META тэг generator в версии 2.5.1 получилось убрать простым удалением из темы.
Tod, я не ошибся, и ссылка была не столько на пост, сколько на комментарии к нему (признаю, возможно, это было не очень очевидно).
Напишу тогда здесь.
Во-первых, посмотрите исходник wp-login.php. Вы поменяли версию в прилинкованых таблицах стилей (?ver=abc), но не все это делают. Кстати, ссылаться на CSS из wp-admin не очень хорошо, если Вы планируете защищать директорию wp-admin .htaccess.
Во-вторых, обратите внимание на wp-includes/js/tinymce/utils/validate.js. Там стоит ревизия и дата. В 2.3 она одна ($Id: validate.js 162 2007-01-03 16:16:52Z spocke $), в 2.5 — другая ($Id: validate.js 673 2008-03-06 13:26:20Z spocke $). Аналогично определяется версия WP по версии TinyMCE. Или по другим библиотекам JavaScript.
В-третьих, в ветке 2.3 (если кэширование включено) присутствует файл wp-content/cache/wp_object_cache.lock (если CACHE_DIR не переопределён).
В-четвёртых, если у пользователя есть возможность зарегистрироваться, то отличить 2.5 от 2.5.1 можно при попытке сбросить пароль (у 2.5.1 есть баг).
В-пятых, на ветку 2.3 есть жесткий тест: http://www.problogdesign.com/?feed=rss2&p=1/**/union/**/select/**/username,2/**/from/**/wpbbd_users/* (раньше работало, сейчас нет — товарищ обновился). Но по XML видно, что версия 2.5.1.
Еще очень рекомендую статью http://www.problogdesign.com/wordpress/should-you-upgrade-wordpress/ и комментарии к ней — зная уязвимости ветки 2.3, можно сказать, какая версия блога стоит. Но это тема для отдельной дискуссии.
В конце концов, версию ВП можно определить по версиям плагинов.
Идея, думаю, понятна.
Vladimir, теперь все более-менее прояснилось. В принципе, я и не сомневался, что версию админки можно как-то узнать. Знаешь, мне почему-то кажется, что если человек «захочет сломать», то ему это будет абсолютно все равно. И никакие способы выше не помогут. Я это прекрасно осознаю.
Но есть тысячи любителей что-то «поковырять» и «попробовать свои силы» — именно от таких базовый набор будет весьма кстати.
Кстати, можно ведь автору блога письмо написать и придумать какую-то фиктивную историю с целью узнать версию админки. Если блоггер общительный и социальной активный — он ответит. Вот я бы ответил, например :)
А у меня этот плагин работать не хочет. Активируется, а когда нажимаешь чтоб зайти во вкладку, редиректится на хостера.
Flash`er, я с таким не сталкивался, проверь какие у тебя версии WordPress и плагина, возможно из-за несовместимости закрался глюк.
Спасибо.. щас воткну .. проверюсь на баги )
Ко всему вышесказаному остается только добавить для корневого .htaccess
<files .htaccess>
order allow,deny
deny from all
</files>
ServerSignature Off
<FilesMatch ^wp-config.php$>
order allow,deny
deny from all
</FilesMatch>
Options All -Indexes
и .htaccess для wp-content и wp-include
Order Allow,Deny
Deny from all
<Files ~ ".(css|jpe?g|png|gif|js|swf)$">
Allow from all
</Files>
Аким, вставить код не так просто:) Поэтому первый раз не получилось. Спасибо за совет, остается только разобраться что это все выполняет.
первая вставка: запрещает доступ к .htaccess, выключает описание сервера,запрещает доступ к конфигам (например https://tods-blog.com.ua/wp-config.php),выключает индексирование директорий(например https://tods-blog.com.ua/wp-includes/)
вторая, чтение из каталогов всяких файлов кроме, выше перечисленных(надо быть внимательным к attach’ам других типов, если что и их добавить)
Хм, очень интересно! Спасибо за столь подробное объяснение!
Возможно, надумаю написать пост о htaccess, обязательно добавлю твои пояснения со ссылкой на автора. Думаю, читателям это будет интересно. В общем, поставил тему поста в очередь, надеюсь найду время чтобы до нее дойти.
Дефолтный конфиг Апача и так не даст доступа к .htaccess/.htpasswd (конечно, если администратор догадался не удалять те строки)
Вряд ли кому сильно поможет — сканирование на уязвимости проводится автоматом, и если версия апача дырявая, то сканер это поймет и без знания строки идентификации.
Меня всегда это умиляло… Аким, а в чем глубокий философский смысл? По HTTP-запросу код wp-config.php все равно не увидеть, а от запроса через файловую систему никакой .htaccess не спасет.
Осторожнее с wp-content. Такой вот конфиг совместим далеко не со всеми плагинами. И с темами… Особенно с теми, которые отдают CSS/JS через PHP
Не лучше ли не извращаться с Apache, а сразу поставить нормальные права доступа к файлам и каталогам?
2Vladimir
Эти .htaccess в той или иной версии переношу с одного сайта на сайт уже несколько лет. Разбирать что на новом хостинге админы пишут/меняют в настройках к апачу, как обновляют php желание возникает не часто, а как говорится: береженого бог бережет.
Это понятно, но от чего конкретно бережет?
На мой взгляд, польза от этих правил минимальна, а Апач тратит время на обработку .htaccess при каждом запросе (причем при запросе к wp-content/plugins Апач сделает три запроса: к wp-content/plugins/.htaccess, wp-content/.htaccess и .htaccess).
Вменяемые админы :-) ни за что не разрешат доступ к .ht(access|passwd).
Если же они это разрешают, то есть серьезный повод сменить хостинг, ибо в этом случае вполне возможны и более серьезные проблемы.
2Vladimir
Конкретно, один раз уберегло от обновления mod_php когда конфиги *.php3 неожиданно стали отдаваться в plain text (правда это было не с WP).
А еще один мой знакомый маскировал Apache под IIS. Но это уже совсем радикально…
ИМХО безлпасность нужно не с помощью плагина решать… Грамотно настроенный сервер + минимальный доступ + нестандартные названия.
Скажите пожалуйста, почему после успешного изменения префикса, вместо админки получил сообщение: «У вас недостаточно полномочий для доступа к этой странице»?!
Автору — WordPress DB Errors turned off. — это значит отключены сообщения об ошибках.
Тоже после изменения префикса вместо админки ошибку 500 выдает. Как вылечить?
А обязателльно ставить права доступа на папки, которые рекомендует этот плагин?
Вадим, думаю, не обязательно, если знаешь какие где права установлены и что они значат, то есть, например, иногда плагины для wp-config просят поставить права 777 (для записи в директорию) чтобы добавить туда свои файлы. Иногда пользователи забывают вернуть в 755 — бац и плагин это подсказывает. В 99% случаев ничего страшного, по идее, не случится, если будет 777.
Подскажите. что нужно сделать.Я установила этот плагин и активировала.Потом зашла в панель просмотреть.Решила пока ничего не настраивать, еще познакомится с этим плагином.Вернуться в плагины не смогла, сайт просто исчез.Почему и что делать дальше не знаю.
Ирина, странно, так как плагин использовал многократно и проблем с ним не было. Если вы точно уверены, что проблема в нем, то можете зайти на ФТП сайта где в директории wp-content/plugins/ удалить его файлы. После этого фактически плагин будет удален. Можно просто поменять название директории (папки) плагина и он автоматически деактивируется.
огромное спасибо автору, я очень беспокоился за безопасность и даже хотел заплатить за эту услугу (но писец как дорогая)cqr.com.ua/audit-bezopasnosti.html а пос ути мне наверное сделают всю работу этим плагином да еще и бабосов срубят бешеных с меня))))) спасибо аффтор!!!!!!!!!!!!!!!!
вопрос: если у меня динамичный айпишник но он меняет не последнюю цыфру а последние 4 цыфры. как поступить в ограничении по ай пи в файле .htaccess???)заранее спасибо.
Богдан, там, конечно, дороговато, но они делают комплексный анализ по всем нюансам — но это актуально только для больших, серьезных проектов/порталов, для обычного блога заказывать нет смысла — регулярное обновление вордпресс и плагинов + использование проверенных модулей защитит на 90%.
По поводу динамического айпишника — указываете в правиле все то, что не меняется, например, можно попробовать использовать только первых 2 числа (после которых ставить точку и все)
allow from 91.250.
а как считаете, если я буду вести блог (не соц.сеть и не портал) но посещаемость будет все равно высока — 14 — 15 тысяч. мне может понадобиться эта услуга аудита безопасности?? или эта услуга нужна только там где есть возможность регистрации и тд, то есть порталы , соц.сети?
просто я хочу понять что подразумеваеться под словами «серьезный проект и портал» . я ведь могу быть блоггером и у меня будет не меньше посещаемость чем у любого»портала-форума»))))
Богдан, блог с 14-15тыс посещениями в день? Ну тогда вы можете предложить им потестировать безопасность в обмен на обзор — думаю такая аудитория их заинтересует. Но звучит это куда проще чем получится реализовать… Исходя из этого о такой глобальной безопасности можно подумать потом, для начала базовой осторожности в вордпресс, о которой я говорил выше, достаточно.
ок, а как вы считаете их услуги и действия буду существенно отличаться от тех которые могут быть проведены мною с помощью плагинов типо wp scan security и базовых знаний о защите вордпресса?? ну то есть их услуга это более мощный и новый этап тестирования и защиты?? я просто плохо разбираюсь в терминологии — в описании))))
не хочеться платить за то что и так сделано мною ранее в плане защиты блога))))
Богдан, у них большего всего, там комплексный анализ, но заказывать его я не вижу смысла.
хорошо. спасибо)) то есть хватит и базовой защиты для блога)))