Домены

Шпаргалки для блогера ► Шаг 27-й. Плагин WebsiteDefender WordPress Security

плагин WebsiteDefender WordPress Security

Сегодня мы на помощь призовем славного рыцаря, который будет стоять на страже нашего блога, плагин-помощник называется WebsiteDefender WordPress Security.

Установка плагина WebsiteDefender WordPress Security

Установка стандартная, вписываем в строку поиска название плагина WebsiteDefender WordPress Securit, находим его, устанавливаем, активируем.

Плагин WebsiteDefender WordPress Security, установка плагина

Плагин появится в меню под вкладкой «Параметры»:

Плагин WebsiteDefender WordPress Security в админке блога

Настройка плагина WebsiteDefender WordPress Security

К сожалению, плагин на английском, в котором я ни в зуб ногой. Но это не повод отказываться от нашего защитника, так что давайте разбираться:

Плагин WebsiteDefender WordPress Security, настройка плагина

1. You have the latest version of Wordpress.

Зеленая галка говорит о том, что тут все ОК — у нас стоит самая последняя версия Вордпресса.

2. Your database prefix should not be.

В этом пункте у нас непорядок —  база данных не должна содержать префикс wp_. Такой префикс выставляется по умолчанию, так же как и логин admin. Надо будет исправить.

3. The WordPress version is hidden for all users but administrators.

Версия Wordpress спрятана от всех потребителей, кроме администратора. Давайте проверим, так ли это?

Если помните, во вчерашней шпаргалке я как раз показывала, что версию Вордпресса спокойно можно узнать в исходном коде, достаточно нажать горячие клавиши Ctrl+U:

горячие клавиши Ctrl+U, версия вордпресса в исходном коде

версию вордпресса видно в исходном коде, горячие клавиши Ctrl+U

Посмотрим снова исходный код, который после установки плагина должен измениться. Нажимаем на Ctrl+U и всё ОК!

Тэга <meta name='generator"> нет и в помине, как нет и других подсказок: плагин убрал версию WordPress из URL-адресов скриптов и таблиц стилей.

4. Database errors are not displayed.

База данных не отображена. Тут я что-то не поняла, где она не отображена, но коль стоит зеленая галка, значит, все в порядке.

5. PHP errors are not displayed.

Ошибки не отображены.

6. Startup errors are not displayed. ОК

7. User admin was not found. ОК

8. The .htaccess file was not found in the wp-admin directory.

А вот тут не ОК — нас предупреждают, что в директории wp-admin нет файла .htaccess. Проверяем. Заходим в админку хостинка и проходим в файловый менеджер. Если забыли, как это делается, заглядываем в шпаргалку №6:

админка хостинга, панель хостинга

Находим директорию wp-admin и видим, что и на самом деле там нет файла .htaccess:

htaccess, директория wp-admin

Добавлять пока не будем, посмотрим, какие еще ошибки нашел плагин WebsiteDefender WordPress Security.

9. Your currently used User to access the WordPress Database holds too many rights. We suggest that you limit his rights or to use another User with more limited rights instead, to increase your website's Security.

Здесь нам говорят, что пользователь, под именем которого вы вошли, имеет слишком много прав и предлагают их ограничить.

Если честно, то с этим пунктом я не разобралась. Возможно, плагин насторожило то, что мы убрали стандартного админа и поставили нового с правами администратора? Ну а кому такие права еще давать, как не себе?

10.  The index.php file was found in the wp-content directory. The index.php file was found in the plugins directory. The index.php file was found in the themes directory.

Эти три пункта одинаковые, плагин говорит, что индексный файл (index.php) обнаружен в директориях и это хорошо.

11. The index.php file was not found in the uploads directory! You should create one in order to prevent directory listings.

А вот в директории загрузок (uploads) файла index.php нет и нам нужно исправить эту ошибку. Но сначала посмотрим, действительно его там нет?

uploads, директория uploads

Не соврал, пусто. Надо будет исправить этот недочет.

12. The readme.html file was not found in the root directory!

Файл readme.htm в корневой директории не обнаружен! И это правильно! Плагин нас похвалил и тем самым поддержал в споре с оппонентами, которые говорили, мол, зачем удалять этот файл.

А дальше плагин наши косяки и ошибки выводит в виде таблицы, чтобы понятней и наглядней было:

WebsiteDefender_WordPress_Security4, ошибки в блоге

Как исправить ошибки?

С анализом разобрались. Вопрос — как исправлять будем? Самим придется мозгами шевелить или плагин нам поможет?

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

Сам он только версию движка изменил, все остальное придется делать ручками. Поэтому я перехожу на следующую вкладку, которая называется «Database», ввожу в графу новый префикс (помните, нам сделали замечание, что он не должен быть wp_?), щелкаю на кнопку «Изменить» и... меня перебросило на главную страницу 🙁

Не знаете почему? А я знаю! Потому что у нас стоит плагин Wordpress Firewall 2, который пресекает подобные попытки, в том числе и со стороны администратора. Тут он, конечно, палку перегнул, но придется смириться и прежде, чем вносить какие-то изменения, нам нужно плагин WordPress Firewall 2 деактивировать.

Теперь можно исправлять наши ошибки:

  • Нужно исправить префикс wp_;
  • В директорию wp-admin добавить файл .htaccess;
  • В директорию uploads добавить файл index.php;
  • Изменить права доступа в файле .htaccess на 640;
  • Изменить такие же права в файле, который лежит в директории wp-admin/.htaccess;
  • Изменить права доступа в файте wp-config.php на 644.

Поехали!

1. Заходим во вкладку "Database", вписываем другой префикс, нажимаем на кнопку «Start»:

WebsiteDefender_WordPress_Security, вкладка Database

2. Заходим в файловый менеджер, копируем файл .htaccess из корневой директории и вставляем в папку wp-admin.

3. Точно также поступаем с индексным файлом -   index.php копируем из корневой директории и вставляем копию в директорию uploads.

4. В корневой директории находим файл .htaccess, щелкаем по нему правой кнопкой и в открывшемся меню ищем пункт «Изменить атрибуты»:

WebsiteDefender_WordPress_Security, файл .htaccess, изменить права доступа

В новом окне меняем цифры 644 на 640:

атрибуты файла

После этого в корневой директории вы увидите внесенные изменения:

корневая директория, атрибуты изменены

5. Точно так же меняем права аналогичного файла, который мы разместили в директории wp-admin/.htacces.s

6. Находим в корневой директории файл wp-config.php и меняем в нем права 666 на 644.

После редактирования обновляем страницу и видим, что у нас осталась одна ошибка — слишком много прав имеет администратор, то есть я. Но ее исправлять не буду, ибо сама себя лишать каких-то прав не намерена.

Вот в принципе и все. Не забудьте только заново активировать плагин Wordpress Firewall 2.

Что делать с плагином Limit Login Attempts?

Среди прочего наш защитник WebsiteDefender WordPress Security убирает подсказки со страницы входа, которые есть в Вордпрессе.

Помните, когда у нас еще не стояли плагины, WordPress при входе все время спрашивал, что мы неправильно ввели — логин или пароль. Его услужливость нам нужна? Нет. Поэтому мы защитили вход с помощью плагина  Limit Login Attempts.

После того, как сегодня установили WebsiteDefender WordPress Security, у нас получилось, что два плагина выполняют похожие функции.

Что делать будем? Удалим Limit Login Attempts или оставим?

Давайте сначала посмотрим, как эти два плагина уживаются друг с другом. Я не заметила, чтобы они конфликтовали, напротив, получается, что плагин WebsiteDefender WordPress Security корректирует недочеты плагина Limit Login Attempts.

Когда мы ограничили число попыток авторизации, то стало появляться такое сообщение:

вход в админку вордпресса

То есть взломщик знал — шансов у него осталось немного. Плагин WebsiteDefender WordPress Security таких подсказок не выдает, он показывает снова и снова одно и то же окно:

entry, вход в административную панель вордпресса

И тут взломщик вообще не поймет, что же он вводит неправильно — логин или пароль? Но долго гадать ему не придется, поскольку плагин Limit Login Attempts тоже без дела не сидит и после четырех (или сколько вы там поставили в настройках) попыток  возможность войти в админку будет перекрыта, неудачного взломщика перебросит на страницу с ошибкой 400:

400_Bad_Request, ошибка 400

Это уже подключился наш славный рыцарь — WebsiteDefender WordPress Security. В отличие от Limit Login Attempts он не церемонится — получи ошибку 400 и гадай, что случилось.

А вот плагин Limit Login Attempts лояльный, вежливый, на подсказки не скупится, мол, вы ошиблись, зайдите, пожалуйста, через 20 минут и можете продолжать свое грязное дело:

ошибка при входе в административную панель вордпресса

Что делать будем? Я предлагаю пока не спешить с удалением. Позже, когда мы установим все плагины и проверим, кто какую нагрузку создает, нет ли конфликтов и так далее, мы можем что-то и убрать. А пока наша задача — тестировать,тестировать и еще раз тестировать.

Комплекс мер по безопасности блога:

  1. Убрать виджет «мета»;
  2. «Параметры» — «Общие» — «Членство» — убрать галку;
  3. Поменять стандартную учетную запись «admin»;
  4. Усложнить логин и пароль;
  5. Изменить URL админки;
  6. На хостинге в папках должен лежать пустой индексный файл - index.php. При попытке набрать адрес по маске - http://ВАШ ДОМЕН.ru/wp-content, http://ВАШ ДОМЕН.ru/wp-content/plugins должно открываться пустое окно или появляться ошибка (404 или 403), но ни в коем случае список папок.
  7. Скрыть версию WordPress;
  8. Удалить файлы readme.html и файл license.txt;
  9. Проверить тему на скрытые ссылки и вредоносные коды;
  10. Блокировать атаки;
  11. Регулярно обновлять движок (с версии 3.8.1 он будет сам обновляться), плагины и тему;
  12. Регулярно делать бэкап файлов и базы данных;
  13. Удалить все плагины и темы, которые не используете.

Кроме перечисленных способов, нужно еще запретить индексацию системных папок через robots.txt, но этим мы займемся чуть позже.

Выполнить комплекс мер по безопасности блога вам помогут плагины:

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

Какие еще плагины можно посмотреть:

  • Better WP Security;
  • WP Ban;
  • Exploit Scanner;
  • Chap Secure Login plugin;
  • Acunetix WP Security;
  • Anti-XSS attack;
  • Belavir;
  • WordPress File Monitor

А какие меры безопасности используете вы на своих блогах? Поделитесь, возможно, я что-то и упустила из виду.

Всем удачи и хорошего трафика!
Елена Олейникова

 

 

Словарь блогера

Анализ сайта — комплекс мероприятий, позволяющий выявить проблемные места с точки зрения поисковой оптимизации.

Блог (англ. blog, от web log) — интернет-дневник или онлайн-дневник. Основное содержимое такого веб-сайта — регулярно добавляемые записи, содержащие текст, изображения или мультимедиа.

Блогер (блоггер) — автор блога (интернет-дневника, онлайн-дневника).

WordPress — система управления содержимым сайта (CMS или движок) с открытым исходным кодом.

Школа блогера: подписаться на рассылку

Домен и хостинг для блога

Домены
 
Поделись ссылкой, добавь в закладки:

Мои комментаторы 6 комментариев

Мои комментаторы

Они уже здесь общаются, присоединяйтесь и вы! И друзей своих зовите!

Есть вопросы? Задавайте!

ДОБРО ПОЖАЛОВАТЬ!

Елена Олейникова - автор Школы блогера

RSS-подписка
RSS-лента Школы блогера

Введите ваш адрес электронной почты:

ВСЁ для БЛОГЕРА

Анализ блога

Проверка Траста

Домен для блога

Регистрируй домен и зарабатывай
Наш адрес не дом и не улица...
Домен на 50 процентов дешевле
Бегет: как изменить домен?
Домен для блога

Регистратор доменов

Хостинг для блога

Фото для блога

Depositphotos

Книжная полка

CMS WordPress
ВЕК ЖИВИ — ВЕК УЧИ:
СОФТ для БЛОГЕРА

Купить The Bat

Фотошоп-онлайн
Транслитераторы
Клавиатурные тренажеры
 
софт в Allsoft.ru
поиск программ
 
СТАТИСТИКА