Определение безопасности блога - плагин WP Security Scan
Sunday, 22 Jun 08 в 0:14
Сегодня хочу поговорить о безопасности блогов на 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 адресов и рассылки.
- Категория: Плагины
Похожие по тематике посты:
Loading ...
Большое спасибо за ссылку, давно слышал, что есть плагин от защиты и проверки, но никак не мог найти, воспользуюсь!
Спасибо за обзор. Действительно очень интересный плагин - пробывал его ставить, у знал много нового о безопасности блога. Правда тогда не разобрался, как вручную сменить префиксы и как изменить юзера - так что спасибо за объяснения.
Пожалуйста, пользуйтесь на здоровье:) Чем больше безопасных блогов в рунете - тем лучше.
Очень хороший обзор, спасибо. Ты мне открыл глаза на безопасность блогов)
[...] Читать [...]
пожалуй самый полный и четкий обхор по безопасности 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, теперь все более-менее прояснилось. В принципе, я и не сомневался, что версию админки можно как-то узнать. Знаешь, мне почему-то кажется, что если человек “захочет сломать”, то ему это будет абсолютно все равно. И никакие способы выше не помогут. Я это прекрасно осознаю.
Но есть тысячи любителей что-то “поковырять” и “попробовать свои силы” - именно от таких базовый набор будет весьма кстати.
Кстати, можно ведь автору блога письмо написать и придумать какую-то фиктивную историю с целью узнать версию админки. Если блоггер общительный и социальной активный - он ответит. Вот я бы ответил, например :)
[...] том, как обезопасить блог, почитайте у Tod’а, а я расскажу о том, как узнать о взломе вашего сайта [...]
А у меня этот плагин работать не хочет. Активируется, а когда нажимаешь чтоб зайти во вкладку, редиректится на хостера.
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, выключает описание сервера,запрещает доступ к конфигам (например http://tods-blog.com.ua/wp-config.php),выключает индексирование директорий(например http://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. Но это уже совсем радикально…
ИМХО безлпасность нужно не с помощью плагина решать… Грамотно настроенный сервер + минимальный доступ + нестандартные названия.